Feature Request: Show Plugin Compatibility

+1

@bdaley When you use the same office and sit next to @bkelleher and “+1” (which isn’t useful per se) you set off moderator flags. ??

For some reason I can’t see the image from where I’m at so I’ll just wing it.

At this time, the WP administrator should be on the newest core version, and should be shown some indicators next to plugins that have available updates,

That already exists: the WordPress core notification is different on the dashboard than plugins and themes.

whether they are compatible or not.

Everything should be compatible and I do not thing the burden of that compatibility check should be on WordPress. It should be on every plugin and theme author.

The information is available for plugins hosted on www.ads-software.com, and shouldn’t be difficult to retrieve.

It isn’t exactly. That’s a label that the authors update when they’re diligent.

When you update a plugin you do get a note about if it’s tested with your version or not and if it’s not then you may not want to update the plugin. But when core is updated, your existing plugins may not have that label updated. So a plugin may be listed as 4.6.1 compatible it’s not listed as 4.7 compatible. Despite plugin authors getting emails saying “Please test with 4.7 and update as needed”.

I don’t think the core updater should make that sort of notification or check but I do see that there would be some people who would want that. Someone should instead write a plugin that does the following.

1. Check for core updates.
2. Check if installed plugins and themes are listed as compatible.
3. Inform the user of the not listed as compatible plugins and their www.ads-software.com URLs.
4. Ask the user what to do next.

That’d be a “pre-core-update-check-versions-of-themes-and-plugins” checker. Catchy title. ?? But definitely a plugin.

Interesting that you are so concerned with a moderator flag on a comment like that, if he agrees with the request, does it matter where he sits?

Here’s the image again, sorry for the restricted access:
https://www.dropbox.com/s/pwovir1r62zu6de/Screenshot%202017-01-06%2010.04.22.png?dl=0

To say that everything “should” be compatible is a very dangerous mentality, especially for a platform as large as WordPress, running (supposedly) 10% of the internet. This is not to say that WordPress prevents you from installing or updating a plugin that is not compatible or has not been given enough information to be deemed so, but some better UI indicator that that might be the case might help those who manage 200+ WP sites to quickly identify that they should not proceed with all of the updates.

Lets take W3 Total Cache, the plugin that made me write this post. For those who have used it, W3TC is an enormous plugin that has a ton of functionality. According to www.ads-software.com, it has over 1+million active installs. It is not the burden of WordPress to make sure this plugin is compatible at the time of beta/production launch of the next version (4.7), however the moment 4.7 is released, 1+million sites that WILL break with a core update. Yes, the responsibility is on the plugin authors to fix any incompatibilities since the time 4.7 was announced, but that is not always feasible for a plugin of this size. 4.7 was announced mid October, and released early December, giving less than 2 months for compatibility testing and fixes. It is likely all plugin/theme authors have other responsibilities and might not be able to fix or even identify all bugs/incompatibilities, especially with large plugins. Now, when early Dec. comes around and 4.7 is released, all of those sites will break. It is unrealistic to believe that 1+million people will avoid updating to 4.7 on a whim that they have researched every plugin they use to make sure it is compatible.

The information is generated by the WP community, not the authors, in terms of compatibility feedback. It relies on users to say it is broken, and in this case, www.ads-software.com was fully aware of this broken compatibility. In the WordPress backend, most people read “Compatible up to: 4.6.1” and “Last Updated: 3 months ago” to be a generally modern and recent plugin that should work, but it might not. Hell, some of the best plugins have compatibility up to 3.2 and get the job done fine today.

I could see this functionality being built into a plugin, but the idea of it being shoved in a plugin sort of goes against the principle it is seeking to aid/solve. A simple compat check between plugin versions and core versions on the updates and plugins pages with a small badge to flag anything certainly incompatible, and perhaps a warning before proceeding seems like a useful enough feature to include in core, something that could prevent possibly millions of users of extremely popular plugins from accidently breaking their sites. Just take a look at how many forum posts are out there trying to figure out how to get back into the admin panel/deleting/disabling plugins through the DB/FTP, or another access method. You are right though, not every request of this nature should be included in core, it just seems like this is a relatively easy feature for the tradeoff of possibly hundreds/thousands/millions of sites not accidently breaking on a plugin/core update.

Interesting that you are so concerned with a moderator flag on a comment like that, if he agrees with the request, does it matter where he sits?

It’s an occupational hazard for me and I am a forum moderator. Fake accounts happen way too often here and I mentioned that just as a point of interest.

It’s not an accusation and I hope you don’t take it that way. If it were an accusation then I would not have replied.

To say that everything “should” be compatible is a very dangerous mentality

How’s that? Don’t you think a platform being held hostage to *looks* to 48,413 plugins a much bigger source of stagnation? There are a lot of stale plugins in the repository.

Like many here I have been using WordPress for years. I’ve never had any problems with any theme or plugin related to a WordPress version upgrade. That’s not luck, that’s just how it is for many users.

Yes, the plugin you’ve mentioned is a problem and many people do use that one. That really is an isolated case as most plugins aren’t that deep into your installation.

The information is generated by the WP community, not the authors, in terms of compatibility feedback.

Sadly, it also means that data is unreliable. From a practical point of view users are not into QA process. If a user reports a plugin as not working, is that because of a WordPress core version? Or is it because of the user’s environment such a conflicting plugin or theme? Or is the user running a version of PHP that the plugin developer didn’t take into account?

That does not invalidate that data the users provided it just means using it in that way is unreliable. It’s just another component of user feedback for that plugin like the reviews are.

I could see this functionality being built into a plugin, but the idea of it being shoved in a plugin sort of goes against the principle it is seeking to aid/solve.

I’m on the Support team and I do not have any special insight into the Core development process.

The reason I proposed a plugin is because that is the first step in making a case for a feature to be included into WordPress. If it solves a problem for enough of the user base then that may be considered by the Core team.