Updating PHP for WordPress

Updated · 31 Aug 2026

Short answer.

A PHP version changes the runtime for all WordPress code. Treat it as a separate release: compare requirements for core, theme, and plugins; test a copy on the target version; then switch production with a prepared way back.

Check first

Evidence before change.

• The current PHP version and target versions available from the host.
• Documented minimum and maximum versions for components.
• Custom theme, MU-plugins, Code Snippets, and legacy custom code.
• Deprecated warnings, fatal errors, and different loaded PHP extensions.
• Database version, memory and upload limits, plus cron/CLI PHP.
• Separate PHP settings for web, cron, and command-line execution.

Safe sequence

Move in small verifiable steps.

• Select a supported target. The newest version is not automatically the right first jump without a component matrix.
• Copy the site to stage. Keep the same WordPress, database, and integration configuration without real external sends.
• Change only PHP. This keeps new errors attributable to one cause.
• Review logs and journeys. An invisible error may still break cron or an administrative action.
• Switch production. Retain the previous version for a short rollback window and repeat postflight.

Common mistakes

What usually increases risk.

• Updating PHP, core, theme, and every plugin together.
• Judging compatibility only by opening the home page.
• Forgetting that cron and WP-CLI may use a different PHP binary.
• Hiding errors without reviewing the protected error log.

320px Site Audit

What can be checked automatically.

Site Audit compares the active PHP version with the documented WordPress baseline and shows selected declared component requirements. This is a preflight signal, not proof that every custom code path is compatible.

When help is useful

A concrete next step.

320px can handle a PHP update as a separate verifiable release within ongoing support.