Compatibility checker

[schlessera]

From Slack:

schlessera: As for the compat checker, there's this one: https://wordpress.org/plugins/php-compatibility-checker/ They also maintain a whitelist of plugins with false positives: https://github.com/wpengine/phpcompat/wiki/Results (edited) garyj: The plugin is a wrapper for https://github.com/wimg/PHPCompatibility (edited) schlessera: We could either collaborate with them, or use our own version of the same library. nerrad: Is the text for this section dependent on us having a suitable tool for site owners to use? techjewel: I think we can use the original library nerrad: Or is the tool something we can work on/implement as we iterate? schlessera: Ideally, we'd have proper tools and solutions to offer. Also, we need to make sure we don't include a lot of vendor bias in that text as a result. As an example, the plugin from WPEngine works as expected. However, pointing people from all other hosts to a tool by WPEngine is problematic, to say the least. techjewel: Yah, we should not promote any specific host company nerrad: Personally I don’t think its problematic if the tool itself is a suitable option and there are no others. flixos90: I think we should use the library in a custom plugin, not the WPE one. WordPress shouldn't be endorsing any host here I'd say. techjewel: Exactly nerrad: I don’t see it as WP endorsing a host. If you had to go to the hosts site to get access to the tool, yes. schlessera: The plugin contains stuff like this, unfortunately. [picture of sales funnel link] But many people will. jpry: @U02RQP19R I don't see it that way either. But other people potentially could see it that way nerrad: k now that is stuff which makes it not suitable to me. a key word is suitability and if there’s marketing all over it then its not suitable. schlessera: WPEngine has really done a great job on the plugin, and they even sponsored work on the library, but we cannot use tools with ads like these if we point people from other hosts to them. nerrad: That I can agree with. I just wanted to make sure we weren’t just discarding a tool because its provided by a host. flixos90: Of course it's GPL anyway, so let's keep in mind that we can just use it and strip away its commercial parts. Then give it a solid neutral name. schlessera: Or discuss with WPEngine to tone down the advertising. flixos90: We should definitely thank WP Engine for that still. techjewel: In that case, I think we can just make a plugin using the library (edited) flixos90: I still think just the affiliation with WPE would be inappropriate here. techjewel: agreed with @flixos90 schlessera: I personally would not see an issue with the tool if there was a small message somewhwere stating that the plugin was provided/sponsored by WPEngine. But as it is right now, it is part of their sales funnel. flixos90: We will need to run this by the lead devs anyway, so they'll end up making the decision whether going with the WPE one is acceptable or not. It's mostly a political discussion we shouldn't spend more time on. :slightly_smiling_face: joostdevalk: sorry busy with other stuff but just want to jump in and say I'll mention this to David Vogelpohl at WPE, I'm guessing they'd be willing to talk about this, especially as Matt is also an investor in WPE flixos90: Great, thanks @joostdevalk! schlessera: @joostdevalk Oh, I already contacted Jason Cohen about it. Is David Vogelpohl the one who makes that call? joostdevalk: don't think so but jason is also a fine contact :smile: pushing from multiple sides will always help

[joyously]

I think using the PHP Compatibility Checker provides very good information about which plugins might have problems, however, the target reader of this page is a site owner, and they won't know what they are looking at. I ran it on several sites in July, and posted plugin support tickets for those plugins with errors reported. Some of the responses from developers were as if they were not programmers! Most have not responded, or fixed their plugins, and one denied there was a problem (it was buried in a library and would not be encountered much). Others claim the errors are not real because they are coded for older versions and that code only runs on older versions (false positives).

So, perhaps the recommendation could be to run the checker and for those plugins with errors, find a replacement plugin. Asking the plugin author might not get them anywhere.

[schlessera]

Yes, the compatibility checker does indeed produce a lot of false positives. That's why we cannot just recommend to move away from the tested plugins, as they might be perfectly fine.

Maybe we should collect a whitelist of plugins with minimum versions that are known to be good. If we do this for the most popular plugins, we could already provide guidance on these.

[Mte90]

About compatibility checker as example there is the Mozilla abandon of the old API for extensions on Firefox 57. They chosen to disable as mandatory all the previous extensions that use the previous SDK and created a little page (https://mozilla.github.io/extension-finder/) to search for old extension and suggests alternative but this list contain less 25 extension and track all the extensions ins not so very easy. Maintain also a page for that can be a difficult job because there are too many plugins and how we can suggest an alternative instead another one?

Probably is better to leave to the user that step so in that we can work on other stuff like evaluate if add an alert for old plugins inside wordpress like to alert that plugin is not receiving updates in the last 2 year with the check in the Readme header of the php version parameter.

[nerrad]

Maybe we should collect a whitelist of plugins with minimum versions that are known to be good. If we do this for the most popular plugins, we could already provide guidance on these.

I really like this idea and I think that's something that could be actively promoted by the wp.org plugins team (maybe announce the list via email/blog post). Plugin authors can submit their plugin to be included on the list of plugins known to be compatible with PHP7. It could also be something we invite site owners to bug the developer of their plugin about if any of the plugins on their site aren't on that list.

OR, we could ask the meta team to add another readme.txt option for simply indicating compatibility with the PHP 7 branch of PHP. I do agree that a "tested up to" flag is not a good idea because it can get stale. But a "Compatible with PHP 7" flag has less risk of being stale and is a metric that could be automatically searched against for some generated list to help site owners determine if they have any plugins that are compatible.

[grappler]

@schlessera I would just like to mention that PHP Compatibility Checker is running an older version of PHPCompatibility. Some of the false positives are fixed in the newer versions. Though running plugins through the PHPCompatibility sniffs is a good start.

[joyously]

If the compatibility checker was run when SVN makes the plugin zip file, it could save the boolean value for PHP 7 compatibility somewhere that can then be used for suggestions. So instead of being in the readme, depending on the developer to populate it, it would be current for every commit of code. But that is only one breakpoint of versions. It's probably the most important one, however.

[schlessera]

Quick update on the WPEngine PHP Compatibility Checker plugin:

I had a brief chat with Jason Cohen of WPEngine, and he will discuss this internally with his team. Nothing's been decided yet, but he wanted to know whether, generally, we'd be okay with recommending the plugin in this context if it was changed from a "hard sell" to a more toned-down message basically stating "created for the community by WP Engine".

What do others think? Is this worth pursuing further, to allow us to have a tested plugin in collaboration with WPEngine? It would avoid the need to create an additional plugin, which will just create duplicate work and confusion.

[JDGrimes]

Personally, I'm comfortable suggesting the plugin.

However, the plugin appears to be using PHPCompatibility 7.0.x, whereas the latest version is 8.0.1. Unfortunately though, 8.0+ doesn't support PHP 5.2, so updating to that wouldn't be possible (yet at least). It could be updated to 7.1.x though, I think. Are there plans to do this?

The fact that we can't really use 8.0+ means that we don't get full support for checking for issues related to PHP 7.2, but perhaps that isn't really important.

I also happened to notice that WPEngine doesn't appear to be active in the plugin's support forums. Which is their prerogative, of course, but it might be worth considering that whatever we suggest is likely going to get quite a lot of support activity, that ought to be monitored by somebody.

[grappler]

It depends on how much they are willing to work on it. As in the past there has not been much work on it.

I have built a similar plugin previously for the theme review team. I will be looking to work on it again soon. Now that PHPCS 3.0 has been released I can write the code differently.

This is the plugin if you are interested. https://github.com/WPTRT/theme-sniffer

It also includes the PHP compatibility as that is important for the Theme developers too.

But I am not sure if recommending the Theme Review plugin would be right as the content would be different depending on the user. Though we could think about having one codebase but two plugins.

The biggest difficulty I think in such a plugin is the running out of memory for certain files.

[schlessera]

@grappler If the plugin uses PHPCS 3.0, we cannot use it for our specific needs because that requires PHP 5.4. We're currently looking for targeting PHP 5.2 sites as a priority.

[danielbachhuber]

One implementation detail to suggest: even if a site requires PHP 5.2 (because of unknown ability to upgrade), PHPCS could be run (and even installed) using the executable for a higher PHP version.

[JDGrimes]

@danielbachhuber true, if a PHP executable is available or can be installed. Since you are familiar with hosting, maybe you have an idea on how often that would actually be the case. I would figure maybe not very often, but I guess I really don't know much about it.

[danielbachhuber]

In a shared hosting environment, it's more likely than not (based on my limited observations) that there are multiple PHP executables installed on the system.

Another hypothesis: sites still running PHP 5.2 probably won't use the PHP compatibility checker (because they're likely abandoned anyway).

[felixarntz]

@danielbachhuber

Another hypothesis: sites still running PHP 5.2 probably won't use the PHP compatibility checker (because they're likely abandoned anyway).

I generally agree, but since this is all part of an effort of WordPress core going into that direction, the idea is that core throws a notice at you when you wanna install a plugin that doesn't work with your setup. This notice would lead you to the information page we're working on, and in turn to the PHP compatibility checker.

[Mte90]

I agree with @felixarntz, hostign can have different way for multiple php version and other so maybe is a dangerous zone for that. We can implement maybe two version of phpcs one for php 5.2 and for the php 5.3+ and based on php version run the right one.

[schlessera]

In a shared hosting environment, it's more likely than not (based on my limited observations) that there are multiple PHP executables installed on the system.

The main problem with this is that there is no obvious way for PHP code to request a different version. From the perspective of the end-user, that's still a technical hurdle that is probably impossible to surmount.