[wp-trac] [WordPress Trac] #26909: Plugin and Theme Requirements Check

WordPress Trac noreply at wordpress.org
Mon Jan 27 16:33:59 UTC 2014


#26909: Plugin and Theme Requirements Check
-----------------------------------------+------------------------------
 Reporter:  dancameron                   |       Owner:
     Type:  enhancement                  |      Status:  new
 Priority:  normal                       |   Milestone:  Awaiting Review
Component:  Plugins                      |     Version:  trunk
 Severity:  trivial                      |  Resolution:
 Keywords:  has-patch 2nd-opinion close  |     Focuses:
-----------------------------------------+------------------------------

Comment (by 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

--
Ticket URL: <https://core.trac.wordpress.org/ticket/26909#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list