Backdrop CMS

This weekend I had some extra time on my hands and decided to checkout Backdrop CMS. As a long time WordPress and Drupal developer I’ve been aware if Backdrop’s existence since the day it came on the scene, but have avoided it for no good reason.

Some history

If you don’t know, Backdrop is a fork of Drupal 7 with some concepts from Drupal 8. It was created by some of the many Drupal developers who didn’t agree with Drupal 8’s full rewrite of the core codebase. Those were some heady-days for us long term Drupal devs. I wavered a lot between frustration and optimism about D8’s new direction.

Since then I’ve put much effort into learning more about everything possible. OOP in both PHP and JS, twig, composer driven custom apps built from random packages, some projects in SlimPHP, Symfony, and one random Zend thing. I figured that if I just continue to level up, I would be in shape to work with any system I ran into.

Past 4 years

During the past few years I’ve become full-time employed at a company that uses D7, but I still created websites for friends, family, and the occasional small business on the side.

You know the story…

close friend/family: I’ve starting a new business, can you make me a site?
me: Sure! We’ll use shared hosting and pick a simple theme.

Then I have to decide how to build that new site, and end up considering:

1. This is a favor or small budget
2. They will manage their own content
3. They should be able to update/maintain the site on their own (see 1)
4. Life span of the site

Early on, Drupal 8 wasn’t even a possibility because it was highly unstable. That left me mostly deciding between D7 and WP. Even though I much prefer Drupal 7, it doesn’t meet many of my considerations from the list above. It can’t be easily updated by a non-developer, it doesn’t have a great editor UX out of the box, and it didn’t have a long life span.

The best things Drupal 7 had going for it was that it is easier for me (the developer) to work with, and that’s a crummy reason to choose a technology someone else was going to have to live with. So I made a lot of WP sites.

When making these decisions I couldn’t help but think that the closer D8 got to being viable, the closer D7 got to death. At what point do you stop creating new D7 sites? Especially in this scenario, knowing that the client may not be able to upgrade to D8 on their own, or afford a Drupal 8 developer to perform the migration.

Friends

For the past 3 years I’ve been a Drupal super fan who has been unable to promote it. I have many WordPress developer friends, but I can’t in good conscience convince them to learn D7 because it’s a dead end. Can’t tell them to learn D8 because the apis have been unstable and it’s wasteful to learn something atop a shaky foundation.

So instead I’ve urged them to use WordPress like Drupal. Find a Content/Post type management, fields plugin, and Views-like plugin to fill that query building UI gap. But there is still nothing like Rules or Panels, and only one effort (I know of) to replicate configuration management Drupal has had with Features for a long time.

Isn’t this post about Backdrop?

Right, so this weekend I tried Backdrop CMS, and it blew me away. My first impression is that it’s basically Drupal 7 but better and with a future. I’m sure it has its own issues like any platform, but the fundamental concepts I’ve needed for the past 3 years were there.

• Good UI and WYSIWYG
• Install/update modules and themes from the UI
• API with a future, providing greater value in learning it
• Solid APIs for forms, rendering, batching, and all the other goodies in D7

And the specifics:

• Content type UI
• Taxonomy type UI
• Fields UI
• Query building UI (Views)
• Event system UI (Rules)
• Output layout UI (Panels)
• Configuration management

Of the above list, WordPress has exactly zero of those things built into core. Sure, it has event-style hooks (which I prefer), and I guess you could argue that “custom fields” is a fields UI (but I wouldn’t). Other plugins can provide those solutions, but they are all random implementations lacking foundational core APIs to work from. Drupal core provides an unmatched scaffolding for interoperability with APIs such as Entity, Form, DBTNG, Render, etc.

Add all these points together and now I have something to be excited about! Next time a small business, aunt, friend asks me to help them with a website, I hope to work with Backdrop. A version of Drupal that gives me the foundation I want as a developer, with modules that work together, and features I demand for the client; a thoughtful UI with the ability to self-update and download new functionality.

As for friends, I am confident recommending they learn Backdrop’s APIs, and in doing so they naturally become competent in Drupal 7’s. They can continue using their Backdrop knowledge for long into the future, and in the next 5 years as they run into that random person with a Drupal 7 site, their knowledge has added value.

Selfishly, Backdrop gives my own Drupal 7 knowledge value. If I run into a random Backdrop site in the future (which I hope to do), I’m ready to roll with it. Without much experience in the actual system, I know that I could make Backdrop sing.

I believe I’m saying that Backdrop’s existence has added value to Drupal 7, and that’s a good thing for everyone.

But what about Drupal 8?

Drupal 8 is here to stay, and that is also incredibly exciting. I love being able to work with Drupal that has a foundation on a different programming style. It is both familiar and challenging, the best of all worlds. Let’s not forget experimental modules which make this the first version of Drupal core that can significantly improve as it ages.

Site building

What’s also great is that all of these systems (Drupal 7 & 8, Backdrop) share incredibly similar UIs. How awesome is that for adding value to site building knowledge!? Let me drive this home.

If you learn to build websites with Drupal 7, 8, or Backdrop, you can do it with the others.

There will be variances for sure, but since they all share the same origins of Drupal core APIs, the similarities will be much greater than the differences, and that is awesome for everyone.

Back to Backdrop

Let’s talk project philosophy. When writing this post I took the time to read all of the mentioned project’s philosophy/mission statements and noticed some subtle but important differences.

Here are the main philosophical points of the following 3 projects. I highly recommend you also read these pages for the sake of completeness, but what I want to draw your attention to is between the lines for the most part.

Drupal Mission & Principles

Values

• Flexibility, simplicity, and utility in our product
• Teamwork, innovation, and openness in our community
• Modularity, extensibility, and maintainability in our code

Principles

• Modular and extensible
• Quality coding
• Standards-based
• Low-resource demands
• Open source
• Usability
• Collaboration

Drupal’s principles and values are significantly based on those of developers and programmers. “Quality coding” and “modular and extensible” are squarely concerns a developer might like to hear when reviewing a project, and as a developer I am glad for them. But how many of these values/principles are focused on the end user? Not many. From these points, I can assume that Drupal is built for developers.

WordPress Philosophy

• Out of the Box
• Design for the Majority
• Decisions, not Options
• Clean, Lean, and Mean
• Striving for Simplicity
• Deadlines Are Not Arbitrary
• The Vocal Minority
• Our Bill of Rights

WordPress strives to make a product for the end user first and foremost. Their first two points, “Out of the box” and “Design for the majority”, are both squarely focused on the end users. “Strive for simplicity” is again about empowering the non-developer site owners to manage their site on their own. But how many of these points are focused on the developers? Not many. From these points, I can assume that WordPress is built for end users.

Backdrop CMS Philosophy

Audience

• Backdrop values site builders over coders
• Backdrop values contrib developers over core developers

Principles

• Backwards compatibility is important
• Write code for the majority
• Include features for the majority
• Ensure Backdrop can be extended
• Meet Low System Requirements
• Plan and schedule releases
• Remain Free and Open Source

Backdrop is explicitly about site builders, but with a heavy nod to the site owners and content creators. “Backwards compatibility is important” and “Include features for the majority” take from the WordPress philosophy in all the right ways, by empowering the site owner with focus on their long term success. And the mere mention of developers/coders at all makes it stand out from WordPress’s philosophy in an important way to me. From these points, I can assume that Backdrop is built with the site owners, builders, and the developers in mind.

Bonus: Contributing

Of the 3 platforms, only Backdrop is using GitHub for contributing. WordPress is using SVN, and Drupal (like drupal do) are maintaining their own system. Talk about a low barrier to entry, today I submitted 2 pull releases to Backdrop core. I’ve never done so for Drupal or WordPress (don’t @ me)

Conclusion

Assuming that these projects continue to be driven by their written philosophies, I think they will each be successful. And that is good.

Backdrop CMS turns Drupal 7- knowledge into Backdrop 1+ value. And that is good.

The next site I build will use Backdrop before WordPress.

If you made it this far, check out Cross-Pollination between Drupal and WordPress by Mike Herchel.