WordPress 7.0 and PHP 8.4: What Breaks in Your Custom Code First

WordPress 7.0 "Armstrong" landed on 20 May 2026 — later than the original WordCamp Asia target — with the first AI substrate in core: an AI Client, a Connectors hub for providers like OpenAI, Google, and Anthropic, and a broader Abilities API than 6.9 shipped in December. The admin got a Command Palette everywhere, visual revisions, responsive block visibility, and new Breadcrumbs and Icons blocks.

Two days earlier, on 22 May, Make WordPress Core published a PHP support clarification that matters more for snippet libraries than any new block: the "beta" label on PHP 8.x is gone. WordPress 6.8+ fully supports PHP 8.4. WordPress 6.9 and 7.0 fully support PHP 8.5. The recommended production version is 8.3 or newer; hosts are being told to default to 8.4.

If your custom code still assumes PHP 7.4 warnings-as-background-noise, this is the release that will surface it.

What 7.0 actually changes for snippet authors

Most snippets do not care about the Icons block. They do care about these:

The AI Client and Connectors. Core can now talk to models without every plugin shipping its own SDK. That is good for product plugins. It is also a new way for poorly reviewed code to send site data off-box. Any snippet that instantiates a client, logs prompts, or registers an ability should go through a security audit the same week you update.

Abilities as a real surface. 6.9 introduced the registry; 7.0 makes it part of the AI story. Snippets that mutate orders, users, or content are now one registration away from being callable by something that is not a human. Capability checks are not optional. See WordPress 6.9's Abilities API if you skipped that pass in January.

Admin chrome. Command Palette everywhere and a refreshed admin will not break hooks, but they will break CSS snippets that targeted old #wpadminbar or menu markup. Scope those snippets to is_admin() and re-test after the update.

PHP-only block registration. If you have been shipping a block via a snippet (no React build), 7.0 makes that path more official. Keep the PHP in a snippet; do not grow a second copy in the theme.

PHP 8.2 is dying this year

PHP 8.2 reaches end of life on 31 December 2026. PHP 8.3 is already security-only. Hosts following the 2026 handbook will push 8.4 as the default.

The failures we see in snippet libraries during these upgrades are boring and consistent:

• Dynamic properties on classes that never declared them (deprecated in 8.2, painful in 8.4)
• Implicit nullable parameters (function foo(Type $x = null) without ?Type)
• Reading undefined globals and array keys that used to be silent
• utf8_encode / other removed functions in copy-pasted helpers
• Code that compared false and 0 in ways 8.x no longer forgives

Core is fine. Abandoned plugins and functions.php fossils are not. Snippets sit in the second bucket unless you treat them like a plugin.

A pre-update audit that fits in an afternoon

Do this on staging, on PHP 8.4, with WP_DEBUG_LOG on, before production 7.0:

1. Export or open the full snippet list. Deactivate anything you cannot name a purpose for.
2. Search for create_function(, each(, utf8_encode(, mysql_, and unprefixed global $.
3. Load checkout, login, wp-admin, and one page-builder template. Read the log, not just the HTML.
4. Re-run a bulk security scan. 7.0's AI connectors make file_get_contents to unknown hosts and loose capability checks more interesting than they were last year.
5. Confirm error isolation still works: break a throwaway snippet on purpose and make sure the rest of the site stays up.

If a snippet fatals only on 8.4, fix the snippet. Do not stay on 8.2 to protect a 12-line hook.

Where AI-generated snippets fit (and fail)

7.0 makes it easier to put a model in the dashboard. It does not make the model's PHP correct.

A chatbot that pastes a block into WPCode or Code Snippets Pro will still happily emit dynamic properties and unsanitized input. The Snippet Engineer is built for the opposite loop: write, sandbox probe, risk score, human approve. That loop matters more now that core itself is an AI client — people will generate more code, faster, with less review.

If you enable core Connectors *and* an in-plugin agent, decide which tool is allowed to publish PHP. Two writers without a Git history is how you get two discount rules on the same cart.

Rollout order we use on client sites

• Staging to 7.0 on PHP 8.4 first, snippets included
• Fix or delete failing snippets before any production core bump
• Production PHP bump or core bump, not both on the same hour
• Keep a file-level rollback. Database-only snippet plugins make "undo that one file" a SQL exercise

GitHub sync helps here: the snippet repo gets a php-84 branch, CI or a staging pull catches the noise, and production pulls after review.

The short version

WordPress 7.0 is an AI-foundations release and a PHP-confidence release at the same time. The block editor will be fine. Your custom code is the part that was never in the 7.0 beta program.

Inventory snippets, run them on 8.4, and do not let an agent publish to production without a sandbox. The sites that treat 7.0 as a theme update will spend June in incident channels. The sites that treat it as a dependency upgrade for *their* code will not.