WordPress Roadmap

What is a CMS? and WordPress Core

A content management system stores content in a database and builds pages from it with templates, so editors can publish without touching code. WordPress is the most widely used CMS. It is written in PHP, stores data in MySQL or MariaDB and is extended through themes and plugins.

WordPress started as blogging software and now runs brochure sites, shops (usually with WooCommerce), membership sites and web applications. Its strengths are a huge ecosystem and an easy editing experience; its weaknesses are plugin quality that varies and the need to keep everything updated.

Developers use it to deliver sites quickly for clients, and to build custom plugins, themes and blocks for products. See PHP Roadmap for the language underneath.

Practice. Describe in your own words what happens, step by step, when a visitor opens a WordPress post.

WordPress.com vs. WordPress.org Core

WordPress.org provides the free, open-source software that you download and host yourself. You control everything: plugins, themes, code and the server, and you are responsible for updates, backups and security.

WordPress.com is a commercial hosting service built on the same software. Its plans differ in what they allow, with lower tiers restricting custom plugins and code and higher tiers lifting that. It trades control for convenience.

For learning development and for client work you almost always want the self-hosted software, or a managed host running it. Be ready to explain the difference, because beginners confuse the two constantly.

Practice. Write a short comparison table of control, cost and responsibilities for the two options.

How the Web Works and HTTP Explained Core

A browser asks a DNS server to turn a domain into an IP address, opens a connection (secured with TLS) and sends an HTTP request: a method such as GET, a path, headers and sometimes a body. The server replies with a status code (200 success, 301 redirect, 404 not found, 500 error), headers and a body.

WordPress sits behind that exchange. The web server passes the request to PHP, WordPress loads, queries the database, builds HTML and returns it. Caches, CDNs and proxies can answer earlier in the chain without ever reaching PHP.

Knowing this lets you debug: is the failure DNS, the server, PHP or the database?

Practice. Use browser developer tools to inspect one request and note its method, status and three response headers.

Installation and Setup Core

WordPress needs PHP, a database and a web server. The classic install copies the files, creates a database and user, then runs a setup screen that writes wp-config.php. With WP-CLI it is a few commands:

wp core download
wp config create --dbname=wp --dbuser=wp --dbpass=secret
wp core install --url=example.test --title=Demo --admin_user=admin --admin_email=me@example.test

After installing, choose a pretty permalink structure, delete sample content, set the site timezone and reading settings, and use a unique administrator name and strong password. Never leave the default admin account with a weak password.

Practice. Install WordPress twice, once through the browser and once with WP-CLI, and compare the steps.

Local Development: LocalWP, XAMPP, VVV and Docker Recommended

Develop locally, not on the live site. LocalWP is a free desktop app that creates a WordPress site in a few clicks, with SSL and database tools. XAMPP bundles Apache, MySQL and PHP in a single installer, which is simple but manual for WordPress. VVV (Varying Vagrant Vagrants) is a virtual machine setup used mainly by core contributors. Docker for Local WordPress Development uses containers defined in a compose file, which match production versions closely and are easy to share through the repository.

Pick one and learn it well. Docker has the steepest start and the best long-term consistency; LocalWP is the quickest.

Practice. Set up a local site with the tool of your choice and make it reachable at a custom hostname.

Hosting: Shared Hosting, VPS Hosting for WordPress and Managed WordPress Hosting Recommended

Shared hosting puts many sites on one server: cheap, but with limited resources and little control. A VPS gives you a virtual server with root access, which you must configure and secure yourself (web server, PHP, database, firewall, backups). Managed WordPress hosting runs the stack for you and usually adds caching, staging sites, backups and security tooling at a higher price.

Choose by traffic, budget and skills. A small brochure site is fine on good shared or managed hosting. A busy shop or custom application benefits from a VPS or managed platform with a dedicated cache layer.

Practice. Compare three hosting plans on PHP version, backups, staging and resource limits.

WordPress File Structure Core

The root contains wp-config.php (database credentials, salts and settings), wp-admin and wp-includes (core code, never edit), and wp-content. Inside wp-content live themes, plugins, uploads (media) and sometimes mu-plugins (must-use plugins loaded automatically) and cache folders.

Your code belongs only in wp-content. Core files are overwritten on every update, so changes there disappear. Move wp-config.php configuration out of version control when it holds secrets, and make sure the web server cannot execute PHP inside uploads. Learn which files change at runtime and which are code.

Practice. Draw the folder tree of an installation and mark which folders are safe to edit.

Frontend Fundamentals: HTML, CSS and JavaScript Core

Themes output HTML, are styled with CSS and add behaviour with JavaScript. Use semantic HTML (header, nav, main, article) because it supports accessibility and search. In CSS, learn the box model, flexbox, grid, custom properties and media queries; block themes now put design tokens into a theme.json file that generates these. In JavaScript, learn modules, the DOM, fetch and the idea of an undefined value versus null, since the block editor is built on React. See HTML Roadmap, CSS Roadmap and JavaScript Roadmap.

Practice. Build a responsive static page with a header, a grid of cards and a form before turning it into a theme.

Backend Fundamentals: PHP and SQL Core

WordPress runs on PHP, so you need variables, arrays, functions, classes and namespaces. Most WordPress code is procedural functions registered through hooks, with newer plugins using classes. Learn how PHP handles requests, escapes output and loads files. See PHP Roadmap.

SQL matters because WordPress stores everything in tables such as wp_posts, wp_postmeta, wp_options and wp_users. You should be able to read a SELECT with a join, add an index and recognise slow queries. WordPress wraps queries in the $wpdb class. See SQL Roadmap.

Practice. Write SQL that lists the ten newest published posts with their authors from the default tables.

Object-Oriented Programming in PHP Recommended

Larger plugins use classes to keep code organised: a class for each concern, interfaces for contracts, and constructor injection for dependencies. You will meet classes in the core too, such as WP_Query, WP_Post and WP_User.

The common pattern is a main plugin class that registers hooks in its constructor or a register() method, with the logic in separate small classes. Keep class names unique with a prefix or namespace to avoid clashing with other plugins. Prefer composition and avoid heavy use of static state, which makes testing difficult.

Practice. Turn three procedural plugin functions into a class that registers its own hooks.

Composer Recommended

Composer manages PHP dependencies. It is not part of WordPress itself, but modern plugin and site projects use it for libraries, autoloading and development tools. You declare packages in composer.json, and Composer writes the vendor folder and a lock file.

For plugins distributed to others, bundle only needed packages and prefix their namespaces to avoid version clashes between plugins, since WordPress has one shared PHP runtime. For whole sites, Composer can install core, plugins and themes from a package repository, which makes builds repeatable.

Practice. Add a PHP library to a small plugin with Composer and load it through the autoloader.

Block Editor Core

The block editor (also called Gutenberg) has been the default since WordPress 5.0. Content is a list of blocks, such as paragraph, heading, image, columns and query loop, each with its own settings. Blocks are stored in the post as HTML with comment delimiters, and the editor is built with React.

Learn the list view, reusable patterns, block styles, the Group and Row blocks for layout, and how global styles from the theme affect blocks. The same block system now powers the site editor, widgets and navigation, so it is the centre of modern WordPress.

Practice. Build a landing page entirely from core blocks and save part of it as a pattern.

Classic Editor, Page Editors and Third-Party Page Builders Optional

The Classic Editor is a plugin that restores the older single-text-area editor; it still works but is not the future direction. Page editors is a general name for tools that edit layout visually. Third-party page builders such as Elementor, Divi and Beaver Builder add their own drag-and-drop interfaces.

Builders let non-developers build quickly, but they store layout in their own formats, add weight and lock you in: removing the plugin can leave the content as shortcodes. Choose deliberately, and for new work prefer core blocks unless a client needs a specific builder.

Practice. Inspect the HTML output of one page built with a builder and one with blocks and compare size and clarity.

WordPress Menus and Widgets Recommended

Menus are managed in the Appearance screens. Classic themes register menu locations with register_nav_menus() and display them with wp_nav_menu(). Block themes use the Navigation block, edited in the site editor.

Widgets are blocks placed in widget areas, which classic themes define with register_sidebar(). Since WordPress 5.8 widget areas use the block editor too. Knowing both generations matters, because client sites run both, and interview questions often ask how you would add a menu to a classic theme.

Practice. Register a header menu location and a footer widget area in a classic theme and display both.

User Roles and Capabilities Core

WordPress has built-in roles: Administrator, Editor, Author, Contributor and Subscriber, with Super Admin on multisite. Each role is a set of capabilities such as edit_posts, publish_posts or manage_options.

Always check capabilities, not role names: current_user_can('edit_post', $id). Plugins can add roles and capabilities with add_role() and add_cap(); remove them on uninstall. Give users the least privilege they need, and never share an administrator login. Capability checks are your main defence against unauthorised actions in plugin code.

Practice. Create a custom role that can edit pages but not install plugins and test it with a second account.

Custom Post Types and Taxonomies Core

Posts and pages are two post types. A custom post type adds your own, such as book or event, registered on the init hook:

add_action('init', function () {
    register_post_type('book', [
        'label' => 'Books',
        'public' => true,
        'show_in_rest' => true,
        'supports' => ['title', 'editor', 'thumbnail'],
    ]);
});

Taxonomies group content: categories and tags are built in, and register_taxonomy() adds more, such as genre. Set show_in_rest for editor and API support, flush rewrite rules only on activation and keep types in plugins rather than themes so content survives a theme change.

Practice. Register a book post type with a genre taxonomy and list the books on a page.

Themes: Classic, Block, Hybrid and Universal Core

A theme controls how the site looks. Classic themes use PHP template files and functions.php. Block themes use HTML template files made of blocks and a theme.json settings file, and are edited in the site editor. Hybrid themes are classic themes that adopt some block features, such as theme.json or block patterns. Universal themes (also called multipurpose themes) try to fit many kinds of site through large option panels.

Classic vs. Block Themes is a standard interview topic: block themes are the direction of core and need little PHP, while classic themes remain common in existing sites and give fine control.

Practice. Install one theme of each type and write down how each stores its layout and settings.

Third-Party Themes, Licensing and Updates Recommended

Free themes in the official directory are reviewed for guideline compliance. Commercial themes come from marketplaces or vendors and often need a licence key for updates and support. Check the update history, active installs, support quality and whether the theme locks content into its own shortcodes or builder.

WordPress core code is licensed under the GPL, and plugins and themes that ship with it must be GPL-compatible. Theme and Plugin Licensing & Updates also covers how paid products deliver updates through a vendor's own update server using the core update filters.

Practice. Evaluate a paid theme with a checklist covering updates, code quality, licence and exit cost.

Template Hierarchy Core

The template hierarchy is the order in which WordPress looks for a template file for a request. For a single book post it tries single-book.php, then single.php, then singular.php and finally index.php. For a category archive it goes category-{slug}.php, category-{id}.php, category.php, archive.php, then index.php.

Learn the main branches (single, page, archive, home, search, 404) and how block themes map the same names onto HTML files in templates/. The Query Monitor plugin shows which template was chosen, which makes debugging easy.

Practice. Create three templates of increasing specificity for one post type and prove which one wins.

Template Files, Template Parts and The Loop Core

Template files assemble a page. Template parts are reusable pieces such as a header, footer or post card: classic themes include them with get_template_part(), and block themes keep them in a parts/ folder.

The Loop is the code that iterates over the posts in the main query:

if (have_posts()) {
    while (have_posts()) {
        the_post();
        the_title('<h2>', '</h2>');
        the_excerpt();
    }
}

Inside the Loop, template tags read the current post. Use WP_Query for secondary loops, and call wp_reset_postdata() afterwards. In block themes, the Query Loop block replaces this code.

Practice. Output a list of the five newest posts for a custom post type with a secondary WP_Query.

style.css and functions.php in Classic Themes Core

In a classic theme, style.css must start with a header comment that names the theme (Theme Name, Version, Text Domain and so on); WordPress reads it to list the theme. The CSS itself is loaded by enqueueing, not by relying on the file existing.

functions.php runs on every request and is where a theme registers features: add_theme_support() for thumbnails and title tags, menus, image sizes, and hooks. Keep it light. Long unrelated logic belongs in a plugin, since it will vanish when the theme changes. Split large themes into files under an inc/ folder.

Practice. Create a minimal classic theme with only style.css, index.php and functions.php that activates correctly.

Style and Script Enqueueing Core

Never print <link> or <script> tags directly. Register and enqueue assets on wp_enqueue_scripts:

add_action('wp_enqueue_scripts', function () {
    wp_enqueue_style('theme', get_stylesheet_uri(), [], '1.0');
    wp_enqueue_script('app', get_theme_file_uri('app.js'), [], '1.0', true);
});

WordPress then manages dependencies, order, duplicates and versions for cache busting. The last argument loads the script in the footer; newer versions also accept a strategy such as defer. Use wp_localize_script or wp_add_inline_script to pass data. Use admin_enqueue_scripts for the admin, and load assets only on pages that need them.

Practice. Load a script only on pages using a certain template and pass it a value from PHP.

Child Themes Recommended

A child theme inherits from a parent theme and overrides parts of it, so updates to the parent do not wipe out your changes. It needs its own folder with a style.css header containing Template: parent-slug, and usually a functions.php. Files with the same name as the parent's replace them, and functions.php is loaded before the parent's.

Use a child theme when customising a third-party classic theme. For block themes, child themes work too, but many changes can be made through the site editor and saved in the database.

Practice. Create a child theme that overrides one template part and changes a colour.

Customizer, Block Themes and Full Site Editing Core

The Customizer is the older live-preview settings panel for classic themes, with an API of settings, controls and sections. It still works and is not formally removed, but block themes replace it.

Full Site Editing (FSE) lets you edit templates, template parts, navigation and global styles with blocks. Block Theme Structure: theme.json, style.css, templates/, parts/ and patterns/. Block Theme Styles are defined in theme.json (colours, typography, spacing, per-block rules). Overrides in Block Themes happen when a user edits a template; the change is saved in the database and overrides the file until reset. Block Patterns are predefined block layouts you register or ship in the theme.

Practice. Build a minimal block theme with a header part, a home template and a theme.json colour palette.

Plugin Basics and File Structure Core

A plugin is a PHP file with a header comment inside wp-content/plugins:

<?php
/**
 * Plugin Name: Book Tools
 * Version: 1.0.0
 * Text Domain: book-tools
 */
defined('ABSPATH') || exit;

Exit when ABSPATH is not defined so the file cannot be run directly. A typical structure has a main file, an includes/ or src/ folder for classes, assets/, languages/ and an uninstall.php. Register activation and deactivation hooks, prefix all function and option names, and keep the main file short. Use must-use plugins only for code that must never be deactivated.

Practice. Create a plugin with a header, an ABSPATH guard and an activation hook that stores a version option.

Hooks: Actions and Filters Core

Hooks are WordPress's extension system. An action runs your code at a point, such as init, save_post or wp_footer. A filter receives a value, changes it and returns it, such as the_content or excerpt_length.

add_action('save_post_book', 'bt_log_save', 10, 3);
add_filter('the_title', fn($t) => strtoupper($t));

The numbers are priority (lower runs first) and the count of accepted arguments. Always return the value in a filter. Create your own hooks with do_action() and apply_filters() so others can extend your plugin, and use remove_action() to unhook. Most WordPress interview questions come back to hooks.

Practice. Use one action and one filter to append a notice to the end of every post, then add a custom hook of your own.

Shortcodes Recommended

A shortcode is a bracketed tag in content, such as [book id="12"], replaced with generated output. Register it with add_shortcode() and return, never echo, the result:

add_shortcode('book', function ($atts) {
    $a = shortcode_atts(['id' => 0], $atts);
    return esc_html(get_the_title((int) $a['id']));
});

Shortcodes work everywhere content is rendered, which makes them useful for builders and classic content. Blocks are the modern alternative with a better editing experience. Always sanitise attributes and escape output, and avoid leaving a plugin's shortcodes as text in the content when it is removed.

Practice. Write a shortcode that outputs a styled notice with a type attribute, escaping all output.

Admin Menu, Settings API and Settings Page Core

Add an admin page with add_menu_page() or add_options_page() on the admin_menu hook. The callback prints a form. The Settings API handles saving, validating and nonces: register_setting() defines an option and its sanitise callback, add_settings_section() and add_settings_field() define the UI, and settings_fields() outputs the hidden security fields.

Check current_user_can('manage_options') before showing the page. A settings page built with the API avoids writing your own form handling and gets security checks mostly for free. Use the REST API with a React page for more complex screens.

Practice. Build a settings page with a text field and a checkbox that sanitises both values.

Options API and Transients API Core

The Options API stores key-value settings in the wp_options table: get_option(), update_option(), add_option(), delete_option(). Set autoload to false for large or rarely used options, since autoloaded options load on every request.

The Transients API stores temporary cached values with an expiry: set_transient('key', $data, HOUR_IN_SECONDS) and get_transient('key'). With an external object cache, they live in memory; otherwise they are stored in the options table. Treat a transient as disposable: it may vanish at any time, so always handle a miss.

Practice. Cache the result of a slow external request in a transient for one hour and handle the miss.

Custom Fields, Metabox and ACF Recommended

Custom fields store extra data about a post in the wp_postmeta table. Read with get_post_meta() and write with update_post_meta(). A metabox is an editor panel for entering the values, added with add_meta_box(), and saved on save_post after checking the nonce, autosave state and capabilities. Register meta with register_post_meta() and show_in_rest to expose it to blocks and the REST API.

Advanced Custom Fields (ACF) is a popular plugin that builds field groups through a UI and has helper functions. It saves time, but your site then depends on the plugin; document that choice.

Practice. Add a price field to the book type with a metabox, with nonce and capability checks on save.

AJAX in WordPress and Cron Jobs Recommended

Classic AJAX goes through admin-ajax.php: register wp_ajax_{action} for logged-in users and wp_ajax_nopriv_{action} for visitors, verify a nonce, return JSON with wp_send_json_success() and exit. Today the REST API is usually cleaner.

WordPress cron (WP-Cron) schedules tasks with wp_schedule_event(), but it only runs when someone visits the site, so timing is approximate. For reliable timing, disable it in config and call wp-cron.php from a real system cron. Use Action Scheduler for heavy queues. Clean up scheduled events on deactivation.

Practice. Create a scheduled event that deletes expired transients nightly, then trigger it manually with WP-CLI.

Custom Tables in WordPress Plugins Optional

When data is large or relational, such as logs, orders or analytics, postmeta becomes slow and awkward. A plugin can create its own table on activation with dbDelta(), using $wpdb->prefix for the table name and the site's charset and collation.

Query through $wpdb, and always use $wpdb->prepare() with placeholders. Store a schema version in an option and migrate on update. Remove tables in uninstall.php only with clear user consent. Custom tables are the right tool when you need joins, indexes or millions of rows.

Practice. Create a log table with dbDelta on activation, insert rows with prepare and list them in the admin.

WordPress Coding Standards Recommended

WordPress has published coding standards for PHP, JavaScript, CSS and HTML: Yoda conditions, spaces inside parentheses, long array syntax in older code and specific naming and documentation rules. Install PHP_CodeSniffer with the WordPress ruleset and run it in your editor and CI.

Standards are mostly about consistency and security: the sniffs also flag unescaped output, missing nonce checks and unprepared SQL. Plugin directory review applies them. Follow the standard when contributing to core or the directory, and an agreed one on private projects.

Practice. Run PHPCS with the WordPress ruleset on a plugin and fix every security-related warning.

WordPress REST API Core

The REST API exposes content as JSON under /wp-json/. Core provides endpoints such as /wp-json/wp/v2/posts, and any custom post type with show_in_rest gets one. Public reads need no login; writes need authentication: cookie with a nonce inside the admin, or application passwords for external clients.

Add your own routes with register_rest_route() on rest_api_init, and always set a permission_callback; leaving it out is an error, and returning true makes the route public. Validate and sanitise arguments with the args schema and return WP_REST_Response or WP_Error with a status code.

Practice. Add a custom endpoint that returns the latest five books as JSON, restricted to logged-in editors.

External API Integrations Recommended

Call other services from PHP with wp_remote_get() and wp_remote_post(), check the result with is_wp_error() and wp_remote_retrieve_response_code(), and decode the body. Always set a timeout, cache successful responses in a transient and handle failure gracefully, so a slow third party cannot slow down your pages.

Keep API keys in constants or environment variables, not in the database in plain text, and never output them to the browser. For webhooks coming in, verify the signature and respond fast, doing heavy work in a queue.

Practice. Display the current weather in a widget using a public API, cached for ten minutes with a graceful fallback.

Building Custom Blocks Recommended

A block has a block.json file describing its name, attributes, scripts and styles, an editor component written in React and either a save function that stores HTML or a PHP render callback for dynamic output. The @wordpress/create-block tool scaffolds a working plugin, and @wordpress/scripts builds it.

Choose a dynamic block (server-rendered) when the output depends on live data, and a static one when the markup can be saved. Use block attributes for settings, InspectorControls for sidebar options and useBlockProps for correct wrapper attributes. Version your markup carefully, since changes can invalidate existing content.

Practice. Scaffold a block that shows a highlighted quote with a colour attribute and render it on the front end.

Headless WordPress Optional

Headless means WordPress is used only as a content backend, and a separate front end, such as one built with Next.js Roadmap, fetches content through the REST API or the WPGraphQL plugin. It suits teams that need a JavaScript front end or content for several channels.

The costs are real: you lose themes, many plugins, previews and built-in SEO behaviour unless you rebuild them, and you run two systems. Choose it for a clear reason, not as a default.

Practice. List three requirements that would justify headless and three that would not.

Localization Recommended

Localization (also called internationalisation, i18n) makes text translatable. Wrap strings in __(), _e(), esc_html__() or _n() for plurals, using a text domain that matches your plugin or theme slug. Never concatenate translated fragments; use placeholders with sprintf.

Extract strings to a .pot file with WP-CLI's wp i18n make-pot, and ship translations as .po and .mo files, or let translate.wordpress.org handle directory plugins. Load the text domain on init. For multilingual content, plugins such as Polylang or WPML manage translated posts.

Practice. Make a plugin translatable, generate a .pot file and add a second language file.

WordPress Multisite and WP-CLI Optional

Multisite runs a network of sites from one install, sharing core, plugins and users, with a Super Admin managing the network. Sites live in subdirectories or on subdomains. Use it for related sites that share administration; avoid it when sites need separate hosting, plugins or failure isolation.

WP-CLI is the command-line interface for WordPress. Examples: wp plugin update --all, wp user create, wp search-replace old new --dry-run, wp db export, wp cron event run --due-now. It makes setup, migrations and maintenance scriptable and fast.

Practice. Use WP-CLI to update plugins, export the database and do a dry-run search and replace.

Security Best Practices: Sanitise, Validate, Escape and Nonces Core

The rule is: sanitise input, validate it, escape output, check capabilities and verify nonces. Use sanitize_text_field(), absint(), wp_kses_post() for input, esc_html(), esc_attr(), esc_url() and esc_js() for output at the point of printing, and $wpdb->prepare() for SQL.

A nonce is a one-time-style token tied to a user and action; check it with wp_verify_nonce() or check_admin_referer() to block cross-site request forgery. A nonce is not authentication, so also check current_user_can(). Most WordPress vulnerabilities in plugins come from skipping one of these steps. See coding practice for exercises.

Practice. Audit a small plugin for missing escaping, nonce checks and capability checks and fix each one.

Security and Hardening, User and Login Security Core

Hardening reduces the attack surface: remove unused plugins and themes, keep everything updated, use PHP at a supported version, disable file editing in the admin with DISALLOW_FILE_EDIT, set correct file permissions, change the table prefix only as a minor extra and keep wp-config.php secret.

User and login security: strong unique passwords, two-factor authentication, limited login attempts, a non-obvious admin username, least-privilege roles and application passwords for API access. Force HTTPS in the admin. Remove inactive users. Most compromises come from outdated plugins and stolen credentials, not clever attacks on core.

Practice. Apply a ten-point hardening checklist to a test site and record which items made a measurable difference.

Firewall, Malware Scanning, Virtual Patching and Vulnerability Monitoring Recommended

A web application firewall filters malicious requests before they reach WordPress, either at the host or CDN level or through a plugin. Malware scanning compares files with known good copies and checks for suspicious code. Virtual patching adds a firewall rule that blocks an exploit for a known vulnerability before the plugin's real fix is installed. Vulnerability monitoring watches your installed plugins and themes against published vulnerability databases and alerts you.

These tools reduce risk and give time to update; they do not replace updates. Choose one coverage layer, and test it so it does not block your own admin or API.

Practice. Subscribe a test site to vulnerability alerts and describe what you would do on receiving one.

Activity Logging and Log Files Recommended

Activity logging records who did what in the dashboard: logins, role changes, plugin installs, content edits. It helps with accountability and incident investigation. Several plugins provide it.

Server log files show requests (access log) and errors (error log, PHP log). Know where they are on your host, and set WP_DEBUG_LOG to write PHP errors to wp-content/debug.log during development only. Watch for repeated login attempts, strange POST requests and PHP errors after updates. Keep logs for a defined period.

Practice. Find the access and error logs on a host and identify the five most requested URLs.

WordPress Backups, Recovery and Update Strategies Core

A backup has two parts: files (at least wp-content) and the database. Automate daily or more often for busy sites, store copies off the server, keep several generations and, above all, test restoring. A backup that has never been restored is a guess.

For updates, use staging first, back up before, update plugins one at a time on important sites, and read changelogs. Minor core releases update automatically by default, and you can enable automatic updates for plugins and themes. Update strategies balance speed against risk: security fixes fast, major version changes after testing. Document the rollback steps.

Practice. Restore a backup to a fresh local site and check pages, media and logins.

Caching and CDN Integration Core

WordPress builds each page with PHP and database queries, so caching has the biggest effect. Layers: page caching stores finished HTML (host-level or a plugin), object caching (Redis or Memcached) stores query results across requests, and browser caching uses headers. A CDN serves static files, and sometimes whole pages, from locations near users.

Exclude logged-in users, carts and checkout pages from page caches, and purge on content updates. CDN Integration usually means rewriting asset URLs or putting the CDN in front of the domain. See Redis Roadmap and Cloudflare and Edge Roadmap.

Practice. Enable page caching and a CDN on a test site and compare time to first byte before and after.

Assets Optimization and Image Optimization Core

Reduce what the browser downloads. Load only the scripts and styles a page needs by dequeueing others conditionally, minify and combine carefully (HTTP/2 makes combining less useful), defer non-critical scripts and use system fonts or a limited set of web fonts.

Images are the usual weight problem: resize them to display size, use WebP or AVIF, rely on WordPress's responsive srcset output and native lazy loading, and avoid lazy-loading the main above-the-fold image. Set explicit width and height to avoid layout shifts. Compression plugins or a CDN can do this automatically.

Practice. Cut the page weight of a media-heavy page by at least half and note each change.

Database Tuning Recommended

Over time wp_options collects autoloaded junk, wp_postmeta grows large, and old revisions, spam comments and expired transients pile up. Tuning means cleaning these, limiting revisions, adding indexes for custom queries and avoiding meta queries on huge tables.

Check the size of autoloaded options and remove abandoned plugin data. Use persistent object caching to reduce repeated queries. For heavy sites, move to a larger database, read replicas or custom tables. Always back up before cleaning.

Practice. Find the ten largest autoloaded options on a site and decide which can be removed.

Core Web Vitals, Performance Monitoring and Query Monitor Recommended

Core Web Vitals (loading, interactivity, layout stability) are measured from real visits and affect search. Test with PageSpeed Insights and field data; use lab tools to find causes. Performance monitoring keeps watching after launch with uptime checks, real user monitoring and server metrics.

Query Monitor is a plugin for developers that shows database queries, slow queries, hooks, HTTP calls, template used and PHP errors for each request. It quickly reveals a plugin running fifty queries per page. Use it on staging, not on public production. See SEO for Developers Roadmap for more on search performance.

Practice. Install Query Monitor, find the slowest query on your home page and fix or cache it.

Basics of SEO and Accessibility Recommended

For SEO: pick clean permalinks, a single canonical per page, an XML sitemap (core generates one), unique titles and descriptions, sensible heading levels, fast pages and structured data from a trusted SEO plugin. Avoid duplicate archives.

Accessibility means everyone can use the site: semantic HTML, alt text, sufficient colour contrast, visible keyboard focus, labelled forms and logical headings. Themes in the official directory must pass accessibility checks to carry the accessibility-ready tag. Test with the keyboard alone and a screen reader.

Practice. Fix five accessibility issues found by an automated checker, then verify them using only the keyboard.

Debugging with WP_DEBUG Core

Turn on debugging in wp-config.php on development sites:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Notices, deprecation warnings and errors then go to wp-content/debug.log. Add SCRIPT_DEBUG to load unminified core scripts. Never leave display on in production. Combine with Query Monitor and Xdebug for deeper work, and read the log after each update. Deprecated function warnings tell you what to replace before it is removed.

Practice. Trigger a deliberate PHP warning in a plugin, find it in the log and fix it.

PHPUnit Testing Recommended

WordPress has a test suite scaffold: wp scaffold plugin-tests creates the PHPUnit configuration and a bootstrap that loads WordPress and a test database. Tests extend WP_UnitTestCase, which gives factories for posts and users and rolls back database changes between tests.

Test pure logic with plain unit tests, and hooks, queries and REST routes with integration tests. Run them in CI on every push. For browser flows, Playwright is the common choice. Writing code in small classes with injected dependencies makes plugins much easier to test.

Practice. Write PHPUnit tests for a plugin function and one REST route and run them in CI.

Composer and Autoloading, Bedrock and Sage Optional

Composer and Autoloading in a plugin means classes load on demand from namespaced files, so you stop writing require lines. Bedrock is a project structure that manages WordPress itself through Composer, keeps config in environment variables and separates the web root from other files. Sage is a theme starter built on Laravel Blade templates and a modern asset build, for teams that want a developer-style workflow in classic themes.

They suit professional agency or product teams. They add concepts to learn, so adopt them when the benefits are clear.

Practice. Create a Bedrock project locally and install a plugin with Composer.

Migrations, Automated Deployments and Workflows Recommended

Migrating a site means moving files and the database, then replacing URLs. Use WP-CLI search-replace (it handles serialised data safely) or a migration plugin, and check media, permalinks and email. Keep settings that differ between environments in config, not the database.

Automated deployments use Git and CI: run tests and coding standards, build assets, and deploy code over SSH or an artifact pipeline, with wp-content/uploads and the database managed separately. Workflows and Automation can include scheduled backups, dependency checks and visual regression tests. See Git and GitHub Roadmap.

Practice. Write a deploy script or CI workflow that runs checks and ships a theme to a staging server.

Advanced PHP and Architecture, Design Patterns and Databases in Advanced Plugins Optional

Large plugins benefit from architecture: a bootstrap that wires services through a dependency injection container, hooks registered in one place, interfaces for external services, and namespaces. Common design patterns are the singleton (use sparingly), factory, repository and observer, which WordPress hooks already implement.

Working with databases in advanced plugins means custom tables with migrations, repository classes wrapping $wpdb, transactions where the engine supports them, indexes and batch processing for large datasets to avoid timeouts. See Software Design and Architecture Roadmap.

Practice. Refactor a plugin so that all database access sits behind one repository class with tests.

Contributing to WordPress and Boosting Your Career Optional

WordPress is built by volunteers and sponsored teams. You can contribute by reporting bugs on Trac, writing patches, translating, helping in support forums, writing documentation, speaking at meetups and organising WordCamps. Contributions are credited on your WordPress.org profile; some outlines mention a WordPress Credit Program for contributor recognition, so check the current official description.

To Boost Your WordPress Career, publish plugins in the directory, keep a portfolio of real sites with the results, learn blocks and the REST API, and show you can handle security and performance. These are what clients and employers test.

Practice. Fix a documentation issue or translate ten strings and submit it to the project.