Drupal 7 vs. Drupal 8 vs. Backdrop CMS – the contenders in a changing community

A 11 minute read written by Kim March 25, 2015

An illustration of hanging boxing gloves.

Let me preface this blog post with a disclaimer: I am a developer primarily working with Drupal 7, so my opinions will likely be subconsciously biased towards the way I currently do things. However, as a developer, I am constantly trying to find better ways to work, so I will do my best to evaluate each of the three platforms and share my honest opinion of the how they stack up against one another. This is my own first-look experience with Drupal 8 and Backdrop so please forgive any incorrect or unknown information.

The contenders

Drupal 7 is currently the reigning heavy-weight champ; it’s intimidating and powerful. Once you learn how to channel its strength, the power it grants you is amazing. OK, that’s terrible analogy. In reality, Drupal is a modular, extremely extensible open source platform (it’s really not just a CMS). From ecommerce to integration with third-party apps, the flexibility of Drupal makes it appealing to developers and site configurators alike. We’ve done some great work with Drupal 7, including the recently launched Business Link site and previously, Edmonton Airports and Backside Tours. We’ve solved a lot of tricky problems in D7 so far, and now that Drupal 8 (D8) is more stable, we’re excited to explore the possibilities it has to offer.

Drupal 8 is a bit of a mystery we’re looking forward to unravelling. We expect it to be a powerhouse, but will it be nimble too? It has built-in responsiveness, includes many popular modules – views, CKEditor, internationalization – as well as the refactoring of the file structure, and the new way to create modules and templates (Symphony, Twig). Should we switch from Drupal 7 to 8? I’ll explore that very question in this blog post, but first, I’d like to introduce you to the final contender.

If you haven’t heard of Backdrop CMS yet, it’s the new kid on the block. My understanding is that it’s a fork of Drupal 7, but with some default functionality included in core, a refactored structure, and a promise to be faster because it doesn’t have the excess that makes up Drupal 8. Additionally, in theory anyway, it won’t be as big of a learning curve to jump from D7 to Backdrop as there may be to shift from D7 to D8. Honestly, I don’t know a whole lot about Backdrop yet, but that’s what this post is about – finding out.

Really, the better comparison may be between Drupal 8 and Backdrop, but I’d like to keep Drupal 7 in the mix to serve as a basis from which to see improvements. I will likely, however, gloss over parts of how D7 works.

The game plan – and a behind-the-scenes peek

I’m about to download three fresh installs to my local machine: D7 (without my usual default build), D8, and Backdrop. The aim is to see what’s included out of the box, how to configure content types, views, add-on modules and themes, how it looks on the file system, and how it looks from a developer’s perspective. This is gonna be a long one, so get comfy.

A comparison view of the file and directory structure of a fresh install of each CMS.

I can already see that both D8 and Backdrop are cleaner, since they hide the core folders in a folder helpfully named “core.” This is actually a fantastic idea as beginners instinctively start looking under themes and modules to start adding their own. And this makes it much more obvious where I need to put modules/themes, etc. It’s interesting to note that Backdrop has both “themes” and “layouts.”

According to Backdrop’s website, layouts is “coming soon,” but you can read up on how to create your own layout or theme. From what I can tell, it seems to me that the region definitions and traditional .tpl template files (HTML structure) of the site have been separated from the CSS, which would be the theme. I am not a front-end developer, so while it is interesting, I’m not going to take an in-depth look at theming.

Moving right along, looking at the size of the core folders (compared to the root for D7), we can see that – holy smokes! – Drupal 8 is massive compared to both its predecessor and Backdrop. Granted, D8 promises to include a lot of features right out of the box, so it makes sense that it takes up almost five times as much space. Yet so far, Backdrop lives up to its promise of reduced bulk.

Drupal 7 Drupal 8 Backdrop
Size: 11.7MB Size: 42.2MB Size: 11.8MB
Size on disk: 14.5MB Size on disk: 72.2MB Size on disk: 15.5MB
Contains: 1,075 files, 136 folders Contains: 11,871 files, 3,017 folders Contains: 1,416 files, 253 folders

Installation and first impressions

There are plenty of tutorials on how to install Drupal, and I’m assuming the process is nearly identical for each: create a MySQL database, fill out the wizard config., and let the magic work.

A screenshot of the Drupal 8 install screen.

Drupal has been given a makeover in D8, and it’s evident from the moment you start installing your site. It’s got a snazzier loading bar, and a brighter, more polished look. It’s definitely slower to install, but that’s unsurprising, given its size. Backdrop has followed the similar box-style installer, but keeps the older Drupal 7 loading bar.

This is the part of the blog, where I wish I did a screencast instead, so we could walk through the pages together. However, I’m going to stick to the game plan. Hopefully, the Drupal 7 look and feel is already familiar to you as I am not going through it. If you’re not familiar with it, here’s a refresher.

Drupal 8 at a glance

A screenshot showing a default timezone php error after install of Drupal 8.

Oops! Drupal 8 starts us off with a warning about setting time zones. Upon refresh it goes away, but this puts me in the mindset that it’s still not totally stable yet; however, it’s definitely a much prettier Drupal. I like that it is responsive, and you can see the expanded menu in a smaller screen. But I wish the admin menu drop-down style was included by default.

Drupal 8 generally just looks better than D7. With minor details, such as better buttons and cleaner layout, the new system definitely has polish. However, it doesn’t feel different – which is a good thing. The navigation takes me to where I expect it would. There are minor differences, such as “extend” instead of “modules,” but nothing that surprises or confuses me (so far).

The creation of a content type is slightly different in terms of fields, as it is more like a wizard. I am glad to see that both Date and Link modules have made it into core.

A screenshot of the manage form display screen in Drupal 8.

On the content type creation side of things, the manage fields, manage display form, and manage display have been broken out into three separate tabs. So the order in which you create your fields is the order they will be on the content type manage fields screen – but not when you create the content node, which is now managed by the manage form display.

One of the things I’m sure we’re all happy about is that Views is now a part of core. Again, no great revelations here; it has the same navigator panel as Drupal 7, with just touch-ups to the display.

So far, everything in core seems fairly solid. The next steps are extending the site via installing a contributed module. Since I already complained about not having the admin menu, I’m going to go ahead and drop that into the folder and enable it on the modules screen and – oops – it’s dead. Oh, the lovely white screen of death.

PHP Fatal error: Call to undefined function user_access() in C:\MAMP\htdocs\d8\modules\contrib\admin_menu.module on line 202

To be fair, this is the development branch of admin menu (since there is no other release for D8), and I am able to find an issue for it. But again, doesn’t give me confidence in the system when one of the most basic modules (used on all my Drupal 7 sites) causes my fresh installation to completely break.

I looked at installing some more contributed modules, but I struggled to find a decent release for the ones I commonly use. I tried a couple (e.g. pathauto, rules, etc.), but for each module, it seems like the contributors are only midway through porting the module over, and (at the time of writing) missing the pieces needed for it to work properly. I will continue to monitor the status of module releases for Drupal 8, but at this time, I don’t think it is ready for me.

So unfortunately, while everything else out of the box seems great and much prettier, there is still a lot of work to do. I’m actually fairly disappointed. I was hoping that by this point it would be in a much better state.

Given that this is just a quick first-glance overview (and I’m sorry if I’m offending any D8 fans by stopping here), I think its safe for me to say that Drupal 8 is not ready. My attempt to make an extremely simple site has not given me confidence. Although some people have already completed sites with D8 (kudos), given the complexity and scale of sites we tackle, it would be in our best interest to stick to Drupal 7.

Before I finalize that thought, though, I’m going to switch over to walking through Backdrop.

Backdrop CMS at a glance

Looking at Backdrop, I can tell it is definitely a fork of Drupal 7, but with a little bit of refinement. The admin-style menu is included out of the box, so that’s already a win over Drupal 8 (seriously, I cannot function without it). Additionally, the menu collapses on a smaller width, making me realize that Backdrop is, in fact, responsive out of the box as well. As I navigate around, similar to Drupal 8, nothing in the navigation surprises me, nor does anything I see on the screen.

A screenshot of an event content type field management view while adding a new 'Date' field.

Creating a content type is the same as always. So is adding fields. Since there is no date field by default, I’m going to go ahead and add this as my first module on my Backdrop test site. There is no module listing on its website (yet), so you have to pull it down from Github directly (no big deal), and it seems like there is a pretty decent list of available modules already.

A screenshot of an event content type field management view while adding a new 'Date' field with an SQL error.

First, the good news: enabling the date module didn’t give me the white screen of death. The bad news: when I went back to update my content type with my new field, it gave me an error and did not create it. When I changed from the date field value to date (Unix timestamp), it actually worked and created the field. But when I actually tried to create content, the date field appeared blank. The same thing happened for an ISO date. So this module is not quite ready yet. I’m not having much luck on my first module choices today.

Perhaps I am just really bad at picking modules to try, but again, this doesn’t lend to the confidence of the system. Date is something we use on just about every single Drupal site. In attempt two – this time I am trying webform out – it proved to be much more successful. I was able to enable and configure a webform with no problem at all.

Like Drupal 8, Views is a part of the core installation for Backdrop. It’s still the same as D7, so no surprises there. Easy-peasy to add content and configure a view. I wish that, like Views, a WYSIWYG was included for content out of the box. I can’t think of any site we’ve ever created that didn’t use one for the content authors.

One thing that is different and unique about Backdrop is the layouts page underneath structure. Earlier, I mentioned that I noticed layouts and themes, so when I edited the default layout we have a page that almost looks like panels to define different components of the site. I can add blocks to different sections (including dragging and dropping them around) and I can configure different components.

A screenshot of the layout editing page of Backdrop.

When I go to create my own layout, I definitely get the panels vibe – only it’s better! To quote Kevin Reynen, the author of this post on the topic of Backdrop layouts:

The approach taken in Backdrop allows any module or theme to define reusable layouts as a .yml. Layouts are essentially these same content region definitions with the necessary HTML and CSS. Once defined, the Layouts are then available to reuse and assign to any path, node, content type, etc., but because I can define these layouts at the module level I can actually actually assign blocks to regions since I'll know how this will render within the theme's content region.

I am totally on board with that. It is super rad to have this built into the core of the CMS.

A screenshot of the layout editing page of Backdrop.

So which CMS wins the battle?

Will it be the prettier powerhouse – or its nimble newbie competition? Or will the old stalwart prevail? Frankly, the answer to this question is “It depends.” That’s because it depends on the problem you have, the experience you (or your team) has, and the type of solution you want. No CMS is perfect, and certain ones will always be best suited to a particular problem.

After comparing the three CMS systems for this post, I can tell you that I’m sticking to Drupal 7. Drupal 8 did not inspire me with any confidence with its errors, modules not ported over, or ported modules killing the site. It is definitely prettier, bulkier, and it’s going to be amazing when it’s ready, but it’s just not there yet. There will be a larger learning curve and a lot of work to get it to where Drupal 7 is now.

After my first quick glance of Backdrop, I have to say that it has potential. I’m very curious to see where this goes and how the Drupal community responds to it. It definitely feels and acts like Drupal 7, but with a bit of refinement that it needed. For now, I worry about the stability of Backdrop as it is fresh and new, but if more modules get ported over (stable releases) and more and more people emigrate from Drupal 7 to Backdrop (instead of Drupal 8), I too, may be persuaded to jump over. But for now, the risk of not having much support or backwards compatibility scares me away from using Backdrop right now. I might try it out on personal projects, but I don’t think it’s ready for the enterprise world yet.

For the time being, I still have the most confidence in Drupal 7. I know what modules I need to get the job done, and I know my own ability to debug issues that arise. I know how to create custom modules and theme the site. It has the most support at the moment, so it’s the most reliable for me to resolve issues. Long story short: I’m sticking to Drupal 7.