Jul 03 2015
Jul 03
Last week, at the amazing Drupal North regional conference, I gave a talk on Backdrop: an alternative fork of Drupal. The slides from the talk are attached below, in PDF format.
Jul 03 2015
Jul 03
Last week, at the amazing Drupal North regional conference, I gave a talk on Backdrop: an alternative fork of Drupal. The slides from the talk are attached below, in PDF format.
Mar 04 2015
Mar 04

I have been thinking awhile about why the Backdrop fork bothers me so much. At first I thought it would just be the fact that it will be splitting the community some or taking resources away from the Drupal project. But lots of projects I have worked with have been forked in the past, and it is almost aways a good thing, so why would this be different?

Thinking about it more, it dawned on me that Backdrop is the easy way out. People can put all sorts of spin on it, but at the end of the day Backdrop is going to cater to developers who don’t want to learn the new development methods in Drupal 8. I understand that mentality, why learn something new when what you know has served you so well for so long. If you jumped on Drupal at version 5, you have had 8 years where you can build awesome web sites and just learn how to develop things the Drupal way.

The thing is, lots has changed in the last 8 years outside of Drupal. I personally think Drupal 8 is a great thing. It is bringing more modern development practices, like object-oriented programming and test-driven development, into the project. It is also doing this by not reinventing the wheel, but by using an established framework in Symfony These are all really good things, not only for the project, but for Drupal developers as well.

Right now, a Drupal developer who just knows Drupal 7 or earlier has limited job opportunities outside of the Drupal community. If they have not kept up on things like MVC frameworks or how to write tests for code, they are behind a lot of other developers. 1

Letting developers live in this world longer, Backdrop does a disservice by having their skills fall further and further behind. I realize, no one is making anyone use Backdrop but by advertising it as “the comprehensive CMS for small to medium sized businesses and non-profits” and talking about how it is easy to convert from Drupal 7, I feel it is making it too easy to suck developers in without thinking about the potential consequences to their careers.

  1. This is just for back-end development, not front-end coding but some of this applies there too ?
Feb 26 2015
Feb 26

This is the third in a series of blog posts about the relationship between Drupal and Backdrop CMS, a recently-released fork of Drupal. The goal of the series is to explain how a module (or theme) developer can take a Drupal project they currently maintain and support it for Backdrop as well, while keeping duplicate work to a minimum.

  • In part 1, I introduced the series and showed how for some modules, the exact same code can be used with both Drupal and Backdrop.
  • In part 2, I showed what to do when you want to port a Drupal module to a separate Backdrop version and get it up and running on GitHub.
  • In part 3 (this post), I'll wrap up the series by explaining how to link the Backdrop module to the Drupal.org version and maintain them simultaneously.

Linking the Backdrop Module to the Drupal.org Version and Maintaining Them Simultaneously

In part 2 I took a small Drupal module that I maintain (User Cancel Password Confirm) and ported it to Backdrop. In the end, I wound up with two codebases for the same module, one on Drupal.org for Drupal 7, and one on GitHub for Backdrop.

However, the two codebases are extremely similar. When I fix a bug or add a feature to the Drupal 7 version, it's very likely that I'll want to make the exact same change (or at least an extremely similar one) to the Backdrop version. Wouldn't it be nice if there were a way to pull in changes automatically without having to do everything twice manually?

If you're a fairly experienced Git user, you might already know that the answer is "yes". But if you're not, the process isn't necessarily straightforward, so I'm going to document it step by step here.

Overall, what we're doing is simply taking advantage of the fact that when we imported the Drupal.org repository into GitHub in part 2, we pulled in the entire history of the repository, including all of the Drupal commits. Because our Backdrop repository knows about these existing commits, it can also figure out what's different and pull in the new ones when we ask it to.

In what follows, I'm assuming a workflow where changes are made to the Drupal.org version of the module and pulled into Backdrop later. However, it should be relatively straightforward to reverse these instructions to do it the other way around (or even possible, but perhaps less straightforward, to have a setup where you can do it in either direction).

  1. To start off, we need to make our local clone of the Backdrop repository know about the Drupal.org repository. (A local clone is obtained simply by getting the "clone URL" from the GitHub project page and copying it locally, for example with the command shown below.)
    git clone [email protected]:backdrop-contrib/user_cancel_password_confirm.git
    

    First let's check what remote repositories it knows about already:

    $ git remote -v
    origin    [email protected]:backdrop-contrib/user_cancel_password_confirm.git (fetch)
    origin    [email protected]:backdrop-contrib/user_cancel_password_confirm.git (push)
    

    No surprise there; it knows about the GitHub version of the repository (the "origin" repository that it was cloned from).

    Let's add the Drupal.org repository to this list and check again:

    $ git remote add drupal http://git.drupal.org/project/user_cancel_password_confirm.git
    $ git remote -v
    drupal    http://git.drupal.org/project/user_cancel_password_confirm.git (fetch)
    drupal    http://git.drupal.org/project/user_cancel_password_confirm.git (push)
    origin    [email protected]:backdrop-contrib/user_cancel_password_confirm.git (fetch)
    origin    [email protected]:backdrop-contrib/user_cancel_password_confirm.git (push)
    

    The URL I used here is the same one I used in part 2 to import the repository to GitHub (that is, it's the public-facing Git URL of my project on Drupal.org, available from the "Version control" tab of the drupal.org project page, after unchecking the "Maintainer" checkbox - if it’s present - so that the public URL is displayed). I've also chosen to give this repository the name "drupal". (Usually the convention is to use "upstream" for something like this, but in GitHub-land "upstream" is often used in a slightly different context involving development forks of one GitHub repository to another. So for clarity, I'm using "drupal" here. You can use anything you want to.)

  2. Next let's pull in everything from the remote Drupal repository to our local machine:
    $ git fetch drupal
    remote: Counting objects: 4, done.
    remote: Compressing objects: 100% (2/2), done.
    remote: Total 3 (delta 0), reused 0 (delta 0)
    Unpacking objects: 100% (3/3), done.
    From http://git.drupal.org/project/user_cancel_password_confirm
    * [new branch]          7.x-1.x -> drupal/7.x-1.x
    * [new branch]          master  -> drupal/master
    * [new tag]             7.x-1.0-rc1 -> 7.x-1.0-rc1
    

    You can see it has all the branches and tags that were discussed in part 2 of this series. However, although I pulled the changes in, they are completely separate from my Backdrop code (the Backdrop code lives in "origin" and the Drupal code lives in "drupal").

    If you want to see a record of all changes that were made to port the module to Backdrop at this point, you could run git diff drupal/7.x-1.x..origin/1.x-1.x to examine them.

  3. Now let's fix a bug on the Drupal.org version of the module. I decided to do a simple documentation fix: Fix documentation of form API functions to match coding standards

    I made the code changes on my local checkout of the Drupal version of the module (which I keep in a separate location on my local machine, specifically inside the sites/all/modules directory of a copy of Drupal so I can test any changes there), then committed and pushed them to Drupal.org as normal.

  4. Back in my Backdrop environment, I can pull those changes in to the "drupal" remote and examine them using git log:
    $ git fetch drupal
    remote: Counting objects: 5, done.
    remote: Compressing objects: 100% (3/3), done.
    remote: Total 3 (delta 2), reused 0 (delta 0)
    Unpacking objects: 100% (3/3), done.
    From http://git.drupal.org/project/user_cancel_password_confirm
      7a70138..997d82d  7.x-1.x     -> drupal/7.x-1.x
    
    $ git log origin/1.x-1.x..drupal/7.x-1.x
    commit 997d82dce1a4269a9cee32d3f6b2ec2b90a80b33
    Author: David Rothstein 
    Date:   Tue Jan 27 13:30:00 2015 -0500
    
            Issue #2415223: Fix documentation of form API functions to match coding standards.
    

    Sure enough, this is telling me that there is one commit on the Drupal 7.x-1.x version of the module that is not yet on the Backdrop 1.x-1.x version.

  5. Now it's time to merge those changes to Backdrop. We could just merge the changes directly and push them to GitHub and be completely done, but I'll follow best practice here and do it on a dedicated branch with a pull request. (In reality, I might be doing this for a more complicated change than a simple documentation fix, or perhaps with a series of Drupal changes all at once rather than a single one. So I might want to formally review the Drupal changes before accepting them into Backdrop.)

    By convention I'm going to use a branch name ("drupal-2415223") based on the Drupal.org issue number:

    $ git checkout 1.x-1.x
    Switched to branch '1.x-1.x'
    
    $ git checkout -b drupal-2415223
    Switched to a new branch 'drupal-2415223'
    
    $ git push -u origin drupal-2415223
    Total 0 (delta 0), reused 0 (delta 0)
    To [email protected]:backdrop-contrib/user_cancel_password_confirm.git
    * [new branch]          drupal-2415223 -> drupal-2415223
    Branch drupal-2415223 set up to track remote branch drupal-2415223 from origin.
    
    $ git merge drupal/7.x-1.x
    Auto-merging user_cancel_password_confirm.module
    Merge made by the 'recursive' strategy.
    user_cancel_password_confirm.module |   10 ++++++++--
    1 file changed, 8 insertions(+), 2 deletions(-)
    

    In this case, the merge was simple and worked cleanly. Of course, there might be merge conflicts here or other changes that need to be made. You can do those at this time, and then git push to push the changes up to GitHub.

  6. Once the changes are pushed, I went ahead and created a pull request via the GitHub user interface, with a link to the Drupal.org issue for future reference (I could have created a corresponding issue in the project's GitHub issue tracker also, but didn't bother):
    • Fix documentation of form API functions to match coding standards (pull request) (diff)

    Merging this pull request via the GitHub user interface gets it onto the official 1.x-1.x Backdrop branch, and into the Backdrop version of the module.

    Here's the commit for Drupal, and the same one for Backdrop:

    http://cgit.drupalcode.org/user_cancel_password_confirm/commit/?id=997d8...
    https://github.com/backdrop-contrib/user_cancel_password_confirm/commit/...

Using the above technique, it's possible to have one main issue (in this case on Drupal.org) for any change you want to make to the module, do essentially all the work there, and then easily and quickly merge that change into the Backdrop version without the hassle of repeating lots of manual, error-prone steps.

Hopefully this technique will be useful to developers who want to contribute their work to Backdrop while also continuing their contributions to Drupal, and will help the two communities continue to work together. Thanks for reading!

Further Backdrop Resources

Do you have any thoughts or questions, or experiences of your own trying to port a module to Backdrop? Leave them in the comments.

Feb 17 2015
Feb 17

This is the second in a series of blog posts about the relationship between Drupal and Backdrop CMS, a recently-released fork of Drupal. The goal of the series is to explain how a module (or theme) developer can take a Drupal project they currently maintain and support it for Backdrop as well, while keeping duplicate work to a minimum.

  • In part 1, I introduced the series and showed how for some modules, the exact same code can be used with both Drupal and Backdrop.
  • In part 2 (this post), I'll explain what to do when you want to port a Drupal module to a separate Backdrop version and get it up and running on GitHub.
  • In part 3, I'll explain how to link the Backdrop module to the Drupal.org version and maintain them simultaneously.

Porting a Drupal Module to Backdrop and Getting it Up and Running on GitHub

For this post I’ll be looking at User Cancel Password Confirm, a very small Drupal 7 module I wrote for a client a couple years back to allow users who are canceling their accounts to confirm the cancellation by typing in their password rather than having to go to their email and click on a confirmation link there.

We learned in part 1 that adding a backdrop = 1.x line to a module’s .info file is the first (and sometimes only) step required to get it working with Backdrop. In this case, however, adding this line to the .info file was not enough. When I tried to use the module with Backdrop I got a fatal error about a failure to open the required includes/password.inc file. What's happening here is simply that Backdrop (borrowing a change that's also in Drupal 8) reorganized the core directory structure compared to Drupal 7 to put most core files in a directory called "core". When my module tries to load the includes/password.inc file, it needs to load it from core/includes/password.inc in Backdrop instead.

This is a simple enough change that I could just put a conditional statement into the Drupal code so that it loads the correct file in either case. However, over the long run this would get unwieldy. Furthermore, if I had chosen a more complicated module to port, one which used Drupal 7's variable or block systems (superseded by the configuration management and layout systems in Backdrop) it is likely I'd have more significant changes to make.

So, this seemed like a good opportunity to go through the official process for porting my module to Backdrop.

Backdrop contrib modules, like Backdrop core, are currently hosted on GitHub. Regardless of whether you're already familiar with GitHub from other projects, there are some steps you should follow that might not be familiar, to make sure your Backdrop module's repository is set up properly and ultimately to get it included on the official list of Backdrop contributed projects.

Importing to GitHub

The best way to get a Drupal module into GitHub is to import it; this preserves the pre-Backdrop commit history which becomes important later on.

Before you do this step, if you're planning to port a Drupal module that you don't maintain, it's considered best practice to notify the current maintainer and see if they'd like to participate or lead the Backdrop development themselves (see the "Communicating" section of the Drupal 7 to Backdrop conversion documentation for more information). In my case I'm already the module maintainer, so I went ahead and started the import:

  1. Go to the GitHub import page and provide the public URL of the Drupal project's Git repository (which I got from going to the project page on Drupal.org, clicking the "Version control" tab, and then - assuming you are importing a module that you maintain - making sure to uncheck the "Maintainer" checkbox so that the public URL is displayed). Drupal.org gives me this example code:


    git clone --branch 7.x-1.x http://git.drupal.org/project/user_cancel_password_confirm.git

    So I just grabbed the URL from that.

  2. Where GitHub asks for the project name, use the same short name (in this case "user_cancel_password_confirm") that the Drupal project uses.
  3. Import the project into your own GitHub account for starters (unless you're already a member of the Backdrop Contrib team - more on that later).

Here's what it looks like:
GitHub import

Submitting this form resulted in a new GitHub repository for my project at https://github.com/DavidRothstein/user_cancel_password_confirm.

As a final step, I edited the description of the GitHub project to match the description from the module's .info file ("Allows users to cancel their accounts with password confirmation rather than e-mail confirmation").

Cleaning Up Branches and Tags

Next up is some housekeeping. First, I cloned a copy of the new repository to my local machine and then used git branch -r to take a look around:


$ git clone [email protected]:DavidRothstein/user_cancel_password_confirm.git
$ git branch -r
origin/7.x-1.x
origin/HEAD -> origin/master
origin/master

Like many Drupal 7 contrib projects, this has a 7.x-1.x branch where all the work is done and a master branch that isn't used. When I imported the repository to GitHub it inherited those branches. However, for Backdrop I want to do all work on a 1.x-1.x branch (where the first "1.x" refers to compatibility with Backdrop core 1.x).

  1. So let's rename the 7.x-1.x branch:


    $ git checkout 7.x-1.x
    Branch 7.x-1.x set up to track remote branch 7.x-1.x from origin.
    Switched to a new branch '7.x-1.x'
    $ git branch -m 7.x-1.x 1.x-1.x
    $ git push --set-upstream origin 1.x-1.x
    Total 0 (delta 0), reused 0 (delta 0)
    To [email protected]:DavidRothstein/user_cancel_password_confirm.git
    * [new branch] 1.x-1.x -> 1.x-1.x
    Branch 1.x-1.x set up to track remote branch 1.x-1.x from origin.

  2. And delete the old one from GitHub:


    $ git push origin :7.x-1.x
    To [email protected]:DavidRothstein/user_cancel_password_confirm.git
    - [deleted] 7.x-1.x

  3. We want to delete the master branch also, but can't do it right away since GitHub treats that as the default and doesn't let you delete the default branch.

    So I went to the module's GitHub project page, where (as the repository owner) I have a "Settings" link in the right column; via that link it's possible to change the default branch to 1.x-1.x through the user interface.

    Now back on my own computer I can delete the master branch:


    $ git push origin :master
    To [email protected]:DavidRothstein/user_cancel_password_confirm.git
    - [deleted] master

  4. On Drupal.org, this module has a 7.x-1.0-rc1 release, which was automatically imported to GitHub. This won't be useful to Backdrop users, so I followed the GitHub instructions for deleting it.
  5. Finally, let's get our local working copy somewhat in sync with the changes on the server. The cleanest way to do this is probably just to re-clone the repository, but you could also run git remote set-head origin 1.x-1.x to make sure your local copy is working off the same default branch.

The end result is:


$ git branch -r
origin/1.x-1.x
origin/HEAD -> origin/1.x-1.x

Just what we wanted, a single 1.x-1.x branch which is the default (and which was copied from the 7.x-1.x branch on Drupal.org and therefore contains all its history).

Updating the Code for Backdrop

Now that the code is on GitHub, it's time to make it Backdrop-compatible.

To do this quickly, you can just make commits to your local 1.x-1.x branch and push them straight up to the server. In what follows, though, I'll follow best practices and create a dedicated branch for each change (so I can create a corresponding issue and pull request on GitHub). For example:


$ git checkout -b backdrop-compatibility
$ git push -u origin backdrop-compatibility

Then make commits to that branch, push them to GitHub, and create a pull request to merge it into 1.x-1.x.

  1. To get the module basically working, I'll make the simple changes discussed earlier:
    • Add basic Backdrop compatibility (issue) (diff)

    If you look at the diff, you can see that instead of simply adding the backdrop = 1.x line to the .info file, I replaced the core = 7.x line with it (since the latter is Drupal-specific and does not need to be in the Backdrop version).

    With that change, the module works! Here it is in action on my Backdrop site:

    Cancel account using password

    (Also visible in this screenshot is a nice effect of Backdrop's layout system: Editing pages like this one, even though they are using the default front-end Bartik theme, have a more streamlined, focused layout than normal front-end pages of the site, without the masthead and other standard page elements.)

  2. Other code changes for this small module weren't strictly necessary, but I made them anyway to have a fully-compatible Backdrop codebase:
    • Replace usage of "drupal" with "backdrop" in the code (issue) (diff)
    • Use method on the user account object to determine its ID (issue) (diff)
  3. Next up, I want to get my module listed on the official list of Backdrop contributed projects (currently this list is on GitHub, although it may eventually move to the main Backdrop CMS website).

    I read through the instructions for applying to the Backdrop contributed project group. They're relatively simple, and I've already done almost everything I need above. The one thing I'm missing is that Backdrop requires a README.md file in the project root with some standard information in it (I like that they're enforcing this; it should help developers browsing the module list a lot), and it also requires a LICENSE.txt file. These were both easy to create following the provided templates and copying some information from the module's Drupal.org project page:

    Once that's done, and after reading through the rest of the instructions and making sure I agreed with them, I proceeded to create an issue:

    Application to join contrib team

    In my case it was reviewed and approved within a few hours (perhaps helped by the fact that I was porting a small module), and I was given access to the Backdrop contributed project team on GitHub.

  4. To get the module transferred from my personal GitHub account to the official Backdrop contrib list, I followed GitHub's instructions for transferring a repository.

    They are mostly straightforward. Just make sure to use "backdrop-contrib" as the name of the new owner (who you are transferring the repository to):

    Transfer repository to backdrop-contrib

    And make sure to check the box that gives push access to your repository to the "Authors" team within the Backdrop Contrib group (if you leave it as "Owners", you yourself wouldn't be able to push to it anymore):

    Grant access to the Authors team

    That's all it took, and my module now appears on the official list.

    You'll notice after you do this that all the URLs of your project have changed, although the old ones redirect to the new ones. That's why if you follow many of the links in this post, which point to URLs like https://github.com/DavidRothstein/user_cancel_password_confirm, you'll see that they actually redirect you to https://github.com/backdrop-contrib/user_cancel_password_confirm.

    For the same reason, you can keep your local checkout of the repository pointed to the old URL and it will still work just fine, although to avoid any confusion you might want to either do a fresh clone at this point, or run a command like the following to update the URL:

    git remote set-url origin [email protected]:backdrop-contrib/user_cancel_password_confirm.git
    

With the above steps, we’re all set; the module is on GitHub and can be developed further for Backdrop there.

But what happens later on when I make a change to the Drupal version of the module and want to make the same change to the Backdrop version (certainly a common occurrence)? Do I have to repeat the same changes manually in both places? Luckily the answer is no. In part 3 of this series, I’ll explain how to link the Backdrop module to the Drupal.org version and maintain them simultaneously. Stay tuned!

Further Backdrop Resources

Do you have any thoughts or questions, or experiences of your own trying to port a module to Backdrop? Leave them in the comments.

Feb 16 2015
Feb 16
Backdrop

So the first BackDrop release is out there in the wild ready for a quick test drive! We're excited to see where this fork of Drupal 7 leads as we believe it to be a good complementary system to Drupal with a long term future.

First off we checked under the hood to get things configured and found the settings.php file in the root folder, which makes for easier access. Also all those txt files have been removed including the CHANGELOG.txt file, which we remove by default, as it supplies useful info to any hacker out there!

Naturally the installation process is very similar to Drupal but with a few less settings giving it a simpler feel.

Upon installation you're presented with a responsive admin menu with a slightly different structure to the standard Drupal menu. Responsiveness out of the box is great and the new menu again has a simpler look.

The first page to visit was the Status page which highlights there's no update server setup to facilitate this at present. Next stop was the Content page - a slight rejig of the layout but essentially the same with filters at the top of the page.

Next stop was the module page which has a cleaner appearance with built in search/filter functionality which is extremely useful.

Module Page

There's a number of modules already converted to BackDrop, see below for simple tips on converting a module to BackDrop.

When adding content the tabs have been reshuffled to put the publishing options top of the list which again is a useful tweak.

Module Page

Views is baked into Core which is very handy considering the amount of sites we build that utilise Views.

It's still early days but the signs are that BackDrop could be a very useful system going forward. The small UI tweaks and responsiveness add up to a lot for me, making this first release a good step forward.

Are you interested in BackDrop or do you see it as an unnecessary distraction from Drupal? How do these changes to the fork of Drupal work for you?

Resources

Feb 03 2015
Feb 03

Part 1 - Reuse the Same Code

In mid-January, the first version of Backdrop CMS was released. Backdrop is a fork of Drupal that adds some highly-anticipated features and API improvements to the core Drupal platform while focusing on performance, usability, and developer experience.

When an open-source fork makes the news, it's often because it was born from a fierce, acrimonious battle (example: Joomla forking from Mambo); the resulting projects compete with each other on the exact same turf and developers are forced to choose sides. Backdrop's goal, however, is not to destroy or replace the original Drupal project. Rather, it aims to be a "friendly fork" that focuses on Drupal's traditional audience of site builders and developers, an audience which the Backdrop founders believe are being slowly left behind by the Drupal project itself.

Because of this, I expect that many existing Drupal developers will not want to choose between the platforms, but instead will continue working with Drupal while also beginning to use Backdrop. In this series of blog posts, I will explain how a module (or theme) developer can take a Drupal project they currently maintain and support it for Backdrop as well, while keeping duplicate work to a minimum.

  • In part 1 (this post), I'll show how for some modules, the exact same code can be used with both Drupal and Backdrop.
  • In part 2, I'll explain what to do when you want to port a Drupal module to a separate Backdrop version and get it up and running on GitHub.
  • In part 3, I'll explain how to link the Backdrop module to the Drupal.org version and maintain them simultaneously.

Sometimes the Same Exact Code can be Used With Both Drupal and Backdrop

To start things off let's look at Field Reference Delete, a Drupal 7 module I maintain which does some behind-the-scenes cleanup in your database when entities such as nodes or taxonomy terms are deleted on the site. It's a moderately-complex module which makes heavy use of Drupal's field and entity systems.

To make this or any Drupal module work with Backdrop, there is one step that is always required: Adding a backdrop = 1.x line to the .info file to inform Backdrop core that the code is Backdrop-compatible.

Easy enough. The big question is what changes are required beyond that?

Checking for Changes

Although Backdrop is not 100% compatible with Drupal 7 (due to the features and API improvements it adds) it aims to be backwards-compatible as much as possible, for example by including a compatibility layer to allow Drupal functionality that is deprecated in Backdrop to still work correctly.

The Backdrop change records and module conversion guide provide technical advice for developers on how and when to upgrade their code. The biggest changes are probably the configuration management system (Backdrop’s replacement for Drupal 7’s variable API and other configuration that was previously stored in the database) and layout system (which removes much of the functionality of the Drupal 7 Block module in favor of a newer, more powerful Layout module).

If your Drupal 7 module makes heavy use of these systems, it’s likely you’ll want to make some changes in order to work with Backdrop. However, the compatibility layer means that you might not actually need to. For example, Backdrop retains Drupal 7’s variable API (although it is marked as deprecated and is not as powerful as the configuration system which replaces it). So your code might still work even if it uses this system. It really depends on the details of how your module works, so the best advice is to test it out and see what (if anything) is broken.

It’s also worth noting that because Backdrop was forked from an early version of Drupal 8 (not from Drupal 7) it inherited a smattering of changes that were added to Drupal 8 early in the release cycle. Not all of these have made it into the list of Backdrop change records yet, although work is ongoing and people are adding them as they are noticed.

In the case of Field Reference Delete, I tested the module on Backdrop and it worked fine. I also skimmed the change records and module conversion guide mentioned above and didn't see anything that obviously needed to change. Even though entities in Backdrop have been converted to classed objects and the field API has been converted to use the configuration management system, Field Reference Delete’s heavy use of the entity and field systems still didn’t require that any changes be made. All I had to do to get the module working was add that one backdrop = 1.x line to the .info file.

Adding the One Line of Code on Drupal.org

Interestingly enough, since Drupal will happily ignore a backdrop = 1.x line in a module's .info file, it's possible to simply add that code to the Drupal.org version of the module and use the same version of the module for either Drupal or Backdrop. I did that in this issue; the resulting diff is simply this:


diff --git a/field_reference_delete.info b/field_reference_delete.info
...
name = Field reference delete
description = Immediately removes references to a deleted entity from fields stored in an SQL database.
core = 7.x
+backdrop = 1.x

Drupal uses the core = 7.x line to determine Drupal compatibility, and Backdrop uses the backdrop = 1.x line to determine Backdrop compatibility. The 7.x-1.0-beta1 release of Field Reference Delete contains the above change and can be used equally well on a Drupal or Backdrop site. Simple!

There are some downsides to doing this, however:

  • Although no changes to the module code may be strictly required, there are usually optional (and non-backwards-compatible) changes that can be made to better integrate with new Backdrop features.
  • It is hard for Backdrop users and developers to find the module and know that it's compatible with Backdrop. I tried to improve its discoverability by adding a "Backdrop compatibility" tag to the above-mentioned issue, and I also put a note on the project page explaining that Backdrop is supported. These aren't ideal, but should help; perhaps a standard will eventually catch on but there isn't a formal one yet.

Despite these disadvantages, for the time being I'd like to just have one copy of the code for this particular module (hosted in one place), and it's nice to know that's possible.

In part 2 of this series, I’ll take a look at a different module I maintain where it isn’t possible to use the same exact code for Drupal and Backdrop, and I’ll show how I went through the official process for porting my module to Backdrop and getting it hosted on GitHub. Stay tuned!

Further Backdrop Resources

Do you have any thoughts or questions, or experiences of your own trying to port a module to Backdrop? Leave them in the comments.

Oct 11 2013
Oct 11
Drupal Fork Backdrop

I've listened to the recent chat on TalkingDrupal about the BackDrop project, a fork of Drupal which is causing much controversy in the community.

Having read the BackDrop website and also read various blog posts there's lots of things to get excited about if you're a D7 enthusiast and some not so great things if you're a Drupal evangelist!

Some people are scared of what it might do to the community, some are overjoyed at its concept but before I cast my opinion here's some of what I've gleaned so far.

We're happy with Drupal 7, we know what it can do but we also know its limitations

We all know Drupal 7 isn't perfect, it's made good strides since Drupal 6 but you might feel Drupal 8 is more of a leap! if you're happy with Drupal 7 and you're already hiding behind your chair having read about what's changing in Drupal 8 then BackDrop could be for you.

They are going to incorporate most, if not all, the Drupal 8 goodness but on a Drupal 7 framework

Worried BackDrop is going to get left behind when Drupal 8 comes out then think again. The idea is to take most, if not all of the new functionality built into the new Drupal 8, such as the built in WYSIWYG, migration module*(see Nate's comment, sorry my mistake, not included at this time), inline editing etc and port them to BackDrop!

Drupal 7 modules will be 90-95% compatible with BackDrop meaning only minor code changes are required

As BackDrop is only a side step away from Drupal 7 all D7 modules will only need minor modifications to become compatible. This is interesting stuff for module developers who can port their module to BackDrop quickly whilst rebuilding it for Drupal 8 at the same time!

BackDrop 1.0 will be released at a similar time to Drupal 8

The idea is to release BackDrop at the same tme as Drupal 8 so you won't feel left behind! If the thought of migrating your site to D8 doesn't appeal then BackDrop could be the way forward for you. Releasing BackDrop at the same time sings to me of competition but competition is healthy right?!

Issue queues will be cross linked

There's already mentions of BackDrop in the Drupal issue queues and this will only increase but they say that solutions in either issue queue can only help, not hinder.

It's not a breakout, more an expansion or sidestep

Only time will tell if BackDrop causes a split in the community but the idea is to keep more people using Drupal, or BackDrop (a version of Drupal) instead of losing them to Wordpress or alike. The founders, feeling turned off by Drupal 8, turned to forking Drupal to stay within the community rather than start over again learning a new system.

BackDrop graph
Estimated and hypothetical post-D8 growth chart of Drupal audience over time.

Upgrading is dead, migration will be the way forward for Drupal 8 and BackDrop

Upgrading Drupal has never been a straight forward process and the decision has been taken to incorporate in core the migrate module. This will be the same for BackDrop, so whether you try D8 and want to move to BackDrop or vice versa you will be able to do this.

An Eco system will be promoted to match that of Drupal

Just the same as is currently available to Drupal developers the BackDrop team are looking to create a thriving Eco system.

The right tool for the job

I'm excited about Drupal 8 and the direction it's going in and am fully behind the project, as you can read in my blog post Cliff Edge or Path To The Summit.

Some of my larger clients will utilise all the D8 functionality and I'll certainly be using it going forward but is it the right framework for every job, no. Should I migrate all my Drupal 5, 6 and 7 sites to it, or more importantly do my clients have the budget to do this, in some cases no.

Drupal 7 will be around for years to come which gives us plenty of time to learn the new ways of Drupal 8. If you're a site builder then D8 will make it even easier for you to build great sites but if you're a module developer or themer then it's going to take you time to get to grips with the new way of working. Do you have the time or the ability to learn what might feel like a whole new system?

For me BackDrop is a good idea as it will give those people who are more than happy with Drupal 7 the chance to stay in the community for many years to come, before Drupal 9 comes along and security updates are halted on D7.

The learning curve for new users of Drupal has always been steep and Drupal 8 could turn off those who have recently joined the community. BackDrop could give them an out.

Could BackDrop be the answer to those that say Wordpress is a sinch to get started with for non-techies but Drupal isn't?

The notion that BackDrop is a bad idea and one that could spilt the community are founded but it should be a catalyst for improvement in Drupal itself.

BackDrop could help the community make both systems even more popular and spread the word that Drupal is a great framework, or it could be one in the eye for Drupal 8 and we could see many moving across to the forked version. What do you think?

Listen to some great interviews with the founders of BackDrop via the Lullabot podcast, Modules Unraveled and TalkingDrupal

Update Dec 2014: The first release of BackDrop is due out on the 15th January 2015! Take a look at the latest documentation or download a preview now.

Sep 20 2013
sun
Sep 20

There is an active attempt to fork the Drupal content management system into a new application:

Backdrop — a play on Drupal's name and origin, which originally intended to be dorp.org (Dutch: village), but due to a typo, became drop.org in 2001. Shortly after, drop.org was renamed to drupal.org.

As the name suggests, Backdrop's intention is to get back to the roots of Drupal:

  • Quality
  • Simplicity
  • Developer Experience and Productivity
  • Performance
  • Targeted vision and use-case

The project was kick-started and is driven by a few people that I personally respect and value a lot. In fact, they are representing a group of brilliant people and excellence, which originally turned Drupal into the product that it is today. A group that felt ignored and unheard in the recent past — even though it were primarily these and like-minded people who enabled the world to interpret Drupal as a real product and competition in the first place.

To be clear: Do not try this at home. The attempt of forking Drupal involves hundreds of factors that you are not considering. There have been many attempts in the past, but not a single one succeeded. Yours will not succeed either. Backdrop may or may not be an exception.
(Did I phrase this clear enough?)

The root of all concerns is Drupal 8, which is in development and undergoes major architectural changes for ~3 years already. Though, despite all changes, there's little to no innovation compared to the competition. The focus is to clean up and modernize all core code and APIs, with the intended goal of ending up with a base system whose architecture is more maintainable and sustainable in the future.

The current state of Drupal 8 is poor and not worth to talk about. However, the final and intended state seems to present a clear and diametrical conflict to the former goals, qualities, values, and roots of the original Drupal project.

The situation

I talked to various different parties. What I learned is simple:

People are not listening to each other.

People do not appear to remotely see the points that others are trying to make. In both directions. Assumptions are utterly wrong, frontiers are built before having any clue at all, counter-arguments are overly naive and misguided, and all communication is generally hindered by a good amount of bad-ass trolling.

What I heard was offensive defense and disagreement. No one appears to listen and to truly perceive and understand all arguments, before drawing any kind of lines and/or conclusions.

As if, you know, the world was flat.

In short, a simple and common conflict resolution scenario.

This blog post originally aimed to cover all aspects on the idea of forking Drupal and my personal stance on this particular fork, but after gathering more and more insights on the current situation, I decided to leave out and save those parts for a future post.

Therefore, this post reflects on the communication conflict only.

Solutions are possible. They will require changes. They will cause conflicts. It is a matter of will, listening, and dedication. It is a matter of respect.

Disconnect in Dissent

In analyzing the situation, and in distilling and deciphering all arguments, I did notice that there appears to be a rather large disconnect in understandings and communication.

It's important to note upfront that the situation did not suddenly appear a week ago, but actually evolved over the past ~2 years throughout the Drupal 8 development cycle.

Drupal core developers appear to be coming from a mindset that is deeply stuck in refactoring work of internal core framework subsystems, which happens to involve plenty of abstractions and complexity. These were major and important undertakings, but in all of this work, not much thought went into the question of how verbose these concepts need to be for the average module developer.

A few core developers are showing good will to fix and improve minor developer experience issues. Some others do not appear to see any issues at all, and they seem to not only ignore the arguments that are being raised, but even strongly and blatantly argue against them. Tension appears to be caused by an attitude of:

I am right and know better, and you are just simply wrong.

...which doesn't make it sound as if anyone was listening.

Conversely, people who are looking at the current state of art are deeply confused as to why so much internal complexity and abstractions are verbosely exposed in the user space, and whether that is really necessary.

From what I've heard, the scope and extent of concerns does not encompass a few individual improvements here and there, but instead, is asking for major changes to remove all unnecessary complexity and ensure simplicity (and productivity, for that matter) in user space code.

The primary disconnect appears to be a major difference in understanding of what exactly is interpreted as "complex."

There further appears to be a misunderstanding in that people would have a general problem with object-oriented code, which is not only misguided but also makes an insulting assumption on the technical learnability skills of others. As a consequence, a line is drawn between parties that does not actually exist, which in turn hinders constructive communication.

The same consideration appears to be further manifested by the assumption that the target developer audience of Drupal 8 would be different. Equally based on the idea that novice PHP developers and hobbyists would not be capable to understand and learn object-oriented code. This nonsensical assumption clearly appears to stem from the disparity in understanding of what exactly "complexity" constitutes.

All communication appears to be distorted by another disturbing detail: The API freeze for Drupal 8 was officially announced already, despite the fact that literally everyone and all parties appear to agree that the current state is a total mess and not remotely releasable. This aspect especially supports the resignation of the non-core party, as they're in fact asking for major API changes, which obviously presents yet another unnecessary conflict.

Drupal appears to have taken steps to remedy the situation through a new D8DX initiative. But coherent to all other communications, this initiative starts with a big list of things that are out of question, and just continues with a list of minor issues that may be debatable. In other words, directly building a frontier, before even starting to listen.
Update: It appears the initiative page has been corrected to somewhat address this issue.

Conclusion

It's a tough situation, because there's a lot of frustration all around. In fact, no one appears to be happy with anything. The lack of a clear leadership, ownership, and authority certainly contributed to the final path that slowly but certainly turned frustration into resignation.

Now the question is whether everything sucks and it's too late, or whether there is a chance to resolve the situation by taking a large step back (stop coding, start listening) and bring everyone on one round table to find concrete, working solutions.

Solutions are very well possible. But they certainly require everyone to leave their comfort zone, start being receptive, listen to and ensure to comprehend concerns of others, accept that there are different world perspectives, and most importantly, to allow yourself to make compromises.

My recommendation is to not calm down and defend, downplay, or ignore the issue. Also, don't be afraid, don't be a jerk, and don't be a hardliner. Instead, I want to encourage you to be open, welcoming, collaborative, and constructive in everything you do. Respect others, respect the culture. In short, respect

The Drupal Way™

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web