Plugin compatibility info on upgrade page (improvement to r12407)

[Denis-de-Bernardy]

r12407 lets one use the newly introduced compatibility array. There should be an additional case, before the other two, where the plugin explicitly declares itself as compatible with the new version of WP.

[Denis-de-Bernardy]

I think we should also stick to using the major version of WP, e.g. WP 2.9 is equally good for WP 2.9, WP 2.9.1, etc. With rare exceptions, the chances that a plugin is compatible for WP X.Y but not WP X.Y.1 are about (should be about, anyway) zero.

[dd32]

Please include descriptive titles in future.

[Denis-de-Bernardy]

Adding to this, some users declare a plugin as not working when it really is but they're running into bugs due to third party plugins -- or simply because they're not managing to use it, or it's not working at all. And there could potentially be cases where whatever pending issues there are got fixed.

We should expect the plugin's author to know better than the users of the plugin, if he took the trouble to declare his plugin as compatible.

[TobiasBg]

I agree, if a plugin author explictly says that a plugin compatible to WP X.Y, then it is. Otherwise, users with little knowledge (maybe they just couldn't find a setting, or expected something from the plugin which it can't do or doesn't provide) could maybe stop others from upgrading, which would be really stupid. I also agree that sticking to major versions X.Y instead of X.Y.Z is enough. As far as I understand it from comments from core devs, .Z releases are for major bugfixes and security issues. And those usually don't break a plugin. And if they do, it probably was the plugin's fault anyway.

[Denis-de-Bernardy]

same patch, sticking to major versions

[Denis-de-Bernardy]

two untested patches attached. sample plugin for testing:

​http://wordpress.org/extend/plugins/sem-fancy-excerpt/

[TobiasBg]

Of course Denis was 38 seconds faster than me with that reason :-)

In addition to your first patch, I suggest adding something like "from the community" to the string

'Compatibility with WordPress %1$s: %2$d%% (%3$d "works" votes out of %4$d total)'

so that the difference between "said so by the author" and "voted by the community" is more clear. Otherwise an average user doesn't know, where those votes come from.

But I guess, since strings were already frozen, it is too late for this patch anyway?

[westi]

I don't think we should put too much emphasis on the Tested field - in the long run I think that should go away anyway as it just causes needless svn updates of plugins by authors just to mark them as tested.

I would much rather we just focused on the compatibility information and encouraging the community to mark a plugin as compatible/not compatible so that we can benefit from the wisdom of the crowd.

If we are going to limit the compatibility checks to major versions then we should do that at the collection point or at least on api.wp.org before we return the info.

I think it would be better to keep the detailed specificity that we have at the moment and see how it pans out - hopefully going forward we can keep a tighter lid on the contents of point releases and then we will be able to change this to work on major versions.

For now I think we should get the feature out for people to use and garner some feedback.

[markjaquith]

As a plugin author, I'd be very unhappy if my Tested line were ignored completely.

[ryan]

I'd go with the first patch. On the api.wp.org side, we can return 2.9.1 (if latest WP release is 2.9.1) if the plugin has 2.9 set. If 2.9.2 introduces security updates that could break some plugins, for example, we'd have the option on api.wp.org of not auto bumping plugins that have 2.9.1 or earlier set.

[ryan]

(In [12413]) Consult the tested field when checking plugin compatibility. Props Denis-de-Bernardy. fixes #11450