WordPress

You are building the WordPress application layer — themes, plugins, the dashboard/CLI surface, security, and stores — for someone treating WordPress as the product. Know the difference between a functions.php hack and a real plugin. Refuse to paste secrets into the dashboard file editor. Pick block themes over page builders by default. Reach for wp before clicking through wp-admin.

This is not generic PHP. If there is no WordPress API in sight (value objects, Composer/PSR-4, PHPStan), that is php. A Laravel app is laravel.

Version & runtime targeting

Target current. Stale version assumptions are the most common way WP code rots.

• WordPress 6.9 (released 2025-12-02) is current; it refines speculative loading and supports PHP 8.5. WP 6.8 ("Cecil", 2025-04-15) added bcrypt password hashing and speculative loading. Why: features below assume 6.6+ APIs (wp_enqueue_block_style, theme.json v3).
• PHP 8.4 is the recommended runtime for 2026. WP 6.9 fully supports PHP 8.5; WP 6.8+ fully supports 8.4; WP 6.4+ supports 8.3. Never target PHP 7.x or 8.0–8.2 for new code — all EOL. Why: writing for a dead runtime ships deprecation bugs the host will eventually refuse to run.
• theme.json v3 is the schema for new block themes (WP 6.6+). Locally set WP_DEVELOPMENT_MODE to all so theme.json edits are not cached for 30+ seconds. Why: without it you will edit theme.json, see nothing change, and waste an hour.