Textpattern: a publishing CMS written for PHP

What this project is

Textpattern is a content management system (CMS) for publishing sites. The only supplied source is the index of the official user documentation, which describes itself as documentation for Textpattern's out-of-the-box functionality. This guide is limited to that index.

Classification matters here. Textpattern is a CMS product. It is not PHP core, not a standalone PHP runtime, and not a general-purpose framework. It is also not Drupal: both are PHP CMS products, but they are separate projects with separate documentation, and nothing about one should be assumed for the other. The supplied source does not say how Textpattern is built internally, so this guide does not describe its internals.

What the documentation index tells us

The index groups the official documentation into these areas:

• Installation handling: installing, upgrading, moving an installation, post-install and upgrade routines, multi-site installation, troubleshooting, and configuring a web server.
• Site administration: explanations of principal functionality, user roles and privileges (default publishing roles and the panels they can access), and system security.
• Tags: core tags (a reference, basics of tag use, tags in development) and custom tags (short-tags and shortcodes, with examples).
• Themes: creating, using and sharing themes, plus creating a custom administration theme.
• Development: plugin development and the source code repositories.
• Tutorials and FAQs: a basic tutorial, shortcode examples and common technical questions.

Architecture and content model

From the index alone we can say that Textpattern has an administration side with role-based panel access, a tag system used to build site output, themes, and a plugin mechanism. How tags are parsed, how content is stored, which database is used and how templates are resolved are not stated in the supplied material, so they are unknown here. Read the tag and administration pages before making design decisions.

Execution model: request lifetimes and persistent workers

A classic PHP request lifetime starts the script for each request, builds its state, sends a response and discards that state. A persistent worker keeps one PHP process alive and serves many requests. That can be faster to start, but only if the application is safe to reuse.

The supplied source does not mention persistent workers, so support for them in Textpattern is unknown. Assume the classic model, with a web server configured per the official web server page, unless the official docs say otherwise. Do not treat any worker setup as supported without evidence.

If you ever evaluate a persistent worker, watch for state leakage. Request data can survive in static properties, global variables, singletons, caches, open database transactions, session or user identity, and output buffers. One visitor's data could then appear in another's response. Cleanup means resetting or rebuilding all of that between requests, closing or validating connections, and restarting workers on a schedule or after errors. Swoole and Open Swoole are separate projects. Do not treat them as interchangeable, and do not assume a CMS runs on either.

Practical use cases

The source describes Textpattern as a publishing CMS. Reasonable uses to investigate are editorial sites run by users with different roles, sites styled through themes, and sites extended with custom tags or plugins. The index lists multi-site installation, but we cannot say how well it fits your hosting model.

Installation approach

Follow the official Installing the software page, then the post-install routines, and read the web server configuration page before going live. The index does not state download methods, version numbers, PHP version compatibility, required extensions or database requirements, so all of these are unknown in this guide. Our learning track uses PHP 8.4, with PHP 8.5 planned. Whether Textpattern supports those versions must be confirmed from the official documentation; do not assume it.

The example below does not install Textpattern. It is a small PHP 8.4 preflight script that reads an extension list you maintain and checks a target directory. Fill the list from the official installation page.

Strengths

From the evidence available, the strengths are limited to what is documented: a documentation set that separates installation, administration, tags, themes and development, and a documented role and privilege model for publishing teams. Claims about speed, ease of use or security are not supported by the source and are not made.

Limitations

• Version, PHP compatibility, license, pricing and support status are unknown from the supplied source, so the lifecycle is marked unknown.
• The index does not describe the architecture in detail.
• Persistent worker support is not documented in the supplied source.
• Several documentation items are labeled in development, including tags and the themes and plugins websites. Check their status before relying on them.

Deployment

The documentation lists web server configuration, moving an installation, upgrading and troubleshooting. Use those pages as your deployment checklist. If a PHP FastCGI service is part of your setup, keep it on a private interface or socket and never expose it publicly. For local development, bind any exposed port to 127.0.0.1. Take backups before upgrades or moves, and keep credentials out of version control. This guide gives no provisioning commands.

Next steps

Read the installation, administration and tag pages, then review the roles and system security pages. Runtime PHP examples need a local PHP CLI and are not browser exercises.

{
  "learning_track_php": "8.4.0",
  "extensions": ["json", "mbstring"],
  "note": "Example values only. Replace the extension list with the requirements from the official Textpattern installation documentation."
}

<?php

declare(strict_types=1);

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

$configPath = $argv[1] ?? '';
$target = $argv[2] ?? '';

if ($configPath === '' || $target === '') {
    fwrite(STDERR, "Usage: php preflight/check.php <expected.json> <target-dir>\n");
    exit(2);
}

$raw = is_file($configPath) ? file_get_contents($configPath) : false;
if ($raw === false) {
    fwrite(STDERR, "Cannot read config file: {$configPath}\n");
    exit(2);
}

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

if (!is_array($config)) {
    fwrite(STDERR, "Config must be a JSON object.\n");
    exit(2);
}

$minimum = is_string($config['learning_track_php'] ?? null) ? $config['learning_track_php'] : '8.4.0';
$extensions = is_array($config['extensions'] ?? null) ? $config['extensions'] : [];

$failed = false;

$phpOk = version_compare(PHP_VERSION, $minimum, '>=');
printf("[%s] PHP %s (learning track minimum %s)\n", $phpOk ? 'ok' : 'FAIL', PHP_VERSION, $minimum);
$failed = $failed || !$phpOk;

foreach ($extensions as $name) {
    if (!is_string($name)) {
        continue;
    }
    $loaded = extension_loaded($name);
    printf("[%s] extension %s\n", $loaded ? 'ok' : 'FAIL', $name);
    $failed = $failed || !$loaded;
}

$dirOk = is_dir($target) && is_writable($target);
printf("[%s] target directory %s exists and is writable\n", $dirOk ? 'ok' : 'FAIL', $target);
$failed = $failed || !$dirOk;

exit($failed ? 1 : 0);

mkdir -p textpattern-site
php preflight/check.php preflight/expected.json textpattern-site