Sulu: a Symfony-based headless and traditional CMS

Sources and evidence limits

The only evidence is the landing page of the Sulu 3.x documentation at docs.sulu.io, which is a table of contents with a short introduction. It does not state versions, PHP compatibility, licensing, prices, or support policy, so this guide treats them as unknown. The lifecycle is marked unknown.

What Sulu is

The documentation says Sulu aims to manage business content in a beautiful interface built on solid, extendable, state-of-the-art technology. The assignment describes it as a Symfony-based headless and traditional CMS. Sulu is a CMS and content platform product. It is not a PHP runtime, an application server, or an async library.

Three layers are easy to confuse:

• PHP core is the language and its engine.
• Symfony components and the Symfony framework are building blocks for applications. They are not a CMS product.
• Sulu is a content product built for the Symfony ecosystem. Drupal is a separate CMS with a different architecture, so do not carry Drupal assumptions over to Sulu or the reverse.

The docs index does not describe how Sulu relates to Symfony in detail. Read the Getting Started chapter before relying on specifics.

Architecture as documented

The index shows a modular design. The Bundles section lists ActivityBundle, AudienceTargetingBundle, CategoryBundle, ContactBundle, ContentBundle, CustomUrlBundle, HashBundle, HttpCacheBundle, LocationBundle, MarkupBundle, MediaBundle, PageBundle, PersistenceBundle, PreviewBundle, ReferenceBundle, RouteBundle, SearchBundle, SecurityBundle, SnippetBundle, TagBundle, TestBundle, TrashBundle and WebsiteBundle. Together these suggest separate responsibilities for pages, media, routing, search, security, previews and caching. Bundle internals are not in the supplied text.

The docs also mention an extendable Admin UI, with cookbook entries on adding tabs and building the administration frontend application. They also mention Elasticsearch, Varnish caching, and storing media in external storage. Treat these as topics to study, not as claims about default behavior.

Content model

The Book chapters outline the model: creating a page template, rendering pages with Twig, the Sulu content architecture, setting up a webspace, configuring image formats, adding localizations, and using smart content. The cookbook adds snippets for page-independent data and extending DimensionContent. From this you can infer that content is organized by templates, webspaces and localizations, and that Twig is the documented way to render pages on the website side. The exact definitions are in the linked docs.

The headless side is stated by the assignment focus only. The index does not describe any API, so how a headless setup works is unknown from this source.

Execution model

In a classic PHP request lifetime, the web server hands each request to a fresh PHP process or worker. Request-scoped state is created and discarded on every request. Persistent workers, as offered by some runtimes and adapters, keep the application in memory across requests. Swoole and Open Swoole are separate projects, and neither is the same thing as PHP core.

The supplied source does not say whether Sulu supports persistent workers. Assume nothing. If you ever run a Symfony-based CMS in a persistent worker, plan for state leakage:

• Static properties, singletons and service instances can keep data from one request and expose it to the next.
• User identity, locale, webspace selection, and request-analyzer results must be reset for every request.
• Open database connections, entity manager contents and caches can go stale.
• Cleanup means resetting or clearing request-scoped services after each request and restarting workers on a policy. Verify this in the official documentation for your setup.

The cookbook entries on the RequestAnalyzer, ESI requests, user context caching and multi-server setups all touch on request-dependent state. Read them with this concern in mind.

Practical use cases

Based only on the docs outline, Sulu fits sites where editors manage structured business content: multilingual pages, media libraries, reusable snippets, filtered lists via smart content, sitemaps and analytics. Teams already working with Symfony may find the bundle model familiar. Whether it is a good fit for your project is a judgment you should make after reading the docs.

Installation approach

The index links to a Getting Started chapter and a System Requirements reference, but their contents are not in the supplied source. This guide therefore gives no install commands and no package names. The approach is to open Getting Started, then System Requirements, and follow them exactly. Check the required PHP version there. This learning track uses PHP 8.4, with PHP 8.5 planned, but Sulu support for either is unknown from the supplied source.

The example below is a small, standalone preflight script. It does not install Sulu. It checks your local PHP against the learning track and prints the documentation sections to read.

Strengths

The documentation is organized into The Book, Cookbook, Reference, Bundles, Developer Guide and Upgrades. It covers upgrade paths, including 2.6 to 3.0, 1.6 to 2.0, and between 2.x and 3.x. A backwards compatibility promise page exists, though its terms are unknown here. The cookbook covers production topics such as HTTPS, Varnish, maintenance mode and server configuration.

Limitations

• The source gives no version, license, price or support status.
• PHP 8.4 and PHP 8.5 compatibility is unknown.
• Headless capabilities are not described in the source.
• Persistent-worker support is unknown.
• Runtime-style Sulu examples would need Composer, a database and other services, and are not browser exercises.

Deployment

The Book has a Deployment chapter, and the cookbook has Server Configuration, HTTPS, Caching with Varnish, Running Sulu in a Multi-Server Setup and Securing your application. Use them as your deployment checklist. Bind development ports to 127.0.0.1, and never expose FastCGI publicly. Do not copy configuration from unofficial sources without comparing it to the docs.

Links

The official documentation at docs.sulu.io is the only source used here.

{
    "name": "learnphponline/sulu-preflight",
    "description": "Local preflight checklist for evaluating Sulu from its official documentation.",
    "type": "project",
    "require": {
        "php": ">=8.4"
    }
}

{
    "source": "https://docs.sulu.io/",
    "sections": [
        "The Book: Getting Started",
        "Reference: System Requirements for Running Sulu",
        "The Book: About the Sulu Content Architecture",
        "The Book: Setup a Webspace",
        "The Book: Deployment",
        "Cookbook: Server Configuration",
        "Cookbook: Running Sulu in a Multi-Server Setup",
        "Developer Guide: Upgrades"
    ]
}

<?php

declare(strict_types=1);

$checklistPath = __DIR__ . '/../data/checklist.json';
$raw = file_get_contents($checklistPath);

if ($raw === false) {
    fwrite(STDERR, "Cannot read checklist: {$checklistPath}\n");
    exit(2);
}

$checklist = json_decode($raw, true, 512, JSON_THROW_ON_ERROR);

$phpOk = version_compare(PHP_VERSION, '8.4.0', '>=');

echo 'Local PHP version: ' . PHP_VERSION . PHP_EOL;
echo 'Learning track baseline (PHP 8.4): ' . ($phpOk ? 'OK' : 'NOT MET') . PHP_EOL;
echo 'Sulu PHP requirements: unknown here; read the official System Requirements page.' . PHP_EOL;
echo PHP_EOL . 'Read these sections at ' . $checklist['source'] . PHP_EOL;

foreach ($checklist['sections'] as $index => $section) {
    echo sprintf('%d. %s', $index + 1, $section) . PHP_EOL;
}

exit($phpOk ? 0 : 1);

php bin/preflight.php