CMS / content platform12 min readNot archived on GitHub

Silverstripe CMS: a CMS module on top of Silverstripe Framework

A guide to Silverstripe CMS, a PHP content management system that is a module for Silverstripe Framework rather than a standalone app, with a Composer install check.

PHP compatibility and project lifecycle

Supported PHP versions, Silverstripe release lines and lifecycle status are unknown from the supplied source. The learning track uses PHP 8.4 with PHP 8.5 planned, so confirm compatibility in the official requirements before use. The check script uses only plain PHP 8.4 syntax.

Official sources checked 2026-10-22. Browser lessons on this site run PHP 8.5.

Sources and evidence limits

It relies on one source, the public repository page for silverstripe-cms. That page is incomplete for many practical questions, and this guide says "unknown" where it is silent.

What this project is

Silverstripe CMS is a PHP content management system. The repository description says it is a module for Silverstripe Framework rather than a standalone app. The README adds that it requires the framework module and a silverstripe-installer base project. The repository is public, carries the BSD-3-Clause license, and its README points to the getting started documentation for installation.

This is a CMS product, not a PHP runtime. It does not replace PHP, execute PHP code by itself, or provide a server. It is PHP application code that runs on whatever PHP environment you deploy it to. Keep these layers separate:

  • PHP core is the language and its engine.
  • Silverstripe Framework is the underlying framework module that the CMS builds on.
  • Silverstripe CMS is the content-management layer added on top of that framework.
  • The installer project is the base project that wires the pieces together.

The same distinction applies elsewhere. Drupal, for example, is a CMS product, and PHP itself is a separate project. A framework component is a library you assemble yourself, while a CMS product ships an editing experience.

Architecture and content model

The repository listing shows a conventional module layout: a code folder for PHP classes, a templates folder, a lang folder for translations, a client folder with front-end assets and build tooling, a _config folder with a _config.php file, and a tests folder. Tooling files suggest PHPUnit, PHPStan, PHP_CodeSniffer, Behat, ESLint, Stylelint, webpack and Babel are used in development.

The source does not describe the data model, page types, templating syntax, permission system or extension API. This guide does not describe them either, so use the official documentation for those. The takeaway is structural: the CMS is a module that depends on the framework, and your site is a base project that requires both.

Execution model

The source does not state the execution model. A module of this kind would normally be loaded by a web server and PHP process in the classic request lifetime, where each request boots, handles input, sends a response and discards its in-memory state. The source does not confirm this, and it says nothing about persistent workers.

If you ever consider running any PHP application inside a persistent worker, the difference matters. In a persistent worker the process outlives the request, and anything stored in static properties, singletons, container services, global variables or open resources can leak into the next request. Examples are the previous user's identity, cached per-request data, an open transaction or a half-built response. Cleanup means resetting or recreating that state at the end of every request, closing connections, and testing that two consecutive requests with different users cannot see each other's data. Whether Silverstripe CMS supports persistent workers is unknown from the supplied source. Do not assume it does. Swoole and Open Swoole are separate projects, and neither is mentioned by the source.

Practical use cases

The source only identifies the project as a PHP CMS. Typical fits for a CMS of this kind are editor-managed websites where non-developers change content, with developers extending the code in a project. Whether it suits a particular use case, such as multilingual sites, large editorial teams or headless delivery, is not established by the source. The lang folder only shows that translation files exist.

Installation approach

The README says not to install the CMS module on its own. It says to use the silverstripe-installer base project and to read the getting started documentation. The example below uses Composer to create a project from the installer. The package name silverstripe/installer is inferred from the repository name and is not stated in the supplied page, so check it against the getting started documentation before running anything.

The example does not include a web server, database configuration or Docker Compose file. The source gives no evidence for them, so inventing image tags or server settings would be unsafe. If you run a development server later, bind it to 127.0.0.1 only. Never expose FastCGI publicly.

Strengths

  • The repository is public and uses the permissive BSD-3-Clause license.
  • A clear separation exists between the framework and the CMS module.
  • It has a documented installer route and a documented contribution process.
  • The test and lint tooling in the repository suggests an active engineering process, although that is not proof of quality or of current maintenance.

Limitations and unknowns

  • Lifecycle is unknown. The supplied page shows stars, forks, issue counts and a commit count, but gives no release, support or end-of-life information.
  • Supported PHP versions are unknown. This learning track uses PHP 8.4, with PHP 8.5 planned, but you must confirm compatibility in the official requirements before using any Silverstripe version.
  • Current versions, performance behavior and hosting prices are unknown.
  • It cannot be installed alone. The framework and installer project are mandatory.
  • Runtime PHP examples like this one need Composer and network access. They are not browser exercises.

Deployment

The source gives no deployment instructions. As a general approach, you would build the project with Composer in a controlled environment, keep configuration and credentials outside version control, and serve it through a standard PHP web stack. Verify every detail against the official documentation. Treat the CMS repository as one piece of the site, not as the deployable unit.

Example in this guide

The example creates a base project through Composer and then runs a small plain-PHP script. The script reads the generated composer.lock and reports whether packages named silverstripe/cms and silverstripe/framework are installed. This shows the CMS-versus-framework split in your own project without calling any Silverstripe API. The script is ordinary PHP 8.4 syntax, but that says nothing about whether the installed Silverstripe version supports PHP 8.4.

Links

The only official source supplied is the silverstripe-cms repository. The README links to the getting started documentation, requirements and changelogs, but those URLs were not supplied as sources, so they are not listed here. Follow them from the repository page.

Practical examples

These examples have not been run in a live environment yet. Commands and versions follow the official documentation linked on this page; check them before relying on them, and report a problem if one does not work.

Create an installer project and verify the CMS and framework packages

Uses Composer to create a Silverstripe base project, then runs a plain PHP CLI script that reads composer.lock and reports whether silverstripe/cms and silverstripe/framework are present. The installer package name is inferred from the repository name and must be checked against the official getting started documentation.

check-stack.php

<?php

declare(strict_types=1);

// Usage: php check-stack.php silverstripe-site/composer.lock
$path = $argv[1] ?? 'composer.lock';

if (!is_file($path)) {
    fwrite(STDERR, "Lock file not found: {$path}\n");
    exit(1);
}

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

$packages = array_merge($data['packages'] ?? [], $data['packages-dev'] ?? []);
$found = [];

foreach ($packages as $package) {
    $name = (string) ($package['name'] ?? '');
    if (str_starts_with($name, 'silverstripe/')) {
        $found[$name] = (string) ($package['version'] ?? 'unknown');
    }
}

ksort($found);

foreach ($found as $name => $version) {
    echo $name . ' ' . $version . "\n";
}

$missing = 0;
foreach (['silverstripe/cms', 'silverstripe/framework'] as $required) {
    $present = isset($found[$required]);
    echo $required . ': ' . ($present ? 'present' : 'MISSING') . "\n";
    if (!$present) {
        $missing++;
    }
}

exit($missing === 0 ? 0 : 2);

Install and run

composer create-project silverstripe/installer silverstripe-site
php check-stack.php silverstripe-site/composer.lock

Expected behavior

Composer creates the silverstripe-site directory with a composer.lock. The script then lists installed packages whose names start with silverstripe/ and prints present or MISSING for silverstripe/cms and silverstripe/framework. It exits 0 when both are present and 2 if either is absent. Exact package names and versions are not confirmed by the source.

Requires Composer, a PHP CLI and network access. The package name silverstripe/installer is inferred and unverified. It does not configure a database or web server, or start the site, so it is not a browser exercise. PHP 8.4 support for the installed Silverstripe version is unknown.