Introduction and Architecture

The name "WordPress" covers several different products, and statements about one are often wrong about the others:

The official explanation describes WordPress as a project "owned by no one individual or company" whose development decisions are made without specific regard to WordPress.com. WordPress.com plans and prices are outside the scope of this sub-section; where a page says "WordPress" it means the self-hosted software.

WordPress is released under the GNU General Public License, version 2 or any later version ("GPLv2 or later"). The GPL gives everyone the right to run, study, modify and redistribute the software, and requires that derivative works that are distributed carry the same licence. The project’s licence page states that it considers plugins and themes to be derivative works, so they inherit the GPL, while acknowledging a "legal grey area" about what counts as a derivative work.

In practice, selling themes and plugins is allowed (customers pay for convenience, support and updates, and receive the GPL freedoms, including redistribution, with the PHP code). Images, CSS and fonts that do not call WordPress code are often licensed separately ("split licensing"), but the WordPress.org theme and plugin directories require everything they host to be GPL-compatible. Running modified code on one’s own server is not distribution, so it does not oblige anyone to publish the changes. The Lumen Press plugin shown later declares License: GPL-2.0-or-later and a License URI in its header, as the Plugin Directory requires. This page is not legal advice.

A must-use plugin is a PHP file placed directly in wp-content/mu-plugins/ (or in the directory set by WPMU_PLUGIN_DIR and WPMU_PLUGIN_URL). The official handbook lists their properties. They are always active, and the only way to disable one is to remove the file. They load before regular plugins, in alphabetical order of file name, so their hooks can affect regular plugins. Only files directly in the directory are loaded, so a plugin in a subdirectory needs a small loader file that requires it. Activation, deactivation and uninstall hooks never run for them, and they do not appear in update notifications: updating them is the site owner’s job.

They are the right place for site-wide policy that must not be switched off from the dashboard by mistake: update filters, security headers, environment-specific behaviour, or the request trace used later on this page. They appear under Plugins > Must-Use in the dashboard and in wp plugin list --status=must-use.

A drop-in is a file with a reserved name placed directly in wp-content/ that replaces a piece of core behaviour. Core looks for each name at a specific point of the bootstrap, so a drop-in runs earlier than any plugin. The list, taken from _get_dropins() in 7.1.3, is:

Source: Code Reference: _get_dropins()

Drop-ins are normally installed by a plugin (a caching plugin writes advanced-cache.php, a Redis plugin copies object-cache.php), and the Plugins screen lists them under Drop-ins. The WP_CACHE constant only tells core to load advanced-cache.php; it caches nothing by itself.

The maintenance drop-in is the simplest one to try. Lumen Press replaces the default "Briefly unavailable for scheduled maintenance" message with its own page, which also sends a Retry-After header:

Source: Code Reference: wp_maintenance()

Core creates the .maintenance file during updates, and wp maintenance-mode activate creates it on demand; with the drop-in above, every request then gets the 503 status, the Retry-After: 600 header and this page.

The drop-in runs from wp_maintenance(), very early in wp-settings.php, before the database connection exists, so it cannot call WordPress functions such as get_option(). A .maintenance file left behind by an interrupted update keeps the site in maintenance mode; core ignores it after ten minutes, and deleting it ends the mode immediately.

The web server sends every request that does not match a real file to index.php (the .htaccess rules on Apache, a try_files line on nginx; see Web Servers: Apache and nginx). index.php only defines WP_USE_THEMES as true and requires wp-blog-header.php, which is short enough to read in full; this is its code in 7.1.3 without the file comment and blank lines:

Source: Code Reference: wp-blog-header.php

The three lines of wp-blog-header.php are the whole lifecycle: load WordPress, run the main query, load a template. WP_USE_THEMES is what makes the template loader pick a theme template; a script that loads WordPress without it gets the API but no theme output.

wp-load.php defines ABSPATH as its own directory, sets a conservative error_reporting() level and looks for wp-config.php, first in ABSPATH and then one directory up, as long as that directory is not another WordPress install. If there is no configuration file at all, it redirects to wp-admin/setup-config.php, the first screen of the installer. wp-config.php defines the database constants, salts, $table_prefix and any other constants, and ends by requiring wp-settings.php. The last lines must stay as they are:

Source: Advanced Administration Handbook: wp-config.php

Constants must be defined above the require_once line: anything defined after it is too late, because wp-settings.php has already applied its defaults. When wp-config.php is moved one level up, ABSPATH must not be changed; wp-load.php finds the file without help. One older book suggests changing ABSPATH in that situation, which breaks the site. Every constant is described in wp-config.php Reference.

wp-settings.php is the real bootstrap. In 7.1.3 it runs these steps in this order; the order explains when a plugin or a theme can use which API.

Source: Code Reference: wp-settings.php

Consequences follow directly from that order. A regular plugin cannot hook muplugins_loaded, which has already fired when the plugin file is included, and a theme’s first useful hook in functions.php is after_setup_theme. is_user_logged_in() and current_user_can() answer reliably only from init onwards. Since 6.7, calling a translation function such as __() before init triggers a "translation loading triggered too early" notice.

Back in wp-blog-header.php, wp() calls $wp->main(), the method that turns a URL into a database query:

Source: Code Reference: WP::main()

wp-includes/template-loader.php decides which file renders the response:

Source: Code Reference: template-loader.php

For a classic theme the included file is a PHP template from the theme, such as single-lp_book.php. For a block theme the hierarchy is resolved against the theme’s HTML templates (and the user’s edited copies stored in the database), and the file actually included is core’s wp-includes/template-canvas.php, which renders the chosen block template. The order in which candidate templates are tried is the subject of Template Hierarchy. When the template finishes, PHP runs the shutdown action and the process ends.

All entry points load the same bootstrap, so plugins and the theme’s functions.php are loaded on every one of them.

Source: Common APIs Handbook: Action Reference

The last row can be checked with wp eval and did_action(): in a WP-CLI process init and wp_loaded report 1, while parse_request, wp and template_redirect report 0.

The order above can be observed on a running site with a must-use plugin that records the time at which each hook fires and writes the result to the debug log at shutdown. It is a development tool, so it does nothing unless the environment type is local.

Source: Advanced Administration Handbook: Must Use Plugins

The plugin registers its callbacks with priority PHP_INT_MIN, so they run before any other callback on the same hook, and the template_include filter with PHP_INT_MAX, so it sees the template that every other filter agreed on. With WP_ENVIRONMENT_TYPE set to local and WP_DEBUG_LOG set to true, a second (warm) request for a book page writes this to wp-content/debug.log. The theme is Twenty Twenty-Five, a block theme, which is why the included file is template-canvas.php:

The absolute times come from PHP’s built-in development server and mean little; the order is the point. Keep such a file out of deployments: the debug log can be publicly readable at its default location.