WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 3 years ago

Last modified 7 months ago

#26909 closed enhancement (wontfix)

Plugin and Theme Requirements Check

Reported by: dancameron Owned by:
Milestone: Priority: normal
Severity: trivial Version: 3.8
Component: Plugins Keywords: has-patch
Focuses: Cc:

Description

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
*/


Attachments (2)

patch_commit_8d334f227fb2.patch (4.1 KB) - added by dancameron 4 years ago.
Requirements check in activate_plugin().
0001-add-plugin-headers-Core-PHP-and-functions-to-check-a.patch (14.5 KB) - added by cfoellmann 4 years ago.

Download all attachments as: .zip

Change History (22)

@dancameron
4 years ago

Requirements check in activate_plugin().

#1 @dancameron
4 years ago

  • Severity changed from normal to trivial

#2 @dancameron
4 years ago

  • Keywords has-patch dev-feedback 2nd-opinion added

#3 @jeremyfelt
4 years ago

#26925 was marked as a duplicate.

#4 @cfoellmann
4 years ago

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

#5 @dancameron
4 years ago

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.

#6 @cfoellmann
4 years ago

@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.

#7 @cfoellmann
4 years ago

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

Network: false => Prevent "Network activate"

#8 follow-up: @nacin
4 years ago

  • Keywords close added; dev-feedback removed

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.

#9 @dancameron
4 years ago

@nacin I'm not sure how 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

Last edited 4 years ago by dancameron (previous) (diff)

#10 @SergeyBiryukov
4 years ago

  • Version changed from trunk to 3.8

#12 in reply to: ↑ 8 @Kopepasah
4 years ago

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.

This ticket was mentioned in Slack in #core by sergeybiryukov. View the logs.


3 years ago

This ticket was mentioned in Slack in #meta by ocean90. View the logs.


3 years ago

This ticket was mentioned in Slack in #core by pmgarman. View the logs.


3 years ago

#16 @DrewAPicture
3 years ago

  • Keywords 2nd-opinion close removed
  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

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.

#17 @strider72
2 years ago

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.

#18 @ocean90
2 years ago

#36826 was marked as a duplicate.

This ticket was mentioned in Slack in #core by sergey. View the logs.


14 months ago

#20 @WraithKenny
7 months ago

#40934 for a similar, but blessed ticket.

Note: See TracTickets for help on using tickets.