PHP compatibility and project lifecycle
Unknown from the supplied source. The packet does not state WordPress's supported PHP versions, license, or support policy. Verify PHP 8.4 support in official WordPress documentation before use. PHP 8.5 is only planned for this track and is not claimed.
Official sources checked 2026-10-22. Browser lessons on this site run PHP 8.5.
What WordPress is
WordPress is a CMS / content platform with a focus on publishing. It is a finished product built with PHP, not part of PHP itself. PHP core is the language engine and its standard extensions. WordPress is an application that runs on top of PHP. It is not a standalone runtime, not an async library, and not a framework adapter. It is also separate from other CMS products such as Drupal. Drupal is a different CMS, and nothing in this guide describes it.
The only source supplied for this guide is the WordPress Developer Resources landing page. It organizes documentation into these areas: Block Editor, Themes, Plugins, Common APIs and Advanced Administration. It also lists WordPress Playground (described as running WordPress entirely in your browser), a Code Reference, a REST API area, WP-CLI commands, Coding Standards and a Developer Blog. The page mentions changes in a "WordPress 7.1 API" and shows Developer Blog posts dated through October 2026. It does not state a supported-version policy, PHP compatibility, license or release schedule. Those are unknown here and must be checked against official documentation before you rely on them.
Architecture and extension model
The documentation areas on the landing page show how developers are expected to extend the platform:
- Themes control presentation.
- Plugins add or change behavior.
- The Block Editor is the content-authoring surface, and developers can create blocks for it.
- Common APIs and the Code Reference document the functions and classes that themes and plugins call.
- The REST API is presented as a way to build your own apps on WordPress.
- WP-CLI is presented as a way to manage WordPress from the command line.
The page does not explain internal load order, database schema or hook mechanics. For those, read the Code Reference and the plugin and theme handbooks linked from the site. The example below uses a plugin because the page lists plugin authoring as a core developer topic.
Execution and content model
The packet describes WordPress as a publishing CMS, so content is authored and managed through the platform and presented through themes and blocks. The page does not specify storage details, so treat any claim about the database layout as unverified until you read the official documentation.
Classic request lifetime. In the usual PHP model, a web server hands each HTTP request to PHP. PHP builds all application state, handles the request, sends the response, and discards that state. WordPress is conventionally described this way, but the supplied page does not document its execution lifecycle, so confirm it in the official docs.
Persistent workers. Some runtimes keep a PHP process alive across many requests. Swoole and Open Swoole are examples of such tools. They are distinct projects and must not be conflated, and neither is covered by this packet. Whether WordPress supports running in a persistent worker is unknown from the evidence supplied. If you ever experiment with one, plan for state leakage. Anything held in global variables, static properties, singletons, in-memory caches, open connections or the current user and request context can survive into the next request. The result can be one visitor's data appearing in another visitor's response, stale configuration, or memory growth. Cleanup means resetting or rebuilding that state at the start or end of each request, closing or revalidating connections, bounding caches, and recycling workers regularly. Plugins and themes that assume a fresh process are the most likely sources of leaks. Do not assume that any given plugin is safe in a persistent worker.
Practical use cases
Based on the stated focus, the use cases are publishing sites such as blogs, news and documentation. Extension work includes custom themes, plugins, and blocks, and integrations through the REST API. The page also points to administration tasks handled with WP-CLI. Beyond that, the packet does not give more specific guidance.
Installation approach
The packet contains a link for getting WordPress and describes WordPress Playground for running it in the browser, but it gives no installation steps, Docker image names or system requirements. This guide therefore does not invent a Compose file or image tags. For learning, the safest approach is to follow the official installation documentation for your host, or to use Playground for non-PHP-runtime experiments. The example below assumes you already have a working WordPress site and WP-CLI. It targets the learning track's PHP 8.4 only to the extent your WordPress version officially supports it. That support is unknown from this packet, so verify it first. PHP 8.5 is planned for the track but is not claimed here. If you expose any local development server, bind it to 127.0.0.1, and never expose FastCGI to the public network.
Strengths
- A broad documentation surface covering blocks, themes, plugins, APIs and administration.
- A command-line tool (WP-CLI) for repeatable administration.
- A REST API area for building applications on top of WordPress.
- Published coding standards.
- An active Developer Blog, as shown by the dated posts.
Limitations
- The source packet is a single landing page, so versions, PHP compatibility, license, security policy and performance characteristics are all unknown here.
- It is a full CMS product, so it carries more conventions than a small library does. You work inside its hooks and APIs rather than designing your own application skeleton.
- Persistent-worker support is unverified.
- It also needs Composer-free but network-dependent WordPress infrastructure, so it is not a browser exercise.
Deployment
The packet gives no deployment procedure. Follow the official Advanced Administration documentation for hosting, updates, backups and hardening. Do not put secrets in plugin files. Keep database credentials in the site's own configuration as the official documentation directs.
Links
The only official reference used is WordPress Developer Resources, listed in the links section.
Practical examples
These examples have not been run in a live environment yet. Commands and versions follow the official documentation linked on this page; check them before relying on them, and report a problem if one does not work.
Minimal plugin: a shortcode, activated and checked with WP-CLI
A one-file WordPress plugin that registers a shortcode, plus WP-CLI commands to activate it and render it. It assumes an existing WordPress installation and WP-CLI run from the site root. The packet does not document a Docker image, so no Compose file is given.
wp-content/plugins/lp-hello/lp-hello.php
/**
* Plugin Name: LP Hello Shortcode
* Description: Minimal learning plugin that registers the lp_hello shortcode.
* Version: 0.1.0
*/
declare(strict_types=1);
if ( ! defined( 'ABSPATH' ) ) {
exit;
}
function lp_hello_shortcode( $atts ): string {
$atts = shortcode_atts(
array( 'name' => 'World' ),
$atts,
'lp_hello'
);
return '<p>Hello, ' . esc_html( (string) $atts['name'] ) . '!</p>';
}
add_action(
'init',
function (): void {
add_shortcode( 'lp_hello', 'lp_hello_shortcode' );
}
);
Install and run
wp core version
wp plugin list
wp plugin activate lp-hello
wp eval 'echo do_shortcode( "[lp_hello name=Ada]" );'Expected behavior
After activation, the plugin should appear as active in the plugin list. The final command should print a paragraph reading Hello, Ada! If the name attribute is omitted, the output should read Hello, World!
Requires an already installed WordPress site and WP-CLI, plus a PHP version that your WordPress release officially supports; PHP 8.4 support is unverified here. Run commands from the WordPress root. Not a browser exercise. Runs in the classic request model only; persistent workers are not addressed.