Upgrading PHP on Shared Hosting Environments

Mar 15, 2026

When PHP 8.0 was released in November 2020, it brought substantial performance improvements—often two to three times faster than PHP 7.4—along with new features like JIT compilation and union types. Yet, many shared hosting environments continue to run PHP 7.4 or even older versions, exposing websites to security vulnerabilities that have not been patched for years. One may wonder: why does this gap persist? The answer lies in the constraints of shared hosting—constraints we’ll explore and navigate in this guide.

For websites running on shared hosting—where multiple customers share a single server—upgrading PHP requires navigating the constraints of the hosting provider’s control panel infrastructure. Unlike dedicated servers or cloud instances where you might have root access, shared hosting typically means you must work within the tools your provider makes available. Understanding this limitation, though, is the first step toward a successful upgrade.

Why PHP Version Matters Beyond Security

Most discussions about PHP upgrades begin and end with security. While security is certainly critical—PHP 7.4 reached its end of life in November 2022 and no longer receives security patches—it is far from the whole story. Three interconnected factors compel timely upgrades: security, performance, and ecosystem compatibility.

Security remains the most urgent driver. When a PHP version reaches end-of-life, the PHP Group stops releasing security patches. Any newly discovered vulnerabilities remain unpatched in that version indefinitely. A site running an unsupported PHP version is, in effect, running with known security holes that attackers actively exploit. The fact that your site has operated without incident for years is not evidence of safety; it is evidence that you have not yet been targeted—or that attacks have gone undetected.

Performance improvements across major PHP releases are substantial. PHP 8.0 introduced the JIT (Just-In-Time) compiler, which can dramatically accelerate CPU-intensive operations. Even without the JIT, subsequent releases have optimized core routines. A WordPress site running PHP 8.1 might handle the same traffic with 30-50% less server resource consumption compared to PHP 7.4. For sites on resource-constrained shared hosting plans, this efficiency gain can translate directly into fewer timeout errors and better user experience during traffic spikes.

Compatibility with modern PHP packages—whether you’re using WordPress plugins, Laravel packages, or standalone PHAR tools—increasingly requires recent PHP versions. Package maintainers follow PHP’s supported versions, meaning they assume at least PHP 8.0 or higher for new releases. If you attempt to install a modern plugin that requires PHP 8.1 on a server running PHP 7.4, the installation will fail or the plugin will malfunction. This creates a situation where your entire software stack becomes frozen in time, unable to benefit from bug fixes and new features.

These three factors interact. A performance optimization in a new package might require a newer PHP version; that same package might also include security improvements. Conversely, staying on an old PHP version means missing out on both performance and security benefits across your entire dependency stack. This creates a kind of technical debt compound interest.

The Shared Hosting Reality

Shared hosting presents a particular set of constraints. You typically do not have sudo or root access. You cannot install system-wide PHP packages or change Apache/Nginx configuration globally. The server’s PHP version and configuration are managed at the account or domain level through the control panel your host provides.

Most shared hosting providers in North America and Europe use either cPanel or Plesk as their commercial control panel solution. Some hosts offer alternative interfaces—DirectAdmin, InterWorx, or proprietary panels—but cPanel and Plesk dominate the market. Your upgrade path will depend on which interface your host has deployed, and on which PHP versions they have installed on the server.

Of course, not all hosts make the latest PHP versions available immediately. There is often a delay of months between a PHP version’s stable release and its appearance in shared hosting panels. The host must compile PHP with their preferred extensions, test compatibility with their infrastructure, and schedule deployment. Before proceeding, you should check what versions your host currently offers—this is typically visible in the PHP selector interface itself, or you can often find this information in your host’s documentation or support portal.

Before You Begin: The Safety Net

Before making any changes to your PHP version, we must address the non-negotiable prerequisite: a complete, verified backup. This is not optional. One may wonder: why such strong emphasis on backups? The answer is simple: PHP upgrades change the runtime environment entirely, and incompatibilities can render a site inaccessible. If your site is mission-critical, you should also consider staging the upgrade on a copy of your site first—many hosts provide staging environments for exactly this purpose.

Your backup strategy should include both files and database. On shared hosting, you can typically create backups through the control panel’s backup wizard or file manager. Download the backup archives to your local machine rather than relying solely on server-side storage. If something goes wrong, you’ll need the ability to restore quickly.

We also recommend committing your code to version control if you have not already done so. While this may feel like extra work if you’re not using Git regularly, it provides an additional recovery path. You can roll back code changes that might interact poorly with the new PHP version. Databases, of course, are not typically version-controlled, which is why a separate database backup remains essential.

Upgrading with cPanel

cPanel is the most common control panel in shared hosting, particularly among US-based providers. The interface for changing PHP versions has evolved over time. Newer cPanel installations use MultiPHP Manager; older installations may still have Select PHP Version. Both accomplish the same goal, though MultiPHP offers per-domain selection.

Here is the step-by-step process:

Log in to your cPanel account. Your cPanel URL is typically at https://yourdomain.com:2083 or provided by your host.
Navigate to the Software section. You may need to scroll; the exact section order can vary.
Look for MultiPHP Manager (preferred) or Select PHP Version. Both are clearly labeled.
In MultiPHP Manager, you will see a checklist of domains associated with your account. Select the checkbox next to each domain you wish to upgrade.
On the right side, a dropdown labeled PHP version will show the current version. Click it to see available versions. Choose the latest stable version your host provides—typically something like PHP 8.1 or 8.2 at the time of this writing. Of course, we recommend avoiding pre-release versions in production; wait for the stable designation.
Click Apply. The change occurs almost immediately. cPanel updates the domain’s .htaccess file and PHP handler configuration.

If you use Select PHP Version instead, the interface is similar but slightly different:

After opening Select PHP Version, you will see a dropdown at the top to choose the global default. Changing this affects all domains that inherit the default.
For per-domain control, you may need to look for a checkbox labeled “Set to inherit from system default” or similar. Unchecking this reveals a domain-specific version dropdown.

Verifying the Change in cPanel

After applying the change, we should verify it took effect. The easiest way is to create a phpinfo.php file in your public_html directory with this content:

<?php
phpinfo();

Navigate to https://yourdomain.com/phpinfo.php and check the displayed PHP version at the top.

Tip: When you have confirmed the version changed, delete the phpinfo.php file immediately—leaving it accessible would expose information potentially useful to attackers. Many developers forget this step; setting a calendar reminder can help.

Upgrading with Plesk

Plesk is common among European hosting providers and some US hosts. The workflow is similar but the interface differs slightly.

Log in to your Plesk account. The URL is typically https://yourdomain.com:8443 or provided by your host.
Go to the Websites & Domains section. This is usually the default view after login.
Find the domain you want to update in the list. If you have multiple domains, you will need to repeat this process for each.
Click on PHP Settings (or sometimes PHP or PHP version). This opens the domain-specific PHP configuration.
You will see a dropdown menu. In newer Plesk versions, it is labeled PHP version; older versions might say PHP support.
Select the latest stable version available from the list.
Scroll down and click OK or Apply depending on your Plesk version.

Plesk’s PHP Settings Additional Options

While you are in the PHP Settings interface, this is an opportunity to review other configuration options. Plesk typically exposes common php.ini directives through checkboxes and dropdowns:

Display errors: Should be Off for production sites. You can temporarily turn it On for debugging after the upgrade if needed.
Memory limit: If your site runs memory-intensive operations, you might need to increase this. The default is often 128M or 256M.
Max execution time: Long-running scripts might require adjustment.
Upload max filesize: Important for sites with file uploads.

We mention these not because you must change them during an upgrade—you generally should not touch settings you do not need to change—but because the upgrade process can expose pre-existing configuration issues. If your site breaks after a PHP upgrade, one cause can be that PHP 8.x is stricter about certain limits than PHP 7.x was, though the default configurations often work fine.

What About Other Control Panels?

Our focus here is on cPanel and Plesk because they represent the vast majority of shared hosting deployments. However, we should acknowledge that other control panels exist. DirectAdmin uses a PHP Selector in the User Level settings. InterWorx has PHP Selector under the System section. Proprietary panels—those custom-built by hosting companies—vary widely.

The pattern is consistent across panels: look for a menu item containing “PHP” and “select” or “version” or “settings.” If you cannot locate the PHP version selector, your host’s documentation or support team should be able to direct you. Some hosts intentionally hide version selection behind support requests to manage server stability; in that case, you will need to open a support ticket.

After the Upgrade: Systematic Testing

Do not assume the upgrade succeeded because no error appeared during the switch. You must test your site thoroughly. A PHP upgrade is effectively replacing core components of your application’s runtime environment; incompatible code will fail immediately.

We recommend this testing sequence:

Basic page load: Visit your site’s home page. Does it render? Check for the White Screen of Death—a completely blank page, which indicates a fatal error. Also look for partial rendering where headers appear but content does not.
Admin area: If you have an admin panel (WordPress wp-admin, Laravel Nova, etc.), log in. Check that the dashboard loads and basic administrative functions work.
Front-end dynamic content: Test pages that use forms, JavaScript that makes AJAX calls, interactive elements like shopping carts or search.
Critical user flows: Go through your most important user journeys. For an e-commerce site: add a product to cart, enter shipping information, process a checkout with a test payment. For a membership site: register a new account, log in, access protected content.
Background processes: If your site has scheduled tasks (cron jobs sending email digests, processing uploads, generating reports), verify these still run. Check your logs for failures.

Understanding Error Logs

If you encounter an error, your control panel’s Error Log feature is your primary diagnostic tool. In cPanel, look under Metrics → Errors. In Plesk, it’s under Websites & Domains → Logs.

The error log shows PHP errors with file paths and line numbers. A typical fatal error might look like:

PHP Fatal error: Uncaught Error: Call to undefined function wp_get_current_user() in /home/username/public_html/wp-includes/class-wp-user.php:123
Stack trace:
#0 /home/username/public_html/wp-content/plugins/some-plugin/some-file.php(45): WP_User->ID
#1 {main}
  thrown in /home/username/public_html/wp-includes/class-wp-user.php on line 123

This tells us a plugin called some-plugin is calling a function that no longer exists or has moved in the new PHP version. The resolution path is clear: update that plugin, or if an update is not available, replace it with an alternative or disable it.

Deprecation warnings are less severe but should not be ignored. PHP 8.x introduced many deprecations from PHP 7.x. A deprecation warning might say:

PHP Deprecated:  Function create_function() is deprecated in /path/to/file.php on line 42

Your site may continue to function with deprecation warnings, but these indicate code that will break in a future PHP version. You should update the offending code when practical—contact the theme or plugin developer if it is third-party code.

Common Issues and Their Resolutions

Let us enumerate the most frequent problems encountered during PHP upgrades on shared hosting, along with practical resolution steps.

”500 Internal Server Error”

A 500 error without specific details is often caused by:

Plugin or theme incompatibility: A plugin has not been updated to support PHP 8.x syntax changes. Common culprits are functions that were removed or changed signature. Use the error log to identify the problematic file. Temporarily rename the plugin directory (e.g., wp-content/plugins/some-plugin to wp-content/plugins/some-plugin-disabled) to confirm. Then seek an updated version or alternative.
PHP version mismatch in .htaccess: cPanel writes handler directives to .htaccess. Occasionally these become corrupted. Check your .htaccess for lines starting with AddHandler or SetHandler. If you are comfortable, you can try removing those lines and re-applying the version through MultiPHP Manager.
Missing extensions: Your application may depend on a PHP extension that is not enabled in the new version. Common examples: mysqli, gd, curl, mbstring. In cPanel, the Select PHP Version interface also lets you enable/disable extensions. Verify any extensions your application requires are checked.

Site Works But Admin Area Fails, or Vice Versa

This pattern suggests a plugin or theme is loaded only in one context. WordPress, for example, loads active plugins on both front-end and admin; some plugins load conditionally. Again, error logs point to the source. If you cannot access the admin area to deactivate plugins, you can temporarily rename the plugins directory, then log in (WordPress will deactivate all plugins). Rename it back, then selectively reactivate plugins through the admin interface to identify the incompatible one.

Database Connection Errors

If you see “Error establishing a database connection” or similar, the PHP version change is unlikely to be the direct cause—database credentials are stored separately. However, if the error appeared immediately after upgrade, check:

Character set issues: PHP 8.x sometimes defaults to different character sets. Verify your database configuration in wp-config.php or equivalent specifies utf8mb4.
Extension availability: The mysqli or pdo_mysql extension must be enabled. Check your phpinfo output.

Performance Degradation

If your site feels slower after upgrading PHP—a counterintuitive but reported occurrence—check:

OPcache: PHP 8.x often ships with OPcache enabled by default, but configuration values may differ from your previous version. An OPcache misconfiguration can cause slower performance if memory is too low or validation is too frequent. In cPanel’s MultiPHP INI Editor, look for OPcache settings.
JIT: PHP 8.0’s JIT is not automatically beneficial for web requests; in some cases it can hurt performance. You can control it through opcache.jit and opcache.jit_buffer_size. Most WordPress sites run faster without JIT enabled. Experimentation may be warranted if you have unusual workloads.

Rollback: When the Upgrade Fails

If your site breaks and you cannot quickly diagnose and fix the issue, rollback is straightforward:

In cPanel MultiPHP Manager, select the domain and change the version back to what it was.
In Plesk PHP Settings, change the dropdown back to the previous version.

The change takes effect immediately. Your site should return to its prior state because the underlying files and database have not changed—only the PHP interpreter version.

Of course, rollback does not fix the underlying compatibility problem. It buys you time to research solutions, update code, or contact developers. If your site cannot function on a modern PHP version indefinitely, you face increasing security risks over time. Rollback should be a temporary measure, not a permanent solution.

Long-Term Considerations

A PHP upgrade is not a one-time event. The PHP Group maintains a release schedule with roughly annual major releases and more frequent minor releases with security patches. Your shared host will eventually provide new PHP versions as they become available. You should plan to upgrade again—typically every 12-18 months as older versions approach end-of-life.

Staying current requires monitoring. Subscribe to your host’s status blog or newsletter. Pay attention to announcements about PHP version deprecation. Some hosts send email warnings when your current version is nearing end-of-life.

We also encourage you to consider your choice of software more strategically. Before installing a new WordPress plugin or PHP package, check its stated PHP requirements. If a plugin requires PHP 8.1 but your host only offers PHP 7.4, that plugin is effectively unavailable to you. This constraint can guide your evaluation of whether to stay with your current host or migrate to one with more up-to-date infrastructure.

Conclusion: A Manageable but Essential Task

Upgrading PHP on shared hosting is among the most consequential maintenance actions you can take for your website’s health. It sits at the intersection of security, performance, and compatibility—three pillars of a reliable web presence. While the process itself is straightforward—selecting a version in a control panel and verifying—the surrounding work of backups, testing, and troubleshooting requires diligence.

The simplicity of the interface should not breed complacency. We have seen sites break because a custom theme used a function removed in PHP 8.0, or because a plugin bundled a library that conflicted with a built-in PHP extension. These are not failures of PHP; they are errors in the site’s code that were latent until a newer PHP version caught them. Upgrading exposes such issues, giving you the opportunity to fix them before they cause a security breach or data loss.

By following the systematic approach in this guide—creating verified backups, testing comprehensively, using error logs to identify problems, and knowing how to rollback if necessary—you can navigate PHP upgrades with confidence. The goal is not merely to change a version number, but to maintain a website that is secure, performant, and compatible with the evolving PHP ecosystem.