As a business website running on WordPress, we recently faced a bump while upgrading our hosting to PHP 8.3. I’m sharing the details so customers know what happened, and so future site admins have a clear, tactical record to follow.

First, an apology

Between upgrades and fixes, some visitors saw errors or a temporarily unavailable site. Sorry about that. We treat uptime seriously; the steps below are to ensure this goes smoother next time.

What happened (in plain English)

We upgraded our server from PHP 8.0 to 8.2 and then 8.3. A few legacy theme/custom snippets and server settings weren’t ready for the jump. That caused:

Fatal errors from deprecated WooCommerce hooks.
Warnings in our child theme on PHP 8.2/8.3 (stricter about array keys).
A brief “HTTP 500” caused by memory exhaustion during logging.
Storage hitting the account quota, which blocked updates and even phpMyAdmin.

What we changed (tactical fixes)

Replaced a deprecated WooCommerce hook
- Removed woocommerce_add_order_item_meta from the child theme.
- Added a tiny must-use plugin (/wp-content/mu-plugins/tn-wc-compat.php) using the current hook:
  - woocommerce_checkout_create_order_line_item
  - Carries _custom_options → saves as item_details (compatible with our emails/admin).
Hardened the child theme for PHP 8.2/8.3
- Guarded all array access with ?? and sanitized outputs.
- Updated functions that read/write _custom_options.
- Kept a record of any output changes (escaping) to avoid future notices.
Stopped hard-pinning old PHP in .htaccess
- Removed legacy AddHandler application/x-httpd-php70 .php.
- Let cPanel’s MultiPHP Manager control the version (now PHP 8.3 with PHP-FPM).
Memory & storage
- Set memory_limit to 512M for the domain (resolved “Allowed memory size” fatals).
- Cleared large/old logs and emptied cPanel Trash (Trash counts toward quota).
- Hosting increased our storage allocation to 30GB to prevent future stalls.
Staging clean-up
- Removed the old staging subdomain when it was no longer needed (and its logs).
- Password-protected staging when in use; HTTP only—no forced HTTPS.
Housekeeping
- Deleted temporary phpinfo.php files after checks.
- Turned production debug off in wp-config.php:
  - WP_DEBUG, WP_DEBUG_LOG, WP_DEBUG_DISPLAY → false.

Impact

Short periods of “critical error”/HTTP 500 on the live site during the transition.
No orders were lost; checkout was verified after each change.

For future admins: repeatable checklist

Before upgrading PHP

Update WordPress core, WooCommerce, theme, plugins.
Search codebase for woocommerce_add_order_item_meta (replace with woocommerce_checkout_create_order_line_item in a mu-plugin).
Guard direct array access (use ??) and escape output.
Check .htaccess for any AddHandler/SetHandler/Action lines that pin a PHP version.
Ensure you have headroom: memory ≥ 512M, disk space ≥ 2–3 GB free.

During upgrade

Flip to PHP 8.2 first; smoke-test (home → product → cart → checkout).
If clean, flip to PHP 8.3; smoke-test again.
Purge caches (LiteSpeed) after each flip.

If you hit errors

cPanel → Metrics → Errors is your friend; fix what it says (don’t guess).
“Allowed memory size…” → raise memory_limit.
“Unexpected ‘:’ expecting ‘{‘” → you’re running an old PHP handler somewhere; remove legacy handlers and re-apply PHP-FPM.
“Disk quota exceeded” → permanently delete large logs/caches and empty Trash.

After upgrade

Remove any dev tools (e.g., String Locator) you no longer need.
Keep the mu-plugin; avoid putting business logic in the theme.

Why we’re sharing this

WordPress and WooCommerce are open source. Upgrades occasionally surface legacy assumptions. Publishing our notes helps our future selves—and anyone else running a similar stack—avoid the same issues.

Tag: wordpress

Website upgrade issues