PHP Version Management and Upgrade Strategies on WordPress Managed Hosting Platforms

Why PHP Version Management Matters on Managed Hosting

Every WordPress site runs on PHP. The version of PHP powering your site affects page load speed, memory consumption, security posture, and compatibility with plugins and themes. On managed hosting platforms, PHP version management works differently than on a traditional VPS where you compile from source or toggle versions through a package manager. Each managed host provides its own interface, its own constraints, and its own timeline for adopting new PHP releases.

This article covers practical PHP version management across six major managed WordPress hosting platforms: Kinsta, WP Engine, Pantheon, Cloudways, WordPress VIP, and a few others worth mentioning. The focus is on the PHP 8.0 and 8.1 era (current as of mid-2022), with attention to upgrade planning, compatibility testing, rollback procedures, and automation strategies that work regardless of which host you use.

If you manage one WordPress site, changing PHP versions is a five-minute task. If you manage fifty or a hundred sites across multiple hosting accounts, you need a strategy. This guide provides both the quick-reference commands and the broader planning framework.

PHP Version Support Overview in 2022

Before looking at platform-specific controls, here is where PHP versions stand as of August 2022:

PHP 7.4 reached end of life for active support in November 2021. Security fixes continue until November 2022, after which no patches will be released. Sites still running PHP 7.4 should treat upgrading as urgent.

PHP 8.0 is in active support until November 2022, with security fixes continuing through November 2023. This is the baseline version that most managed hosts now default to for new installations.

PHP 8.1 is the current stable release, with active support through November 2023 and security support through November 2024. It introduced fibers, enums, readonly properties, intersection types, and the never return type. For WordPress sites, the practical benefits are better performance (benchmarks show 2-5% improvements over 8.0 on typical WordPress workloads) and access to modern PHP features in newer plugins.

PHP 8.2 is in release candidate stage and expected in late November 2022. WordPress core has been working on 8.2 compatibility, but early adoption on production sites is not recommended until WordPress explicitly declares support.

Most managed WordPress hosts currently support PHP 7.4, 8.0, and 8.1. A few still offer PHP 7.3 for legacy compatibility. The direction is clear: PHP 8.0 is the floor, 8.1 is the recommended target, and planning for 8.2 should begin now.

WordPress Core PHP Requirements

WordPress itself has historically been conservative about minimum PHP requirements. As of WordPress 6.0, the minimum supported version is PHP 5.6, though the recommended version is 7.4 or higher. The WordPress project has signaled that PHP 7.0-7.3 will eventually be dropped, but no firm timeline exists for requiring PHP 8.0.

This gap between what WordPress requires and what PHP.net supports creates a situation where site owners must make their own decisions about when to upgrade. Managed hosts help by limiting the available versions to those that are tested and supported, but the actual upgrade decision and testing responsibility falls on the site owner.

Kinsta: Per-Site PHP Version Control

Kinsta provides granular PHP version management at the individual site level. Each site on your Kinsta account can run a different PHP version, which is useful when managing a portfolio of client sites with varying compatibility requirements.

Changing PHP Version via MyKinsta Dashboard

The MyKinsta dashboard exposes PHP version controls under each site’s settings:

1. Log in to MyKinsta at my.kinsta.com
2. Select the site from your sites list
3. Navigate to Tools in the left sidebar
4. Find the PHP Engine section
5. Use the dropdown to select your target PHP version
6. Click Modify

The change takes effect within minutes. Kinsta restarts the PHP workers for that specific site without affecting other sites on your account. During the transition, there may be a brief period (typically under 30 seconds) where requests queue while the new PHP processes start.

Available PHP Versions on Kinsta

As of August 2022, Kinsta supports:

PHP 7.4
PHP 8.0
PHP 8.1

Kinsta typically adds support for new PHP versions within weeks of their stable release. They also maintain extended support for older versions longer than some competitors, giving site owners more time to migrate.

Kinsta API for Bulk PHP Version Changes

For agencies managing many sites, Kinsta offers an API that allows programmatic PHP version changes. This is particularly valuable when you need to upgrade dozens of sites on a schedule.

First, retrieve your API key from the MyKinsta dashboard under User Settings > API Keys. Then list your sites:

curl -s -H "Authorization: Bearer YOUR_API_KEY" 
  "https://api.kinsta.com/v2/sites" | jq '.company.sites[] | {id, name, php_version: .environments[0].php_version}'

This returns each site’s ID, name, and current PHP version. To change a specific site’s PHP version:

curl -X PUT 
  -H "Authorization: Bearer YOUR_API_KEY" 
  -H "Content-Type: application/json" 
  -d '{"php_version": "8.1"}' 
  "https://api.kinsta.com/v2/sites/environments/YOUR_ENVIRONMENT_ID"

For bulk operations across all sites, you can script this:

#!/bin/bash
API_KEY="YOUR_API_KEY"
TARGET_PHP="8.1"

# Get all environment IDs
ENV_IDS=$(curl -s -H "Authorization: Bearer $API_KEY" 
  "https://api.kinsta.com/v2/sites" | 
  jq -r '.company.sites[].environments[].id')

for ENV_ID in $ENV_IDS; do
  echo "Updating environment $ENV_ID to PHP $TARGET_PHP"
  curl -s -X PUT 
    -H "Authorization: Bearer $API_KEY" 
    -H "Content-Type: application/json" 
    -d "{"php_version": "$TARGET_PHP"}" 
    "https://api.kinsta.com/v2/sites/environments/$ENV_ID"
  echo ""
  # Rate limit: wait between requests
  sleep 2
done

A word of caution: do not run this against production environments without testing first. Use Kinsta’s staging environments (each site gets one by default) to validate compatibility before touching production.

Kinsta Staging and PHP Testing

Every Kinsta site includes a staging environment that mirrors the production setup. The staging environment can run a different PHP version than production, making it ideal for upgrade testing:

1. Push your production site to staging (or use the existing staging copy)
2. Change the staging environment’s PHP version to your target version
3. Run your test suite or manually verify critical functionality
4. If everything passes, change production to match

The staging environment uses a separate URL (e.g., stg-sitename.kinsta.cloud) and separate PHP workers, so testing has zero impact on your live site.

WP Engine: PHP Version Selection and Staging-First Testing

WP Engine takes a slightly more guided approach to PHP version management. They strongly encourage testing on staging before changing production, and their interface reflects this philosophy.

Changing PHP Version on WP Engine

In the WP Engine User Portal:

1. Log in to my.wpengine.com
2. Select your environment (production, staging, or development)
3. Click Overview
4. Find the PHP Version setting
5. Select the desired version and confirm

WP Engine supports PHP 7.4, 8.0, and 8.1 as of mid-2022. They retired PHP 7.3 support in early 2022 and automatically migrated sites that had not upgraded.

WP Engine’s Three-Environment Workflow

WP Engine provides three environments per install: Production, Staging, and Development. Their recommended PHP upgrade workflow uses all three:

Step 1: Development Environment
Change the development environment to the target PHP version. Run automated tests if you have them. Fix any deprecation notices or errors that appear in the error logs.

Step 2: Staging Environment
Copy production to staging, then change staging to the target PHP version. Perform manual testing of all critical paths: checkout flows, form submissions, membership areas, custom functionality.

Step 3: Production
After staging validation, change production to the target PHP version. Monitor error logs closely for the first 24-48 hours.

WP Engine CLI (wpe-cli)

WP Engine provides a command-line tool for site management. While PHP version changes are not directly available through the CLI as of this writing, you can use it for related tasks:

# Install WP Engine CLI
npm install -g @wpengine/wpe-cli

# Authenticate
wpe auth login

# List your installs
wpe installs list

# Check environment details
wpe installs get YOUR_INSTALL_NAME

# Create a backup before PHP change
wpe backup create YOUR_INSTALL_NAME --environment=production --description="Pre-PHP-8.1-upgrade"

Always create a backup before changing PHP versions. WP Engine maintains automatic backups, but having an on-demand backup with a clear description makes rollback faster and more confident.

WP Engine Automatic PHP Compatibility Checks

WP Engine runs periodic PHP compatibility scans on sites running older versions. If your site is on PHP 7.4, you may receive emails alerting you to detected incompatibilities that would arise from upgrading to 8.0 or 8.1. These scans check for:

Deprecated function calls that are removed in the target version
Type declaration conflicts
Changed function signatures
Removed extensions

These automated scans are helpful but not exhaustive. They analyze code statically and cannot detect runtime issues that depend on specific data or configurations.

Pantheon: The pantheon.yml php_version Directive

Pantheon uses a configuration-as-code approach for PHP version management. Instead of clicking through a dashboard, you set the PHP version in a YAML file that lives in your site’s Git repository.

Setting PHP Version in pantheon.yml

The pantheon.yml file sits in the root of your Pantheon site’s repository. To change the PHP version:

# pantheon.yml
api_version: 1

php_version: 8.1

Commit this change and push it to Pantheon:

git add pantheon.yml
git commit -m "Upgrade PHP version to 8.1"
git push origin master

When Pantheon receives this commit, it rebuilds the environment with the specified PHP version. The change applies to the environment you push to (Dev, Test, or Live, depending on your workflow).

Pantheon’s Workflow: Dev, Test, Live

Pantheon enforces a strict deployment pipeline: code moves from Dev to Test to Live, never the reverse. This pipeline maps well to PHP upgrade testing:

Dev Environment: Set php_version: 8.1 in pantheon.yml, push to Dev. Test functionality in the Dev environment using the Dev URL.

Test Environment: Deploy the pantheon.yml change from Dev to Test. The Test environment uses a copy of the Live database, so you can test with real content and data. Run your compatibility checks here.

Live Environment: Deploy from Test to Live. The PHP version change takes effect on the production site.

# Using Terminus CLI for Pantheon
# Install Terminus
curl -O https://raw.githubusercontent.com/pantheon-systems/terminus-installer/master/builds/installer.phar
php installer.phar install

# Authenticate
terminus auth:login --machine-token=YOUR_TOKEN

# Check current PHP version
terminus env:info my-site.dev --field=php_version

# Deploy from Dev to Test
terminus env:deploy my-site.test --note="PHP 8.1 upgrade"

# Deploy from Test to Live
terminus env:deploy my-site.live --note="PHP 8.1 upgrade"

Pantheon php.ini and Custom PHP Configuration

Beyond the PHP version itself, Pantheon allows limited PHP configuration through a php.ini file or individual .ini files in a specific directory:

# Create custom PHP settings
mkdir -p /code/php
cat > /code/php/custom.ini <<EOF
upload_max_filesize = 100M
post_max_size = 100M
max_execution_time = 300
memory_limit = 512M
EOF

These settings can be important during PHP version transitions. Some plugins may need higher memory limits when running on a newer PHP version, especially during the initial opcode cache warm-up period.

Version Constraints on Pantheon

Pantheon supports PHP 7.4, 8.0, and 8.1. They validate the php_version value in pantheon.yml and reject unsupported values. If you specify a version that Pantheon does not support, the deployment fails with a clear error message indicating which versions are available.

One detail unique to Pantheon: the PHP version applies per-environment based on which code is deployed there. This means your Dev environment can be running PHP 8.1 while Live is still on 8.0, as long as the pantheon.yml in each environment specifies the appropriate version.

Cloudways: Server-Level vs. Application-Level PHP

Cloudways occupies an interesting middle ground between fully managed WordPress hosting and infrastructure-as-a-service. Their PHP version management reflects this dual nature, and the specifics depend on which server management mode you are using.

Cloudways Flexible (Server-Wide PHP)

In Cloudways’ standard (Flexible) mode, PHP version is set at the server level. All applications on that server share the same PHP version. To change it:

1. Log in to the Cloudways Platform at platform.cloudways.com
2. Select your server from the server list
3. Navigate to Settings & Packages
4. Click the Packages tab
5. Find PHP and select the desired version
6. Click Save

The server restarts its PHP-FPM service, which causes a brief interruption (typically 10-30 seconds) for all applications on that server. This is the most significant limitation of the Flexible approach: you cannot test one application on PHP 8.1 while keeping another on 8.0 if they share a server.

Cloudways Autonomous (Per-Application PHP)

Cloudways introduced the Autonomous mode to address the server-wide limitation. In Autonomous mode, each application can run its own PHP version independently. This is closer to what Kinsta and WP Engine offer.

To use Autonomous mode, you must launch a new server with Autonomous enabled (it cannot be switched on existing Flexible servers). Once running:

1. Select your application in the Cloudways dashboard
2. Go to Application Settings
3. Change the PHP Version dropdown
4. Save the setting

The change applies only to that specific application. Other applications on the same server continue running their independently configured PHP versions.

Cloudways CLI (CW CLI)

Cloudways provides a command-line interface for server and application management:

# Install Cloudways CLI
curl -sS https://cw-cli.cloudways.com/install.sh | bash

# Login
cw-cli login --email=YOUR_EMAIL --api-key=YOUR_API_KEY

# List servers
cw-cli server:list

# List applications on a server
cw-cli app:list --server_id=YOUR_SERVER_ID

# Get current PHP version (Flexible mode)
cw-cli server:getSetting --server_id=YOUR_SERVER_ID --setting=php_version

For agencies managing multiple Cloudways servers, the CLI enables scripted PHP version updates across your fleet. However, the server-restart requirement in Flexible mode means you should schedule these changes during low-traffic windows.

Cloudways PHP Configuration

Cloudways exposes many PHP settings through the dashboard that other managed hosts lock down:

execution_limit
memory_limit
upload_size
max_input_vars
max_input_time
OPcache settings

When upgrading PHP versions on Cloudways, review these settings. PHP 8.x changed some default values compared to 7.x. For example, the default value for error_reporting changed, and certain previously silenced warnings became more visible. Adjusting display_errors and error_reporting after an upgrade can prevent unexpected output on production sites.

WordPress VIP: Platform-Managed PHP Versions

WordPress VIP operates differently from the other platforms discussed here. VIP is an enterprise-grade managed platform where the infrastructure team controls most server-level settings, including PHP versions.

How VIP Handles PHP Versions

On WordPress VIP, you do not choose your PHP version through a dashboard or configuration file. The VIP platform team manages PHP version rollouts across the platform, and upgrades happen on their schedule. This approach ensures consistency, security, and compatibility across all VIP-hosted sites.

As of mid-2022, WordPress VIP runs PHP 8.0 across its production environments. The migration from PHP 7.4 to 8.0 was handled by the VIP team in coordination with clients, with advance notice and compatibility assistance provided.

Preparing for VIP PHP Upgrades

Even though you do not control the timing of PHP upgrades on VIP, you still need to prepare your code. VIP provides several tools for this:

VIP CLI:

# Install VIP CLI
npm install -g @automattic/vip

# Login
vip login

# Check your site's current environment
vip app --app=YOUR_APP_NAME

# Run PHP compatibility analysis
vip dev-env exec -- wp eval 'phpinfo();' --app=YOUR_APP_NAME

VIP Code Analysis Bot: When you submit code through the VIP GitHub repository workflow, automated checks scan for PHP compatibility issues. The VIP bot flags deprecated functions, removed features, and type conflicts before your code reaches production.

Local Development Environment: VIP provides a local development environment (vip dev-env) that mirrors the production PHP version:

# Create local dev environment matching VIP production
vip dev-env create --app-code=~/my-vip-site --php=8.0

# Start the environment
vip dev-env start

# Run your test suite against the VIP-matching PHP version
vip dev-env exec -- vendor/bin/phpunit

VIP PHP Version Communication

VIP communicates PHP version changes through several channels:

Lobby posts (internal VIP client communication channel)
Direct communication from your VIP account team
VIP documentation updates at docs.wpvip.com
Advance notification periods (typically 60-90 days before a change)

The trade-off with VIP is clear: you sacrifice direct control in exchange for a platform team that handles the complexity of PHP upgrades across a fleet of high-traffic sites with enterprise SLAs.

Compatibility Testing Strategy

Regardless of which hosting platform you use, the testing process for a PHP version upgrade follows a similar pattern. The goal is to identify breaking changes before they reach production and to have a clear rollback plan if something slips through.

Static Analysis with PHPCompatibility

The PHPCompatibility standard for PHP_CodeSniffer is the primary tool for static PHP version compatibility checking. It analyzes your codebase without executing it and flags functions, syntax, and patterns that are incompatible with your target PHP version.

Install and run it:

# Install PHP_CodeSniffer and PHPCompatibility
composer global require squizlabs/php_codesniffer
composer global require phpcompatibility/php-compatibility
composer global require phpcompatibility/phpcompatibility-wp

# Configure the installed standards path
phpcs --config-set installed_paths ~/.composer/vendor/phpcompatibility/php-compatibility,~/.composer/vendor/phpcompatibility/phpcompatibility-wp

# Scan your theme for PHP 8.1 compatibility
phpcs --standard=PHPCompatibilityWP 
  --runtime-set testVersion 8.1 
  --extensions=php 
  -p 
  wp-content/themes/your-theme/

# Scan all plugins
phpcs --standard=PHPCompatibilityWP 
  --runtime-set testVersion 8.1 
  --extensions=php 
  -p 
  wp-content/plugins/

# Generate a report file for review
phpcs --standard=PHPCompatibilityWP 
  --runtime-set testVersion 8.1 
  --extensions=php 
  --report=full 
  --report-file=php81-compatibility-report.txt 
  wp-content/plugins/

The PHPCompatibilityWP standard extends the base PHPCompatibility rules with WordPress-specific polyfills. For example, WordPress core includes polyfills for certain functions, so using those functions is not actually an incompatibility even though they were introduced in a newer PHP version.

Common PHP 8.0 and 8.1 Breaking Changes

When scanning results come back, these are the most frequently encountered issues in WordPress plugins and themes:

Null passed to internal functions (PHP 8.0+): Many PHP internal functions that previously accepted null now throw a deprecation notice or TypeError. Common culprits include strlen(null), strpos(null, ...), trim(null), and strtolower(null). WordPress core addressed many of these, but plugins frequently trigger them.

// Before (works in 7.4, deprecation in 8.0, error in 8.1)
$length = strlen($maybe_null_value);

// After (safe across all versions)
$length = strlen((string) $maybe_null_value);
// Or more explicitly:
$length = $maybe_null_value !== null ? strlen($maybe_null_value) : 0;

Named arguments (PHP 8.0+): PHP 8.0 introduced named arguments, but this also means that internal function parameter names became part of the API. If a plugin uses call_user_func_array with string keys in the arguments array, those keys are now treated as parameter names, which can cause unexpected behavior.

Match expression and enum reserved words (PHP 8.0+ and 8.1+): match became a reserved keyword in PHP 8.0, and enum in PHP 8.1. Any class, function, or constant named match or enum will cause a fatal error.

Return type changes in built-in classes (PHP 8.1): Several built-in classes and interfaces now declare return types. If your code extends these classes and overrides methods without matching return types, PHP 8.1 throws a deprecation notice:

// PHP 8.1 deprecation: Return type of MyIterator::current() should
// either be compatible with Iterator::current(): mixed, or the
// #[ReturnTypeWillChange] attribute should be used

class MyIterator implements Iterator {
    // Add the attribute to suppress the deprecation
    #[ReturnTypeWillChange]
    public function current() {
        return $this->items[$this->position];
    }
}

Passing null to non-nullable internal function parameters (PHP 8.1): This was a deprecation in 8.0 that becomes stricter in 8.1. Many WordPress plugins trigger this with patterns like:

// Common in older plugins
add_filter('the_content', function($content) {
    return str_replace('old', 'new', $content); // $content can be null
});

Error Log Monitoring

Static analysis catches many issues, but runtime behavior can only be observed by actually running the site on the new PHP version. After switching a staging environment to the target PHP version, monitor error logs aggressively.

On most managed hosts, you can access PHP error logs through the dashboard or via SSH/SFTP. Some platform-specific approaches:

# Kinsta: Access logs via SFTP or MyKinsta log viewer
# Logs are at ~/logs/error.log

# WP Engine: Access via User Portal > Logs or SSH
ssh YOUR_INSTALL@YOUR_INSTALL.ssh.wpengine.net
tail -f /var/log/php-errors.log

# Pantheon: Use Terminus
terminus logs:get my-site.dev --type=php-error

# Cloudways: SSH into your server
ssh master@YOUR_SERVER_IP -p YOUR_PORT
tail -f /home/master/applications/YOUR_APP/logs/php-fpm/error.log

Enable WP_DEBUG and WP_DEBUG_LOG on your staging environment to capture WordPress-level errors:

// wp-config.php (staging only)
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

After enabling debug logging, exercise the site thoroughly: visit every major page type, submit forms, run any AJAX-dependent features, trigger scheduled tasks (WP-Cron), and process any queue-based operations. Check wp-content/debug.log for new deprecation notices, warnings, and errors.

Plugin and Theme Compatibility Checking Tools

Beyond manual scanning, several tools and resources help assess compatibility:

WordPress Plugin Directory: Each plugin’s page on wordpress.org now shows a “Requires PHP” field. Check this for all your active plugins. If a plugin lists PHP 7.4 as its minimum without mentioning 8.0 or 8.1 support, investigate further.

WP CLI PHP Compatibility Check: The WP-CLI community has packages that integrate compatibility scanning:

# Install WP-CLI compat check package
wp package install developer/php-compat-command

# Run compatibility check
wp php-compat --php-version=8.1

Plugin Update Changelogs: Before upgrading PHP, update all plugins and themes to their latest versions. Plugin developers frequently release updates to add PHP 8.x compatibility. Reading changelogs for phrases like “PHP 8.0 compatibility” or “fixed deprecation notices” tells you which plugins have been actively maintained for newer PHP versions.

WordPress.org Plugin Trac: For popular plugins, check their Trac or GitHub issues for PHP 8.0/8.1 related bug reports. A plugin with open, unresolved PHP 8.1 issues is a risk. A plugin with resolved PHP 8.1 issues indicates active maintenance.

Automated Testing for PHP Version Upgrades

Manual testing catches obvious issues, but automated testing provides repeatable, thorough coverage. If your WordPress site has custom plugins or a custom theme with business logic, automated tests are the most reliable way to validate PHP version compatibility.

PHPUnit for WordPress:

WordPress core ships a test suite based on PHPUnit. For custom code, the WP-CLI scaffold command generates test boilerplate:

# Scaffold plugin tests
wp scaffold plugin-tests your-plugin-name

# The generated structure:
# your-plugin-name/
#   tests/
#     bootstrap.php
#     test-sample.php
#   phpunit.xml.dist
#   .travis.yml (or you can use GitHub Actions)

# Run tests locally against PHP 8.1
phpunit --configuration phpunit.xml.dist

GitHub Actions Matrix Testing:

A GitHub Actions workflow that tests against multiple PHP versions catches compatibility issues on every commit:

# .github/workflows/php-compat.yml
name: PHP Compatibility

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        php-version: ['7.4', '8.0', '8.1']

    steps:
      - uses: actions/checkout@v3

      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: ${{ matrix.php-version }}
          extensions: mysqli, gd, zip, intl
          tools: phpunit, composer

      - name: Install dependencies
        run: composer install --prefer-dist --no-progress

      - name: Run PHPUnit
        run: vendor/bin/phpunit

      - name: Run PHP_CodeSniffer with PHPCompatibility
        run: |
          composer global require phpcompatibility/phpcompatibility-wp
          phpcs --config-set installed_paths $(composer global config home)/vendor/phpcompatibility/php-compatibility,$(composer global config home)/vendor/phpcompatibility/phpcompatibility-wp
          phpcs --standard=PHPCompatibilityWP --runtime-set testVersion ${{ matrix.php-version }} --extensions=php -p .

This workflow runs on every push and pull request, testing your code against PHP 7.4, 8.0, and 8.1. If a developer introduces code that is incompatible with any of these versions, the CI pipeline fails before the code is merged.

Docker-Based Local Testing:

For local development, Docker provides a fast way to test against different PHP versions without modifying your system:

# Test against PHP 8.1
docker run --rm -v $(pwd):/app -w /app php:8.1-cli php -l your-file.php

# Lint all PHP files against PHP 8.1
docker run --rm -v $(pwd):/app -w /app php:8.1-cli bash -c 
  "find . -name '*.php' -not -path './vendor/*' -exec php -l {} ;"

# Run PHPUnit against PHP 8.1
docker run --rm -v $(pwd):/app -w /app 
  php:8.1-cli bash -c 
  "curl -sS https://getcomposer.org/installer | php && 
   php composer.phar install && 
   vendor/bin/phpunit"

Integration Testing with wp-env:

The @wordpress/env package provides Docker-based WordPress environments for testing. You can specify the PHP version in .wp-env.json:

{
  "phpVersion": "8.1",
  "plugins": [
    "./my-plugin"
  ],
  "themes": [
    "./my-theme"
  ]
}

// Start the environment
npx wp-env start

// Run plugin tests inside the environment
npx wp-env run tests-cli --env-cwd=wp-content/plugins/my-plugin 
  phpunit --configuration phpunit.xml.dist

// Stop when done
npx wp-env stop

Rollback Procedures Per Platform

Every PHP upgrade should have a tested rollback plan. The specifics depend on your hosting platform.

Kinsta Rollback

Kinsta makes rollback straightforward:

1. Go to MyKinsta > Sites > Your Site > Tools
2. Change the PHP version back to the previous version
3. The change takes effect within minutes

If the PHP upgrade caused data corruption or configuration issues beyond the PHP version itself, use Kinsta’s backup restore feature:

1. Go to MyKinsta > Sites > Your Site > Backups
2. Select a backup from before the PHP change
3. Restore to the production environment

Kinsta maintains automatic daily backups plus environment-level backups created during pushes and restores.

WP Engine Rollback

WP Engine provides multiple rollback mechanisms:

PHP Version Revert: Change the PHP version back through the User Portal. The process is the same as upgrading, just selecting the previous version.

Backup Restore: WP Engine creates automatic backups and allows on-demand backups. Restore from a pre-upgrade backup if needed:

# WP Engine also supports restore via their API
# Check available backup points in the User Portal under Backup/Restore

Checkpoint Restore: WP Engine creates automatic checkpoint backups before certain operations. If a PHP version change was recent, a checkpoint may be available for quick restoration.

Pantheon Rollback

Pantheon’s Git-based workflow makes rollback a standard Git operation:

# Revert the pantheon.yml change
git revert HEAD  # If the PHP change was the last commit
git push origin master

# Or manually set the previous version
# Edit pantheon.yml to set php_version back to 8.0
git add pantheon.yml
git commit -m "Rollback PHP version to 8.0 due to compatibility issues"
git push origin master

# Then deploy through the pipeline
terminus env:deploy my-site.test --note="PHP rollback"
terminus env:deploy my-site.live --note="PHP rollback"

Because Pantheon uses Git, you have a complete history of PHP version changes and can revert to any previous state.

Cloudways Rollback

On Cloudways, rollback depends on your server mode:

Flexible mode: Change the server’s PHP version back through Settings & Packages. All applications on the server revert together.

Autonomous mode: Change the individual application’s PHP version back through Application Settings.

Cloudways also provides server-level backups that can be restored:

# Using Cloudways API for backup restoration
curl -X POST 
  -H "Authorization: Bearer YOUR_TOKEN" 
  -d "server_id=YOUR_SERVER_ID&backup_id=YOUR_BACKUP_ID" 
  "https://api.cloudways.com/api/v1/server/manage/restore"

General Rollback Best Practices

Regardless of platform, follow these rollback principles:

Create a manual backup immediately before the upgrade. Automatic backups are great, but having a named, timestamped backup that you created specifically for this purpose removes any ambiguity about which backup to restore.

Document the pre-upgrade state. Before upgrading, note the current PHP version, any custom php.ini settings, and the current state of all plugins (versions, active/inactive status). A simple text file or spreadsheet works.

Set a rollback deadline. Decide in advance how long you will monitor after the upgrade before declaring success. Common windows are 24 hours for low-traffic sites, 48-72 hours for medium-traffic sites, and one full business cycle (typically one week) for high-traffic or e-commerce sites.

Monitor key metrics. After the upgrade, watch PHP error rates, page load times, server response times, and conversion rates (if applicable). A PHP upgrade that does not cause errors but degrades performance by 20% still warrants investigation.

Timeline Planning with WordPress Core PHP Requirements

Planning PHP version upgrades requires understanding three timelines: the PHP release cycle, the WordPress core compatibility timeline, and your hosting platform’s support window.

PHP Release Cycle

PHP follows a predictable annual release cycle:

New major/minor version released in late November each year
Two years of active support (bug fixes and security fixes)
One additional year of security-only fixes
Then end of life: no more patches

For planning purposes, the timeline for currently relevant versions:

PHP 7.4: EOL November 2022 (security only since November 2021)
PHP 8.0: Security only from November 2022, EOL November 2023
PHP 8.1: Active support through November 2023, EOL November 2024
PHP 8.2: Expected release November 2022, active support through November 2024

WordPress Core Compatibility

WordPress core tests against new PHP versions before their release and typically achieves compatibility within one or two minor WordPress releases after a new PHP version launches. For PHP 8.1, WordPress 5.9 (released January 2022) included initial compatibility improvements, and WordPress 6.0 (May 2022) addressed the majority of remaining issues.

The WordPress project maintains a PHP compatibility tracking page on Make WordPress Core (make.wordpress.org/core) where you can follow the status of compatibility work for upcoming PHP versions.

Building a PHP Upgrade Timeline

Here is a practical timeline template for upgrading from PHP 8.0 to 8.1 on a managed WordPress hosting platform:

Week 1-2: Audit

Run PHPCompatibility scan on all custom code
Check all plugin/theme compatibility with PHP 8.1
Identify plugins that need updates or replacements
Update all plugins and themes to their latest versions

Week 3: Fix

Fix any compatibility issues found in custom code
Contact plugin developers about unresolved issues
Find alternatives for plugins that will not support PHP 8.1

Week 4: Test on Staging

Copy production to staging
Change staging PHP to 8.1
Run automated test suite against staging
Perform manual testing of all critical paths
Monitor staging error logs for 48 hours

Week 5: Upgrade Production

Create a manual backup
Change production PHP to 8.1 during a low-traffic window
Monitor error logs continuously for the first 4 hours
Check key metrics at 24 and 48 hours
Declare success or rollback

For agencies managing multiple sites, this timeline applies per-site or per-batch. Group sites by similarity (same plugins, same theme) and upgrade in batches, using the first batch as a canary group.

Handling Sites That Cannot Upgrade

Some sites will have hard blockers that prevent upgrading: a business-critical plugin that does not support the target PHP version, custom code that requires significant refactoring, or a legacy integration that uses deprecated features.

For these sites:

Short-term: Document the blocker, set a review date, and keep the site on its current PHP version. Make sure the current version is still within PHP’s security support window.

Medium-term: Create a plan to resolve the blocker. This might mean replacing a plugin, refactoring custom code, or working with a plugin developer to expedite compatibility work.

Long-term: If a site cannot move forward due to fundamental architectural issues, consider whether a larger rebuild or migration is warranted. Sites stuck on PHP 7.4 after November 2022 are running on unsupported software, which is a security risk regardless of how many WordPress security plugins are installed.

PHP Configuration Differences Across Platforms

Beyond the PHP version itself, managed hosting platforms vary in how much control they give you over PHP configuration. These differences matter during upgrades because certain PHP settings interact with version-specific behavior.

OPcache Settings

OPcache compiles PHP scripts into bytecode and caches them in memory. After a PHP version upgrade, the opcode cache needs to be flushed and rebuilt. Most managed hosts handle this automatically when you change PHP versions, but if you experience strange behavior immediately after an upgrade (stale code executing, methods appearing to not exist), clearing the OPcache is the first troubleshooting step.

# If you have WP-CLI access, clear OPcache
wp eval "if (function_exists('opcache_reset')) { opcache_reset(); echo 'OPcache cleared'; } else { echo 'OPcache not available'; }"

# Or create a temporary PHP file (delete after use!)
# opcache-clear.php
<?php
if (function_exists('opcache_reset')) {
    opcache_reset();
    echo 'OPcache cleared successfully.';
} else {
    echo 'OPcache is not enabled.';
}
?>

Memory Limits

PHP 8.x can use slightly more memory than 7.x for the same workload due to changes in internal data structures. If your site runs close to the memory limit on PHP 7.4 or 8.0, you may encounter fatal errors after upgrading to 8.1. Check your current memory usage before upgrading:

# Check WordPress memory limit
wp eval "echo 'WP Memory Limit: ' . WP_MEMORY_LIMIT . PHP_EOL; echo 'PHP Memory Limit: ' . ini_get('memory_limit') . PHP_EOL; echo 'Peak Usage: ' . round(memory_get_peak_usage(true) / 1024 / 1024, 2) . 'M' . PHP_EOL;"

If peak usage is within 80% of the limit, consider requesting a memory limit increase from your host before upgrading PHP.

Error Reporting Levels

PHP 8.0 and 8.1 made several previously silent type coercions into deprecation notices or warnings. A site that ran cleanly on PHP 7.4 with E_ALL error reporting might produce hundreds of notices on PHP 8.1. This does not necessarily mean the site is broken, but it does mean the error logs will be noisy.

On production, keep WP_DEBUG disabled to suppress these notices. On staging, enable it to see everything, fix what you can, and document what you accept as known noise.

Platform Comparison Matrix

To summarize the PHP version management capabilities across platforms:

Per-Site PHP Control:

Kinsta: Yes
WP Engine: Yes (per environment)
Pantheon: Yes (via Git/pantheon.yml per environment)
Cloudways Flexible: No (server-wide)
Cloudways Autonomous: Yes
WordPress VIP: No (platform-managed)

API/CLI PHP Version Change:

Kinsta: Yes (REST API)
WP Engine: Limited (CLI for backups, not PHP version)
Pantheon: Yes (Terminus CLI + Git)
Cloudways: Yes (API and CW CLI)
WordPress VIP: No (managed by VIP team)

Staging Environment:

Kinsta: 1 included per site
WP Engine: Staging + Development environments
Pantheon: Dev + Test + Live (3 environments)
Cloudways: Staging available (cloning)
WordPress VIP: Preprod environments

Rollback Time:

Kinsta: Minutes (dashboard toggle)
WP Engine: Minutes (dashboard toggle)
Pantheon: Minutes (Git revert + deploy)
Cloudways: Minutes (dashboard toggle) + server restart
WordPress VIP: Varies (coordinated with VIP team)

Advanced: Monitoring PHP Upgrades at Scale

For organizations managing more than a handful of sites, monitoring PHP upgrades across your fleet requires tooling beyond what any single hosting platform provides.

Centralized Error Tracking

Deploy a centralized error tracking service that aggregates PHP errors from all your sites. Tools like Sentry, Bugsnag, or Rollbar can capture PHP errors, categorize them by type, and alert you to new error patterns that emerge after a PHP upgrade.

A basic Sentry integration for WordPress:

# Install Sentry PHP SDK
composer require sentry/sentry

# In your theme's functions.php or a must-use plugin:
# mu-plugins/sentry-init.php
<?php
if (file_exists(ABSPATH . 'vendor/autoload.php')) {
    require_once ABSPATH . 'vendor/autoload.php';
    Sentryinit([
        'dsn' => 'https://[email protected]/YOUR_PROJECT',
        'environment' => defined('WP_ENV') ? WP_ENV : 'production',
        'release' => '[email protected]',
        'traces_sample_rate' => 0.2,
    ]);
}

After deploying this to all your sites, a PHP version upgrade on any site will surface new errors in your Sentry dashboard. You can filter by PHP version tag to isolate upgrade-related issues.

Performance Benchmarking

Measure performance before and after each PHP upgrade to quantify the impact:

# Simple benchmark using Apache Bench
ab -n 100 -c 10 https://your-site.com/ > benchmark-php80.txt

# After PHP upgrade
ab -n 100 -c 10 https://your-site.com/ > benchmark-php81.txt

# Compare results
diff benchmark-php80.txt benchmark-php81.txt

# More detailed benchmarking with wrk
wrk -t4 -c20 -d30s https://your-site.com/

# Or use curl for individual page timing
curl -o /dev/null -s -w "DNS: %{time_namelookup}snConnect: %{time_connect}snTTFB: %{time_starttransfer}snTotal: %{time_total}sn" https://your-site.com/

Run benchmarks on staging before and after the PHP change, then again on production after the upgrade. Keep the results in a shared document for historical reference.

Automated Smoke Tests

A simple smoke test script that runs after every PHP version change can catch the most critical failures:

#!/bin/bash
# smoke-test.sh - Run after PHP version upgrade
SITE_URL="https://your-site.com"
FAILURES=0

check_url() {
  local url=$1
  local expected_code=$2
  local description=$3

  actual_code=$(curl -s -o /dev/null -w "%{http_code}" "$url")

  if [ "$actual_code" != "$expected_code" ]; then
    echo "FAIL: $description - Expected $expected_code, got $actual_code ($url)"
    FAILURES=$((FAILURES + 1))
  else
    echo "PASS: $description ($url)"
  fi
}

# Check critical pages
check_url "$SITE_URL/" "200" "Homepage"
check_url "$SITE_URL/wp-login.php" "200" "Login page"
check_url "$SITE_URL/wp-admin/" "302" "Admin redirect"
check_url "$SITE_URL/wp-json/wp/v2/posts" "200" "REST API"
check_url "$SITE_URL/feed/" "200" "RSS Feed"
check_url "$SITE_URL/sitemap.xml" "200" "Sitemap"

# Check for PHP errors in page output
homepage_content=$(curl -s "$SITE_URL/")
if echo "$homepage_content" | grep -qi "fatal error|parse error|warning:"; then
  echo "FAIL: PHP errors detected on homepage"
  FAILURES=$((FAILURES + 1))
else
  echo "PASS: No PHP errors on homepage"
fi

# Report
echo ""
if [ $FAILURES -eq 0 ]; then
  echo "All smoke tests passed."
else
  echo "$FAILURES smoke test(s) failed. Investigate before proceeding."
  exit 1
fi

Integrate this script into your deployment pipeline or run it manually as part of your post-upgrade checklist.

Handling Deprecated Features and Migration Patterns

PHP deprecations do not cause immediate failures, but they signal features that will be removed in future versions. Addressing them during the current upgrade reduces work for the next upgrade cycle.

Finding and Fixing Deprecations

After upgrading to PHP 8.1 on staging, grep the error log for deprecation notices:

# Search for PHP 8.1 deprecation notices
grep "Deprecated:" wp-content/debug.log | sort | uniq -c | sort -rn | head -20

This gives you a ranked list of the most frequent deprecation notices. Focus on fixing the top offenders first, as they generate the most log noise and represent the highest risk for the next PHP version.

Common deprecation patterns in the PHP 8.0-8.1 era and their fixes:

Dynamic properties (PHP 8.2 deprecation, flagged in 8.1 with certain tools):

// Deprecated: creation of dynamic property
class MyWidget {
    // Fix: declare properties explicitly
    public string $title = '';
    public int $count = 5;
}

String interpolation with ${} (deprecated in PHP 8.2, good to fix now):

// Deprecated in 8.2
$greeting = "Hello ${name}";

// Preferred
$greeting = "Hello {$name}";

Implicit float-to-int conversion (PHP 8.1):

// Deprecation: implicit conversion from float to int loses precision
$index = 2.5;
$array[$index]; // Deprecation notice

// Fix: explicit cast
$array[(int) $index];

Using Rector for Automated Refactoring

Rector is a PHP refactoring tool that can automatically upgrade code to be compatible with newer PHP versions:

# Install Rector
composer require rector/rector --dev

# Create rector.php configuration
cat > rector.php <<'EOF'
<?php
use RectorConfigRectorConfig;
use RectorSetValueObjectLevelSetList;

return static function (RectorConfig $rectorConfig): void {
    $rectorConfig->paths([
        __DIR__ . '/wp-content/themes/your-theme',
        __DIR__ . '/wp-content/plugins/your-plugin',
    ]);

    $rectorConfig->sets([
        LevelSetList::UP_TO_PHP_81,
    ]);
};
EOF

# Preview changes (dry run)
vendor/bin/rector process --dry-run

# Apply changes
vendor/bin/rector process

Rector can handle many mechanical transformations: adding return type declarations, replacing deprecated function calls, updating syntax to modern equivalents. Review its output carefully before committing, as automated refactoring occasionally makes incorrect assumptions about intent.

Special Considerations for Multisite Networks

WordPress Multisite networks add complexity to PHP version upgrades because a single WordPress installation serves multiple sites that may have different plugin configurations.

On managed hosts that support Multisite, the PHP version applies to the entire network. You cannot run different PHP versions for different sites within a Multisite installation. This means your compatibility testing must cover all active plugins and themes across all sites in the network, not just the main site.

Before upgrading a Multisite network:

# List all active plugins across the network
wp plugin list --status=active --network --fields=name,version,update

# List all active plugins per site
wp site list --field=url | while read site_url; do
  echo "=== $site_url ==="
  wp plugin list --status=active --url="$site_url" --fields=name,version
done

# Check for plugins activated on individual sites but not network-wide
wp site list --field=url | while read site_url; do
  wp plugin list --status=active --url="$site_url" --field=name
done | sort | uniq -c | sort -rn

This gives you a complete inventory of active plugins across the network. Every one of these plugins must be compatible with the target PHP version.

PHP Version Pinning in Composer

If your WordPress project uses Composer for dependency management (increasingly common in modern WordPress development), you can enforce PHP version constraints at the project level:

{
    "require": {
        "php": ">=8.0 <8.2"
    },
    "config": {
        "platform": {
            "php": "8.1.0"
        }
    }
}

The require.php constraint prevents composer install from succeeding if the running PHP version is outside the specified range. The config.platform.php setting tells Composer to resolve dependencies as if running on PHP 8.1, regardless of the actual system PHP version. This is useful when your local development machine runs a different PHP version than your hosting platform.

# Check what PHP version Composer sees
composer show --platform | grep php

# Validate that all dependencies are compatible with your platform settings
composer check-platform-reqs

Summary of Action Items

For site owners and agencies planning PHP version upgrades on managed hosting platforms, here is the practical checklist:

Before Upgrading:

Update all plugins and themes to their latest versions
Run PHPCompatibility scans on all custom code
Check plugin compatibility listings for the target PHP version
Create a manual backup with a descriptive label
Document the current state: PHP version, plugin versions, PHP settings

During the Upgrade:

Change PHP on staging first, never directly on production
Run automated tests if available
Perform manual testing of all critical user paths
Monitor error logs on staging for at least 24 hours
Fix all errors and retest before proceeding to production
Upgrade production during a low-traffic window

After the Upgrade:

Monitor error logs for 48-72 hours minimum
Compare performance metrics to pre-upgrade baselines
Run smoke tests on all critical functionality
Address deprecation notices to prepare for the next PHP version
Update your documentation to reflect the new PHP version
Schedule the next PHP version review for 6 months out

PHP version management on managed hosting platforms is a recurring operational task, not a one-time event. Each platform provides different tools and workflows, but the underlying principles remain consistent: test on staging, monitor after deployment, have a rollback plan, and stay ahead of PHP’s annual release cycle. The platforms covered here represent the most common managed WordPress hosting options in 2022, and while their interfaces and APIs will evolve, the fundamental approach to safe PHP upgrades will remain the same.