A recent comment on a LinkedIn post of ours inspired us to cover Backdrop CMS…
What is Backdrop CMS?
Backdrop CMS is a free and open-source content management system (CMS) that can be used for designing a range of websites from a one-person business or blog to a multi-level eCommerce site.
Backdrop CMS aims to offer useful features, but only those that are totally necessary for most websites. You can add themes, layouts and modules to the site.
It’s essentially Drupal 7 under the hood, but with some extra features that aren't in Drupal core. Backdrop has Views, WYSIWYG and a configuration management system in core.
Backdrop CMS History
Backdrop is an offshoot or fork of Drupal 7 with additional work done on top. It was forked from the Drupal project just before the inclusion of Symfony into Drupal. It, therefore, contains very little in the way of object-oriented code and doesn't support composer.
Although it shares a common codebase with Drupal, it has a distinct philosophy. Backdrop values the needs of the editor over the needs of the developer, but will listen to the needs of the contributed developer space over the need for core requirements.
Advantages of Backdrop CMS
- Drupal 7 and Backdrop have the same advantages, but they differ in some aspects.
- As it contains no object-oriented code, dependency management or third party components it requires little technical knowledge
- Features added aim to benefit the majority of sites using it
- Low and basic system requirements (which means affordable hosting)
- Some features not found in Drupal core are packaged into Backdrop core
Disadvantages of Backdrop CMS
- Drupal 7 modules are not compatible with backdrop CMS. Although Backdrop states 90% of the most popular modules have been ported
- The Backdrop community is still quite small
- As Backdrop is based on Drupal 7 it still suffers from the same security issues that Drupal 7 has/had
- Most Drupal developers are concentrating on working with Drupal 8 and aren't interested in porting their modules over to Backdrop
- Backdrop has no official support for composer. Although third-party forks are integrating composer into Backdrop this is not part of the official package. This makes package management using composer challenging. It could be argued that composer isn't needed with Backdrop.
Why was Drupal forked?
The four main reasons were this:
Technical differences
When large, system-wide, changes were being proposed for Drupal 8 there was a minority of users who weren't keen on the changes. They said they liked the proven success of the architecture of Drupal 7 and saw no need to change.
There was also the inclusion of the composer dependency manager. The inclusion of composer was essential for keeping track of the different third party packages in Drupal, as well as integrating new modules and themes into the system. Composer can be challenging to use. Improper use can create problems with circular dependencies.
The fork of Backdrop happened just before the inclusion of composer. At the time, composer was being introduced to add the HTTP client Symfony component.
Diverging priorities
The Backdrop community has different issues and priorities to the Drupal community. When the community priorities change, the code has to follow.
For example, you probably won't see any new core modules being introduced to Drupal 7. At least, not at this point in its lifespan with support officially dropping for Drupal 7 in 2022. This is different to Backdrop, which has introduced the modules like Views and Redirects into the core system. The reason being, everyone is using them, so why not make them a core part of the system?
Drupal and Backdrop have configuration management as a feature. However, they’re implemented differently. Backdrop stores the configuration in JSON files without a required database cache. This is because it suits the principles of speed, performance and simplicity.
Target audience
Backdrop is intended by non-profits, SMEs and educational institutions. It’s for those who want the functionality of Drupal 7 and who don't want to upgrade to Drupal 8.
At the time of developing Drupal 8 there was momentum towards supporting high-end, enterprise-level organisations with vast and complex requirements. Backdrop was created to give a voice to the smaller organisations that needed a decent website. We recently covered if Backdrop CMS is a good alternative to LocalGov Drupal.
Decision making
Why is Drupal 7 so different from Drupal 8? It’s probably because of how decisions were made about the project. Many Drupal developers were getting frustrated that Drupal was being left behind in the PHP world and so opted to start introducing Symfony components to start leveraging component-based architecture.
The developers who were quite happy with how Drupal worked and didn't want this change were ignored. Backdrop CMS has its own principles and ways of managing conflict.
Should you go with Drupal or Backdrop CMS?
It depends!
On one hand, Backdrop is simple to maintain and has a low footprint. On the other, it is considered by some to be a weaker methodology and containing outdated technology.
It has lead to confusion for users and developers and there are some compatibility issues. Drupal 8 offers some migration modules which were made for Drupal 7 sites. There are also ways to update Drupal core, too.
Picking Backdrop is a simple solution for those who don’t wish to work on their coding skills. Forking Drupal to create your own version is often a result of considerations based on financial limitations and the skills of the development team. The general rule of "don't hack core" doesn't always apply if you don't have the skills to implement the needed hooks.
If you are a Drupal 7 expert, there's a good chance you'll feel at home in Backdrop.
Some might opt for Backdrop as an easier route, rather than keeping up with Drupal (which is constantly changing, updating and improving). Drupal 9 is here and has the backward capability within Drupal 8. There are richer features en route to Drupal 10, too.
More and more organisations are moving to Drupal from their current system because they know it can manage their accelerated growth. Also, it too doesn’t need a host of developers for successful migration!
Ultimately, the choice is yours. It depends on your organisation, project needs, internal expertise, time, resource, budget and even company values.