How to upgrade a WooCommerce site from PHP 7.4 to PHP 8.4 safely

Upgrading a WooCommerce site from PHP 7.4 to PHP 8.4 can expose years of accumulated compatibility debt, especially when the site depends on older premium plugins. In one upgrade project, Freshy found that the main blockers were not WordPress core or WooCommerce itself, but two outdated YITH extensions that produced fatal PHP 8 errors.

Freshy reproduced the failures on staging, updated the incompatible YITH plugins, moved the staging site to PHP 8.4, verified the custom theme and critical ecommerce workflows, and then pushed the approved plugin and PHP changes to production. Final production checks confirmed that the homepage, shop, cart, account, REST API, WooCommerce Store API, convention registration product, Square gateway, Gravity Forms, Advanced Custom Fields, order export, and YITH refund functionality were all operating normally.

Issue background

A WooCommerce site was still running PHP 7.4 and needed to move to PHP 8.4 without breaking registration, ecommerce, payments, forms, or administrative editing.

The project was intentionally scoped as a controlled compatibility upgrade rather than a redesign or general cleanup effort.

The planned process was:

• Create or verify a staging environment and backup.
• Enable debugging and reproduce the existing PHP 8 failure.
• Identify the incompatible plugin or component.
• Update outdated dependencies.
• Move staging to PHP 8.4.
• Resolve remaining compatibility issues.
• Regression test the critical workflows.
• Only after staging was stable, update production and retest.

Diagnosis

Freshy reproduced the PHP 8 failures on staging and isolated two blocking plugins.

The first was YITH Advanced Refund System, which was running version 1.1.3. The reported blocker was:

Parse error in plugin-fw/lib/yit-plugin-gradients.php:443

The second was YITH Added to Cart Popup Premium, which was running version 1.4.5. Its PHP 8 failure was:

Fatal error from unsupported nested ternary in class.yith-wacp-admin-premium.php:468

Those versions were significantly behind the available releases. The documented update path was:

• YITH Advanced Refund System: 1.1.3 → 1.59.0.
• YITH Added to Cart Popup Premium: 1.4.5 → 2.40.0.

The age of the plugins also complicated the maintenance process. Manual activation workarounds did not work reliably, so current plugin packages and valid licensing access were required before the upgrade could move forward safely.

Freshy also reviewed the wider plugin stack because a PHP runtime upgrade can expose compatibility issues in components that do not fail immediately on the homepage. The update checklist included Gravity Forms, Advanced Custom Fields Pro, Defender Pro, WooCommerce extensions, WPMU DEV components, WP Migrate DB Pro, and WooCommerce Gravity Forms Product Add-Ons.

Resolution steps

The documented upgrade process was:

1. Use staging for the PHP upgrade first. The site was tested away from production so fatal errors could be reproduced and resolved safely.
2. Enable debugging and isolate the blockers. The two YITH plugins were confirmed as the PHP 8 fatal-error sources.
3. Update the incompatible YITH plugins. YITH Advanced Refund System and YITH Added to Cart Popup Premium were moved to current compatible versions.
4. Review the remaining plugin stack. Other outdated components were evaluated for PHP 8.4 compatibility and updated where appropriate.
5. Move staging to PHP 8.4. After the plugin blockers were addressed, the staging environment was switched to the newer PHP runtime.
6. Verify the custom theme. The site’s custom theme continued to function correctly under PHP 8.4.
7. Review WooCommerce compatibility. WooCommerce templates and ecommerce behavior were checked after the runtime and plugin updates.
8. Regression test the critical workflows. Freshy verified:

• Homepage and public site pages.
• WooCommerce shop, cart, account, and checkout routing.
• WooCommerce Store API and WordPress REST API.
• PHP 8.4 WordPress/plugin bootstrap without public fatal errors.
• Square credit-card gateway enabled.
• Gravity Forms active, including the site’s active contact form and notification configuration.
• Advanced Custom Fields with 24 active field groups.
• Order export functionality.
• YITH refund functionality.
• Product add-ons and product-dependency plugins.
• Administrative content editing.
• Desktop and mobile homepage rendering at tested viewport sizes.
• YITH add-to-cart popup behavior without the earlier PHP 8 errors.

9. Deploy the approved plugin updates to production. Freshy pushed the plugin changes live after the staging review.
10. Move production to PHP 8.4. The live site was running PHP 8.4 after the production upgrade.
11. Retest production after deployment. Freshy repeated the primary health checks on the live site.

Two WP Migrate-related plugins remained without active licenses and were not updated. Freshy noted that they did not appear to be in active use and could likely be disabled if the client did not need them, but the source task does not document that removal as part of the completed PHP upgrade.

Final outcome

The WooCommerce site was successfully moved from PHP 7.4 to PHP 8.4 after the incompatible YITH extensions were updated.

Production validation confirmed that:

• The homepage, shop, cart, and account pages returned normally.
• The WordPress REST API and WooCommerce Store API were functioning.
• The main public pages and registration product showed no visitor-facing PHP fatal, warning, parse, or deprecation output.
• The convention registration product existed, was in stock, and was purchasable.
• Square was enabled as a credit-card gateway.
• Gravity Forms was active.
• Advanced Custom Fields had 24 active field groups.
• Order export and YITH refund plugins were active.
• WooCommerce had 19 published products, with 3 in stock and 16 purchasable.

The broader lesson is that a PHP upgrade should be treated as a dependency-compatibility project rather than a simple hosting toggle. Old premium plugins can block the runtime upgrade even when the rest of WordPress appears ready, and the safest path is to reproduce the failure on staging, update the known blockers, then regression test the workflows that matter before changing production.

If your WordPress or WooCommerce site is still running an older PHP version and you need help upgrading without breaking payments, forms, or custom functionality, contact Freshy. Our WordPress team can identify incompatible dependencies, test the upgrade on staging, and validate the live site after deployment.