Preparing Your WordPress Site for a PHP 7.4 → 8.0 Upgrade

Upgrading PHP is one of the most impactful maintenance tasks you can do for a WordPress site. Moving from PHP 7.4 to 8.0 is a bigger step than 8.x‑to‑8.x upgrades because PHP 8 introduced new language features and stricter behaviors. With the right preparation, it’s a smooth, high‑value change.

This guide explains how site owners (non‑sysadmins) can get ready for a successful upgrade from PHP 7.4 to 8.0—what to check, who to involve, how to test, and how to reduce risk.

Why upgrade from 7.4 to 8.0?

Before scheduling the change, here are the practical reasons site owners benefit from moving to PHP 8.0.

• Security posture: PHP 7.4 is end‑of‑life; upgrading closes an important risk gap.
• Performance: PHP 8.0 brings engine optimizations and a JIT compiler that can improve certain workloads.
• Plugin/theme support: Many vendors only test and support current major branches (8.0+). Staying on 7.4 increases compatibility risk over time.

Tip: WordPress core supports modern PHP, but plugins/themes drive most upgrade risk. Currency here matters most.

What changes in 8.0 that might affect WordPress sites?

You don’t need to know internals, but awareness helps. The jump from 7.4 → 8.0 is where many older plugins/themes show their age. Here are the changes most likely to surface in WordPress installs and what to test.

1) Stricter typing & comparisons

• Non‑numeric string vs. number comparisons no longer coerce the string to 0. This can flip conditionals in custom code (e.g., "$qty" == 0). Prefer explicit casting or ctype_digit()/is_numeric() checks.
• Many internal functions now throw TypeError on invalid argument types instead of returning false or null. Watch logs for new fatals in edge cases.

2) Removed curly‑brace string/array offset syntax

• The old $str{0}/$arr{0} syntax is removed. Replace with $str[0] / $arr[0]. Older plugins may still use the curly‑brace form and will error on 8.0.

3) Resource → object migrations (GD & cURL)

• GD image functions now return GdImage objects instead of resource. Code using is_resource($img) or passing the handle by reference may fail. Validate thumbnail generation and image edits (regeneration plugins, custom media pipelines).
• cURL handles are CurlHandle objects in 8.0. Old SDKs that expect resources (some payment/shipping integrations) can break. Ensure gateways/marketing SDKs are current and run checkout tests.

4) Error handling changes you might notice in logs

• Tighter parameter validation means some warnings/notices become errors. Typical symptoms: functions receiving null where a string/array is expected, or invalid image quality values.
• @ error suppression won’t hide certain fatal conditions; plan to fix root causes rather than suppress.

5) New language features (not breaking, but show up in modern plugins)

• Nullsafe operator ($obj?->prop) and union types allow cleaner code; ensure your environment is actually on 8.0+ before deploying plugins that rely on these.
• Constructor property promotion, Stringable, match expressions appear in contemporary libraries. Staying on 7.4 blocks upgrades to these versions; moving to 8.0 unlocks them.

6) WordPress‑specific places to double‑check

• Media: upload JPG/PNG/WEBP; regen thumbnails; verify image edits. Pay attention to plugins that watermark, compress, or convert images.
• Ecommerce: payment gateways (Stripe/PayPal/Authorize.Net) and shipping/tax plugins—many depend on cURL; run test transactions and refunds.
• Caching/optimization: image/CDN optimizers and object cache drop‑ins (Redis/Memcached) should be on versions that list 8.0 support.
• Custom code: search your theme/plugins for { offset syntax and loose comparisons against numbers.

Your pre‑upgrade plan (owner’s checklist)

This section is a non‑technical prep list you can work through with your developer or host. Completing it ahead of time removes most upgrade risk and shortens any maintenance window.

1) Align your team

• Identify decision makers: Who can approve maintenance windows and sign off after testing?
• Name a technical contact: Your developer/agency/host who will execute changes.

2) Capture good backups

• Confirm your host takes daily backups plus on‑demand snapshots. Ask for both files and database. Know how to restore or whom to call.

3) Create (or refresh) a staging site

• Staging should mirror production plugins, theme, and configuration.
• Ensure staging can send test emails (or uses a sandboxed mailer) so you can validate forms without spamming customers.

4) Update what you control

• In WordPress Admin → Dashboard → Updates: update themes and plugins (ideally on staging first).
• Replace abandoned plugins (no recent updates) with actively maintained alternatives.

5) Review plugin/theme compatibility

• Check each critical plugin’s changelog or support notes for PHP 8.0 mentions.
• For custom code, ask your developer for a quick compatibility review and to fix any deprecations flagged on 7.4.

6) Inventory critical user journeys

List the flows that must work after the upgrade (copy/paste and fill in):

• Home → Category → Product → Checkout (which gateways?)
• Login/registration (including social/SSO)
• Forms (contact, quote, application)
• Search & navigation
• Media: image upload + thumbnail generation (JPG/PNG/WEBP)
• Multilingual (WPML/Polylang) + URL switching
• Membership (subscriptions, renewals, coupons)
• Editorial: block editor, pattern library, custom fields (ACF/Meta Box)
• Integrations: CRMs, ERPs, marketing automation, shipping/tax services

7) Confirm cache/CDN behavior

• Note what caching you use (page cache, object cache like Redis, CDN). Plan to purge caches after the upgrade.

8) Communicate the window

• Draft a brief notice for staff and (if applicable) a banner for customers explaining a short maintenance window. Include a support contact.

The testing game plan (on staging first)

Staging is your rehearsal space: switch PHP there first, then walk through the key paths your customers use. Here’s a simple sequence we recommend for owners to follow with their team.

1. Switch staging to PHP 8.0 (your developer/host will do this).
2. Clear caches (plugin cache, CDN, server cache) and reload the site.
3. Run the critical user journeys you listed. Capture screenshots or short notes for anything unexpected.
4. Media test: Upload a few sample images (JPG/PNG/WEBP). Check that thumbnails generate and display.
5. Forms & email: Submit key forms; verify messages are delivered (or appear in transactional email logs like SendGrid/Mailgun).
6. Ecommerce checks (if applicable):
   • Test checkout with sandbox gateways (Stripe test card, PayPal sandbox).
   • Create/refund a test order in the admin.
7. Cron & schedules: If you rely on scheduled posts, inventory syncs, or subscription renewals, ask your developer to confirm scheduled tasks are running.
8. Scan for new warnings: Have your developer glance at the PHP error log and any application monitoring for new notices.

If staging is clean, you’re ready to schedule the production change.

Day‑of upgrade: what to expect

Here’s what a typical PHP upgrade window looks like from a site owner’s perspective, plus signs that things are on track right after the switch.

• A short maintenance window (often 5–15 minutes) while the server switches PHP and caches are cleared.
• A quick sanity pass: homepage, login, a form submission.
• Cache warmup: initial page loads may be slower for a few minutes while caching repopulates.

After the switch

• Run your critical user journeys again.
• Keep an eye on analytics, error trackers, and order notifications for the next few hours.
• Report anomalies to your developer with timestamp, URL, and steps to reproduce.

Rollback mindset

A well‑defined backout plan turns a risky change into a routine one. Agree in advance on who can call a rollback and how it will happen; that clarity reduces stress for everyone involved.

• Confirm your host can revert the PHP version quickly if needed.
• Keep the staging site on 8.0 to continue debugging while production temporarily runs 7.4.
• Document any issues and resolutions for future upgrades.

Special cases to test more deeply

Some sites have extra moving parts that deserve deeper testing because they touch subscriptions, payments, media pipelines, or complex access rules. If your site matches any of the scenarios below, budget additional time on staging before the upgrade.

• WooCommerce/EDD stores with custom checkout, subscriptions, or shipping rules
• Membership/learning sites with complex access rules
• Multisite networks or sites with heavy ACF/Custom Post Types
• Headless/API‑driven sites with external front ends
• Sites using advanced image formats (WEBP) or heavy media processing

FAQ

Here are quick answers to common questions we hear from site owners preparing for a PHP upgrade.

Will my site look different after upgrading PHP?
No—PHP is the engine under the hood. Visual changes only happen if a plugin/theme update changes markup or styles.

Do I need to upgrade WordPress itself first?
It’s best to run a current WordPress core and plugin set before switching PHP. Update on staging, test, then upgrade PHP.

What if a plugin isn’t labeled “PHP 8.0 compatible”?
Lack of labeling doesn’t mean it won’t work, but treat it as a testing priority. Consider alternatives for abandoned plugins.

Can I skip staging?
We strongly recommend against it. Staging catches most issues cheaply.

Need a hand?

Reliable Penguin helps WordPress site owners plan and execute safe PHP upgrades with staging, testing, and rollback built in. If you’d like us to review your plugin stack or run a supervised upgrade, get in touch.