Most of the tech-geeks are excited with PHP 8.0, and certainly, the changes are huge this time. everyone is going to consume some time to understand the compatibility, configurations, benefits, etc., of PHP 8, and among all, one of the biggest questions popping up is – “is WordPress already compatible with PHP 8, and if not, then what actions are needed.”
Well, as soon as PHP 8 is released, our expert time dived into the deepest level of testing, and the outcome can shock anyone! Yes, we know everything now and feel pleasure to flaunt our reports and outcomes of tastings.
Not just we’ll show what all has changed, but also give you a pure advice regarding whether you should update to PHP 8 or not.
So many breaking changes in PHP 8: But why?
PHP 8 is a huge update of PHP, and it’s common practice to remove negatives in major versions from the recent range of minor versions. For the highly-talked PHP 8, several breaking changes have been reduced in the previous 7.* versions.
Hence, for projects that were attentively updated over the years, fixing their derogated API’s, it shouldn’t be tough to upgrade at all. Telling the truth, PHP 7.* versions have observed a far bigger set of deprecations in contrast to previous versions of PHP.
We’d say PHP 5.6 to PHP 7 was a pretty simple migration, but going from 7.x to 8 could be somewhat painful, especially for the old codebases, including WordPress, besides several available plugins.
Certainly, for well-typed codebases or up-to-date codebases with the latest PHP versions, big problems won’t occur. However, the reality is that WordPress isn’t such a codebase.
Is WordPress already compatible with PHP 8?
Saying honestly, maybe WordPress is already compatible with PHP 8, but sealing those words isn’t possible, though. WordPress targets to always be compatible with the latest versions of PHP. However, we’ve deeply analyzed the biggest concerns later in this guide.
We’ve done an amazing job concerning finding the perfect fixes for the majority of the compatibility problems that could be found using the available strategies. We’ll certainly dive deeper into what all was there and the problems that exist with them.
What performance changes are coming?
The major potentially exciting feature arriving with PHP 8 is JIT (Just In Time) compilation and debugging. As we know, PHP is an interpreted language, which means it’s translated into machine code when it runs.
JIT tracks the code that’s frequently used and works on optimizing the machine code translation to make it reusable. Now, this can result in a huge performance improvement for a given functionality.
For the time being, the actual performance elevation for web apps like WordPress is minimal. Besides that, it will take a huge time before a developer or an average WordPress user reaps the advantages of this new feature.
There are several other new features to bring ease to the developers’ lives; it’s unlikely that these are going to be used in WP themes and plugins for the foreseeable future because the majority would break compatibility with PHP’s earlier versions still in use by several WordPress sites.
How to update PHP for your WordPress site?
In this guide, we’ll describe how conveniently you can update PHP to the latest version, most importantly, without breaking your WordPress site.
If you are eager to know the path, then just check your current PHP version, then Update WordPress to the newest version. After that, Install the “one.com PHP scanner” and run a scan to fix potential issues. Further, update PHP to the latest version, and verify whether your site is working as expected or not.
Let’s show the whole process.
Step 1: Check your current PHP version
In the very beginning, you have to check what PHP version you’re currently rolling on with. You can get the information of the current PHP version of your website from the phpinfo page.
If you are running on the cPanel, you can view PHP version from the article how to view and change PHP version in cPanel.
In case you’re using PHP version 7.3 or higher, then everything is fine. For those having PHP 7.2, an update is needed. Please cherish to step 2.
Step 2: Update WordPress to the latest version
Ensure that WordPress core and all the plugins and themes are updated to the latest version if you really want to avoid any malfunction.
- Log in to your WordPress Admin and Click Dashboard > Updates.
- Check whether you’ve got the latest version of WordPress installed and that all themes and plugins are up to date.Update your WordPress to the latest version now.
Step 3: Install the “one.com PHP scanner.”
- In your WordPress Admin, tap one.com > Plugins.
- Locate the one.com PHP scanner and tap Install now.
- Now, click Activate, and move to the next step.
Step 4: Run a scan & fix potential issues
- In the menu on the left, tap PHP scanner.
- Tap PHP version 7.4, then “All themes and plugins,” and then tap Start scan.
- You can proceed once the scan is finished.
- You can have three results:
– Compatible = It means all is good!
– Warning = It means that it should work but might give issues with the upcoming PHP version.
– Error = It’s not so good, will certainly cause issues after updating.
Fix any themes or plugins that read errors, either by updating it to the latest version or by replacing it with an alternative plugin providing the same functionality.
Tip: We recommend you to use just those plugins use plugins that get updated regularly and bring no compatibility issues with the latest version of WordPress. Besides that, it’s a good practice to remove any unwanted plugins to enhance the site’s performance.
Step 5: Update PHP to the 8.0 version
You are now all set to update PHP. We recommend to turn on PHP error messages simultaneously. In case there’s an issue with the code, you’ll see error messages telling you what’s causing it and also where exactly it’s located.
- In the control panel, return to PHP and database settings.
- Scroll down to PHP error messages.
- Click Update after setting the error messages to On.
- Directly below this, change the version and tap Update.
Step 6: Verify whether your website is working as expected.
Now, you’ve got the PHP version updated, and it will take a minimum of 20 minutes before the changes apply. If your site receives a lot of visitors, the time frame may extend to even several hours. That’s the reason we recommend checking your website a couple of times minimum during the upcoming 24 hours.
In case your site isn’t working against what you expected, then the most likely issue is your theme or any plugin. To find out what’s exactly causing issues:
- Temporarily switch to the default WordPress theme, we’d say, “Twenty Seventeen”.
- Select all installed plugins and deactivate them altogether.
- Enable themes and all plugins again, one by one, and keep checking each time whether your site is still working or not. You can catch the culprit this way.
If we talk technically, then the compatibility of the present-time nightly of WordPress with the highly discussed PHP 8 is at a similar level as we inhabit from WordPress releases right before a fresh version of PHP pops-up.
Our testing was as substantial, the fixing was as meticulous, and the level of trouble-fixes was as huge as any of PHP compatibility fixing inside WordPress core. However, if you don’t follow this guide, you won’t be able to understand the compatibility challenges and reap maximum benefits out of PHP 8.
The huge amount of breaking changes and the sorts of changes included in PHP 8, besides a few added complexities in cross-version tooling, certainly make this compatibility challenge a bigger beast from what we’ve experienced before with the previous versions of PHP. This report targets to explain the same case.
WordPress and PHP8 Compatibility challenges
We’d show you a few strategies that you can deploy for making an existing codebase compatible with PHP 8.
- Static analysis tools such as PHPCompatibility to detect syntactic problems.
- Automated testing to detect runtime problems.
- Manual testing to detect runtime problems.
Depending on your test suite’s coverage and the proportion of syntactic changes and runtime, these strategies serve nicely for fixing the codebase’s compatibility with a new version of PHP (currently discussing PHP 8).
Truly, in the case of PHP 8 and WordPress, there are a few additional challenges that make it difficult to rely on these strategies in accordance to ensure perfect compatibility of WordPress with PHP 8. Below we’ll report on strategies which we’ve deployed for WordPress and share the results.
Static analysis tools
Because of the nature of a few changes in PHP 8.0, the problems which can be detected using static analysis are limited. In those circumstances, where static analysis looks to go beyond their traditional potentials and plans to trace the value of variables and constants and runtime type, the results of such scans are certainly going to be prone to false positives.
Besides that, PHP Compatibility is the one and only static analysis tool meant to find PHP cross-version compatibility related issues.
Besides PHP Compatibility, other static analysis tools report on a larger scope of issues. Cherishing the results to detect the issues, which are PHP cross-version compatibility related and actually correct, is pretty time-consuming and needs in-depth tooling-related knowledge, especially about configuring them for the least amount of noise.
Simultaneously, these tools are in constant instability, trying to roll on with the changes in the PHP version and updating the possible scans. Hence, we can expect these tools to detect still more issues in the upcoming future.
So independently of what has already been and can be further found at this time, the chances are that these tools will still find more issues in the (near) future.
Scanning WordPress with PHPCompatibility
“__destruct() won’t be called after die() in __construct() any longer” is another PHP 8 issue found by PHPCompatibility. This is perfectly detected by the scanner. However, upon further analysis, it has been figured out not to be problematic in this case.
Besides that, PHPCompatibility detected a problem in code that’s used by “Plugin/Theme editor.” Involved code’s analyses have determined the existence of an underlying oversight in the code. In the editor, WordPress looks forward to doing minimum analysis of the code; however, it doesn’t take PHP 5.3+ code into account.
While taking relevant changes in PHP8 into account, this oversight is now be made more complex to solve. We ran scans with PHPCompatibility with the developed version, and the results, as we expected, were much different from what we obtained with the previous updates of PHP. Issues detected by the scanner are maintained externally.
Scanning WordPress with Exakat
Talking about the latest public scan that took place on October 16th, based on WP trunk, Exakat reports 149.567 issues in total.
The PHP 8 compatibility report shows us a total of 93 issues. However, it’s incomplete as an analysis number relevant for PHP 8 aren’t included in the report.
While we expect these reports to contain a great number of false positives because WordPress doesn’t use type declarations, and therefore the types are extrapolated from the code that’s found and the types shown in docblocks, these problems should still be examined individually.
No matter just 1% of the found problems is right that would still decline to ~450 errors, which still needs to be dealt with. Besides that, the great amount of time required to weed out the authentic issues from the false positives.
Scanning WordPress with PHPStan
Scans with PHPStan require a fully customized ruleset to attain remotely usable results, and still, they prove to be riddled with a few false positives, making the output unusable.
Note: We aren’t criticizing the PHPStan tooling, but it is hugely due to the fact that WordPress hardly uses type declarations, while on the other hand, PHPStan is primarily inclined towards projects using modern code, isn’t it?
An initial scan comprising the most basic of configurations will yield 20.000+ issues. A scan with the highly customized above-mentioned ruleset, targetted at PHP 8 related problems specifically, still yields exactly 580 issues at level 5 and additional 2.150 potential issues at level 7. These will likely contain a few false positives and yet yield 380 issues more at level 8 with a similar caveat.
A Trac ticket was recently opened to address a list of issues on the basis of an unknown configuration, but fully targeted yo passed parameter type mismatches (level 5). Draft PR is available to fix these issues.
An inceptive assessment of this PR indicates that most of the fixes proposed would typecast variables to the expected type and hide issues, not actually fix them by checking properly. This leads to unexpected behavior in the application in case these changes aren’t accompanied by strict unit tests. Besides that, tit likely results in increasing difficulty while debugging errors further down the line for sure.
Currently, it isn’t confirmed whether the fixes proposed are warranted or that the identified issues should be observed as false positives.
Static analysis can just go so far because of the nature of the problematic swaps in PHP8. Manually reviewing and testing software proves to be such painstaking work, and humans are also pretty prone to overlook things when there’s much to be looking out for.
Now, talking about testing performed by end-users, they prove to be relatively useless, as this will normally result in “happy paths” being tested. If we want to achieve more reliable results, then we need comprehensive exploratory and regression testing.
Having automated tests of high quality and running these on PHP 8 is more important than anything. This will offer the perfect indication of the PHP 8.0 issue to expect.
Most of the tech-geeks are excited with the PHP 8.0, and certainly, the changes are huge this time. everyone is going to consume some time to understand the compatibility, configurations, benefits etc. of PHP 8, and among all, one of the biggest question popping up is – “is WordPress already compatible with PHP 8, and if not, then what actions are needed.”
Well, as soon as PHP 8 released, our expert time dived into deepest level of testing, and the outcome can shock anyone! yes, we know everything now, and feel pleasure to flaunt our reports and outcomes of testings.
Let’s move on to Running automated tests on PHP 8 now.
Running automated tests on PHP 8
PHPUnit 9.3 is the first PHPUnit version that’s officially compatible with PHP 8.0, and it was released in August 2020. Well, running an automated test suite running on PHP is tough because the de facto tool for unit testing.
Getting an automated test suite to run on PHP 8 takes us down the next rabbit hole as the de facto tool for performing the unit test in the PHP world; PHPUnit normally does a huge release every year, with every single major drop support for previous PHP versions. It introduces breaking changes, but as PHPUnit 9.3 is officially compatible with PHP 8.0, as we mentioned above, there is no need to worry!
We know that, as a minimum, WordPress still supports PHP 5.6. For running tests on PHP 8.0, any test suite related to WordPress needs to be fully compatible with PHPUnit 5 up to PHPUnit 9. Certainly, tooling is built to help you with that; it still consumes effort and time to implement these tools to make a test suite compatible.
Getting the tests running on PHP8 for WordPress Core
The tests for WP Core are currently passing and running against PHP 8. These tests are being conducted on PHPUnit 7.5’s composer installed version. Even though PHPUnit 9.3 is the oldest PHPUnit version that’s officially compatible with PHP 8.
This last issue has been tackled by copying a selected number of files/classes from PHPUnit 9.3 to the WordPress test suite, excluding the native classes of PHPUnit from the Composer autoload generation, supporting the usage of copies from PHPUnit 9.3 in the WordPress test suite. This works, for now, however, we’d call it a hacky solution, and it may not be sustainable in the upcoming, besides the maintenance it may currently need.
For the sake of tests’ quality, this was certainly low to start with, with loose type checking being utilized in most of the cases.
Getting deeper, a Trac ticket to address this was opened back in 2016. Considering the stricter type adherence in PHP, this ticket has been restored. Much work has been undertaken to mitigate this.
While we wrote, there are around 800 instances (676 assertEquals() added to 96 assertNotEquals()). Still utilizing loose type checking – down from 8000+ instances.
In part, the loose type assertions that were remaining are legitimate when objects are compared; in part, these certainly need to be addressed. However, it would currently lead to test failures. These last ones underline shortcomings either in the tests, however more occasionally, in the code being tested.
Testing themes and plugins
There is only a small percentage of the available plugins, the professionally developed ones and more popular and, have automated tests in place. Generally speaking, this is worrisome as a normal WordPress site runs nearly 19 or 20 plugins for sure. Quite a few sites roll on with even more plugins! Having automated testing in place for themes is even rarer.
It is challenging to allow these test suites to run on PHP version 8. And also before insight can be gained regarding the compatibility of plugins and themes with PHP 8.
However, the plugins/themes which having are mostly the ones where the minimum amount of PHP 8.0 issues can be expected. We exclaim so because such themes/plugins use a professional development model.
The bigger cause of concern is the multitude of tests and themes without tests, as these are more prone to be problematic while running with PHP 8.
For themes and plugins, which do have tests, primarily two types of tests are there which they may or may not have right in place:
- Unit tests. Stand-alone tests which “deride” WP to permit the testing of the plugin code. Popular frameworks likeBrainMonkey and Mockery are used.
- Integration tests. Now, Integration tests are where WordPress itself loads before we run the test suite, and it will use the WPcore code and integrate with the WP test suite.
We know WordPress has decided to stick to PHPUnit 7.5. What does that mean?
Well, for integration tests for themes and plugins, those will also be jumped to PHPUnit 7.5 (maximum).
Themes and plugins will either have to copy the hack in WP core to get their integration tests perfectly running, or alternatively, they will have to use the files in WP Core. However, they will then have to create a custom autoloader because the same Composer autoload generation hack can’t be used.
If PHPUnit native files need to be prevented from loading anyway, such a custom autoloader will have to be surely bootstrapped right before the Composer autoload file.
For unit tests with the help of Mockery or BrainMonkey, PHPUnit > 8 is required as the Mockery framework available for PHPUnit 7.x isn’t compatible with PHP 8.0. Hence, the comparability of these test suites is compulsory with PHPUnit 5 up to 9, which certainly adds another challenge.
Different versions of PHPUnit are required to run each test suite when both sorts of test suites are being used. To aggravate this circumstance, plugins will normally have a committed composer.lock file to ensure that their runtime dependencies are at a given version they can rely on and which is fully compatible with PHP 5.6.
At certain times, this last part is enforced by having a platform php 5.6 sorts of configuration in the composer.json file. That also means their dev-dependencies BrainMonkey, Mockery, PHPUnit, will also get locked at a version that’s compatible with PHP 5.6. now, that would surely prevent running tests on PHP 8.0.
You can overcome that by on-the-fly removing the platform besides updating the composer.lock files and composer.json. However, this makes running the tests on PHP 8.0 more involved, both in CI and locally, for its developers.
PHP 8 compatibility is looking somewhat tricky on large WordPress sites
By just investigating a chain of breaking changes in PHP 8, we could confirm this is prone to cause huge breakage on sites with the unclear reason for that breakage. At certain times, the error will happen in one place but is generated by a theme or plugin in a different place, amd that would certainly make these issues pretty hard to debug.
accuwebhosting.com is certainly an actively maintained WordPress site, and a dedicated team of professional developers supports it. The vast majority of WordPress sites don’t have such luxury, and mitigating compatibility issues on these sites will be challenging for sure.
How long do developers have to update?
The life cycle of Each version of PHP is of 2 years, and bugs are fixed in this era. One more year is added during which security problems are patched. PHP 7.4 arrived in November 2019. It was the final version of PHP 7. It means that bugs in PHP 7.4 are going to be fixed until November 2021. Security problems will be patched until November 2022. It will reach its “End of Life” at that point in time.
Hence, the hard cutoff date is November 2022: all PHP code needs to be compatible with PHP 8 by this time, or dangers of being stuck on a potentially vulnerable PHP version.
PHP 8 will contain numerous breaking changes. We’ve described a good range of those changes in our report, the ones which our experts assume will have the fiercer impact on WordPress besides the broader WordPress ecosystem. Those generally have to deal with warnings becoming problems. And several errors are introduced, which can be tough to deal with. You can detect a higher percentage of these changes on runtime.
Fixing all of these compatibility issues is a huge task. To accomplish that, you need to use a variety of strategies, starting from static analysis to automated testing. It requires huge time+ effort.
You should have the right to tool to conduct everything perfectly. For projects such as WordPress, which have to support a variety of PHP versions, several extra complexities are introduced in juggling various versions of the analysis tools, as we discussed above.
Certainly, it becomes pretty hard due to the runtime and syntactic differences between PHP 5 and 8 being so incredibly huge.
Is using PHP 8 on WordPress good or not? Actually isn’t the argument here. The only conclusion here is – it becomes very challenging to do so.
Also, we’ve considered the issue of coverage and WordPress’s PHP dependencies. If you want to reliably detect compatibility, then high test coverage proves to be necessary. And talking about PHP 8, it’s even more important because the number of compatibility issues is higher than usual. A major percentage of them can be detected just on runtime.
So, what do we advise?
If issues are detected, extensive debugging is required to find the root of the problem, no matter it’s WordPress, Theme, Plugin, or it’s associated directly with PHP compatibility.
Test coverage is virtually absent for dependencies and low. Hence, it’s hard to exclaim what is WordPress core compatibility with PHP 8 in a true sense.
Because of PHP 8 concentrating so deeply on strict typing, WP’s type unsafe extensibility system becomes extra vulnerable to issues, potentially leading to plugins generating type errors in other plugins or WP itself.
We put this to testing by running an analysis on error data the last month. As a huge site, we figured it might give a strong indication of the sorts of problems we can expect. Certainly, we found several warnings that will evolve into errors with PHP 8.
We’d prefer making a final note here. WordPress isn’t the only legacy codebase available. Also it’s not the sole project which targets to support a huge range of PHP versions. The info in this article might apply well to other projects too.
The primary goal of this article from Accuweb is to inform and make an overview of the challenges and issues related to PHP 8 compatibility in WP. We highly hope it serves this purpose perfectly.