Week 24: WordPress Security & Performance

1. Nonces

A WordPress nonce ("number used once," though in practice time-limited and reusable within a window) is CSRF protection — the same mechanism built by hand in Week 8, wrapped in a WordPress-native API:

<form method="post" action="">
  <?php wp_nonce_field('pm_save_inquiry', 'pm_nonce'); ?>
  <input type="email" name="email" required>
  <button type="submit">Submit</button>
</form>

<?php

if ($_SERVER['REQUEST_METHOD'] === 'POST') {
    if (!isset($_POST['pm_nonce']) || !wp_verify_nonce($_POST['pm_nonce'], 'pm_save_inquiry')) {
        wp_die('Security check failed.');
    }

    // Safe to proceed -- the request genuinely originated from this form
}

'pm_save_inquiry' as the action string matters — it scopes the nonce to this specific action, so a nonce generated for one form can't be replayed against a different, more sensitive action even if an attacker somehow obtained it. AJAX requests use the same mechanism, passed as a header or request parameter instead of a hidden form field.

2. Capabilities

WordPress's authorization model is built on capabilities — granular permissions like edit_posts, manage_options, delete_users — grouped into roles (Subscriber, Author, Editor, Administrator). Check a capability, never a role directly:

<?php

// Wrong -- brittle, and ignores custom roles entirely
if ($user->roles[0] === 'administrator') { /* ... */ }

// Right -- checks the actual permission, regardless of which role grants it
if (current_user_can('manage_options')) { /* ... */ }

// Object-specific capability checks
if (current_user_can('edit_post', $postId)) { /* ... */ }

This is precisely the "check capability, not who someone is" principle from Week 13's Policies — a site might have a custom "Shop Manager" role with manage_woocommerce but not manage_options; checking the specific capability handles that correctly, where a hardcoded role-name check would get it wrong.

3. Sanitize vs. Escape, Precisely

Weeks 19 and 21 used esc_html() and esc_attr() without fully unpacking the rule. Now, precisely: sanitize on input, escape on output — every single time, with the function matched to the exact context:

• sanitize_text_field($_POST['name']) — cleaning data as it comes in, before it's used or stored
• esc_html($name) — printing into HTML text content
• esc_attr($name) — printing inside an HTML attribute value
• esc_url($url) — printing inside an href/src
• esc_js($string) — printing inside an inline <script> block
• $wpdb->prepare() — binding a value into a SQL query, per Week 21

<?php

// 1. Sanitize on the way in
$name = sanitize_text_field($_POST['name'] ?? '');

// 2. Store it (via $wpdb->prepare(), or wp_insert_post(), etc.)
$wpdb->insert($table, ['name' => $name], ['%s']);

// 3. Escape on the way out -- for the context it's actually being printed into
echo '<p>Hello, ' . esc_html($name) . '</p>';
echo '<input value="' . esc_attr($name) . '">';

4. Object Caching with Redis

WordPress's WP_Object_Cache caches expensive computed values — database query results, API responses — but by default only for the duration of a single request. A persistent object cache backed by Redis keeps that cache alive across requests, dramatically cutting database load on a busy site:

wp plugin install redis-cache --activate
wp redis enable

<?php

function pm_get_project_count(): int {
    $cached = wp_cache_get('pm_project_count', 'portfolio_manager');

    if ($cached !== false) {
        return $cached;
    }

    $count = (int) wp_count_posts('project')->publish;
    wp_cache_set('pm_project_count', $count, 'portfolio_manager', 300); // cache for 5 minutes

    return $count;
}

This is the same idea as Redis caching in Python or Node backends — compute once, serve from memory for a while, invalidate deliberately — expressed through WordPress's own cache API so it automatically benefits from whatever caching backend (Redis, Memcached, or the request-scoped default) the site has configured.

5. Query & Asset Performance

Two of the most common WordPress performance mistakes, both avoidable with what's already been covered:

<?php
// Slow -- fetches every single project, no matter how many exist
$all = new WP_Query(['post_type' => 'project', 'posts_per_page' => -1]);

// Better -- paginated, and skip counting total rows if you don't need pagination UI
$page = new WP_Query([
    'post_type' => 'project',
    'posts_per_page' => 20,
    'no_found_rows' => true, // skips a separate COUNT(*) query when you don't need it
]);

posts_per_page => -1 is the WordPress-specific version of forgetting a LIMIT clause from Week 6 — fine on a small site, a real problem once a post type has thousands of rows. Loading unused plugins and unoptimized images is the other classic culprit — every active plugin can enqueue its own CSS/JS on every page load regardless of whether that page uses it, so periodically auditing what's actually active (and using a plugin like Query Monitor to see what's slow) matters on any real WordPress site.

6. Hands-on Exercise

7. Knowledge Check

Four quick questions. Expand each to check your answer.