Transitioning to PHP 8.x with Four steps - Interview with Juliette Reinders Folmer (r)
Upgrading the functionality of a WordPress site, plugin, or theme to a new version PHP is a process that recurs regularly. However, how can you complete this as efficiently as possible? What can you do to ensure that you'll not miss anything? Are there any plans to follow?
In this article this article, we'll answer these questions (and many more) and examine how to make a smooth change into PHP 8.x on your WordPress site, plugin or theme, including some guidelines.
We'll do this based on an interview we conducted with PHP specialist Juliette Reinders Folmer. Her primary focus is on dedicating her daily life to programming, and all things related to it, focusing mainly on open-source projects, including WordPress.
Are you ready to make the switch smoothly also? Curious about our step-by-step plan? So let's begin!
PHP 8.x -- What's New?
To give a brief overview of the changes, we recommend following articles:
- Release notes with release notes PHP 8.0 and PHP 8.1
- Migration guide for the PHP 8.0 and PHP 8.1
- WordPress as well as PHP 8.0 and the current state
When you read these articles after reading these articles, you'll be informed about what's changed with PHP 8.x and what you must do in order to make your PHP applications running smoothly without issues.
If you're not certain which way to begin, don't worry. The time we had a conversation with Juliette, we went over this issue in depth as well as we'll explain the reader in this post the best way you can make the switch into PHP 8.x.
Moving to PHP 8.x What Should You Do To Get Started
However, before doing this you should consider the following things you need to ensure. In accordance with your degree of experience and knowledge The following are our recommendations:
- If your WordPress site was developed by an outside party, a developer, or an agency, contact them to ask if your site can run on PHP 8.x.
- If you've created your WordPress site -- through the theme you have created like, for instance, or your own plugins that you have developed -- we've got a plan to help you follow it below.
If your website falls in one of these two categories, we certainly encourage you to go through the remainder of this article, but we don't recommend you start testing your site to ensure PHP 8 compatibility yourself. Leave it to the professionals.
If you don't see any difficulties in your staging environment, it doesn't necessarily indicate that there's not any issues. The roadmap below will tell you the reason.
The PHP 8.x Compatibility Testing: The Roadmap
Testing is the key to excellent software. In all cases, even for WordPress websites and their components including themes, plugins, as well as the WordPress main page testing can be the way to be sure that no problems occur that you do not want to happen.
The following kinds of tests are discussed in this blog article:
Let's look more closely at the various types of tests we can conduct.
Static Analysis (or Static Testing)
One of the first steps you could do as a PHP designer is to conduct an analysis that is static of your code with different tools. Static analysis is the method that analyzes software, but without actually running the program. With static analysis, it can detect any mistakes, identify issues with PHP 8.x compatibility, and enforce Coding standards (for example in for example, the WordPress Coding Standards), and even modifying or cleaning the code can be done.
Instruments for Static Analysis
It is possible to perform static analysis by using different instruments, including:
In the moment of writing, not all PHP 8.1 checks are included in the latest PHPCompatibility release. PHP 8.1 checks can be in the development release, so make sure you use those (for now) when using PHPCompatibility to analyze your project and see what errors/recommendations there are.
PHP 8.1 checks will soon be released in a new majorversion. If you want to be informed about this and already have a GitHub account visit the the PHPCompatibility GitHub repository PHPCompatibility and go to Watch and then Custom -> Releases, where you can opt to be informed each time a new version gets made available.
PHPCompatibility, which only tests the compatibility of a specific version (or number of versions) of PHP It is simple to install. The best results are obtained if you run a testVersion -- for example, 8.0+ (8.0 and up) inside PHPCompatibility.
Be on the lookout the possibility of deleted or obsolete functions, changed default values of function parameters, whether to use concat without parenthesis, if you should utilize match in an expression for a name of the function (since it's been used since PHP 8.0) or not, and more.
Psalm and PHPStan are excellent additions that are able to assist in carrying out additional checks related to variable types. One disadvantage of these programs is that they need many configurations for reports to be generated that are based on PHP 8.0 or 8.1. However, even if these tools are effective, you can expect many false positives. False positives refer to notifications that are given wrongly because of static analysis's limitations.
A solid understanding of PHPStan is essential for interpreting the outputs from these tools but that knowledge can aid in the identification of other incompatibilities which PHPCompatibility cannot discover. Review the manuals for Psalm as well as PHPStan If you'd like to know more about these tools.
Summary:
- Perform static analysis with PHPCompatibility, Psalm, PHPStan
- Solve all legitimate issues
Unit Testing
The next stage of the procedure will be unit test. Unit testing is the process of testing pieces of code individually. In unit testing, specific focused tests are created for each unit. It will include running through various scenarios. The ideal scenario should be examined separately from all the other ones to ensure that the tests are independent of one another.
Having unit tests alone however, obviously, is not enough. Also, they must be tested. Tests for unit are most effective when they're automated with CI (continuous integration) tools like Jenkins, GitHub Actions and Travis.
Supporting Multiple Versions of PHP
As a plugin builder, should you wish to be able to run several PHP versions, you must ensure that your tests in CI are tested on the entire range of PHP versions you can support.
Of course, you can also support only newer versions and the decision is completely up to you.
Testing with various versions of PHP will require you to use different versions of PHPUnit, based on the PHP version you are using. As PHPUnit has made several modifications in the past that have affected how tests are written this can be a challenge.
Now that you have the tests running The next thing to do is ensure any issues you find in your tests have been fixed.
Code Coverage
Conducting these tests is the most reliable way to identify cross-version compatibilities.
When you do this, pay attention to the codes coverageof the tests you run:
- If you've created one function and developed a test, and function A call functions B, C, and D as part of the logic of the function.
- Function A's test was written to check the logic behind function A, but it can also invoke function B C, and D during testing. In the case of functions B, C, and D the test will typically examine the "happy path" -- the situation that everything runs smoothlywhich is why those functions have not been fully tested, although (part in) the code in those functions is executed during the test of function A.
- For each of your tests make sure you specify the code that is specifically being examined. This is done by assigning each test a @covers So, B, C, and D are not "counted" in the calculation of code coverage This allows you to see which part of your code is being covered by the tests.
Sometimes, developers write and test -- sometimes without knowing it -- to find the "happy way." When this happens the testing of what happens when unexpected data is passed to a function is also essential. Testing with only typed or expected values is not sufficient.
The 2nd part of the above quote is often forgotten, when it's actually more significant than the previous part. What happens when you type an incorrect kind of data? If you receive an error message? Does the variable get cast with the function continuing as normal? What happens if an unanticipated value is sent into the function?
Test your PHP functions using unexpected types, variables, as well as values. Only then can you trust your test results to find problems that a new PHP version could result in.
PHP Is Getting Stricter
PHP is becoming more specific (strict) in how it handles "types" for PHP's own functions, as well as things like dynamic properties. The goal of these changes is to assist developers in delivering flawless programming (well, code with less mistakes). This can be an upgrade hurdle for pre-existing PHP code that is written using "old" fundamentals of PHP.
Due to this need to provide more useful error messages for error messages in PHP it is evident the process of making code compatible to the latest PHP versions takes more and more time. The process of making code written for PHP 5.6 appropriate for PHP 7.0 just took a fraction of the time in most cases when compared with upgrading the codes to ensure it's appropriate for PHP 8.1. And that's despite the fact the PHP 7.0 was an "major" release. PHP 8.1 is classified as a "minor."
For many, testing remains the best way to determine what needs to be changed to accommodate the new version.
Testing units is done using various tools, including:
A lot of these programs have been developed on or in conjunction with, PHPUnit.
It doesn't really matter the tools you choose to use. The most important thing is that you run tests, and run the tests with the latest PHP versions. This step can sometimes difficult, however it is fortunately, like we mentioned previously it is possible to use tools for this like PHPUnit Polyfills.
Integration Testing
Integration testing is the next step we will perform, after static analysis as well as unit testing. Integration tests are where scenarios from real life are tested within a wider context than just the concept of a "code unit." This includes testing using an active (test) database, or testing with an external API, to give only two instances.
If you're testing the code of a plugin or theme inside the context of WordPress and then use a live version, these are, according to the definition Integration tests.
WP Test Utils (again written by Juliette and sponsored by Yoast) is an excellent instrument to test integration. WP Test Utils provides tooling for writing integration and unit tests, that is, WordPress is "mocked up" with Brainmonkey as well as Mockery, where commonly used WordPress features are "faked" in order to make sure you are testing your own code, not the WordPress code.
Integration testing with WordPress is an arduous task due to the fact that it requires an integration between WordPress as well as WordPress testsuite. It is dependent on what versions of WordPress the plugin or theme supports, you have take into consideration the PHPUnit versions are supported by WordPress in order to conduct the tests across various PHP versions.
As an example, WordPress 5.6 through 5.8 uses PHPUnit 5 to 7 to test PHP 5.6 through PHP 8.0, but in WordPress 5.9, WordPress itself is also using PHPUnit Polyfills to provide a wider functionality. WP Test Utils acts as bridge between all the differences.
Do you want to know more about how to run integration tests against multiple different versions of WordPress which includes WordPress 5.9 and above? Then read about it on WordPress' website.
Manual Tests
Once you've finished the unit test and integration tests and have fixed all the bugs you've found, it's time to do the manual tests. Your website is operating, and your code is working, but you're using the plugins A, B, and C. Are you aware if those plugins are compatible?
In this case, for instance, consult with the developers of the plugin to see if they indicate the plugin can be PHP 8.x compliant. The question then, of course, is how it was tested. Often the answer here is: in isolation. The plugin's capabilities have generally been tested in conjunction with WordPress by itself, with no the use of other plugins. And even if other plugins were utilized in the tests, it is likely that not all plugins used by you were part of the testing, so take such a compatibility statement with a grain of salt.
For example, an example is a WordPress site that has 3 plugins (A, B, and C). There is a possibility that plugin B, for instance results in an invalid kind of variable through a filter, which plugin C uses the same filter, wants to use. It could result in a fatal error because the type returned isn't what is expected. The plugin C can then be seen as the culprit for the error message, however, plugin B could be actually the culprit.
Plugin interoperability-incompatibilities are impossible to discover when testing in isolation. The more active plugins, the higher chance that something could go wrong. As an example, it could be extremely beneficial to send page requests from a live website into a staging site (with errors logging turned on) in order to find out what's really going on.
When this happens, a site owner will usually only see a message that there was an error with the last executable code (in this instance, the code was generated by plugin C) regardless of the fact that plugin C does not have to be the primary cause of the problem.
In most cases, a lot of manualand human effort is involved, and a healthy amount of elbow grease is required for identifying and fixing these problems. This couldbe automated using end-to-end testing however we haven't seen this happening much in WordPress.
Test Availability for used Plugins
For developers and development teams: Accept code only after tests have been made. This way, you ensure that less manual testing is needed, and you save lots of time.
Question its testing strategy if you want to buy an commercial theme or plugin. That way, we collectively create awareness among developers/development teams in the WordPress community to get testing higher on the agenda, and we all benefit.
Testing is often viewed -in a way that is unfairly as an expense but, in actuality testing can save cash. The extra investment required for writing tests is rewarded with the result of smaller bug reports, and less time spent working on issues. Additionally, thanks to automated testing of software, extension or modifications are able to be completed quicker because tests are able to quickly confirm that the functionality continues to work.
The Function of WordPress Hosts and PHP 8.x
If you are a typical site owner, assistance from your hosting provider is extremely important. Consider the following:
- Documentation and updates for customers who WordPress Core, plugins, or themes are (in certain cases) not PHP cross-version-compatible.
- The methods for reporting errors and for contacting helpline
It also helps a host, as site owners frequently contact their host for assistance when they encounter problems. If a switch towards PHP 8.0 or 8.1, the site owner is responsible for potential problems, and the more information an owner can gather to plan for the change as well, the better.
The minimum PHP version for WordPress
Over 15% of all websites currently use PHP versions 7.0 or less. This is apparent within statistics from the official WordPress statistics. About 83% of all WordPress sites currently use PHP version 7.4 or lower. Please note that anything lower or equivalent to version 7.4 is no longer supported by PHP. The use of end-of-life versions PHP could cause problems due to security updates not being anymore made available.
Because WordPress only requires the minimum version that is 7.4, there is insufficient motivation for many websites and hosting providers to upgrade their websites. This is in spite of having PHP 7.4 has reached the end of its life in November 2022.
If WordPress increases the minimum PHP version, this may cause some websites to not be compatible after an upgrade to the most current WordPress version. Security updates, however, continue to be available in these outdated versions for a long duration.
Summary
To switch from PHP 8.0 or greater on your site There are a few steps that you, or your web developer, need to complete. Important steps include:
- Static analysis
- Unit testing
- Integration testing
- Manual testing
When switching to PHP 8.x ensure that all has been properly tested. This is your only chance to guarantee that your site runs efficiently, speedily and with security on a newer PHP version.
We thank Juliette greatly for her participation in this piece and all the work she has done in the tool mentioned!
Image of Juliette Photo taken by Jip Moors and used by permission.
- Simple setup and management on the My dashboard
- Support is available 24/7.
- The best Google Cloud Platform hardware and network powered by Kubernetes for maximum scalability
- An enterprise-level Cloudflare integration that improves speed as well as security
- Global audience reach with the possibility of 35 data centers, and 275 PoPs worldwide