And how to migrate without downtime.
PHP version is the most underestimated infrastructure decision in WordPress. Most businesses are running something they inherited and haven't touched since. That's a security problem, a performance problem, and a compatibility time-bomb — all at once.
When I first looked at the Anchor build's hosting account, the server was on PHP 7.4. PHP 7.4 reached end-of-life in November 2022 — meaning no security patches, no bug fixes, nothing. We were running a business's primary customer-facing system on software the PHP team had officially stopped maintaining.
That's not unusual. Plenty of hosting providers still default to 7.4 or even 7.2 because upgrading is on the customer to do, and most customers don't know they should. Shared hosting setups routinely stay on EOL PHP versions for years.
The performance gap is real. PHP 8.x introduced JIT compilation, an improved OPCache implementation, and internal type system changes that make common PHP operations (array operations, string handling, object instantiation) measurably faster. In my testing on WordPress with WooCommerce-adjacent load patterns, the jump from 7.4 to 8.2 produces a 20–30% baseline throughput improvement before touching application code. That's not trivial.
The security exposure is not trivial either. EOL PHP means unpatched CVEs. Any new vulnerability discovered in the PHP runtime after November 2022 will never be fixed in 7.4. You're running a production system on known-vulnerable software with no remediation path.
I migrated from PHP 7.4 to 8.2 in four steps.
PHP 8.0 made breaking changes that 8.1 and 8.2 maintained. The big ones:
create_function() was hard-removed in 8.0. Any plugin using it crashes with a fatal error.each() was removed in 8.0. Same result.TypeError in strict contexts.str_replace() with array needles and a $count argument changed behavior subtly.I set PHP to 8.2 on the staging environment with error_reporting(E_ALL) and display_errors = Off (log to file, don't expose to visitors). Then I ran through every page type — listing pages, the contact form, admin, all active plugins. I checked the error log after each pass.
The Anchor build had one legacy plugin using create_function(). I updated it. Every other compatibility issue was a plugin that had a newer version available — updating the plugin resolved it.
On Cloudways, PHP version is a server-level toggle. I set it to 8.2, flushed OPCache, hit the homepage immediately, checked the error log. If anything had broken, I would have toggled back to 7.4 in under 30 seconds. Nothing broke.
OPCache caches compiled PHP bytecode. After a PHP version upgrade, old bytecodes compiled under 7.4 can cause subtle errors or incorrect behavior because they were compiled with a different engine version. Flush it explicitly — don't assume the upgrade does it for you.
<?php
if (function_exists('opcache_reset')) {
opcache_reset();
echo 'OPCache cleared';
} else {
echo 'OPCache not enabled';
}
Deploy that file, curl it once, delete it. On Cloudways you can also flush OPCache through the cache panel.
PHP version affects every request your server handles. It's not a one-time fix — it's a baseline you set and maintain. The 20–30% throughput improvement from the runtime upgrade alone is real infrastructure capacity you're leaving on the table by running an outdated version.
More practically: every WordPress plugin update you apply from here on is tested against current PHP versions. Running PHP 7.4 in 2026 means you're on a slowly diverging path where plugin updates increasingly assume features or behaviors that PHP 7.4 doesn't support. The longer you wait, the more compatibility debt accumulates.
The security argument is simple: EOL software has unpatched CVEs. There's no argument for keeping it.
Phase 0 of the Anchor build was a PHP 7.4 → 8.2 migration. Along with the Cloudways managed hosting migration and Cloudflare Pro setup, the PHP upgrade contributed to the baseline throughput improvement before any application code changed.
The 745-second listing page load was primarily an N+1 query problem (covered in Module 2), but the PHP upgrade meant the queries that did run were processed faster, and OPCache hit rates improved because 8.x's OPCache is more aggressive about caching compiled opcodes.
Zero downtime. The migration took 45 minutes total: 30 minutes on staging verification, 10 minutes on production, 5 minutes of smoke testing.
phpinfo() or your hosting control panel. If it's anything below 8.1, you have a problem.Every lesson stays free — no account, no paywall, no email gate, ever. But if you’d rather have this system standing on your business than wire all 48 lessons yourself, leave your email. We’ll send you a direct line to a build — and you’ll be first to hear when we add new tools to the curriculum.
None of this gates a single lesson. The curriculum was free before you got here and it stays that way.
You came here to understand the system, and now you do. If you’d rather have it standing on your business than spend the next three months wiring it yourself, GAP Concierge is the same architecture from these lessons — a white-label AI agent that knows your catalog and captures your leads — set up for you, from $97/mo.
See GAP Concierge →