Concrete CMS: a page-editing CMS for PHP developers

Sources and evidence limits

The only evidence supplied is the landing page of the official Concrete CMS documentation, so anything it does not state is marked unknown. Lifecycle is recorded as unknown because the page does not describe support or release status beyond titling itself Version 9 Documentation.

What Concrete CMS is

Concrete CMS is a content management system, a finished product that people use to build and edit websites. It is not a PHP runtime, an interpreter, an async library or a framework adapter. PHP is the language it is written in and the platform it runs on, and PHP itself stays a separate thing that you install and configure on your host.

The documentation landing page splits its material into audiences. The User Guide covers everything to know before touching code. The Developers section covers extending Concrete with custom Add-Ons, Themes and core development. A Legacy Documentation area holds older material, which you should treat as historical reference rather than current guidance. The assigned focus for this guide is page editing, and the documentation's own framing supports that: it talks about setting up a site and using Concrete before you write code.

PHP core, CMS product and framework components

Keep three layers apart:

• PHP core is the language engine, its standard extensions and the SAPI that runs it (CLI, FPM and so on).
• A CMS product such as Concrete adds a content model, an editing interface, users, themes and extension points on top of PHP.
• Framework components are reusable libraries. The supplied page does not say which, if any, Concrete uses internally, so do not assume a specific framework or component set. Do not confuse Concrete with Drupal either; they are different CMS products with different documentation.

Content and execution model

The sources describe the content model only in outline. The tutorials listed on the landing page mention a calendar built into the core, blocks and block types, export and import of block data using the CIF XML format, edit domains with sitemaps, and customization of the default page title format. Together these suggest a model where pages are composed of blocks, that site content can be exported and imported as XML, and that themes and add-ons customize presentation and behavior. For anything more precise, such as the page-type or permission details, read the Building a website with Concrete guide and the Full Developer Documentation that the landing page links to.

The execution model is not described in the supplied source. This guide therefore does not claim whether Concrete targets classic request lifetimes, persistent workers or both. Treat it as unknown and check the official documentation before attempting any non-standard runtime.

Request lifetimes versus persistent workers

In a classic PHP request lifetime, a web server and PHP-FPM or similar start each request with fresh variables, run the script, then discard state. Leaks are limited by design. Persistent worker runtimes keep the application booted across many requests to avoid repeated startup work.

Persistent workers introduce state leakage. Static properties, singletons, service containers, open database connections, caches, session or user data held in memory, and global variables can survive from one request to the next, so one visitor's data may appear in another's response. Cleanup means resetting or rebuilding per-request state after every request, closing or revalidating connections, restarting workers periodically, and testing with many sequential and concurrent requests. A CMS with editing sessions, permissions and cached page output is a heavy candidate for such leaks. Because the sources do not mention worker support, do not run Concrete under a persistent worker without explicit official guidance.

A related naming point: Swoole and Open Swoole are separate projects with separate documentation. Neither is part of Concrete's documentation supplied here, and nothing in the sources links them.

Practical use cases

Based on the sources, reasonable use cases are editor-managed websites where non-developers change page content, sites that need an event calendar from the core calendar feature, and sites with custom themes or add-ons built by a development team. Whether it suits large-scale, API-first or headless projects is unknown from the supplied evidence.

Installation approach

The landing page points to an Introduction and Installation section under Developers, but its text is not included in the packet. Exact install commands, system requirements, supported PHP versions and database requirements are therefore unknown here. Follow the official documentation for those. The learning track on this site uses PHP 8.4 with PHP 8.5 planned, but whether Concrete supports either version is unknown, so check before you commit to a version.

To make that check easier, the example below is a small host preflight script. It reports your PHP version and SAPI and can test for any extension names you copy from the official requirements. It does not install Concrete and encodes no Concrete requirement of its own. It is a command-line exercise, not a browser exercise.

Strengths

• Separate documentation for users and developers.
• A stated extension model of add-ons and themes.
• Core features that are visible in the tutorials, such as the calendar and block data export and import.
• Ongoing documentation updates: the tutorial list shows entries dated from 2025 and February 2026, though that is not evidence of support status.

Limitations

• The supplied evidence is only a landing page, so architecture, requirements, licensing, pricing and performance are unknown.
• Version 9 is the only version named, and no PHP compatibility is stated.
• Legacy documentation exists and may describe older behavior.
• No deployment guidance appears in the supplied text.

Deployment

Deployment specifics are unknown from the evidence. In general, a CMS is deployed on a host with PHP, a web server and a database, with writable storage areas and backups for content. Confirm each of those requirements in the official docs. Never expose FastCGI publicly, and keep development ports bound to 127.0.0.1 if you test locally.

Links

Use the official documentation site for the User Guide, the Developers section, the installation introduction and the legacy documentation.

<?php

declare(strict_types=1);

if (PHP_SAPI !== 'cli') {
    fwrite(STDERR, "Run this script from the command line only.\n");
    exit(2);
}

$baseline = '8.4.0';

echo 'PHP version: ' . PHP_VERSION . PHP_EOL;
echo 'SAPI: ' . PHP_SAPI . PHP_EOL;
echo version_compare(PHP_VERSION, $baseline, '>=')
    ? "Learning-track baseline (PHP 8.4) is met.\n"
    : "Below the learning-track baseline (PHP 8.4).\n";
echo "Concrete CMS support for this PHP version: unknown here; check the official documentation.\n";

$requested = array_slice($argv, 1);
$missing = [];

foreach ($requested as $name) {
    $loaded = extension_loaded($name);
    echo sprintf('Extension %s: %s', $name, $loaded ? 'present' : 'MISSING') . PHP_EOL;
    if (!$loaded) {
        $missing[] = $name;
    }
}

if ($requested === []) {
    $all = get_loaded_extensions();
    sort($all, SORT_STRING | SORT_FLAG_CASE);
    echo 'Loaded extensions: ' . implode(', ', $all) . PHP_EOL;
}

exit($missing === [] ? 0 : 1);

php preflight.php
php preflight.php mbstring json