Getting ready for WordPress 7.0 — three things to check now: PHP requirements, FSE migration, and editor extensions

Five failure patterns from past WordPress major upgrades ended with the observation that “the same structures will recur in some form in the next major (7.0 or 8.0).” This post applies that pattern knowledge to WordPress 7.0 specifically — not as a list of things that will happen, but as a preparatory checklist for what you can verify now.

This sits alongside the seven-item pre-flight checklist from W1 rather than replacing it. Think of it as the 7.0-specific supplement.

Item 1 — PHP minimum requirement increase (W3 pattern 3 again)

W3’s pattern 3 was “older plugins break with parse errors when the PHP minimum requirement is raised.” This pattern repeats on every major upgrade cycle. WordPress 7.0 is expected to follow the same trajectory.

Background:

• PHP 7.4 reached end-of-life from the PHP project in November 2022 (security support ended November 2023)
• WordPress 6.6 requires PHP 7.2 minimum
• WordPress 7.0 is expected to raise the minimum to PHP 8.0 or later

When this happens, sites running PHP 7.x will encounter plugins and themes that “worked fine before” but break with syntax or fatal errors after the upgrade. The mechanism is the same as past cycles — the plugin hasn’t updated its code to handle PHP 8.x stricter type handling, and the errors surface only at runtime.

What you can check now:

# Confirm the server’s PHP version
php -v

# List all plugins with their current version and update status
wp plugin list --fields=name,version,update,update_version --format=table

# Run a JSON output check — noisy output here means PHP warnings already leaking
wp plugin list --format=json

The pattern to watch for: plugins with an old “Tested up to” value and no updates in the past year. These are the highest risk candidates for PHP compatibility issues when the minimum requirement moves.

The post on PHP 8.2 Deprecated warnings leaking into WP-CLI JSON output covers a related symptom — even when PHP compatibility doesn’t cause a hard break, it can silently corrupt output in ways that are hard to trace. Worth having on the checklist alongside the version check.

Item 2 — FSE standardization and theme migration (W3 pattern 4 revisited)

W3’s pattern 4 was the FSE migration period in 6.0, where child theme customizations stopped working when switching to Block Themes. The 6.x cycle has steadily moved Block Themes toward the center — WordPress 7.0 is expected to continue that trajectory, with Classic Themes moving further toward “supported but not the primary path.”

What this means in practice: sites still on Classic Themes don’t necessarily break when 7.0 arrives, but the friction accumulates. Theme updates, new block features, and plugin compatibility improvements increasingly target Block Theme architecture first. Classic Theme sites may find themselves in a “technically working but falling behind” position.

What you can check now:

• Identify which sites use Classic Themes and which use Block Themes
  bash
wp theme list --status=active --format=table
# Check for a block-templates/ directory — its presence indicates a Block Theme
• For sites on Classic Themes with deep customization: estimate what a migration to Block Theme would require
• Identify sites where the migration cost is high enough that staying on Classic Theme is the right call for now (and document that decision)

The key discipline here: treat upgrading the WordPress core and migrating the theme architecture as two separate decisions. Doing both at once when a major version drops makes it impossible to isolate which change caused a problem. The core upgrade can happen on 7.0’s schedule; the theme migration happens on its own schedule.

Item 3 — Gutenberg Phase 3 and editor extension impact (W3 pattern 1 continuing)

W3’s pattern 1 was the 5.0 Gutenberg launch where editor extensions built for the Classic Editor stopped working. Gutenberg’s roadmap follows a phase structure — Phase 3 (collaborative editing, enhanced revision management, data library) continues that trajectory.

Collaborative editing changes the fundamental state management model of the editor. Third-party plugins that hook into editor internals — custom meta boxes, custom field UIs, sidebar extensions — face the same structural risk they faced in 5.0. The specific APIs differ, but the pattern is the same: a significant internal change in how the editor works causes adjacent extensions to lose their footing.

What you can check now:

• List your active editor extension plugins
  bash
wp plugin list --status=active --format=table
# Manually identify editor-adjacent plugins: ACF, Pods, Meta Box, custom meta boxes, etc.
• Check whether major vendors (ACF, Pods, Meta Box, WooCommerce block extensions) have announced Phase 3 compatibility
• For plugins where no Phase 3 announcement exists yet, identify potential alternatives and flag them for follow-up

Note: “we don’t use collaborative editing” doesn’t mean you’re unaffected. Internal API changes in Phase 3 can affect plugins even on sites where the collaborative features themselves are never used. The dependency is on the editor internals, not the end-user feature.

Summary — what to do before 7.0 drops

The common thread: starting this work after 7.0 is announced puts you under time pressure. Replacing plugins that don’t support PHP 8.x requires research, testing, and a migration window. Theme migration is a substantial project. Editor extension alternatives may need to wait for vendors to ship updates.

The step-by-step WP-CLI upgrade procedure from W4 pairs well with this list: once you’ve completed the pre-flight checks, the actual upgrade sequence follows the same pattern regardless of which major version you’re applying. And W2’s staged rollout approach — applying to lower-risk sites first before production — is especially useful when you have a mix of sites at different levels of readiness.

The W series in full

Pattern knowledge from W3 is most useful before the upgrade, not after. Knowing that PHP requirement increases follow a predictable pattern is only actionable if you run the plugin audit before 7.0 drops, not after the first site breaks. The preparation window is now.