🏛️ WordPress Core Architecture

What WordPress Really Is

WordPress began in 2003 as a blogging tool. Twenty years later it is a full-featured content management system (CMS) released under the GPL, running everything from personal journals to enterprise publishing platforms and e-commerce stores. Its dominance is not an accident — it rests on a small set of architectural decisions that traded raw purity for practical flexibility.

💡 A useful analogy: Think of WordPress like a modern apartment building. There is shared core infrastructure you never modify (plumbing, wiring, the elevator = core files), a records office that tracks who lives where (the database), and units that tenants decorate freely (themes and plugins). You customize your unit; you don't rewire the building.

Four properties explain why it caught on and stayed on top:

• Open-source — free to use, modify, and distribute; no vendor lock-in.
• Extensible — a hooks system lets plugins and themes change behaviour without editing core.
• Accessible — non-technical editors publish content through a friendly admin dashboard.
• Mature — two decades of hardening, an enormous community, and predictable release cycles.

Understanding the architecture is the difference between using WordPress and building on it. Everything in this module builds on the mental model you form here.

Core Components

WordPress is best understood as a handful of cooperating subsystems. A single incoming request touches nearly all of them.

The Database Schema

A fresh WordPress install creates twelve tables. The clever trick is that a single table — wp_posts — stores posts, pages, attachments, revisions, menu items, and every custom post type, distinguished only by the post_type column. This "unified content model" keeps the schema simple while supporting rich content.

The wp_ prefix is configurable at install time (a small security nicety). Because everything shares a few flexible tables, WordPress can model complex relationships — a post authored by a user, filed under two categories, carrying five custom fields — without a sprawling schema.

The File Structure

The file system separates core (replaced on every update) from your content (preserved). This single boundary is why WordPress can auto-update without wiping your customizations.

wordpress/
├── wp-admin/          # Admin dashboard (core — never edit)
├── wp-includes/       # Core functionality (core — never edit)
├── wp-content/        # YOUR stuff (preserved across updates)
│   ├── themes/        # Theme directories
│   ├── plugins/       # Plugin directories
│   ├── mu-plugins/    # "Must-use" plugins, auto-activated
│   ├── uploads/       # Media, organized by year/month
│   └── languages/     # Translation files
├── index.php          # Front-controller entry point
├── wp-config.php      # DB credentials, salts, constants
├── wp-load.php        # Locates and loads wp-config.php
├── wp-settings.php    # Bootstraps the whole environment
└── .htaccess          # Apache rewrite rules (pretty permalinks)

Of the root files, only wp-config.php is meant to be edited directly. It holds your database credentials, secret keys, and configuration constants. Everything else in the root is core plumbing that runs the bootstrap.

The Request Lifecycle

When someone visits a URL, WordPress runs a well-defined sequence to turn that request into HTML. Knowing this order tells you where and when your own code can intervene.

1. Entry & rewrite — the server routes the request to index.php using .htaccess (Apache) or a location block (Nginx).
2. Bootstrap — wp-load.php → wp-config.php → wp-settings.php load config, connect to the database, and set up core functions.
3. Plugins & theme load — active plugins are included and the plugins_loaded, then init hooks fire.
4. Query parsing — WP_Query turns the URL into query variables (here, "single post with slug sample-post").
5. Content query — SQL runs against the database to fetch the matching rows.
6. Template selection — the template hierarchy picks a file (e.g. single.php).
7. Rendering — The Loop iterates results and template tags emit HTML.
8. Output — filters get one last chance to modify markup before it is sent.

At almost every step, WordPress fires hooks. That is the seam plugins slip into — which is exactly what we cover next.

The Hooks System

Hooks are the beating heart of WordPress extensibility. As core runs, it repeatedly pauses and announces, "if anyone wants to do something here, now's the moment." Your plugin registers a callback and joins in — no core edits required.

Actions — do something

Action hooks let you run code at a point in execution. They don't return a value; they just act. Think of them as event notifications: "a post was just saved — react if you like."

<?php
// Run after a post is saved. Signature: ($post_id, $post, $update)
add_action( 'save_post', 'mycb_touch_edit_time', 10, 3 );

function mycb_touch_edit_time( int $post_id, WP_Post $post, bool $update ): void {
    if ( $update && $post->post_type === 'post' ) {
        update_post_meta( $post_id, 'last_edited_time', time() );
    }
}

Filters — change something

Filter hooks pass data through your callback so you can modify it. The one rule: always return a value. Think of a water filter — data flows in, altered data flows out.

<?php
// Append a call-to-action to the end of single posts.
add_filter( 'the_content', 'mycb_append_cta' );

function mycb_append_cta( string $content ): string {
    if ( is_single() && ! is_admin() ) {
        $content .= '<div class="cta">Thanks for reading! Please subscribe.</div>';
    }
    return $content; // Filters MUST return.
}

Commonly used hooks you will meet constantly: init, wp_enqueue_scripts, wp_head, wp_footer, the_content, the_title, pre_get_posts, admin_menu, and save_post.

Core APIs

WordPress ships standardized APIs for common jobs. Using them (instead of hand-rolling) keeps your code update-safe and compatible with other plugins.

Options in practice

<?php
// Read with a fallback default.
$per_page = get_option( 'mycb_items_per_page', 12 );

// Write (creates the row if it doesn't exist).
update_option( 'mycb_items_per_page', 24 );

A safe external HTTP call

<?php
$response = wp_remote_get( 'https://api.example.com/data' );

if ( is_wp_error( $response ) ) {
    error_log( 'API call failed: ' . $response->get_error_message() );
} else {
    $data = json_decode( wp_remote_retrieve_body( $response ), true );
    // ...use $data
}

A shortcode

<?php
add_shortcode( 'greeting', 'mycb_greeting' );

function mycb_greeting( array $atts ): string {
    $atts = shortcode_atts( [ 'name' => 'World' ], $atts, 'greeting' );
    return '<p>Hello, ' . esc_html( $atts['name'] ) . '!</p>';
}
// Usage in content: [greeting name="Ray"]

Security Architecture

Security is baked into WordPress core, but it is a shared responsibility: the tools exist, and your code must use them. Four pillars matter most.

1. Prepared statements (stop SQL injection)

<?php
global $wpdb;

// SAFE — user input is bound, never concatenated.
$results = $wpdb->get_results(
    $wpdb->prepare(
        "SELECT * FROM {$wpdb->posts} WHERE post_type = %s AND post_status = %s",
        'post',
        'publish'
    )
);

<?php
// VULNERABLE — raw user input dropped straight into SQL.
$status  = $_GET['status'];
$results = $wpdb->get_results( "SELECT * FROM {$wpdb->posts} WHERE post_status = '$status'" );

2. Nonces (stop CSRF)

<?php
// In the form:
wp_nonce_field( 'delete_post_' . $post_id, 'security' );

// When processing the submission:
if ( ! isset( $_POST['security'] )
     || ! wp_verify_nonce( $_POST['security'], 'delete_post_' . (int) $_POST['post_id'] ) ) {
    wp_die( 'Security check failed' );
}

3. Capabilities (authorize the user)

<?php
if ( current_user_can( 'edit_post', $post_id ) ) {
    // Safe to show the edit link / perform the edit.
}

4. Sanitize input, escape output

<?php
// Sanitize on the way IN:
$name  = sanitize_text_field( $_POST['name'] );
$email = sanitize_email( $_POST['email'] );

// Escape on the way OUT:
echo '<a href="' . esc_url( $url ) . '">' . esc_html( $name ) . '</a>';

The mantra: "Sanitize early, escape late, always validate." Common helpers include sanitize_text_field(), absint(), wp_kses_post(), esc_html(), esc_url(), and esc_attr().

Hands-on: Hook Detective

<?php
/**
 * Plugin Name: Hook Detective
 * Description: Logs when common WordPress hooks fire, in order.
 * Version: 1.0.0
 */

// A tiny factory so each hook logs its own name.
function hd_logger( string $hook ): callable {
    return static function () use ( $hook ) {
        error_log( "Hook fired: {$hook}" );
    };
}

foreach ( [ 'plugins_loaded', 'init', 'wp_loaded', 'wp_head', 'wp_footer' ] as $hook ) {
    add_action( $hook, hd_logger( $hook ) );
}

// Filters must return their value:
add_filter( 'the_content', static function ( string $content ): string {
    error_log( 'Hook fired: the_content' );
    return $content;
} );

// Bonus: see which template file rendered the page.
add_filter( 'template_include', static function ( string $template ): string {
    error_log( 'Template loaded: ' . $template );
    return $template;
} );

Best Practices

Summary & Quiz

📚 Further Reading

• WordPress Developer Resources
• Plugin Handbook — Hooks
• Common APIs — Security
• WP_Query Class Reference

🚀 What's Next?

Now that you know how WordPress is built, the next lesson zooms in on how it manages content — post types, taxonomies, custom fields, and the query system you'll use every day.