I think I first heard about Backdrop CMS from the Weekly Drop. As many Drupal developers do, I have a Wednesday ritual of pausing and surfing through the weekly headlines over a cup of coffee. Usually, I save a few articles for reading later, but on this particular Wednesday what do I see but...whoa, a fork?
Since I am a noob to the Drupal community coming in around the release of Drupal 7, I didn't know of the other fork attempts in Drupal's past, like Pressflow. Pressflow is a Drupal fork, or sometimes claimed to be a distribution, for sites that had higher levels of traffic than traditional Drupal sites had received in the past. It was so successful that a lot of the architectural decisions made for Pressflow made it into Drupal 7 core.
So, while the fork didn't remain for long, you could say it was quite successful in getting the concerns of the sites using Pressflow heard by the larger Drupal development community. Yet, I kept seeing articles that said things like, "For now, my advice is...keep Drupaling and carry on." or even worse disses on a very nascent open source project.
Since I do not discriminate in most areas of my life and don't like to take people's words for it, I decided I was going to try building a new site on Drupal 8 and Backdrop just to see what the differences would be.
I decided to start with Drupal 8 since the community was larger and all the talk of forks failing can scare any noobish dev away. And...I had to learn a lot of stuff, man. Not to say that I didn't enjoy learning this stuff, but I did devote many hours to OOP paradigms, Symfony components, Composer, and even looked a little into Backbone.js.
I like to learn, and I had a lot of fun leveling up my skills and saying things like "well, you know you gotta program to the interface", and "there's an event dispatcher for that"...but I did pause and think how other people, maybe less curious, will do with the transition from Drupal 7 to Drupal 8.
A Serendipitous BOF
Then, as happens in life, I got busy and didn't have time to experiment and blog. So, Backdrop took an ahem...backseat (lololol)...to other things in my life. That was until a most Serendipitous Birds of a Feather (BOF) at Drupalcamp Colorado 2015.
The previous day, I had the misfortune of having no one come to my BOF, and so when I walked in the BOF room and saw one person standing there, I was ecstatic. He said he was there for the Phonegap BOF and then two more groups rushed in wanting to talk about accessibility and Backdrop.
We all simultaneously said, "This room ain't really BOFfin' for us..." as the configuration of chairs was not circular or that talkative. The coder lounge did have a good chair config situation going on so we just exclaimed: "to the lounge!"
Somewhere along the way, the Phonegap guy went MIA mobile, and I ended up happily at the Backdrop BOF. It was cool to see the maintainers really open and receptive to questions, concerns, or ideas that camp-goers talked about.
I gathered that the main thing the BOF members thought that Backdrop needed right now was more people to install and experiment with Backdrop, which is one of the reasons I'm picking back up my blogdown idea and trying to build the same site on Drupal 8 and Backdrop.
To be clear, I am not doing a Drupal 8 vs. Backdrop "one sucks" and "one rules" type of thing. I like both for what they are, and my main intent here is just to report back my experiences in preparing for the next phase of client work after Drupal 7 becomes old news.
Pantheon to the Rescue
One of the best things about trying out Backdrop, and Drupal 8 for that matter, is that it's so easy to do with the help of Pantheon! You can get a free developer account and begin testing out Backdrop by using this link.
Once you have your account setup, the Backdrop install process is super fast and easy. To me, without looking at metrics, it would seem that Backdrop has a pretty minimal memory footprint, which is important when you are thinking about hosting options for your clients.
While Backdrop is a fork of Drupal 7, the initial release came with a few changes and improvements in the codebase. The first huge improvement is focused on Configuration Management. Every Drupal 7 developer should be familiar with the Features module.
With the Features module, you can take any piece of configuration and move it into the code instead of having it precariously exist solely in your database records. So, when you create a new content type, view, rules action, or whatever, you can systematically move that configuration change to production in a managed way rather than pushing code to production and madly clicking all the buttons before the client notices the new feature doesn't look quite right. (NB: Features was originally intended to just package up functionality of a site, like a blog, but developers increasingly used it for changing configurations for deployment workflows.)
Or...you use Features unwisely and when you push code to production the whole site breaks. Then they yell at you for trying something new, and you go back to clicking the configuration in since it's "safer." Maybe, I'm just a dumb noob, but I had issues with adopting Features that prohibited me from really getting to use it.
Needless to say, configuration management in D7 could use some help in becoming more of a smooth experience. So, the Backdrop maintainers have taken a lot of what you'll see in Drupal 8 CMI and put it in Backdrop core. In future posts, we'll go through the specifics of what this means, but for now, just know that you'll be doing stuff like this...
// Drupal 7 code $post_length = variable_get( 'post_length', '2000'); // Backdrop code $post_length = config_get('modulename.settings', 'post_length'); // Or get full config object $post_config = config('modulename.settings'); // Then get props $post_length = $post_config->get('post_length');
You can also see some OOP in here with the config object and getters and setters. Yay! Some Drupal 7 modules can even be primarily converted to Backdrop by just changing their configuration forms and how they store variables.
As a disclaimer, I don't pretend to be much of a front-end person, but I do front-end stuff regularly enough that I want a system that can be easily configured and modified for client needs but that is also easy to code up and make changes in without having to nestle myself in between twisted template files and functions.
Backdrop has taken an approach where they separate layouts from themes. What does that mean for you? One initial benefit is that you can change themes and still have your blocks placed in the same regions. Yay! So, now testing out themes or experimenting in that way will be less painful than in the past.
The layouts part of Backdrop will remind you a lot of using Panels and the Panels Everywhere approach. It is context aware, so you can make a layout for "node/%" and Backdrop will apply it to all nodes or "article/%", and in Backdrop, blocks have per-instance settings so you can finally place multiple blocks of the same kind on a page. Wowzers Batman!
One difference you'll notice right away when making your first layout is that the region definitions are no longer in the theme .info files but rather in the layout's .info file.
name = 2 columns version = BACKDROP_VERSION backdrop = 1.x ; Specify regions for this layout. regions[header] = Header regions[top] = Top regions[content] = Content regions[sidebar] = Sidebar regions[footer] = Footer
Much more will be talked about in regards to the theme layer in future posts, but this intro should give you a good idea of some of the initial differences between D7 and Backdrop.
Converting A Module
I aim to convert a decently popular module to Backdrop here shortly and include that conversion as part of this series. So...I'll probably update this section with that info later, but just know it'll be a part of this series.
Now I'm Presenting?!
I'm also presenting two Backdrop sessions coming up...whaaa? You mean you just got involved a mere few weeks ago and now you're presenting some sessions? Yes, the Backdrop fever is that strong...
But more seriously, I like to work on smaller projects as well as enterprise-level ones, and I think Backdrop has the focus to be part of that smaller market as Drupal trends more towards enterprise clients. Also, so far the core developers have been really friendly, positive, and approachable. So I urge you to look at Backdrop and try it, maybe you'll like it :)