A First Look at the Backdrop CMS

There’s a lot of excitement about Drupal 8 and its imminent release. There’s also some angst. Yes, Drupal 8 is super slick and full of frameworky, object oriented coolness. The thing is, a lot of people have invested a lot of time learning how to do things in Drupal 7, and the idea of learning how to do things in Drupal 8 can be pretty daunting. This is where Backdrop aims to step in and serve developers and end-users who want to continue doing things mostly the Drupal 7 way, but not fall behind the new technology (or product support) curve.

So what motivated this fork in early D8 development?

Drupal 7 took some time to take hold – there were several reasons for this:

1) D7 is different enough from D6 that it took a considerable investment of time and money to learn (it was more enterprise focused).

2) D7 is often times more abstracted than D6. E.g.: The Commerce suite of modules is extremely powerful, and is considered by most Drupal developers to be the defacto solution for ecommerce, but it is more of a construction kit than a fully asembled product. Whereas, in D6, Ubercart is the way to go for ecommerce, which is pretty close to being fully functional right out of the box. The Commerce vs. Ubercart example serves to highlight the differences in approach between the two.

Also, Drupal 8 arguably needs developers with more in-depth experience or training to make the most out of it as a development platform. The consideration was that this may be a more expensive position to hire into for smaller organizations compared with Drupal 7, which is more approachable to hobbyist developers.

Backdrop has a well defined philosophy

The first and most defining tenet of which is to serve small businesses, non-profits, schools or just any organization that doesn’t have a big budget. By continuing to use most of the now familiar D7 API, Backdrop lets devs work with and extend what they already know, thereby lessening the talent pool strain which in turn leads to more affordable web development solutions.

A second tenet of the Backdrop philosophy is that it should be easy to use. Site builders who don’t have coding experience should be able to use it without a lot of ramp up time.

A third tenet of the Backdrop philosophy is that contrib developers should be valued over core developers. The idea here being that the more hands there are in core (and focus on core development), the more potential for wonkyness awaits module developers who will be trying to hook into an API in constant flux.

A fourth tenet is that backdrop should be low resource. Speaking from a package size perspective, the most recent version of D8 beta has a 17.2 MB package, whereas Backdrop is 3.9MB.

Lastly, and perhaps the most notable tenet of the Backdrop philosophy, is that they are committed to releases being well planned, small, and on time. These have seemed more challenging for D8, although its ambition also differs.

So, how is it different from D7?

Side by side, Backdrop and D7 look a lot alike: both come with the default Bartik and Seven themes, and the same default content types. Looking a little more closely, there are enhancements to Backdrop that help get things moving a little more quickly.

1) A dropdown admin menu with sensible options comes baked in.

2) The annoying admin overlay is gone.

3) All themes are fully responsive.

4) Backdrop comes stock with “Layouts”, which I would kind of liken to a scaled down, much lighter weight version of panels, with a much more intuitive, simplified ui, but is still very powerful.

5) Blocks are a lot smarter. They have selection rules that when combined with Layouts, enhance the Panels like experience, but with a learning curve soft enough to make a novice developer productive quickly.

6) Configuration Management! Sick and tired of confusing features conflicts? Yeah, me too. Configuration management is a breeze to use, and makes migrating database / config settings from server instances fast and easy.

How is Backdrop extended? Just like in D7 = with modules

There are already a few that have been ported over from D7, but creating a new Backdrop module is almost the same as a creating one in D7 (it’s pretty much just a difference in namespacing), and all of the coding conventions and hooks appear to be the same. For example, Backdrop doesn’t come with any kind of wysiwyg functionality, and I wanted one with a local install I created, so I went to Drupal.org, downloaded the CKeditor module and the corresponding js library, installed it, and made one change to the .info file, where core was defined as 7.x: I removed this line and replaced with “backdrop = 1.x.” After doing this, CKeditor was available, and I was able to use it. This is possible because Backdrop has a convenient conversion layer in place, that replaces the Drupal namespace in modules to the Backdrop namespace.

Another cool thing about the Backdrop project is that it lives on Github, which differs from Drupal, that hosts its own repo. This is fine, but I think in the spirit of encouraging developers from all disciplines to collaborate and discover this project, hosting it on Github seems like a great idea. So, you can find the project, here: https://github.com/backdrop/backdrop.

If you want to read the project API docs, they can be found here: https://api.backdropcms.org/

Or, if you want to have a look at the project website, that can be found here: https://backdropcms.org/.

And if you wanna get an instance setup quickly without downloading anything, you can fire up an instance on Pantheon, here: https://dashboard.getpantheon.com/products/backdrop/spinup – you’ll need to setup a Pantheon account, but it’s free and easy to create.

Happy site building!

2017-03-31T06:19:57+00:00 Categories: Drupal, Drupal 8|Tags: |

About the Author:

Ethan Teague joined CivicActions in 2013. He channels his passion for solving code-related puzzles and his strong back- and front-end development skills into swift and tangible results.

Almost immediately upon joining CivicActions, Ethan impressed stakeholders and end users of a federal collaboration platform when he developed a custom module solution to enable file data sharing amongst multiple agencies. His many talents include rapid CSS development, Javascript / jQuery solutions, Drupal Contributed Module and Drupal Admin knowledge, and advanced experience with Views and Context, all of which he leverages to create out-of-the-box solutions and custom modules for our clients.

Before joining CivicActions, Ethan developed Destination and Marketing solutions for Miles Media and others, with a heavy focus on front-end development for responsively designed websites. He worked on multiple high volume regional and state level websites and did custom Drupal application development for Humana Insurance.
Ethan received a BA in English Literature from the University of Tennessee-Knoxville. When he’s not cracking code, he enjoys riding his bike, and playing bluegrass music with friends and family.