Backdrop CMS: a Drupal-derived PHP CMS

It relies on one source, the Backdrop documentation landing page. That page is a table of contents, so many details below are marked unknown instead of guessed.

What this project is

Backdrop CMS is a content management system, a CMS product. It is not a PHP runtime, not a PHP framework, and not part of PHP core. The documentation site describes itself as complete documentation for people using Backdrop to build or maintain websites, developers working with Backdrop, and contributors to the project.

The assignment focus describes Backdrop as Drupal-derived, and the documentation has an "Upgrading from Drupal" section. Treat that as a family relationship, not as API equivalence. Do not assume that Drupal modern APIs, Drupal documentation, Drupal modules or Drupal tutorials apply to Backdrop. Check the Backdrop documentation for every API, hook or configuration detail you rely on.

Keeping the layers apart

PHP core is the language engine and its standard extensions. Backdrop is application code that runs on PHP. Drupal is a different CMS product, and this guide does not cover it. A framework component library, such as a router or HTTP package, gives developers parts to assemble. A CMS product ships an administration experience, content handling and an extension system. Backdrop belongs in the CMS group.

Swoole and Open Swoole are separate projects with a shared history. They are persistent-worker PHP extensions, not CMS products. The supplied source says nothing about running Backdrop on either one, so treat that combination as unknown and unsupported until Backdrop's own documentation says otherwise.

Architecture and content model

The landing page lists these documentation areas: Getting started, Upgrading from Drupal, User guide, Add-On Documentation, Developing for Backdrop, Contributors guide, Developer API, and Appendix/reference.

This suggests several things about the product:

• It has a user-facing site-building and maintenance layer.
• It has an add-on system, since add-ons have their own documentation.
• It has a developer API and guidance for developing for Backdrop.
• It has a contribution process.

The page does not describe internal structure, the storage layer, the content entity model, the theming engine, the configuration format or the hook system. All of that is unknown here. Read the Developer API and Developing for Backdrop sections before writing any code.

Execution model

A classic PHP request lifetime starts PHP state for each request, runs the code, sends the response and discards the request state. A persistent worker boots once and handles many requests in one long-lived process, so memory survives between requests.

The supplied source does not say which model Backdrop expects. Do not assume it works under a persistent worker. If you ever test one, the risk is state leakage. Static properties, global variables, singletons, in-memory caches, open database handles, per-user data and current-request objects can all carry over from one request to the next. One visitor's identity or permissions could then reach another visitor. Cleanup means resetting or rebuilding all request-scoped state after every request, closing or validating connections, clearing static caches and recycling workers on a schedule. Without documented support for this model, the safe course is to follow the standard hosting approach in the official documentation.

Practical use cases

The documentation's audiences point to these uses:

• Building and maintaining content-driven websites through the user guide.
• Extending a site with add-ons.
• Writing custom code through the developer documentation.
• Moving a site from Drupal, using the upgrade documentation.
• Contributing back to the project.

The source gives no suitability claims for particular site sizes, traffic levels or industries, so do not infer any.

Installation approach

Start with the Getting started section of the official documentation. This guide does not invent download locations, package names, Composer commands, Docker images or database setup steps, because none appear in the source. Expect a PHP-capable host and some form of persistent storage, but treat exact requirements as unknown until you read the official pages.

The example here is a local preflight helper. It is not a Backdrop installer. It prints your PHP version and checks any extension names you list in a small JSON file. Copy the required PHP version and extensions from the official documentation into that file. The learning track uses PHP 8.4 with PHP 8.5 planned, but Backdrop's compatibility with those versions is unknown from the supplied source. Confirm it in the official documentation before installing.

Strengths

The documentation is organized by audience, so site builders, developers and contributors each get a section. There is dedicated material for Drupal upgraders, a developer API reference and an appendix. Beyond that, the source does not support claims about performance, security or ecosystem size.

Limitations

• Version, PHP compatibility, support status, license and pricing are unknown from the source.
• The lifecycle is recorded as unknown.
• The Drupal relationship can mislead, so verify each API against Backdrop documentation.
• Persistent-worker support is unknown.
• The landing page alone is not enough to design an architecture.

Deployment

Deployment steps are not in the supplied source. Plan using the official documentation and the usual concerns for any CMS: file storage, database backups, configuration management, upgrades and access control. Do not expose development services publicly. If you try a local server, bind it to 127.0.0.1, and never expose FastCGI on a public interface. Test any production deployment in an isolated environment first.

Links

Use the official documentation site for all authoritative details. The example below needs a local PHP CLI only. It is not a browser exercise.

{
  "note": "Copy required values from the official Backdrop documentation. Left empty because the supplied source does not list them.",
  "required_extensions": []
}

<?php

declare(strict_types=1);

$file = __DIR__ . '/requirements.json';

if (!is_readable($file)) {
    fwrite(STDERR, "Cannot read requirements.json\n");
    exit(2);
}

try {
    $config = json_decode((string) file_get_contents($file), true, 512, JSON_THROW_ON_ERROR);
} catch (JsonException $e) {
    fwrite(STDERR, 'Invalid JSON: ' . $e->getMessage() . "\n");
    exit(2);
}

$extensions = $config['required_extensions'] ?? [];

if (!is_array($extensions)) {
    fwrite(STDERR, "required_extensions must be an array\n");
    exit(2);
}

echo 'PHP version: ' . PHP_VERSION . "\n";

if ($extensions === []) {
    echo "No extensions listed. Fill requirements.json from the official Backdrop docs.\n";
    exit(0);
}

$missing = 0;

foreach ($extensions as $name) {
    $loaded = extension_loaded((string) $name);
    echo sprintf("%-20s %s\n", (string) $name, $loaded ? 'loaded' : 'MISSING');
    if (!$loaded) {
        $missing++;
    }
}

exit($missing > 0 ? 1 : 0);

php -v
cd backdrop-preflight
php check.php