PHP 8 Upgrade Guide on Shared Hosting and VPS for WordPress and Laravel

PHP 8 is now the standard for modern WordPress and Laravel projects. It brings real performance gains, stronger typing, and new language features, while older PHP 7.x branches are reaching end of life. That means less security support, more vulnerability risk, and increasing compatibility issues with new plugins and packages. The challenge is simple to describe but tricky to execute: how do you upgrade to PHP 8 on shared hosting or a VPS without breaking your sites, losing SEO, or dealing with hours of downtime?

In this guide, we walk through a practical, hosting-side plan for upgrading to PHP 8 safely. We will focus on real-world WordPress and Laravel setups, from small blogs on shared hosting to multi-project stacks on a VPS. You will see how to prepare backups, create a staging environment, test code, switch PHP versions per site, and roll back cleanly if anything misbehaves. As the dchost.com team, we see these upgrades every day, so the steps below are based on what actually works in production, not just theory.

Why PHP 8 Matters for WordPress and Laravel Sites

Performance, Security and Support Lifecycles

Upgrading to PHP 8 is not just about new syntax like match expressions or attributes. For WordPress and Laravel workloads, you typically gain:

• Better performance: PHP 8’s JIT and engine improvements reduce CPU usage and response times, especially for complex Laravel applications or heavy WooCommerce stores.
• Longer security support: PHP 7.4 and many earlier branches are out of active support. Staying on them means relying on your hosting environment to isolate and protect outdated runtimes, which is never ideal.
• Future plugin and package compatibility: New WordPress plugins, themes, and Laravel packages increasingly assume PHP 8+ features and may drop older versions entirely.

On the flip side, PHP 8 is stricter. It turns many previously silent issues into warnings or fatal errors (for example, passing null to non-nullable parameters, or using deprecated functions). That’s why a structured upgrade process is essential.

If you want a deeper, developer-focused checklist, we also recommend our detailed article on the PHP 8.x upgrade checklist, backwards compatibility and FPM tuning for WordPress and Laravel.

Pre‑Upgrade Checklist: What to Do Before Touching PHP

1. Inventory Every Site and Application

Start by listing everything that depends on PHP on your hosting account or VPS:

• All WordPress sites (including multisite networks)
• All Laravel applications (and which versions they run)
• Other PHP apps: old CMSes, custom panels, legacy tools
• CLI jobs, cron tasks and queue workers that call php

This matters because you can (and should) upgrade sites one by one, especially on shared hosting where multiple domains share the same account. On a VPS, you can also run multiple PHP versions side by side and migrate vhosts gradually.

2. Check Application Compatibility with PHP 8

Next, check what PHP versions your applications officially support.

• WordPress core: modern versions support PHP 8+, but many older themes/plugins do not. Aim for at least WordPress 6.x before the PHP 8 transition.
• Laravel:
  • Laravel 8 supports PHP 7.3–8.1 (depending on minor version)
  • Laravel 9 requires PHP 8.0+
  • Laravel 10 requires PHP 8.1+
• Composer dependencies: check composer.json for the php constraint and packages that require PHP 8+.

On shared hosting, you usually have a PHP selector in cPanel/DirectAdmin/Plesk. On a VPS, run:

php -v

to see your current PHP version, and make sure your OS repositories or packages can deliver the PHP 8 branch you need.

3. Take Full, Verifiable Backups

Before any major version change, you must be able to get back to a known-good state quickly.

• Files: public web roots, wp-content, Laravel app/, config/, storage/, and any custom code outside those.
• Databases: mysqldump or panel backups for each site’s database.
• Configs: .env files for Laravel, WordPress wp-config.php, web server vhost configs, cron job definitions.

Do at least one test restore to confirm your backup process actually works. For WordPress-focused setups, our guide on WordPress backup strategies on shared hosting and VPS walks through practical scheduling and restore testing.

At dchost.com we follow the 3‑2‑1 principle (three copies, two media types, one off‑site) for critical environments; you do not need to be that strict for a small blog, but you should always have at least one off‑server backup.

4. Plan a Maintenance Window and Communication

Even when you aim for zero downtime, it is wise to schedule a realistic maintenance window:

• Pick low‑traffic hours based on your analytics.
• Announce a short maintenance window on your site or via email.
• Prepare a simple, branded maintenance page if needed.

If you care about SEO and want to avoid negative signals during short outages, see our article on maintenance windows and downtime pages without hurting SEO. It explains how to use correct HTTP status codes and temporary pages safely.

Setting Up a Safe Staging Environment

Staging for WordPress on Shared Hosting

The cleanest way to test PHP 8 is to clone your site to a staging environment and switch PHP there first. On shared hosting, you have two common options:

• Subdomain staging: staging.example.com with a full copy of files and database.
• Subdirectory staging: example.com/staging if subdomains are not convenient.

cPanel and some installers can clone WordPress automatically; alternatively, you can copy files via File Manager/SFTP and export/import the database. Then update the site URL in wp_options and in wp-config.php if needed.

We have a step‑by‑step walkthrough in our dedicated guide on setting up WordPress staging on shared hosting with subdomains and clones.

Staging for Laravel on a VPS or Shared Hosting

For Laravel, staging is usually a separate virtual host and .env:

• On shared hosting, create a new subdomain or addon domain pointing to a copy of your Laravel project, with its own database and .env file.
• On a VPS, add a new vhost (Nginx/Apache) pointing to a cloned code directory, typically a different Git branch or a deployed copy.

Use a separate database and queue connection to avoid mixing staging and production data. In .env, change APP_URL, database credentials, cache, and session prefixes to keep them isolated.

What to Test on Staging Under PHP 8

Once your staging environment is live, switch it to PHP 8 (we will show how in the next sections) and test thoroughly:

• Key user journeys: login, registration, contact forms, checkout, search.
• Admin tasks: publishing posts/products, editing menus, uploading media.
• Background tasks: scheduled posts, cron jobs, Laravel queues and scheduled commands.
• Logs: check error_log or storage logs for PHP warnings, deprecated notices and fatal errors.

Fixing issues on staging first dramatically reduces stress when you upgrade production.

Upgrading to PHP 8 on Shared Hosting

Understanding Per‑Site PHP Version Control

Most modern shared hosting platforms (including our shared hosting at dchost.com) allow you to select PHP versions per domain or even per directory. In cPanel, this is usually called “MultiPHP Manager” or “Select PHP Version”; in DirectAdmin, you may see “PHP Version Selector”.

If you are not yet familiar with this feature, our article on managing multiple PHP versions on cPanel and DirectAdmin per site explains the UI and common scenarios.

Step‑by‑Step: Switching a WordPress Site to PHP 8

1. Upgrade WordPress core, themes and plugins to the latest stable versions while still on your current PHP version. Many compatibility fixes are delivered via normal plugin updates.
2. Enable debugging logs (not display) in wp-config.php:

   define( 'WP_DEBUG', true );
   define( 'WP_DEBUG_LOG', true );
   define( 'WP_DEBUG_DISPLAY', false );
   

3. Open your control panel and go to the PHP Selector / MultiPHP Manager.
   • Select only the staging domain first and change its PHP version to 8.0, 8.1 or 8.2 depending on your plan.
   • Apply the change and wait a few seconds.
4. Test staging thoroughly as described earlier. Check wp-content/debug.log and error_log for issues.
5. When staging is clean, repeat the version change for the production domain and retest the most critical flows (home page, login, checkout, contact forms).
6. If anything fails, switch the PHP version back in the same panel and use your backups/logs to diagnose.

On shared hosting, rollbacks are usually as simple as selecting the old PHP version again, which is why we recommend this path if you are upgrading a smaller site with limited custom code.

Step‑by‑Step: Switching a Laravel App to PHP 8 on Shared Hosting

Laravel on shared hosting is less common but absolutely doable if your provider exposes PHP 8 via both web and CLI.

1. Check Laravel version (see composer.json or run php artisan --version) and verify it supports the PHP 8 version you want.
2. Update Composer dependencies on a local or staging environment:

   composer update
   

   Ensure your composer.json has an appropriate constraint like:

   "php": "^8.0"

3. Switch the domain/subdomain to PHP 8 in the panel, just as for WordPress.
4. Check the CLI PHP version used by cron jobs:

   php -v
   

   If your host has multiple binaries (e.g., /opt/php81/bin/php), update cron commands and queue worker commands to use the PHP 8 binary.

5. Run key commands on staging: php artisan config:cache, php artisan route:cache, php artisan queue:work and verify no compatibility errors appear.

If you cannot control which PHP version cron uses, contact our support or your provider’s support; on dchost.com we can help align web and CLI PHP versions so your Laravel schedulers and queues run under the correct runtime.

Upgrading to PHP 8 on a VPS

Install the New PHP 8 Packages

On a VPS, you are responsible for installing PHP 8 yourself (unless you are on a managed stack). The exact commands depend on your Linux distribution; for example:

• Debian/Ubuntu (with appropriate repositories):

  sudo apt update
  sudo apt install php8.2 php8.2-fpm php8.2-cli php8.2-mysql php8.2-xml php8.2-mbstring php8.2-curl php8.2-zip
  

• AlmaLinux/Rocky Linux/CentOS (with Remi or AppStream):

  sudo dnf module reset php
  sudo dnf module enable php:8.2
  sudo dnf install php php-fpm php-mysqlnd php-xml php-mbstring php-curl php-zip
  

We strongly recommend running PHP‑FPM rather than mod_php on modern stacks; it is more efficient and works better with multiple PHP versions.

Configure PHP‑FPM Pools Per Site or App

With PHP 8 installed, configure separate FPM pools for each major site or group of sites. This gives you isolation: a fatal error in one app cannot easily crash others, and you can tune settings per pool (memory, max children, etc.).

Our article on running multiple PHP‑FPM pools per site without drama walks through a real‑world configuration strategy on Nginx.

Basic steps:

1. Create a new pool file like /etc/php/8.2/fpm/pool.d/example.conf.
2. Set a unique listen socket (e.g., /run/php-fpm-example.sock), user, group and reasonable limits (pm, pm.max_children, etc.).
3. Restart PHP‑FPM: sudo systemctl restart php8.2-fpm.

Point Your Web Server to PHP 8

Update your Nginx or Apache configuration for the specific site you are upgrading:

• Nginx FastCGI example:

  fastcgi_pass unix:/run/php-fpm-example.sock;
  

• Apache with ProxyPassMatch (FPM via proxy_fcgi):

  ProxyPassMatch ^/(.*) fcgi://127.0.0.1:9000/var/www/example.com/public/$1
  

  (Adjust to your socket/port and document root.)

Reload the web server (not just restart):

sudo systemctl reload nginx
# or
sudo systemctl reload apache2

Now only that specific site is running under PHP 8; others can continue on PHP 7.x until you are ready.

Align CLI PHP for Artisan, WP‑CLI and Cron

For Laravel, the PHP version used by artisan, queue workers and scheduled tasks must match your web PHP as closely as possible. On many systems, you can update /usr/bin/php via update-alternatives (Debian/Ubuntu) or adjust paths in cron:

crontab -e
# Example:
* * * * * /usr/bin/php8.2 /var/www/app/artisan schedule:run >> /dev/null 2>&1

Similarly, ensure queue workers (systemd units or Supervisor programs) call the PHP 8 binary.

Tune OPcache and Performance Under PHP 8

While you are upgrading, it is a good opportunity to review OPcache settings, which greatly affect WordPress and Laravel performance under PHP 8. Key directives include:

• opcache.enable=1
• opcache.memory_consumption (e.g., 128–256MB for a busy app)
• opcache.max_accelerated_files (increase for large codebases)
• opcache.validate_timestamps and revalidate_freq for deployment behaviour

For a deeper dive with hosting‑side examples, see our article on PHP OPcache settings for WordPress, Laravel and WooCommerce.

WordPress‑Specific PHP 8 Gotchas and Fixes

Keep Core, Themes and Plugins Modern

Most serious PHP 8 issues in WordPress come from old themes and plugins. Before upgrading:

• Remove completely unused or abandoned plugins.
• Replace outdated themes with maintained ones where possible.
• Update everything to the latest version before touching PHP.

On staging, enable debug logging and scrutinize warnings like “Deprecated” or “Trying to access array offset on value of type null”. Some are just noise; others reveal logic bugs that may become fatal in future PHP versions.

Typical PHP 8 Errors in WordPress

Common patterns we see during upgrades include:

• Type errors: plugins calling functions with wrong argument types (e.g., string vs array) now throw fatal TypeError exceptions.
• Deprecated function calls: older code using removed functions (like create_function) or relying on magic quotes.
• Deprecated dynamic properties: PHP 8.2 deprecates dynamic properties; some plugins will log many notices until updated.

When you see these issues:

• Update the offending plugin/theme if a newer version exists.
• Temporarily disable problematic plugins and retest.
• If a critical plugin is abandoned and incompatible, you may need to stay on an older PHP branch temporarily while you replace it.

Multisite, WooCommerce and Heavy Sites

For multisite and WooCommerce stores, we strongly recommend staging and step‑by‑step upgrades. Consider:

• Testing payment gateways, shipping calculators and complex checkout flows under PHP 8.
• Monitoring resource usage (CPU, RAM) during peak traffic after the upgrade.
• Combining the PHP upgrade with caching and database tuning for maximum benefit.

We have separate guides for WooCommerce performance, MySQL tuning and object caching in our blog, which pair nicely with a PHP 8 migration.

Laravel‑Specific PHP 8 Gotchas and Fixes

Match Laravel Version to PHP Version

Before you even install PHP 8, check your Laravel version:

• If you run Laravel 5.x or 6.x, you will almost certainly need to upgrade Laravel first before switching to PHP 8.
• Laravel 7/8 may support PHP 8.0 with certain minor releases; consult the official docs or your composer.json.
• Laravel 9 and 10 are built for PHP 8.x and are usually the best targets for new projects.

Update your Composer constraints to allow PHP 8 and run a full composer update in a development environment before deploying.

Third‑Party Packages and PHP 8

Even if Laravel core supports PHP 8, packages may lag behind. Pay special attention to:

• Payment gateways and SDKs
• PDF generators, Excel import/export libraries
• Old admin panels or scaffolding packages

On staging under PHP 8, run your test suite (if you have one) and check logs in storage/logs/laravel.log for type errors and deprecations.

Queues, Schedulers and Octane

Laravel’s background workers are highly sensitive to PHP configuration:

• Ensure all queue workers run with PHP 8 (systemd units, Supervisor configs).
• Check your schedule:run cron entry uses the same binary.
• If you use Laravel Octane, verify support for your chosen PHP 8 version and Swoole/RoadRunner versions.

After the upgrade, monitor job failure counts and worker logs closely for the first few days.

Rollback and Zero‑Downtime Strategies

Instant Rollback on Shared Hosting

On shared hosting, rollback is usually a UI operation:

• Open your PHP version selector.
• Change the problem domain back to its previous PHP version.
• Clear any caches (WordPress caching plugins, opcode caches, CDN edge cache) and retest.

Because you did not touch code or database schemas when changing only PHP versions, this is normally safe and fast. If errors persist, restore from your backups.

Blue‑Green Style Releases on a VPS

On a VPS, we recommend a simple blue‑green pattern for bigger Laravel and WordPress sites:

• Keep two application directories: releases/blue and releases/green.
• Point your web root symlink (e.g., current) to one of them.
• Deploy the new code and PHP version to the other directory, warm caches, run migrations.
• Switch the symlink and reload PHP‑FPM when ready.

If anything fails under PHP 8, switch the symlink back. We explore these patterns in more depth in our articles about blue‑green deployments and zero‑downtime releases on VPS environments.

Combining PHP Upgrades with Planned Maintenance

For high‑traffic stores or critical applications, it is often best to treat the PHP upgrade like any other production change:

• Announce a maintenance window.
• Enable a friendly maintenance page or queue‑draining mode.
• Upgrade PHP, run sanity checks, then reopen traffic.

The key is to have a documented runbook: step‑by‑step actions, checks, and a clear rollback path. We follow the same pattern internally at dchost.com when we upgrade shared hosting clusters and VPS templates.

When Shared Hosting Is Not Enough: Moving to a VPS

PHP 8 itself will run happily on shared hosting, but some workloads outgrow this environment:

• Laravel applications with heavy queues, WebSockets, or API traffic.
• WooCommerce stores handling thousands of concurrent users.
• Multi‑tenant SaaS platforms with strict isolation and custom PHP modules.

In those cases, a VPS gives you:

• Full control over PHP versions, extensions and FPM pools.
• Dedicated CPU/RAM and disk I/O.
• Freedom to run Redis, RabbitMQ, Elasticsearch and other services.

If you are considering a move, our guide comparing shared hosting vs VPS for Laravel and other PHP frameworks explains when it makes sense to upgrade and how to size your VPS correctly.

Putting It All Together: A Practical PHP 8 Upgrade Plan

To summarise the safest approach to upgrading WordPress and Laravel sites to PHP 8 on shared hosting or a VPS:

1. Prepare: inventory all PHP applications, confirm compatibility, and take full backups.
2. Build staging: clone your site or app to a staging subdomain or vhost and update it to the latest code and dependencies.
3. Upgrade staging to PHP 8: use the panel selector on shared hosting or configure a new PHP‑FPM pool on your VPS.
4. Test deeply: run through real user flows, check logs, fix deprecations and type errors.
5. Switch production during a planned window: change the PHP version for the live domain or update your VPS vhost, then verify quickly.
6. Monitor and be ready to roll back: keep your previous PHP version available for quick rollback if something unexpected appears.

PHP 8 is a big step forward in performance and long‑term supportability for both WordPress and Laravel. With careful staging, predictable backups and a clear rollback path, the upgrade does not need to be stressful.

At dchost.com, we design our shared hosting, VPS and dedicated servers to make multi‑PHP environments and controlled upgrades as smooth as possible. If you are planning a PHP 8 migration and want a hosting platform that supports per‑site PHP versions, proper staging environments and expert support, you are welcome to reach out to our team. We are happy to review your current setup, suggest an appropriate shared hosting, VPS or dedicated plan, and help you plan a calm, low‑risk upgrade path for your WordPress and Laravel projects.