Backdrop CMS: a Drupal fork that kept the learning curve short

A fork of Drupal with ease of use as the stated goal

Backdrop describes itself as a fork of Drupal, and the reason for the fork is stated in the developer section: it preserves the legacy audience of developers who value ease of use and speed of learning over architectural flexibility. That sentence is the whole design brief, and it explains most of what distinguishes Backdrop from other PHP CMSes.

The stated aims are three. A CMS that can be used out of the box. Code that can be learned quickly. Extensible APIs. The middle one is the differentiator, and it is a constraint rather than a feature: a codebase that a new contributor can read is one that avoids the accumulated abstraction layers that make large frameworks hard to enter.

The result is aimed at non-technical users managing content, and the project lists the site types it suits as blogs, image galleries, social networks and intranets, with the phrase "and more" left open. The homepage is `backdropcms.org`, and the user-facing documentation lives in the Backdrop Handbook at `docs.backdropcms.org`, with API documentation kept separately.

The repository layout is the standard CMS shape and worth reading as a map. `core/` holds the framework, `modules/` the bundled and contributed modules, `themes/` the themes, `layouts/` the layout templates, `files/` the upload directory, `sites/` the site-specific configuration, and there is a `settings.php` at the root next to `index.php` and `robots.txt`. A `.htaccess` sits alongside them, which is the Apache configuration file that the project also lets you replace with Nginx rules.

Version numbers that arrive in pairs on the same day

The release history is the most surprising thing in the repository, and it deserves reading carefully.

Three tagged versions are listed, and two of them were published on the same day. Version 1.34.6 and version 1.35.2 were both published on 2026-10-14, with 1.35.2 created 46 seconds after 1.34.6. Version 1.35.1 came earlier, on 2026-09-24. The last push was on 2026-10-15, the day after those two tags.

The pattern is a maintenance branch and a feature branch released side by side. A site that wants only fixes takes 1.34.6, and a site that wants the current 1.35 line takes 1.35.2. The default branch of the repository is `1.x`, which is consistent with a single major line carrying both.

For an adopter this has a concrete consequence. You are not choosing between "stable" and "latest", you are choosing between two minor versions that are both supported, and the two lines will receive different fixes at different times. The README does not spell out the branching policy, so a team that needs to know which line receives security fixes would need to check the release notes and the issue tracker.

The security process is documented, at least in outline. Security issues are handled separately in a private repository until the issue has been resolved, and the request is to contact the security team directly at `[email protected]` before filing a public issue, even when you are not certain it is a security problem. That is a mature convention and worth taking at face value for a project with this release cadence.

The install path is a browser-driven installer, not a CLI

Installation for Backdrop is a web installer reached through the browser, and the first step is the database. The documented sequence is to create a new database, username and password in MySQL for Backdrop to use, then point a browser at the URL of the installation. If the redirect does not happen automatically you visit the install URL directly, and the documentation gives a concrete example: if Backdrop was installed at `http://example.com/backdrop`, the install URL is the `core/install.php` path under it.

http://example.com/backdrop/core/install.php

From there the installer walks you through the remaining steps. The whole flow assumes the web server is already serving the directory, so the host configuration work happens before anything in the application does.

The server requirements are stated plainly. PHP 7.1.0 or higher, with the note that even if Backdrop can run on older PHP versions the project strongly recommends using a supported version of PHP. MySQL 5.5.0 or higher with PDO enabled. Apache, which is the recommendation, or Nginx. And disk space of 50 MB recommended, 15 MB minimum.

That disk figure is a useful signal about the shape of the system. A CMS with a 50 MB recommended footprint has a small one, which is consistent with a codebase that is meant to be read and modified rather than extended with large contributed modules.

The module ecosystem is a fork of its own, not Drupal's

The single most consequential thing about Backdrop for a Drupal developer is the module boundary, and the project is explicit about it. Contributed modules live in their own organisation, `backdrop-contrib`, separate from the core repository. The security section points to that organisation when it asks you to report a problem in Backdrop or in any of its contributed modules.

The reasoning behind the split is documented, at least for issues. The project uses a separate issue tracker that is not part of the main code repository because of GitHub's restrictions on the use of labels and issue management. So bug reports and feature requests go to `backdrop/backdrop-issues`, while the code lives in `backdrop/backdrop` and modules live in `backdrop-contrib`.

This is where the fork's promise costs something. A Drupal developer arriving with a library of existing modules cannot assume compatibility, because a module written for Drupal is not automatically one that works on a fork with reworked internals. The `core/` and `modules/` directories at the repository root are where the built-in functionality lives, and a module's fitness for Backdrop is a per-module question.

The contribution route for core itself is conventional and documented. You fork the repository on GitHub, create a pull request that references an issue in the separate issue tracker, and the details are in the contribute-to-backdrop-core documentation. Core code carries a copyright notice running from 2001 to 2026, which reflects the Drupal inheritance rather than the age of the fork.

Apache and Nginx are both supported, and the rewrite rules live in .htaccess

Backdrop is a PHP application with a front controller, and the repository shows how the routing is wired. The root contains `index.php`, which is the entry point, alongside `robots.txt` and `settings.php`. The `.htaccess` file in the root is the Apache configuration file.

Apache is the recommended server, and Nginx is supported. That distinction is not cosmetic. An `.htaccess` file only does something on Apache, so a deployment on Nginx needs the equivalent rules written into the server configuration by hand. If you are deploying on Nginx, that translation is your first task, not an afterthought.

The `settings.php` file at the root is where the database credentials, the base URL and the site configuration go. The file sits outside `sites/`, which holds per-site configuration, so the structure supports several sites sharing one codebase, which is what multi-site deployments in this family of CMSes normally mean.

The `.tugboat/` directory at the repository root is worth noting for anyone who wants a disposable environment. The sponsorship list credits Tugboat for powering the demo site sandboxes, and ZenCI for continuous automated testing and sandbox testing, so there is an automated test story behind the project even though the README does not describe the test suite itself.

A permissive reading of GPL v2, with a caveat about bundled works

The licence is GPL v2 or higher, and the README adds a specific permission that is easy to miss: distributions of this software may relicense it as any later version of the GPL. In practice that means an organisation shipping Backdrop can distribute it under GPL v3 terms if it wants to, which is more freedom than a plain GPL v2 grant gives you.

The project also states that Backdrop includes works under different copyright notices distributed according to the terms of the GNU General Public License or a compatible license, and that these individual works may have specific copyright information noted within their source code files or directories. That is the standard statement for a codebase carrying inherited code, and it means the licensing question for a specific file can differ from the licensing question for the project as a whole.

This is a licensing observation rather than legal advice. The `LICENSE.txt` file in the repository is the text that governs, and for a distribution with a commercial requirement, the file-level notices are the thing to check.

The remaining institutional detail is the sponsorship list, which is a good indicator of where the project's operational costs sit. BrowserStack provides interface testing across desktop and mobile browsers, JetBrains provides a PHPStorm licence, Fastly provides CDN services for all `backdropcms.org` properties, GitHub provides collaboration tools, SendGrid handles email delivery, 1Password holds the passwords, Linode provides hosting, and Tugboat powers the demo sandboxes. Nothing in that list changes how you run the CMS, but it does tell you which services the project depends on to keep operating.

Editorial conclusion

Backdrop suits a team that wants a conventional, readable PHP codebase for a content site and values an editor experience that works without a rebuild, particularly for intranets, small institutional sites and community sites run by volunteers. It does not suit a developer whose plan depends on dropping in existing Drupal modules, because the fork carries its own module ecosystem under `backdrop-contrib`, and it does not suit a project that needs to run on an unsupported PHP version, since the project asks for PHP 7.1.0 or higher and a supported release of PHP. Verify first that the installer at `core/install.php` completes against your MySQL instance, that a contributed module you depend on has a Backdrop-compatible release, and that the version you deploy matches the branch you tested, since the repository default branch is `1.x` and tags 1.34.6 and 1.35.2 were both published on 2026-10-14.

Frequently asked questions

Official sources

1. backdrop/backdrop on GitHub
2. License: GPL-2.0
3. Project website
4. README
5. Releases