Plugin and Theme Requirements Check

[dancameron]

A simple way for plugin authors to require certain version of WordPress, PHP and MySQL.

/*
Plugin Name: Hello Dolly
...
WP Requirement: 3.9
PHP Requirement: 5.3
MySQL Requirement: 5.0
*/

[dancameron]

Requirements check in activate_plugin().

[jeremyfelt]

#26925 was marked as a duplicate.

[cfoellmann]

Additional core plugin headers for compatibility filtering on plugin.php.
Fully optional like Network: True

Headers:

$plugin_data['Core'] // The minimum WordPress version required.
$plugin_data['PHP'] // The minimal PHP version required.

Additional view on plugins.php:

plugins.php?plugin_status=incompatible // listing all incompatible plugins (removed from ?plugin_status=all)

DONE:

ADDED headers: Core, PHP, Multisite
ADDED checks for headers values: is_plugin_compatible() + separate checks for the three single headers
ADDED view "incompatible" to plugins.php
UNSET incompatible plugins from view "all"
ADDED option to "Delete" plugin on view "incompatible"

TODO:

ADD function to remove incompatible plugins from mu-plugins loading
ADD display of compatibility issues details for each single plugin

Direct checkout: ​​https://github.com/cfoellmann/WordPress/tree/headers
Patch(es): Attached

[dancameron]

I can help with the TODOs if you're not already working on them.

I do believe there should be a check on activation, similar to my original patch; since I assume plugin/theme uploads (including those installs downloads from .org) would not be checked otherwise with your current patch. A compatibility check should also be thrown into the plugin-install.php table list too.

[cfoellmann]

@dancameron sure, would be nice to combine our efforts.
You are right. I have no check onActivation in it which needs to be in.

Have a look at the GitHub repo. We can fiddle around there. I added you to the repo.

I would love to get everyones input on
1) Core check: Yes/No
2) PHP check: Yes/No
3) MySQL check: Yes/No

so we know how far we need to go with this.

[cfoellmann]

Another possible extension of the ticket could be this idea from #24744:

Network: false => Prevent "Network activate"

[nacin]

I don't think any of these are material for core. If a plugin needs to not load itself on certain versions, it already has the tools needed to do so. Annotations are not really good for enforcing what can easily be done in code. I also don't like the idea of core making it any easier to so easily disregard large swaths of the user base.

[dancameron]

@nacin I'm not sure how you labels here are used but I'd like to see a discussion before the ticket is closed for good. This addition should mean more than a plugin/theme enhancement to the core developers, my idea (1) is that it can be used by the core development team to improve compatibility requirement adoption.

For example, 2015 (Theme) and/or next version of bbPress (since they're popular) can set a PHP requirement above the current PHP requirement; the official messaging will link to a codex article about the requirements and help provide resources.

IMO: Without proper messaging (and official utility) "large swaths" of the user base are simply ignored until the hypothetical day when the group size dwindles and WP can update the requirements, even then a subset of those users are stuck because no initiative was made to inform and persuade before the change.

If core doesn't want to help persuade users than core should better facilitate plugin/theme developers making the effort. Otherwise we're stuck with throwing notices after activation, all of which are different, providing a poor UX.

With all of that said I don't want to get into a "what version of PHP should WP support" discussion, my intention is to argue that core should be proactive to move the percentages regardless if the initiative above is used within core or it's plugin/theme developer community.

If you disagree with the intent above, or the method, and argument can still be made that the user experience for installing a theme/plugin that isn't compatible should be improved. The user should know if the plugin/theme is going to be compatible before they click "install" from the admin (and it's downloaded, activated and a notice is thrown); it's as if the plugin/theme developer is fooling them the way it is now. This was one of the UIs that I was planning next.

(1) ​http://planetozh.com/blog/2014/01/why-wordpress-should-drop-php-5-2/?cp=1

[SergeyBiryukov]

Related: #12260, #23880, #24271.

[Kopepasah]

Replying to nacin:

I don't think any of these are material for core. If a plugin needs to not load itself on certain versions, it already has the tools needed to do so. Annotations are not really good for enforcing what can easily be done in code. I also don't like the idea of core making it any easier to so easily disregard large swaths of the user base.

Although I do agree that checks for PHP and MySQL are not a good idea for core, I think there are some real benefits to having compatibility checks for plugins and themes. While there may be cases for users having issues with incompatible versions of PHP & MySQL (as most cannot update or change versions), checks for WordPress version will most likely encourage users to update WordPress (which is good for everyone).

See #28574 for more information on my idea.

[DrewAPicture]

Based on feedback from @nacin in comment:8, closing as wontfix.

Tickets do not need to remain open for discussion to continue, however, so please feel free to continue the conversation.

[strider72]

I too would like to see this. Even accounting for plugin authors' ability to deactivate if not compatible, it makes a lot of sense that users know if they can use a plugin before they install and activate it.

[ocean90]

#36826 was marked as a duplicate.

[WraithKenny]

#40934 for a similar, but blessed ticket.