--- title: "Choosing PHP And MySQL Versions, And The Compatibility Trap In Between" url: https://hostmy.blog/wordpress-php-version/ date: 2026-09-12 modified: 2026-09-03 lang: en author: "Aditya Sharma" description: "The PHP version dropdown in your hosting panel is the highest-risk button on the page. Here is how to choose, test and flip it safely." categories: - "Hosting" image: https://hostmy.blog/wp-content/uploads/2026/09/hmb-card-1858-1024x538.jpg word_count: 1654 --- # Choosing PHP And MySQL Versions, And The Compatibility Trap In Between The PHP version dropdown in a hosting panel looks like a settings change. It is closer to swapping the engine while the car is running. Nothing in WordPress warns you before it happens. The site either keeps working or it does not, and when it does not, the failure is usually a white screen with the real error hidden in a log you have to go and find. The trap sits between two true statements. Old PHP versions stop receiving security fixes, so staying put is a real risk. New PHP versions turn old code patterns into fatal errors, so moving is also a real risk. Working through that properly takes about an hour on a staging site, and it is one of the recurring line items in [an hour by hour maintenance month](/wordpress-maintenance-service/). ## Know the support policy, then check today's dates yourself PHP releases a new minor version roughly once a year. Each one gets two years of active bug fixes, followed by two more years of critical security fixes only. Four years in total, after which it receives nothing at all. Do not take specific end-of-life dates from any blog post, including this one, because they move as you read. The current table lives on php.net under supported versions, and it is the only source worth quoting. Same principle for WordPress itself: the minimum and recommended PHP and database versions are published on the WordPress requirements page and change over time. What follows from the policy rather than the dates: | Where you are | Risk | What to do | | ------------- | ---- | ---------- | | On a version past end of life | Unpatched interpreter, and hosts eventually force a move | Plan the upgrade now, on your schedule | | On the security-fix-only version | Acceptable short term | Schedule the move within months | | One minor behind the latest | The sweet spot for most sites | Stay here | | On the newest release, day one | Plugin ecosystem has not caught up | Wait a few months unless you have a reason | Being one version behind the newest is deliberate. The ecosystem needs time, and you are not gaining anything by being first. ## What actually breaks: deprecations that became fatals Most WordPress PHP upgrade failures come from a handful of language changes. Knowing the shape of them helps you read an error log. **Dynamic properties.** Assigning to an undeclared class property was normal for years and is deprecated as of PHP 8.2. Depending on how a site handles errors, that surfaces as a notice, a log flood, or a fatal. It is the most common single cause of a plugin breaking on a modern PHP version. **Passing null where a non-nullable parameter is expected.** Deprecated for internal functions in PHP 8.1, and extremely common in older code that passes an unset variable into a string function. **Comparison semantics.** PHP 8.0 changed how strings and numbers compare. Old code relying on the previous behaviour can start taking a different branch, which is worse than a crash because it fails quietly and looks like a bug in your data. **Removed functions and extensions.** Each release drops things. Code calling something that no longer exists fails immediately, which is at least honest. Notice the pattern. The dangerous failures are not the fatals. A fatal is loud, and you find it in minutes. The expensive one is the site that keeps loading while a form validation, a price calculation or a date comparison quietly takes the wrong path. ## The pre-upgrade inventory, in five commands Run these against the live site, then work on a staging copy that matches it. The conditions that make staging trustworthy are in [a staging environment worth testing on](/wordpress-staging/). `# 1. Where you are now wp cli info # 2. What is installed, and what has updates waiting wp plugin list --fields=name,status,version,update wp theme list --fields=name,status,version,update # 3. What each plugin claims it needs grep -ri "Requires PHP" wp-content/plugins/*/*.php | sort -u # 4. Anything abandoned, which is the real blocker # Check each plugin's WordPress.org page for last-updated date # 5. Syntax check the custom code you own find wp-content/themes/your-child-theme -name "*.php" -exec php -l {} \;` Step three deserves attention. The `Requires PHP` header is a plugin author's declaration of a minimum, not a maximum, so it tells you what is too old rather than what is too new. The genuine signal for "too new" is the plugin's last update date. Code untouched for three years has not been tested against anything released since. ## Test with a static analyser, not by clicking around Clicking around a staging site exercises maybe a tenth of the code. A compatibility scan reads all of it. `composer global require phpcompatibility/phpcompatibility-wp phpcs -p wp-content/plugins/ wp-content/themes/ \ --standard=PHPCompatibilityWP \ --runtime-set testVersion 8.3-` Set `testVersion` to the version you are moving to. The output is noisy, so read it in priority order: errors before warnings, and code paths that run on every request before admin-only screens. Then run the site with errors visible, on staging only: `// wp-config.php on STAGING ONLY define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false );` Walk the flows that matter: publishing a post, submitting the contact form, completing a checkout, running a scheduled job. Then read `wp-content/debug.log` rather than trusting that the pages looked fine. ## The database half, which nobody tests PHP gets the attention. The database version moves too, and it breaks different things. **Reserved words.** MySQL 8 added reserved words that older plugin code used as unquoted column or table names. `rank`, `groups` and `system` are examples. A query that worked for a decade returns a syntax error, and only on the code path that runs it, which might be a report nobody opens until month end. **Strict mode.** Newer defaults reject data that older versions quietly coerced, such as an invalid date or an over-length string. Check what you are running: `wp db query "SELECT @@sql_mode;"` **Storage engine and charset leftovers.** Old sites carry MyISAM tables and `utf8mb3` collations from migrations long past. Find them before an upgrade forces the issue: `wp db query "SELECT table_name, engine, table_collation FROM information_schema.tables \ WHERE table_schema = DATABASE() AND (engine <> 'InnoDB' OR table_collation NOT LIKE 'utf8mb4%');"` **MySQL and MariaDB are not interchangeable.** They share a heritage and have diverged. A host moving you from one to the other during a "database upgrade" is a bigger change than the version number suggests, and it is worth asking which one you are on before and after. ## The upgrade sequence that keeps you in control - Update every plugin and theme first, on the current PHP version. Half of compatibility work is just being current. - Deal with anything abandoned. Replace it or accept it will break, and decide that now rather than at 11pm. The decision framework is in [thinning the plugin list safely](/wordpress-plugin-bloat/). - Clone production to staging, matched on everything except the version you are changing. - Flip PHP on staging only. Run the scan, walk the flows, read the log. - Fix or replace what the log names. Repeat until the log is quiet. - Take a full backup of production, including the database. - Flip production at a low traffic hour, with a rollback path you have confirmed exists in the panel. - Watch the error log and response times for the next hour, then again the next morning. What to watch is in [what is worth watching, and what is not](/wordpress-monitoring/). Step seven has a detail worth stating plainly: confirm before you flip that the panel will let you flip back. Most will. Some hosts remove old versions entirely, which is the sort of constraint [the arithmetic behind a very cheap plan](/cheap-shared-hosting-economics/) tends to produce, and discovering it after the change is a bad way to learn it. ## The genuine upside, stated without exaggeration Newer PHP is meaningfully faster than older PHP for the same code, and it is free performance in the sense that you are not rewriting anything. On a site where server response time is the bottleneck, the version bump is one of the better available moves, which is why it sits early in [the order that moves the Core Web Vitals number](/core-web-vitals-wordpress/). What it will not do is fix a slow site whose problem is a heavy plugin, a missing page cache or a large autoload set. Version upgrades reduce the cost of the work being done. They do not reduce the amount of work. ## One layer a version bump does not touch A newer interpreter changes how fast your pages get built. It does not change whether an AI crawler can fetch and read them, which is a separate layer sitting in WordPress rather than in the stack. RankReady is a WordPress AI SEO plugin that covers that layer: post level schema, a Markdown copy of each page, robots.txt rules for AI crawlers, and an llms.txt file if you want one. Setup takes about five minutes, and it runs alongside Rank Math, Yoast, AIOSEO or SEOPress rather than replacing them, so your existing plugin keeps titles, meta descriptions and the sitemap. Add it after the upgrade rather than during it, for the same reason the sequence above changes one thing at a time. The scope is crawlability and machine readability, not what any assistant decides to quote. It is on [the WordPress.org plugin directory](https://wordpress.org/plugins/rankready-ai-llm-seo/). ## Where Host My Blog fits Nothing above requires a service. The inventory is five commands, the scan is one, and the sequence is eight steps you can run on a Sunday. Host My Blog does this on a schedule for the sites we manage, which is most of [what a managed plan is actually paying for](/managed-wordpress-hosting/), keeping staging matched to production so the test means something, and keeping sites one version behind the latest rather than three versions behind end of life. If you are comfortable reading a debug log, do it yourself. It is a good skill and the tools are free. Two things worth knowing right now: which PHP version is your site on, and is that version still receiving security fixes today?