Drupal: a PHP CMS and content platform

What Drupal is

Drupal is a content management system and content platform written in PHP. It is an application you install on top of PHP, a web server and a database. It is not a PHP runtime, not an interpreter and not an async library. PHP core is the language engine. Drupal is a large PHP codebase that runs on that engine.

The source for this guide is a single page, the Drupal.org Getting started guide. It is mostly a table of contents, so it supports only a high-level description. Anything it does not state is marked unknown below.

Drupal core, Drupal CMS and the wider ecosystem

The Drupal.org navigation in the source lists Drupal Core and Drupal CMS as separate entries. It also lists modules, themes, recipes, site templates and distributions. Treat these as different things:

• PHP core is the language and its extensions. It is maintained separately from Drupal.
• Drupal core is the base platform that the documentation describes.
• Drupal CMS appears in the navigation as its own product entry. The packet does not explain how it relates to Drupal core, so check the official pages before you assume.
• Distributions are packaged starting points. The page lists several and mentions documentation for Drupal 9 distributions. It does not say whether those distributions are still maintained.
• Modules, themes, recipes and site templates extend or shape a site.

A CMS product is different from a set of reusable framework components. The Getting started page says the "Understanding Drupal" section helps you understand Drupal's framework. It does not say which libraries Drupal is built on, so this guide does not name any.

Architecture and content model

The packet gives no architecture diagram or content-model description. The page does show these concerns:

• a web server, a database server, memory, Composer, PHP and the PHP OpenSSL extension, each with its own requirements page
• Composer-managed dependencies
• a database you create before running the installer
• an installer followed by a status check
• trusted host settings, protection of file directories, and load balancer or reverse proxy guidance
• multisite setups and an Umami demonstration installation profile

From this we can say a Drupal site combines PHP code, a database and a files area. The detailed entity, field and routing model is unknown from this source. For that, read the Understanding Drupal chapter and the Drupal User Guide.

Request lifetime and persistent workers

A classic PHP request lifetime means each HTTP request starts with fresh PHP state. Variables, static properties and objects are discarded when the request ends. Persistent workers such as Swoole, Open Swoole (a separate project from Swoole) or other long-running processes keep one process alive across many requests.

That difference creates state leakage risk. Static properties, singletons, caches, open connections and request-specific data such as the current user can survive into the next request. In a persistent worker you must reset or isolate per-request state, close or validate connections, and bound memory growth, for example by recycling workers.

The source packet says nothing about running Drupal inside a persistent worker. Whether that is supported is unknown, and this guide does not recommend it. Start with the conventional web server and PHP arrangement that the official installation docs describe.

Practical use cases

The source hints at several uses:

• Content-managed sites. The navigation names industry pages such as government, higher education, nonprofit, eCommerce, healthcare and others.
• Accessibility-focused work. There is a dedicated accessibility section.
• Several sites from one codebase. The multisite pages cover this.
• Pre-built starting points through distributions, recipes and site templates.

The packet makes no performance or scalability claims, and this guide makes none either.

Installation approach

The page points to three routes: an Evaluator Guide for quick local testing, a Local Development Guide for the recommended development environment, and an installation guide. Its install headings include installing with DDEV for local development, installing dependencies with Composer, creating a database, running the installer and doing a status check.

The example below follows that DDEV and Composer path. The exact commands and flags are not shown in the packet. They come from general DDEV and Composer usage, so compare them with the linked installation guide before relying on them. Choose the Drupal release and PHP version the official system requirements page specifies. This learning track uses PHP 8.4, with PHP 8.5 planned, but the packet does not confirm that any Drupal release supports either, so that is unknown.

Strengths

• Extensive official documentation covers requirements, installation, administration, upgrading, updating and extending.
• There is a documented local development path using DDEV.
• Composer-based dependency management is part of the documented install flow.
• Distributions, recipes and site templates give reusable starting points.
• A large community presence is shown through forums, Slack, events and partner listings.

Limitations and unknowns

• Current version, PHP compatibility, support or end-of-life dates, and license terms for individual components are not stated in the packet. The page does mention that the documentation text is under Creative Commons Attribution-ShareAlike 2.0 and that PHP code is distributed under the GNU General Public License. Check these on Drupal.org before you decide anything.
• Lifecycle is recorded as unknown because the packet does not state a support status.
• Hosting prices and managed hosting details are unknown.
• Drupal is a full CMS, so it is more than you need for a tiny script or a minimal API.
• It needs a database and Composer, so it is not a browser-only exercise.

Deployment notes

The source lists trusted host settings, securing file directories, using a load balancer or reverse proxy, a relocated web root on shared hosting using a symlink, and a MySQL transaction isolation level setting. Read each before deploying. Keep any development server bound to 127.0.0.1. Never expose FastCGI publicly. This guide contains no cloud provisioning steps.

Using the example

The example is a local DDEV setup. It requires Docker, DDEV and network access, and it is not a browser exercise. A small PHP script reports the host PHP version and two extensions. This is the learning track's own informational check, not an official Drupal requirement list. After running the commands, finish the installer in the browser and compare the result with the official status check.

<?php

declare(strict_types=1);

// Informational check for the learning track (PHP 8.4 target).
// This is NOT the official Drupal requirements list.

echo 'PHP version: ' . PHP_VERSION . PHP_EOL;
echo 'Meets learning track baseline (8.4+): '
    . (PHP_VERSION_ID >= 80400 ? 'yes' : 'no') . PHP_EOL;

foreach (['openssl', 'pdo'] as $extension) {
    echo $extension . ': '
        . (extension_loaded($extension) ? 'present' : 'missing') . PHP_EOL;
}

cd drupal-learn && php tools/status.php
mkdir -p drupal-learn/site
cd drupal-learn/site && ddev config --project-type=drupal --docroot=web
cd drupal-learn/site && ddev start
cd drupal-learn/site && ddev composer create-project drupal/recommended-project .
cd drupal-learn/site && ddev launch