[wp-trac] [WordPress Trac] #43992: Prevent activation of a plugin if its required PHP version is too high

[WordPress Trac]

#43992: Prevent activation of a plugin if its required PHP version is too high
-------------------------------------------------+-------------------------
 Reporter:  flixos90                             |       Owner:  (none)
     Type:  task (blessed)                       |      Status:  new
 Priority:  normal                               |   Milestone:  5.2
Component:  Plugins                              |     Version:
 Severity:  major                                |  Resolution:
 Keywords:  needs-unit-tests servehappy dev-     |     Focuses:
  feedback has-patch needs-testing               |
-------------------------------------------------+-------------------------

Comment (by TimothyBlynJacobs):

 Looking at .14

 1. Patch applies cleanly.
 2. The `get_plugin_validation_data()` header should be updated to
 reference `get_file_data` instead of the readme parser.
 3. The `$validation_headers` is invalid. It has duplicated array keys.
 While less clean, the array keys should probably be separate for the
 `tested|required` and the `tested|required up to` header variants and then
 merged back together with whichever variant is better.
 4. I think the `null === $plugin_data` check needs to either be relaxed or
 removed. I'd think the plugin headers should take priority and thus that
 code branch should always run, but not sure, either way the expected
 precedence should be documented. If just opting to relax the checks, it
 should also verify that the headers are not empty strings.
 5. When calling `get_plugin_data`, can we disable `$markup` and
 `$translate`?
 6. Document the return type. Should we return the tested up to values? It
 seems like they aren't used anywhere else in the patch and aren't provided
 by the plugin header.
 7. Consider making the return type less ambiguous by returning
 `requires_wp` instead of just `requires`.
 8. I'd update `validate_plugin_requirements()` to return `true|WP_Error`.
 The error would detail which requirements weren't met.
 9. In concert with 7 update the error message in `activate_plugin` to be
 more specific. Depending on the implementation of
 `validate_plugin_requirements` it might make sense to just return that
 WP_Error object. Otherwise, if `activate_plugin` returns its own WP_Error,
 I think the error code could be more specific. Maybe `unmet_requirements`?

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