MODX Revolution: a PHP CMS and content framework

It relies only on the public repository page for MODX Revolution.

What MODX is

The repository describes MODX Revolution as a "Content Management Framework" and as a "Content Management System and Application Framework". It is a CMS product written in PHP, and its topics include content-management, modx and php. The README says it can power multi-language, multi-domain corporate sites, personal blogs and mobile APIs. It also says you control the markup and design without having to code. Those are the project's own claims. The README's "fastest, most secure" wording is marketing, and this guide has not verified it.

What it is not

MODX is an application that runs on PHP. It is not a PHP runtime, an interpreter, an async library or a framework adapter. It is also not part of PHP core. The same distinction applies elsewhere in the ecosystem. Drupal CMS is a product built on a framework's components, which are not the product itself. Swoole and Open Swoole are separate projects and should not be conflated. None of them is relevant to MODX unless official MODX documentation says so, and the supplied source says nothing of the kind.

Architecture as visible in the repository

The top level of the repository lists these entries:

• core, manager and connectors directories.
• A setup directory.
• A _build directory and a .github directory.
• index.php and composer.json.
• A file named ht.access.
• package.json and package-lock.json.
• Lint and coverage configuration files.

From the names alone, core likely holds the engine, manager likely holds the admin interface, connectors likely serve requests from that interface, and setup likely holds the installer. The page does not describe these roles, so treat them as hints and read the official documentation to confirm. The presence of package.json suggests some JavaScript tooling, but the page does not say what it is used for.

Execution and content model

The source does not describe how a request is processed, so the exact model is unknown here. A conventional PHP CMS starts a fresh request lifetime for each HTTP request. Memory is released at the end, and state lives in a database or the filesystem. The source does not confirm this for MODX, and it does not document any persistent-worker mode.

This matters because persistent workers behave differently. A worker boots once and serves many requests. Static properties, singletons, caches, open connections, the current user and request objects can then leak from one request to the next. Safe use requires resetting or rebuilding request-scoped state, closing or validating connections, and testing with interleaved users. Do not run MODX under a long-lived worker unless official sources explicitly support it.

For content, the README mentions controlling markup and design, lexicons translated on Crowdin, and an extensible core. It does not define resources, templates or extras, so this guide does not explain them. Consult the official documentation for that terminology.

Practical use cases

Based on the README, plausible uses are:

• Corporate sites in several languages or on several domains.
• Personal blogs.
• Content-backed APIs for mobile clients.

Whether MODX is the better choice than another CMS depends on your team's skills, hosting and extension needs. The source offers no comparison, so none is made here.

Installation approach

The README points to several routes: downloading MODX Revolution, a requirements page, an installation guide, installing via git, and an upgrade guide from 2.x to 3.0. The documentation URLs are not in the supplied evidence, so this guide does not reproduce them or paraphrase their steps. Follow the official instructions for requirements and the installer.

The example below does something smaller and safer. It clones the repository and runs a small PHP script that checks the layout described above. It does not install, configure or run MODX, so it is not a working CMS.

Strengths

• A GPL-2.0 license is shown on the repository page. The README also says GPL version 2 or, at your option, any later version.
• Visible project hygiene: a security policy, a code of conduct, contributing guidelines and an AI policy file.
• An established repository with a long history: 12,689 commits, 1.4k stars and 529 forks at the time of the page snapshot.
• Extensibility and control over markup, according to the README.

Limitations and unknowns

• Supported PHP versions: unknown. Compatibility with the PHP 8.4 learning track, or planned 8.5, is not established.
• Current release number and support window: unknown.
• Required database and web server settings: unknown from the supplied source.
• Official container images or a documented Docker setup: none in the evidence, so no Compose file is given.
• Hosting prices and performance figures: unknown, and none are claimed.
• The page shows 596 open issues and 130 open pull requests, which is a snapshot rather than a health verdict.

Because lifecycle evidence is incomplete, the lifecycle is marked unknown. Do not read that as either an endorsement or a deprecation.

Deployment notes

The source gives no deployment procedure. Sensible general practice still applies. Follow the official install guide and the SECURITY file for reporting vulnerabilities. Keep credentials out of version control. Never expose a development server beyond 127.0.0.1. Never expose FastCGI publicly. The ht.access file is listed under that exact name, and its purpose and handling are not described, so rely on the official guide for it. Plan and test upgrades, especially from 2.x to 3.0, against a copy of your data first.

Classic request lifetime versus persistent workers

In a classic setup, PHP-FPM or an Apache module starts each request fresh, and leaks are bounded by that request. In a persistent worker, you must audit global and static state, reset per-request services, close handles and clear caches that depend on the user. MODX's behavior in that environment is unknown from the supplied material, so assume classic request handling only after confirming it in the official documentation.

Next steps

Run the layout check, read the README's linked installation and requirements pages, and then plan an isolated integration test on a PHP version the official docs confirm. Any real MODX install should be reviewed by a human before you rely on it.

<?php

declare(strict_types=1);

// Usage: php check-layout.php [path-to-checkout]
$root = rtrim($argv[1] ?? 'modx-revolution', '/');

$directories = ['_build', 'connectors', 'core', 'manager', 'setup'];
$files = ['composer.json', 'index.php', 'README.md', 'LICENSE', 'SECURITY.md'];

if (!is_dir($root)) {
    fwrite(STDERR, "Checkout not found: {$root}\n");
    exit(2);
}

$missing = 0;

foreach ($directories as $name) {
    $ok = is_dir($root . '/' . $name);
    echo ($ok ? 'ok      ' : 'MISSING ') . 'dir  ' . $name . "\n";
    if (!$ok) {
        $missing++;
    }
}

foreach ($files as $name) {
    $ok = is_file($root . '/' . $name);
    echo ($ok ? 'ok      ' : 'MISSING ') . 'file ' . $name . "\n";
    if (!$ok) {
        $missing++;
    }
}

if ($missing > 0) {
    echo "{$missing} expected entries missing.\n";
    exit(1);
}

echo "All expected entries found. This does not install or run MODX.\n";

git clone https://github.com/modxcms/revolution modx-revolution
php check-layout.php modx-revolution