Tutorial - Testing plugins for PHP Compatiblity

[jonathanbossenger]

Topic Description

With all versions of PHP 7 now officially EOL (end of life) any plugins you develop, or have developed, must support PHP 8. While WordPress does run on PHP 8, many plugins still do not support it fully. In this workshop, we'll look at how to can test your plugins for PHP compatibility, in order to get them updated.

Related Resources

Links to related content on Learn, HelpHub, DevHub, GitHub Gutenberg Issues, DevNotes, etc.

• Online Workshop

Guidelines

Review the team guidelines

Tutorial Development Checklist

• Vetted by instructional designers for content idea
• Provide feedback of the idea
• Gather links to Support and Developer Docs
• Review any related material on Learn
• Define several SEO keywords to use in the article and where they should be prominently used
• Description and Objectives finalized
• Tutorial created and announced to the team for Q/A review
• Tutorial reviewed and ready to publish
• Tutorial submitted and published to WPTV
• Tutorial published on WPTV
• Tutorial captioned
• Tutorial created on Learn.WordPress.org
• Tutorial post reviewed for grammar, spelling, etc.
• Tutorial published on Learn.WordPress.org
• Tutorial announced to Marketing Team for promotion

[jonathanbossenger]

Script: https://github.com/jonathanbossenger/wp-content/blob/main/tutorials/php-version-compatibility-testing.md

[jonathanbossenger]

Tutorial for review.

Note to the reviewer, I again had some audio issues on this video, which I have noted and I will re-record those sections, but I wanted to get the video up for review so long.

I'll make sure those audio glitches are fixed before publishing.

php-compatibility.mp4

[github-actions]

This content is ready to be reviewed. Please follow the steps listed under Guidelines for reviewing content. Thank you for your contribution! ✨

[digitalchild]

Great video as always @jonathanbossenger When you're running the composer commands, there are deprecation notices. Might be worth mentioning if people get these notices, they can ignore them? Otherwise, all good!

[WpNoisemaker]

Tutorial Review Checklist

Please tick all items you've confirmed:

• Learning outcomes/objectives are clear.
• Technical concepts introduced in the content are accurate.
• The speed of demonstrations are easy to follow.
• The narration audio matches what is shown visually.
• Spelling and grammar are correct.
• Sound quality is consistent throughout the video.
• Brand Usage Guidelines and Promotional Guidelines are being followed.
• Media assets are all in the public domain (CC0).

[WpNoisemaker]

Hello @jonathanbossenger. This is a good video and I can hardly notice the audio glitches you made mention of. But can you kindly reword or fix some slight typo, punctuation, and sentence structure in the topic description please?
Example: I think the part that was written as “ many plugins do still not support it fully” can be re-written as “ many plugins still don’t fully support it” and the “to” word in the second to the last sentence should be replaced with “you”.
Really, they are very minor issues and probably typo errors but this is my first contribution and I had to just fish something out 🙂. Otherwise, great content!

[jonathanbossenger]

Hi @WpNoisemaker thanks for the review.

I agree with your suggestion to change "many plugins do still not support it fully" to "many plugins still do not support it fully" (I prefer to use "do not" instead of the contraction here, to make the point). However, the use of the word "to" in the last sentence is not supposed to be "you".

[jonathanbossenger]

Thanks for the review @digitalchild

When you're running the composer commands, there are deprecation notices. Might be worth mentioning if people get these notices, they can ignore them?

Hmm interesting point, those notices are more related to my local PHP versions and would be different for different environments. That being said, it might be worth it in a future tutorial about composer, and to mention this.

[jonathanbossenger]

https://wordpress.tv/2023/08/11/testing-plugins-for-php-version-compatibility/

[jonathanbossenger]

https://learn.wordpress.org/tutorial/testing-your-plugins-for-php-version-compatibility/

[jrfnl]

At the request of @jonathanbossenger, I'm leaving some feedback to the tutorial here. This feedback is not meant in any negative way. It is intended to help make the tutorial better.

Note: I've not watched the video, I've only read the article and my remarks focus on the "Automated compatibility testing using PHPCompatibility" section of the article.

Either way, here's some things I believe need fixing:

• I'm missing a mention of giving the Composer PHPCS plugin permission to run.
  Either running the below (before the require) or explicitly giving permission during the install is needed.

  composer config allow-plugins.dealerdirect/phpcodesniffer-composer-installer true

• it will check your code against the rules for the PHP version you specify.

  version => version(s)

• For Composer to work, you also need the CLI version of PHP installed on your system.

  There is no "CLI version of PHP", there is only PHP.
  Might be worth mentioning that the user should add the path to PHP to the operating system path ? and that where (Windows) / which (*nix) can be used to find out what the path is for both PHP as well as Composer.
  Especially as php -v and composer -v will not work unless those paths are in the system path.

• If you’re already using Composer for your plugin, you can skip this step.

  Suggestion: move this to above the info on running composer init.

• composer require --dev phpcompatibility/php-compatibility:"dev-develop"
  You’ll be installing the develop branch of PHPCompatibility tool, which at the time of creating this tutorial contains the latest version of the code.

  1. WP users should not be using PHPCompatibility. They should be using PHPCompatibilityWP, which takes the polyfills WP has in place into account to prevent false positives.
  2. I wonder if this will even install as the default minimum-stability is stable, while to use this it would need to be dev.

     composer config minimum-stability dev

  3. While PHPCompatibility 10 has not been released yet, using PHPCompatibilityWP with the dev version of PHPCompatibility is slightly more complex as you'll need to also add PHPCompatibility and alias the branch.

     composer require --dev phpcompatibility/phpcompatibility-wp:"^2.1" phpcompatibility/php-compatibility:"dev-develop as 9.99.99"

     VIP has a nice tutorial about this.

• Once version 10 of PHPCompatibility is released, you can leave out the specifying of the develop branch.

  Once PHPCompatibility 10 is out, the require for PHPCompatibility should be removed, so only PHPCompatibilityWP remains. That version constraint should then be updated to ^3.0.

• Then you need to require the WordPress coding standard rules for PHP_CodeSniffer:

  I have no clue what this has to do with anything, but WordPressCS is totally unrelated to PHPCompatibility and completely unnecessary for running PHPCompatibility.

• Once you’ve set up your dependencies, you’ll need to install them by running the following command:

  This is an unnecessary step as the composer require ... commands already install.

• In all run commands, it should use --standard=PHPCompatibilityWP not --standard=PHPCompatibility (as per the above comments).

• However, notice that the second array_key_exists error is not reported. This is because the PHPCompatibility tool is an open-source project that relies on contributions, based on the changes in PHP versions. At the time of recording this tutorial the array_key_exists removal has not yet been added.

  Actually, the reason the check has not been added is that it is neigh impossible to check via PHPCompatibility as we don't have access to the runtime type of variables, so we cannot determine whether $post is an array or an object.
  It is unlikely this check will ever be added to PHPCompatibility.

Other than that, but I know that's a biggie, I'm missing any mention of automated testing (vs manual testing) against all supported PHP versions using tooling like PHPUnit.

The combination of automated tests + PHPCompatibility should be able to catch nearly everything. Manual testing is likely to miss a lot.

Please let me know if you have questions about these points.

[jonathanbossenger]

Thank you for this feedback @jrfnl I am reopening this issue so that we can discuss the items you've detailed, and work towards improving the tutorial. I'll review your feedback this week, and get back to you with any questions I may have.

[jonathanbossenger]

@jrfnl before I reply to your specific points, I want to take the time to acknowledge the time taken to leave these notes and to thank you for your thorough review. I can't express how much I appreciate the technical feedback on my tutorials, especially given the fact that I know you do this voluntarily.

I'm missing a mention of giving the Composer PHPCS plugin permission to run.

Good spot, thank you. I actually do mention this in the tutorial video, but not in the associated article. I will amend this.

There is no "CLI version of PHP", there is only PHP.

You're not wrong, however, I'm struggling with two things here:

1. I'm somewhat limited in how long a tutorial can be. We try and keep tutorials between 5-10 minutes, and I'm already over the 10-minute mark with this one. This means sometimes I have to leave out some details, especially when it comes to software required on the user's machine to make something work.
2. What I'm trying to convey here (in one very short paragraph) is that PHP contains a CLI binary that allows one to run PHP scripts in the terminal (which many folks don't know) and that this means that PHP will need to be installed on the users machine, as opposed to whatever local development environment they may already be using, which might not install PHP on the users machine.

Perhaps I can convey this better, and change that sentence to this:

For Composer to work, you also need PHP installed on your computer, so that you can use the PHP CLI binary, which allows you to run PHP scripts in the terminal, instead of just in a browser.

Would you feel comfortable with that rephrasing?

Might be worth mentioning that the user should add the path to PHP to the operating system path ? and that where (Windows) / which (*nix) can be used to find out what the path is for both PHP as well as Composer.
Especially as php -v, and composer -v will not work unless those paths are in the system path.

I was hoping that the sentence linking to the installation instructions on the PHP website would suffice, but perhaps it might be sufficient to leave a note like this:

Once you install PHP, make sure to add the path to the PHP CLI binary to the operating system path of your computer 

Suggestion: move this to above the info on running composer init.

Noted

WP users should not be using PHPCompatibility. They should be using PHPCompatibilityWP,

Oh, wow. Today I learned about PHPCompatibilityWP! I had no idea this existed. I am probably going to need to update the rest of this tutorial to use this instead. Thank you for pointing this out.

I'm also noting that any other changes related to PHPCompatibility vs. PHPCompatibilityWP will also need to be amended, so I will take them into account, but not refer to them further here.

I have no clue what this has to do with anything, but WordPressCS is totally unrelated to PHPCompatibility and completely unnecessary for running PHPCompatibility.

It's been some time since my original research for this tutorial, but somewhere along the line, I got the impression this was required. This will probably change anyway now, given the above.

Actually, the reason the check has not been added is that it is neigh impossible to check via PHPCompatibility as we don't have access to the runtime type of variables, so we cannot determine whether $post is an array or an object.
It is unlikely this check will ever be added to PHPCompatibility.

Noted, thank you.

I'm missing any mention of automated testing (vs manual testing) against all supported PHP versions using tooling like PHPUnit.
The combination of automated tests + PHPCompatibility should be able to catch nearly everything. Manual testing is likely to miss a lot.

You're 100% correct. In preparation for this tutorial, I went back to when I interviewed you for the WPTavern post I wrote about PHP 8 back in 2020, and made a note about automated testing. Then, when it came time to prepare the tutorial, I realized that automated testing is a whole other tutorial in itself and that I would need to first create that.

I'm hoping to create a tutorial on automated testing in the near future, and once that's done come back to update this tutorial to include a section on automated testing, so that this tutorial is more rounded. For now, though, I hope that you'll agree with me that something on Learn WordPress about testing for compatibility is better than nothing at all.

[jrfnl]

@jonathanbossenger Happy to help.

There is no "CLI version of PHP", there is only PHP.

You're not wrong, however, I'm struggling with two things here:

1. I'm somewhat limited in how long a tutorial can be. We try and keep tutorials between 5-10 minutes, and I'm already over the 10-minute mark with this one. This means sometimes I have to leave out some details, especially when it comes to software required on the user's machine to make something work.

2. What I'm trying to convey here (in one very short paragraph) is that PHP contains a CLI binary that allows one to run PHP scripts in the terminal (which many folks don't know) and that this means that PHP will need to be installed on the users machine, as opposed to whatever local development environment they may already be using, which might not install PHP on the users machine.

The thing is, all of this will also work in typical local development environments with the PHP binary included in that environment.
For this tutorial, explaining the difference for the set up in a system local environment vs Docker/FlyWheel etc is out of scope IMO, but if someone is using such an environment, it's up to them to know the tools they are using.

Perhaps I can convey this better, and change that sentence to this:

For Composer to work, you also need PHP installed on your computer, so that you can use the PHP CLI binary, which allows you to run PHP scripts in the terminal, instead of just in a browser.

Would you feel comfortable with that rephrasing?

That definitely makes more sense to me.

I was hoping that the sentence linking to the installation instructions on the PHP website would suffice, but perhaps it might be sufficient to leave a note like this:

Once you install PHP, make sure to add the path to the PHP CLI binary to the operating system path of your computer 

You could maybe even use it to let people check if PHP is already installed as in that case it will already be in the path and they don't have to do a new install ;-)

WP users should not be using PHPCompatibility. They should be using PHPCompatibilityWP,

Oh, wow. Today I learned about PHPCompatibilityWP! I had no idea this existed. I am probably going to need to update the rest of this tutorial to use this instead. Thank you for pointing this out.

Oops... well, glad I pointed that out in that case ;-)

Note: WP Core itself is also using PHPCompatibilityWP.

You can see a list of the framework/CMS specific rulesets available in the readme of PHPCompatibility. The packages all "live" in the same GH organisation too.

Actually, the reason the check has not been added is that it is neigh impossible to check via PHPCompatibility as we don't have access to the runtime type of variables, so we cannot determine whether $post is an array or an object.
It is unlikely this check will ever be added to PHPCompatibility.

Noted, thank you.

Note: PHPStan could probably help with finding that particular issue. Going into that is something for another tutorial, I suppose. Maybe mentioning that all tooling has limitations and that PHPStan compliments PHPCompatibility well for variable type related issues might still be valuable ?

I'm missing any mention of automated testing (vs manual testing) against all supported PHP versions using tooling like PHPUnit.
The combination of automated tests + PHPCompatibility should be able to catch nearly everything. Manual testing is likely to miss a lot.

You're 100% correct. In preparation for this tutorial, I went back to when I interviewed you for the WPTavern post I wrote about PHP 8 back in 2020, and made a note about automated testing. Then, when it came time to prepare the tutorial, I realized that automated testing is a whole other tutorial in itself and that I would need to first create that.

I'm hoping to create a tutorial on automated testing in the near future, and once that's done come back to update this tutorial to include a section on automated testing, so that this tutorial is more rounded. For now, though, I hope that you'll agree with me that something on Learn WordPress about testing for compatibility is better than nothing at all.

Well, you could create anticipation for that future tutorial by a mention in this one ?

Maybe something along the lines of the below ?
"Better yet than manual testing, you can automate most tests and this will allow you to continuously safeguard your code both against bugs as well as for PHP compatibility issues, but that's for another tutorial...."

[jonathanbossenger]

You could maybe even use it to let people check if PHP is already installed as in that case it will already be in the path and they don't have to do a new install ;-)

That's a great idea, thanks

You can see a list of the framework/CMS specific rulesets available in the readme of PHPCompatibility. The packages all "live" in the same GH organisation too.

Thank you.

Well, you could create anticipation for that future tutorial by a mention in this one ?

That is a great idea, I will do so.

Thank you again @jrfnl for your valuable feedback. I'll be working on updating the article and re-recording the tutorial. I'll add this to my list for my batch of October tutorial work.

I will post the updated article in Markdown format here once it's ready, and if you have time to review the updated version, that would be great, but I also appreciate that you have other, more important things to work on.

[jonathanbossenger]

@jrfnl as mentioned, I have completed the second draft of the tutorial, to include the changes we've discussed here.

https://github.com/jonathanbossenger/wp-content/blob/main/tutorials/php-version-compatibility-testing.md

I know you are busy, but when/if you have some time, I would appreciate it if you could read through the new version, and let me know if you have any further feedback.

With it being hosted on a public Github repo, if you'd prefer to simply suggest changes via a PR, I welcome that as well.

Once again, I thank you greatly for your input, I really appreciate having such direct access to your vast knowledge of PHP compatibility testing, and I've enjoyed collaborating with you on this tutorial.

[Greennc]

WP 6.4 WordPress/gutenberg#52982 Bump plugin minimum supported PHP version to 7.0 https://make.wordpress.org/core/2023/08/10/whats-new-in-gutenberg-16-4-9-august/#minimum-supported-php-version-bumped-to-7-0

[jonathanbossenger]

Hi @Greennc could I check, if was there a specific addition to the tutorial that you were suggesting to include, related to the minimum version? I do mention that currently WordPress requires PHP version 7.4.

[jrfnl]

requires PHP version 7.4.

I presume you meant to say "recommends" ?

[jonathanbossenger]

Yeah, that's a good point.

[jrfnl]

I know you are busy, but when/if you have some time, I would appreciate it if you could read through the new version, and let me know if you have any further feedback.

Thank you for all your work on this @jonathanbossenger ! I've gone through the new version. Please find my feedback/remarks below.

---

Introduction

Only plugins or does the info in the tutorial also apply to themes containing PHP code ?

While WordPress has a specific minimum requirement for PHP, older PHP versions will eventually reach end of life by the PHP developers, and will not receive any security updates in the near future.

☝️ This is mostly a grammar thing, but it is also incorrect. A package can "reach end of life" or be "marked end of life by...". If the latter, it would be by the "developers of the PHP language" (which is written in C, so these are not necessarily PHP developers).

the current version of PHP required to run WordPress is 7.4

Suggestion: the current minimum PHP version to run WordPress is 7.0, with PHP 7.4 or higher being recommended.

WordPress core itself is considered compatible with PHP 8.0, and the WordPress core team is working on making WordPress compatible with PHP 8.1 and PHP 8.2. However, they cannot guarantee that all plugins will be compatible with current or future versions of PHP.

WP is currently considered compatible (with select explicit exceptions) with PHP 8.0 and PHP 8.1.
WP is currently beta-compatible with PHP 8.2 and with the upcoming PHP 8.3 release.

At the time of this recording, all PHP 7.x versions or end of life,

or => ++are++

For example, the Migrating from PHP 7.4.x to PHP 8.0.x guide lists all the changes between PHP 7.4 and PHP 8.0.

Suggestion: "...lists the most important changes..." or just "...lists the changes..." (for all the changes, you'd need to go through the UPGRADING.md file of a release + the NEWS.md file and even those don't contain all the info).

Code sample...

May I recommend to run the code through WPCS and make sure that it complies with the WP Coding Standards ? (lead by example principle) It mostly does, but not completely by the looks of it.

add the WP_DEBUG_LOG constant and set it to tru,

tru => ++true++

composer -v

It is actually composer -V or composer --version. Lowercase -v is for verbose not version.

Once this is done, you will have a package.json file, which is the file Composer uses to manage your project dependencies.

Eh... no, once this is done, you will have a composer.json file. package.json is used in JS projects, not PHP projects.

composer require --dev dealerdirect/phpcodesniffer-composer-installer:"^0.7"

Please change the version constraint to "^1.0". The 1.0 version was released earlier this year.

composer require --dev phpcompatibility/phpcompatibility-wp:"*"

This is called using the "death-star", which is generally seen as a bad idea as it will allow for unmanaged upgrades to a new major release, which could, and more often than not does, break (CI) builds.

Better to set this to "^2.1 || ^3.0". This should set people up for the latest release, but will allow for the PHPCompatibility 10 release (once available via PHPCompatibilityWP 3.0).

This is where automating your manual tests would come in handy, as the if you ran the tests in a new PHP environment, the tests would fail, altering you to a possible problem. And with logging enabled, you'd see the error logged to the log file.

Suggestions: ... as when you'd run the tests... + ... the tests would fail, alerting you ...

---

Once again, I thank you greatly for your input, I really appreciate having such direct access to your vast knowledge of PHP compatibility testing, and I've enjoyed collaborating with you on this tutorial.

Indeed and please know that I really appreciate you creating tutorials like this one and unlocking access to tooling like this to a wider group of developers, as it will ultimately benefit the end-users a great deal!

[jonathanbossenger]

Thank you so much @jrfnl for taking the time to review, I greatly appreciate your feedback.

Eh... no, once this is done, you will have a composer.json file. package.json is used in JS projects, not PHP projects.

Whoops! I think I might be spending too much time in npm land 😅

[hellofromtonya]

the current version of PHP required to run WordPress is 7.4

Suggestion: the current minimum PHP version to run WordPress is 7.0, with PHP 7.4 or higher being recommended.

I 100% agree with @jrfnl to change the wording of that sentence as it's misleading and incorrect. PHP 7.4 is not "required" for WordPress. Rather, the minimum PHP version WordPress supports is PHP 7.0.

[justlevine]

Something else to consider
From the introduction it seems as if the purpose is upgrading compatibility, but PHPCompatibilityWP is a tool to help with backwards compatibility. If you set your ruleset to PHP 7.4, and run it on PHP 8.0, you're not going to get warnings about PHP 8.1 or PHP 8.2 issues.

In lieu of rewriting around a premise of b/c, it might make sense to have an explicit call-out that you want to set PHPCompatibilityWP to the lowest supported version, but you should still run your env on the highest (or CI or whatever).
For similar reasons, I +1 @jrfnl 's suggestion to have a callout to phpstan-wordpress to catch the errors PHPCompatibilityWP (and PHPCS as a whole ) miss, even if it's just as a caveat in a linkdump at the bottom.

[jonathanbossenger]

Hello @jrfnl, after a short break (work trip and some leave) I have been able to implement your suggested changes, thank you.

I will probably record the final tutorial video in the coming weeks, and work to have it updated on Learn WordPress before the end of the month.

One question regarding the phpcompatibility/phpcompatibility-wp version set when installing via Composer, should this also be updated in the Installation instructions on the repository readme?

The main reason I ask is that whenever I prepare tutorials, I tend to refer to any specific documentation for installation instructions, and it would be ideal if the tutorial instructions matched the readme/documentation.

Happy to create this PR if indeed this should be changed.

[jrfnl]

Hello @jrfnl, after a short break (work trip and some leave) I have been able to implement your suggested changes, thank you.

I will probably record the final tutorial video in the coming weeks, and work to have it updated on Learn WordPress before the end of the month.

@jonathanbossenger Hope you had a nice break! I look forward to seeing/reading the new version.

One question regarding the phpcompatibility/phpcompatibility-wp version set when installing via Composer, should this also be updated in the Installation instructions on the repository readme?

The main reason I ask is that whenever I prepare tutorials, I tend to refer to any specific documentation for installation instructions, and it would be ideal if the tutorial instructions matched the readme/documentation.

Happy to create this PR if indeed this should be changed.

I'm inclined to say "no" as the installation instructions as per the README are the official ones for tagged releases and are correct for that.

The "temporary" instructions are literally just that: temporary and should only be used while PHPCompatibility 10.0.0 has not been released yet. As soon as 10.0.0 comes out, people should revert back to using the official install instructions and not doing so will cause problems.

In that respect, it might even be better to use the official instructions in the video (though a scan will then barely show anything PHP 8.x related) and to just mention that if someone wants to use "bleeding edge" PHPCompatibility , which includes a lot of checks related to PHP 8.x, that people can find instructions on how to do that in the pinned issue.

[jrfnl]

(or was your question about the install instructions not about the use of PHPCompatibility 10 ?)

[jonathanbossenger]

Sorry if this wasn't clear. My question was specifically related to your suggestion when requiring/installing PHPCompatibilityWP:

Better to set this to "^2.1 || ^3.0". This should set people up for the latest release, but will allow for the PHPCompatibility 10 release (once available via PHPCompatibilityWP 3.0).

So

composer require --dev phpcompatibility/phpcompatibility-wp:"^2.1 || ^3.0"

instead of

composer require --dev phpcompatibility/phpcompatibility-wp:"*"

In the readme in the PHPCompatibilityWP repo under Installation instructions it indicates the second option.

[jrfnl]

Correct. The README in the PHPCompatibilityWP repo will be updated to say composer require --dev phpcompatibility/phpcompatibility-wp:"^3.0" as soon as 3.0 comes out as PHPCompatibility 10 contains breaking changes which affect the repo.

[jonathanbossenger]

Ok, got it, thanks.

In order to publish the tutorial before 3.0 is released, but to keep it as updated as possible, I will include the suggested installation instructions, and make a note that the current installation instructions will change when 3.0 is released.

[jonathanbossenger]

@jrfnl I have an alternative suggestion regarding installation instructions and versions.

Ultimately my goal is to create content that is both technically correct, as well as "evergreen". However I appreciate this is often not possible, but I'd like to try and reduce too many future updates to this content in the near future. How does this sound as a compromise:

Keep the installation instructions in the tutorial in line with the instructions in the readme

composer require --dev dealerdirect/phpcodesniffer-composer-installer:"^1.0" 
composer require --dev phpcompatibility/phpcompatibility-wp:"*"

Then, include a note that it's generally considered a good idea to specify a specific version, to prevent unmanaged upgrades to a new major release, and to specify a version for PHPCompatibilityWP, using the current stable version

composer require --dev phpcompatibility/phpcompatibility-wp:"^2.1"

After that, update the section on PHPCompatibility and PHPCompatibilityWP versions, as follows (see next comment):

[jonathanbossenger]

A note on PHPCompatibility and PHPCompatibilityWP versions.

Currently, the stable release of PHPCompatibility is 9.3.5, and the most recent sniffs are part of the upcoming version 10.0.0. release. The current stable version of PHPCompatibilityWP is 2.1.4

When version 10.0 of PHPCompatibility is released, version 3.0 of PHPCompatibilityWP will be released, which will depend on PHPCompatibility version 10.0.

In the meantime, it is possible to install the dev-develop branch of PHPCompatibility to run PHPCS with the cutting-edge additions of PHP 8 sniffs before their release in version 10.0.0 of PHPCompatibility as detailed in this WordPress VIP documentation.

To do this, run the following commands to alias the dev-develop branch of PHPCompatibility:

composer config minimum-stability dev
composer require --dev phpcompatibility/phpcompatibility-wp:"^2.1"
composer require --dev phpcompatibility/php-compatibility:"dev-develop as 9.99.99"

These commands will alias the develop branch of PHPCompatibility to a 9.x version which is within the allowed range for PHPCompatibility, and set PHPCompatibilityWP to install the latest stable 2.1 version.

Once PHPCompatibility 10 and PHPCompatibilityWP 3 are released, it should be possible to update the PHPCompatibilityWP version constraint to "^3.0", which will depend on version 10 of PHPCompatibility.

[jonathanbossenger]

The goal here is to allow for an easy update to both the text and the video once PHPCompatibility 10 and PHPCompatibilityWP are released, as I can just delete the section on PHPCompatibility and PHPCompatibilityWP versions, and update the installation instructions to match the updated instructions from the project readme.

[justlevine]

Then, include a note that it's generally considered a good idea to specify a specific version, to prevent unmanaged upgrades to a new major release, and to specify a version for PHPCompatibilityWP, using the current stable version

@jonathanbossenger I'm a layperson here (not even that compared to @jrfnl) , but I always understood this principle to be about avoiding using * as a version constraint, and not about calling composer require ... without any version, which will just set composer.json to use the latest semver compatible version at the time the call.

Meaning if you use composer require --dev phpcompatibility/phpcompatibility-wp as your "evergreen" command, you'll still get `"phpcompatibility/phpcompatibility-wp: "^2.1.4", but if you run the same command in a few months (🤞), you'll get "^3.0.0" (both with the correct versions of PHPCompatibility, and both semver protected against an unwanted release ). And then your PHPComptatibility 10 note can be additive to the evergreen instructions instead of a temporary alternative.

[jonathanbossenger]

@jrfnl is there any specific reason not to simply exclude the "*" as @justlevine has suggested?

I try as much as possible to follow any software/dependancy-specific installation instructions in my tutorials, to avoid confusion from learning from the content ("why do you say do x when the docs say do y").

[jonathanbossenger]

Hi @jrfnl I hope you don't mind the ping, I just wanted to check if you agree the above suggestion is a good way forward.

[jonathanbossenger]

The updated version of this has been published: https://learn.wordpress.org/tutorial/testing-your-products-for-php-version-compatibility/

Thanks to everyone for their input.

Please feel free to reopen this issue if there are any other suggested changes.