WordPress is largely based on PHP. The PHP version used therefore has a direct influence on whether WordPress, plugins, themes, and custom program code can be executed correctly.
A current PHP version is important for security, compatibility, and performance. Nevertheless, you should not simply update the PHP version of an existing WordPress website to the highest possible version without first checking whether all the components used are compatible with it.
Especially on older websites, outdated plugins, themes, or custom modifications can cause errors after a PHP version change. Typical consequences are a critical WordPress error, an HTTP 500 error, a white screen of death, or individual functions suddenly stopping to work.
Briefly explained: For WordPress, use a current and still security-supported PHP version. Before switching, check WordPress, plugins, themes, and custom code for compatibility. Create a backup and test important functions after the switch. If an error occurs immediately afterwards, you can revert to the previous working PHP version and then identify the incompatible component.
What is PHP? #
PHP is a server-side programming language. WordPress itself and a large part of its plugins and themes consist of PHP code.
When a visitor accesses a dynamic WordPress page, the server processes the PHP code and generates, among other things, the HTML that is subsequently sent to the browser.
Normally, the visitor does not see the PHP code. They only see the result of the server-side processing.
Why does WordPress need PHP? #
PHP handles a significant portion of WordPress's application logic. For example, it is used to process content from the database, load plugins, execute theme templates, check user permissions, and generate dynamic pages.
Therefore, WordPress cannot run normally without a suitable PHP environment.
The PHP version is therefore one of the basic technical requirements for a WordPress installation.
Why are there different PHP versions? #
PHP is continuously being developed. New versions bring new features, technical improvements, bug fixes, and security updates.
Older PHP versions eventually reach the end of their official lifecycle. After that, they no longer receive regular security updates from the PHP project.
Therefore, a WordPress website should not be run permanently on an outdated PHP version just because it still technically boots up.
Which PHP version does WordPress recommend? #
WordPress generally recommends a modern PHP version. Which specific version is suitable additionally depends on the WordPress version used as well as the installed plugins and themes.
For an existing website, therefore, one should not only check which PHP version WordPress itself supports. The deciding factor is whether the entire installation is compatible with this version.
Important: The statement „WordPress supports this PHP version“ does not automatically mean that every installed plugin and every theme is also compatible with it.
Why a current PHP version is important #
The most important reason for a current PHP version is security. If a PHP version is no longer provided with security updates by the PHP project, websites should be migrated to a supported version in a timely manner.
Newer PHP versions can also include improvements in performance and memory management.
Therefore, a PHP upgrade is part of reasonable technical maintenance for a WordPress website.
Why you shouldn't simply choose the highest PHP version #
A higher version number does not automatically mean that an existing website can be updated to it without preparation.
In practice, WordPress consists of more than just the WordPress core. An installation typically also uses a theme, multiple plugins, and possibly custom PHP code.
Each of these components can have its own PHP requirements.
For example, a new PHP version can remove functions or change behaviors that older program code still uses. A plugin that has not been maintained for years can thus cause errors, even though WordPress itself works without problems with the new PHP version.
Update WordPress before PHP upgrade #
With an older WordPress installation, you should first check which WordPress version is being used.
A very old WordPress core can be incompatible with a current PHP version.
However, that does not mean you should simultaneously update WordPress, all plugins, the theme, and PHP in an uncontrolled manner. In the case of major version jumps, a planned approach is advisable so that any error that occurs can be attributed to a specific change.
Check plugins before switching #
Plugins are one of the most common causes of issues after a PHP update.
Check in particular extensions that have not received an update for a long time or whose developers do not support the PHP version being used.
Self-developed or custom-adapted plugins should also be taken into account.
If a plugin is responsible for an important function of the website, its compatibility should be checked particularly carefully before the transition.
Also check theme and child theme #
Themes also contain PHP code. An older theme can therefore be just as affected by a PHP change as a plugin.
If the website uses a child theme, any custom code within that child theme must also be taken into account.
Individual adjustments are particularly common in:
functions.php
Such code may have worked unchanged for years and only trigger an error with a new PHP version.
Custom PHP code is an additional risk factor #
Over time, many WordPress websites contain custom code snippets.
These can be located, for example, in a child theme, a snippet plugin, a custom plugin, or other customized files.
This code should not be forgotten during a PHP upgrade.
The fact that a snippet works with an old PHP version does not automatically prove its compatibility with a newer version.
Create a backup before switching #
A current backup should be available before any major technical change.
The backup should include the WordPress files required for a restoration and the database.
While a PHP version switch usually does not directly alter your posts or pages, a recent backup is still advisable because further changes might become necessary during troubleshooting.
Practical Tip: An existing backup is only truly helpful if it is clear how it can be restored in an emergency.
Test PHP change on a staging website first #
For a mission-critical or complex website, a staging environment is the safest place for a PHP test.
The staging copy should correspond as closely as possible to the production website in terms of WordPress version, plugins, theme, and custom code.
There you can activate the new PHP version and subsequently check if any errors occur without immediately affecting the publicly accessible website.
For small websites, a direct switch may be possible #
Not every simple WordPress website requires an extensive staging process for every PHP upgrade.
If the website is manageable, uses current extensions, and a working backup is available, a controlled migration on the production environment can be justifiable.
However, you should then choose a time when you can thoroughly test the website immediately afterwards and react if there are any problems.
Change PHP version in hosting #
In modern hosting environments, the PHP version can often be selected per domain or hosting account.
Which interface is used for this depends on the hosting system.
In a cPanel or CloudLinux environment, PHP management can be handled, for example, via the PHP tools provided by the hosting provider.
Before selecting a version, you should make sure that you are actually changing the PHP configuration of the correct domain or installation.
Consider multiple websites in the same hosting account #
If there are multiple websites in a hosting account, you should check whether the PHP version is set globally or individually per domain.
Depending on the hosting configuration, a change may affect more than one application.
This is particularly relevant if older applications are run in the same account alongside WordPress.
Change PHP version and test immediately afterwards #
After the switch, you shouldn't just check whether the homepage appears.
Test both the public website and the WordPress admin area.
Visit several different page types and check the main functions of your website.
For a standard corporate website, these can be navigation, a contact form, search, and login, for example. In a WooCommerce store, product pages, the shopping cart, the customer account, and the checkout are among the critical areas in particular.
Why the homepage alone is not enough #
An error can only occur in a specific function.
A form plugin might not even run on the homepage. A WooCommerce issue might only appear during checkout. An administrative plugin can exclusively be used within wp-admin generate an error.
The fact that the home page works after a PHP change therefore does not prove the complete compatibility of the installation.
Consider cache after PHP change #
When a page cache is active, the public website may initially continue to appear correct even though dynamic WordPress requests are already causing an error.
This is possible if existing cached HTML pages are delivered without WordPress having to be completely re-executed for this request.
Therefore, also check uncached or dynamic areas such as the WordPress admin area.
Typical errors after a PHP version change #
An incompatible plugin, theme, or code snippet can manifest in various ways.
For example, WordPress may report a critical error, display a white screen, or respond with an HTTP 500 error. In other cases, just a single function stops working.
If such an error begins immediately after the PHP switch, the chronological correlation is a very important diagnostic clue.
WordPress shows a critical error #
If the critical error message appears after the PHP upgrade, you should first check whether WordPress has sent a recovery mode link to the administrator email address.
Further steps can be found at WordPress shows a white screen or a critical error: What to do?.
HTTP 500 after PHP change #
An HTTP 500 error means that the request could not be successfully processed on the server side.
If this error begins immediately after changing the PHP version, incompatible PHP code, extensions, or the PHP configuration are likely areas for diagnosis.
We cover detailed troubleshooting under How to fix WordPress error 500.
Switch back to the previous PHP version #
If the website goes down immediately after the PHP switch, a temporary switch back to the previously working version can be useful.
If the website works again after that, it is a strong indication of an incompatibility with the new PHP environment.
The rollback initially restores the website's functionality. However, it does not yet answer the question of which component is incompatible.
Important: Running an outdated PHP version permanently should not be the solution for an incompatible plugin or theme. Use the reversion as a temporary restoration and then identify the actual root cause.
Find the incompatible component #
If the new PHP version triggers an error, you should systematically isolate the component involved.
Particularly helpful is the combination of controlled plugin/theme diagnostics and error logs.
Our manual Identifying and Resolving Plugin or Theme Conflicts in WordPress shows how to disable extensions in a controlled manner without blindly deleting plugins.
Check error logs after a PHP change #
In case of PHP incompatibilities, error logs often provide significantly more information than the visible website.
A log entry may, for example, contain a file path within a plugin or theme and thus provide a specific clue about the component involved.
Typical terms in PHP errors can be, for example:
PHP Fatal error
Uncaught Error
TypeError
Call to undefined function
What is crucial is not only the error description, but also in which file and at what time the error occurs.
Use WordPress debugging #
When standard server logs are not enough, WordPress can log additional debug information.
Among other things, the following constants play a role in this:
WP_DEBUG
WP_DEBUG_LOG
WP_DEBUG_DISPLAY
We explain how to use these settings securely and evaluate logs at Enable WordPress debugging and use error logs.
Properly classifying warnings and deprecation messages #
After a PHP change, not only fatal errors can occur. Older code can also generate warnings or notices about deprecated functions.
Simply put, a deprecation warning means that a used function or approach is considered outdated and may no longer be supported in the future.
Such notices should be fixed in well-maintained code. However, they are not automatically the same as a fatal error that completely stops execution.
Do not display error messages publicly on a permanent basis #
On a production website, detailed PHP errors should not be permanently visible to visitors.
Such messages can reveal internal file paths, technical information, and further details.
For diagnosis, error logs are usually better suited than public output directly in the browser.
PHP Memory Limit after the version change #
PHP version and PHP memory limit are two different settings.
Switching from PHP 8.x to another PHP version does not automatically increase the memory available for WordPress.
If after a change an error such as:
Allowed memory size ... exhausted
appears, you should investigate the memory limit and the actual memory consumption.
You can find more about this at PHP Memory Limit in WordPress: Identify and fix errors.
PHP extensions can also be relevant #
In addition to the actual PHP version, WordPress uses various PHP extensions. Plugins can also require specific extensions.
If an application reports a missing PHP function or extension after changing the PHP environment, you should therefore check which modules are active for the new PHP version.
Depending on the hosting configuration, an existing extension for an old PHP version does not automatically mean that it is enabled identically for every other PHP version.
PHP settings can be version-dependent #
In addition to extensions, configuration values can also vary depending on the hosting environment and PHP version.
These include, for example, storage, upload, or execution limits.
If, after a version change, not the entire website fails, but for example only large uploads or certain processes cause problems, the active PHP configuration should therefore also be taken into account.
PHP Version and Performance #
Newer PHP versions regularly include technical improvements that can also have a positive impact on the execution of applications.
Therefore, a PHP upgrade can contribute to the performance of a WordPress website.
However, it does not replace the optimization of slow plugins, inefficient database queries, large images, or other performance issues.
If WordPress is fundamentally slow, you should investigate the causes systematically. You can find our detailed article on this WordPress is slow: Finding causes and improving loading time.
OPcache and PHP version #
OPcache can cache already compiled PHP code in memory and thereby make repeated PHP executions more efficient.
In a modern hosting environment, OPcache is one of the important components of a high-performance PHP configuration.
As a normal WordPress user, you normally don't need to manually influence how OPcache works for a PHP version change.
Check PHP version in WordPress #
WordPress displays technical information about the server environment within the site health.
You can find this information in the WordPress admin area under:
Tools → Website health → Report
There you can check, among other things, the PHP version recognized by WordPress under the server information.
This is particularly helpful after a migration to check which version the WordPress installation is actually using.
Compare hosting ad and WordPress ad #
If you have changed the PHP version in your hosting, but WordPress continues to show a different version, the configuration should be checked more closely.
The setting for another domain, subdomain, or PHP context may have been changed.
Therefore, do not rely solely on a specific version number being selected somewhere in the hosting panel when troubleshooting.
Command line and website can use different PHP versions #
In technical hosting environments, it is also possible that the website's PHP version does not match the PHP version used for a direct command line execution.
This is particularly relevant for WP-CLI, cron jobs, or custom shell scripts.
If a website works correctly in the browser, but a cron job or WP-CLI command shows PHP compatibility errors, you should check which PHP binary or environment the respective process is using.
Consider PHP version for cron jobs #
Depending on the configuration, a server-side cron job can explicitly call a specific PHP version.
If the website has been updated to a new PHP version, an older cron job may still be using a different version.
This can lead to differences that are difficult to trace because normal website requests work, but scheduled processes generate errors.
Special testing of WooCommerce after a PHP version change #
For a WooCommerce shop, a PHP upgrade should not be evaluated solely on the basis of the visible shop pages.
Test in particular the shopping cart, checkout, customer account, and important payment and shipping functions.
Extensions for payment providers, invoices, shipping, or enterprise resource planning can also use custom PHP code and must work with the new environment.
Check forms and email functions #
Contact and inquiry forms should also be tested after a major PHP update.
It is not enough to simply view the form visually. Perform a real test submission and check whether the processing works without errors.
The same applies to other business-critical processes that PHP processes on the server side.
Do not unnecessarily mix PHP upgrades and WordPress updates #
If WordPress, multiple plugins, the theme, and PHP are updated at the same time, a subsequent error can be difficult to trace back to a specific change.
For major maintenance work, a traceable sequence is therefore sensible.
Following a relevant change, it should at least be checked whether the website continues to function correctly before the next major technical step takes place.
Use old PHP version only as a temporary workaround #
In the case of a problematic website, it can be useful to temporarily revert to the previous PHP version so that the website becomes accessible again.
This buys time for a controlled diagnosis.
However, a PHP version that is no longer supported with security updates should not be used as a long-term solution for months or years just because a single old plugin does not allow an upgrade.
In such a case, the plugin should be updated, replaced, or the problematic code adjusted.
When a plugin should be replaced #
When a plugin only works with an outdated PHP version and is no longer maintained by the developer, it creates a technical maintenance problem.
Keeping the entire WordPress installation permanently on an old runtime environment in order to continue using a single plugin is rarely a good solution in the long run.
In this case, check whether a clean alternative exists or if the required function can be implemented differently.
Complete PHP change after successful test #
If the website functions stably with the new PHP version, you should check the most important features again and, if necessary, reset any diagnostic settings that were temporarily activated.
On a staging website, a successful test also does not automatically mean that content changes made there should be transferred to the live website. The initial goal of the PHP test is to check technical compatibility.
What you should better not do when switching PHP versions #
Do not switch to a new PHP version on a mission-critical website unprepared and then immediately leave the site without testing it.
Also, do not indiscriminately install additional plugins just to supposedly „repair“ PHP compatibility.
If an error occurs after the switch, do not change the theme, multiple plugins, PHP settings, and the WordPress configuration all at once. This makes it harder to trace the actual cause.
And do not keep an outdated PHP version permanently just because it can still run an incompatible plugin.
Basic rule: Change the PHP version in a controlled manner, test the website, and in the event of an error, first look at the temporal correlation. If the previous version works and the new one does not, you should identify the incompatible component instead of remaining on an outdated environment permanently.
What information helps CURIAWEB support? #
If a WordPress website at CURIAWEB no longer functions correctly after a PHP change, please share the affected domain, the previously used PHP version, and the newly selected version if possible.
The exact error message and information on whether the entire website or only a specific function is affected are also helpful.
If the website works again after switching back to the previous PHP version, you should mention that as well. This comparison is especially valuable for diagnosis.
If an error log contains a specific PHP error, please include the relevant snippet with a timestamp. You should not transmit passwords unprompted.
Summary #
The PHP version is a central component of every WordPress installation. A current and security-supported PHP version improves the technical foundation of the website, but must be compatible with WordPress, plugins, theme, and custom code.
Therefore, before making a change, you should check the components used and have a current backup. For complex websites, a prior test on a staging environment is recommended.
After the conversion, not only the homepage and frontend, but also the admin area and mission-critical functions should be tested. In WooCommerce, this includes, for example, the shopping cart and checkout.
If a critical error or HTTP 500 occurs immediately after the switch, a temporary switch back can restore the website initially. Afterwards, the actually incompatible component should be found using error logs and a controlled plugin/theme diagnosis.
An old PHP version is not a sustainable solution for outdated WordPress code. The goal should be a current, supported, and fully compatible WordPress environment.
