The WordPress Request Lifecycle

Phase 1: The Shared Bootstrap (The Common Foundation)

Whether the request is for a public-facing blog post or the admin dashboard, the initial steps of loading the WordPress core are nearly identical.

1. HTTP Request & Server Handling

A user clicks a link, and the browser sends an HTTP request to your web server (e.g., Apache or Nginx). The server's rewrite rules direct all non-file requests to WordPress's universal entry point: index.php.

2. The Initial PHP Load

index.php

This file does very little on its own except define a constant (WP_USE_THEMES) and load the next file.

wp-blog-header.php

This file's primary job is to kick off the loading of the WordPress environment by loading wp-load.php.

wp-load.php

This crucial file defines the ABSPATH constant and searches for your wp-config.php file, allowing it to be securely placed outside the web root.

3. The Engine Room: `wp-settings.php`

Once wp-config.php is loaded, it immediately calls wp-settings.php. This massive file orchestrates the loading of the entire WordPress core:

• Sets Up Environment: Configures versions, constants, and error handling.
• Loads Core Files: Requires all essential function libraries from the wp-includes directory.
• Connects to Database: Initializes the $wpdb global object.
• Loads Plugins & Themes: It loads Must-Use plugins, then network plugins, then all other active plugins, and finally the active theme's functions.php file.
• Initializes Core Objects: Creates global instances of key objects like $wp, $wp_query, and $wp_rewrite.
• Fires the `init` Hook: This is a critical action hook (do_action('init')). Many plugins use this to run their setup code after the core is fully loaded.

Phase 2A: The Front-End Request (Displaying Content)

This path is all about converting a URL into a specific set of posts and wrapping them in the correct theme template.

4. Parse the Request (wp() function)

The wp() function uses the global $wp object to parse the incoming URL against the site's rewrite rules, translating a "pretty URL" like /my-first-post/ into a set of query variables that WordPress understands (e.g., post_type = 'post').

5. Run the Main Query (WP_Query)

The query variables are passed to the main query object, $wp_the_query. Its get_posts() method builds and executes a highly optimized SQL query, fetching the relevant posts from the database.

6. Select the Template (template-loader.php)

This file implements the WordPress Template Hierarchy. It uses a series of conditional checks (e.g., is_single(), is_page()) to determine the exact template file from your theme that should be used (e.g., single.php, falling back to index.php).

7. Render the Page

The chosen template file is loaded. Inside, developers use The Loop (while ( have_posts() )) to iterate through the retrieved post data, using template tags like the_title() and the_content() to display the final HTML.

Phase 2B: The Admin Request (Managing Content)

Admin requests are more direct, calling specific PHP files and using query strings (?key=value) to determine the action.

4. Direct File Execution

An admin URL like /wp-admin/edit.php directly executes that file. Nearly every file in wp-admin starts by loading /wp-admin/admin.php.

5. Admin Bootstrap & Authentication

The admin.php file acts as the gateway. After loading the core, it immediately performs authentication checks, verifying the user is logged in and has the required permissions (capabilities) to access the page.

6. Load Screen-Specific Logic

Execution returns to the original file (e.g., edit.php), which now loads its specific dependencies and processes any URL query variables (e.g., ?post_type=page).

7. Render the Admin UI

The script includes admin-header.php to render the top bar and menu. The main body of the script generates the primary content (e.g., the list of posts), and finally, admin-footer.php closes out the HTML structure.