WordPress.org

Make WordPress Core

Opened 20 months ago

Closed 8 months ago

Last modified 5 months ago

#43992 closed task (blessed) (fixed)

Prevent activation of a plugin if its required PHP version is too high

Reported by: flixos90 Owned by: desrosj
Milestone: 5.2 Priority: high
Severity: major Version:
Component: Site Health Keywords: needs-unit-tests servehappy has-patch 2nd-opinion close
Focuses: Cc:
PR Number:

Description

Note: This ticket is a subtask for the overarching #40934 ticket.

While the plans from #43986 and #43987 will ensure nobody can install or update plugins that require a PHP version higher than the version used, a third step should be to prevent plugin activations of said plugins. It is still possible to just upload plugin directories and then activate them from there. While the above tickets will cover the majority of cases, we should also account for the latter.

A difference between other work and this one would be that here, we need to read the required PHP version from the plugin readme file directly instead from the w.org plugins API.

Attachments (24)

43992.diff (3.6 KB) - added by afragen 12 months ago.
Prevents plugin activation if either minimum WP or minimum PHP versions not met.
43992-2.diff (4.2 KB) - added by afragen 12 months ago.
Allow for plugins not in Plugin Directory but containing plugin headers Requires WP and/or Requires PHP
43992-3.diff (5.5 KB) - added by afragen 12 months ago.
Need to add Requires WP and Requires PHP as default plugin headers.
43992-4.diff (5.6 KB) - added by afragen 11 months ago.
Allow for API response to error
43992-5.diff (5.7 KB) - added by afragen 11 months ago.
renamed function and more complete docs
43992-6.diff (5.9 KB) - added by afragen 11 months ago.
Improved error checking of API response
43992-7.diff (5.9 KB) - added by afragen 11 months ago.
fixed docBlock error
43992-8.diff (5.9 KB) - added by afragen 11 months ago.
Reverse logic of validate_plugin_activation() to improve readability
43992-9.diff (5.7 KB) - added by afragen 11 months ago.
fix version_compare so 5.1.10 is greater than 5.1.2 and true
43992.10.diff (6.4 KB) - added by afragen 11 months ago.
patch refreshed for 5.2 milestone
43992.11.diff (6.4 KB) - added by afragen 11 months ago.
rename function to is_wp_compatible() and is_php_compatible() for readability
43992.12.diff (16.8 KB) - added by afragen 11 months ago.
now based on new local readme parser
43992.13.diff (16.2 KB) - added by afragen 11 months ago.
improve sanitization and docblocks
43992.14.diff (6.1 KB) - added by afragen 10 months ago.
use get_file_data()
43992.15.diff (6.0 KB) - added by afragen 9 months ago.
Updated from feedback
43992.16.diff (6.2 KB) - added by afragen 9 months ago.
test for actionable data
43992.17.diff (6.1 KB) - added by afragen 9 months ago.
simpler logic
43992.18.diff (6.1 KB) - added by afragen 9 months ago.
Update docblock
43992.19.diff (6.1 KB) - added by afragen 9 months ago.
update function names to wp_is_wp_compatible() and wp_is_php_compatible()
43992.20.diff (6.2 KB) - added by afragen 9 months ago.
add plugin name to data returned, prep for better messaging
43992.21.diff (7.2 KB) - added by afragen 9 months ago.
granular messaging added
43992.22.diff (7.2 KB) - added by afragen 9 months ago.
oops, missed @param in docblock
43992.23.diff (7.2 KB) - added by afragen 9 months ago.
now actually include the last fix in the patch :facepalm:
43992.24.diff (4.0 KB) - added by SergeyBiryukov 9 months ago.

Download all attachments as: .zip

Change History (86)

This ticket was mentioned in Slack in #core-php by flixos90. View the logs.


19 months ago

#2 @Luciano Croce
19 months ago

  • Keywords dev-feedback added
  • Severity changed from normal to major

This ticket is fantastic: i am fully in agreement with it, and at its introduction.

I have introduced this good practice in all my plugins for a long time''

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


19 months ago

#4 @flixos90
14 months ago

  • Milestone changed from 5.0 to 5.1

#5 @afragen
12 months ago

Last edited 11 months ago by afragen (previous) (diff)

#6 @afragen
12 months ago

I've been working on this and should have a patch ready soon. I'll need help with any unit tests.

Last edited 12 months ago by afragen (previous) (diff)

@afragen
12 months ago

Prevents plugin activation if either minimum WP or minimum PHP versions not met.

#7 @afragen
12 months ago

  • Keywords has-patch added; needs-patch removed

This ticket was mentioned in Slack in #core-php by afragen. View the logs.


12 months ago

#9 @afragen
12 months ago

@SergeyBiryukov we can reuse the is_compatible_wp() and is_compatible_php() functions in several of the other Servehappy patches.

@afragen
12 months ago

Allow for plugins not in Plugin Directory but containing plugin headers Requires WP and/or Requires PHP

@afragen
12 months ago

Need to add Requires WP and Requires PHP as default plugin headers.

@afragen
11 months ago

Allow for API response to error

@afragen
11 months ago

renamed function and more complete docs

@afragen
11 months ago

Improved error checking of API response

@afragen
11 months ago

fixed docBlock error

#10 @afragen
11 months ago

A difference between other work and this one would be that here, we need to read the required PHP version from the plugin readme file directly instead from the w.org plugins API.

Before we can do this some sort of stripped down version of the dot org class-parser.php will need to be included with core.

Once added it should be simple to swap the internals of get_plugin_validation_data() to use the new local parser and parse the local readme.txt.

@afragen
11 months ago

Reverse logic of validate_plugin_activation() to improve readability

This ticket was mentioned in Slack in #core-php by afragen. View the logs.


11 months ago

@afragen
11 months ago

fix version_compare so 5.1.10 is greater than 5.1.2 and true

#12 @afragen
11 months ago

We probably need to change milestone to 5.2

This ticket was mentioned in Slack in #core-php by afragen. View the logs.


11 months ago

#14 @flixos90
11 months ago

  • Milestone changed from 5.1 to 5.2

@afragen
11 months ago

patch refreshed for 5.2 milestone

@afragen
11 months ago

rename function to is_wp_compatible() and is_php_compatible() for readability

@afragen
11 months ago

now based on new local readme parser

#15 @afragen
11 months ago

  • Keywords needs-testing added

43992.12.diff contains a new(ish) readme parser for a local plugin readme.txt file. It is mostly a pared down version of the WordPress.org Plugin Readme Parser

No more calls to w.org plugins API.

@afragen
11 months ago

improve sanitization and docblocks

#16 follow-up: @joyously
11 months ago

I only looked at the last diff, but it is adding unnecessary code for reading the plugin file.
The headers are added to get_plugin_data, which is already reading the plugin file, so that function should be where the default value is returned if needed.

#17 in reply to: ↑ 16 @afragen
11 months ago

Replying to joyously:

I only looked at the last diff, but it is adding unnecessary code for reading the plugin file.
The headers are added to get_plugin_data, which is already reading the plugin file, so that function should be where the default value is returned if needed.

I admit I'm a little confused. In what part of the diff are you referring to and what do you think is unnecessary?

#18 follow-ups: @joyously
11 months ago

The WP_Readme_Header_Parser is unnecessary. The get_plugin_data function does that.

#19 in reply to: ↑ 18 @afragen
11 months ago

Replying to joyously:

The WP_Readme_Header_Parser is unnecessary. The get_plugin_data function does that.

Actually it doesn't do the same thing. get_plugin_data() parses and returns the headers in the main plugin file. The new class WP_Readme_Header_Parser will parse a local readme.txt file and return the headers.

Please refer to #10 above.

#20 in reply to: ↑ 18 ; follow-up: @joyously
11 months ago

Comment 10 is talking about reading local versus using the API. get_plugin_data calls get_file_data which reads from the local file. The first parameter is the file to use, so you pass it the readme instead of the main plugin file. Still don't need your WP_Readme_Header_Parser.

#21 in reply to: ↑ 20 @afragen
11 months ago

Replying to joyously:

Comment 10 is talking about reading local versus using the API. get_plugin_data calls get_file_data which reads from the local file. The first parameter is the file to use, so you pass it the readme instead of the main plugin file. Still don't need your WP_Readme_Header_Parser.

Comment 10 references the last part of the ticket description. Obtaining the data from a local readme.txt file and not from the API. The API parses the uploaded readme.txt file.

get_file_data() reads from a plugin or theme main file, not from the readme.txt. get_file_data() references File Header in the Codex. get_file_data() will not correctly parse a readme.txt file.

Specifically from the Codex:

File Headers in readme.txt
Some plugins contain the readme.txt file which might contain look-a-like headers as well. Those files are  not handled by WordPress but by third-party applications. Because those applications can be quite popular, I note down here those tags from an example readme file:

Contributors: markjaquith, mdawaffe (this should be a list of wordpress.org userid's)
Donate link: http://example.com/
Tags: comments, spam
Requires at least: 2.0.2
Tested up to: 2.1
Stable tag: 4.3

As ticket #12260 suggests, the headers from readme.txt are used through remote WP.org API calls. This is a good example of how third party applications use has direct impact on wordpress core code usage.
Last edited 11 months ago by afragen (previous) (diff)

#22 follow-up: @joyously
11 months ago

get_file_data() will not correctly parse a readme.txt file.

I bet it will, and it would be better than adding a lot of extra code. It takes parameters for the file to use and the headers to look for. What's the big deal? The format is the same. Did you try it?

But I notice that this diff adds those headers to the defaults in get_plugin_data(), so are they just in the readme or in the plugin file also?

#23 in reply to: ↑ 22 @afragen
11 months ago

Replying to joyously:

get_file_data() will not correctly parse a readme.txt file.

I bet it will, and it would be better than adding a lot of extra code. It takes parameters for the file to use and the headers to look for. What's the big deal? The format is the same. Did you try it?

But I notice that this diff adds those headers to the defaults in get_plugin_data(), so are they just in the readme or in the plugin file also?

The overwhelming majority of plugins in dot org do not contain the added Requires WP and/or Requires PHP headers, but they all contain a readme.txt.

In fact, these were added to this patch as a method for plugins that are not hosted in dot org to be compliant and not necessarily require a valid readme.txt file.

As an example, a readme header of Requires or Requires at least, which are the excepted readme headers, will not parse correctly from get_plugin_data and will not return expected results.

Please submit a patch based on your idea. I'm happy to test it.

Last edited 11 months ago by afragen (previous) (diff)

This ticket was mentioned in Slack in #core-php by afragen. View the logs.


10 months ago

#25 @afragen
10 months ago

@aaroncampbell pinging for a sanity check as discussed at WordCamp Phoenix Contributor Day. Thanks.

#26 @DrewAPicture
10 months ago

Yeah, so @joyously's suggestion for using get_file_data() instead is a pretty elegant solution to the problem. I didn't prepare a patch but a code example should suffice.

Readme:

=== Test Plugin ===
Requires at least: 5.0
Tested up to: 5.1
Stable tag: 1.0.0
License: GPLv2
Requires WP: 5.0
Requires PHP: 7.3

Read with:

<?php
$headers = array(
    'requires_at_least' => 'Requires at least',
    'tested_up_to'      => 'Tested up to',
    'stable_tag'        => 'Stable tag',
    'license'           => 'License',
    'requires_wp'       => 'Requires WP',
    'requires_php'      => 'Requires PHP',
);

var_dump( get_file_data( __DIR__ . '/readme.txt', $headers ) );

Outputs:

Array
(
    [requires_at_least] => 5.0
    [tested_up_to] => 5.1
    [stable_tag] => 1.0.0
    [license] => GPLv2
    [requires_wp] => 5.0
    [requires_php] => 7.3
)

I think get_file_data() should be more than adequate. And bonus points for leveraging something already in core!

Last edited 10 months ago by DrewAPicture (previous) (diff)

#27 @afragen
10 months ago

I’ll take a look but I remember something about that not quite working. I certainly could be wrong.

#28 @afragen
10 months ago

I admit to becoming confused in my exchange with @joyously as the initial point was using get_plugin_data on the plugin file.

I’ll see if I can make this work and refresh or comment either way.

Thanks @joyously @DrewAPicture

@afragen
10 months ago

use get_file_data()

#29 follow-up: @afragen
10 months ago

@joyously @DrewAPicture You guys were absolutely correct. Thanks for making me see the light.

Latest patch uses get_file_data(). Seems to work as expected.

#30 in reply to: ↑ 29 @DrewAPicture
10 months ago

Replying to afragen:

@joyously @DrewAPicture You guys were absolutely correct. Thanks for making me see the light.

Latest patch uses get_file_data(). Seems to work as expected.

All of the credit goes to @joyously, I just tested the theory :-)

#31 @afragen
10 months ago

Drew, that’s why I listed Joy first. 😉

This ticket was mentioned in Slack in #core-php by afragen. View the logs.


9 months ago

#33 follow-up: @TimothyBlynJacobs
9 months ago

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?

@afragen
9 months ago

Updated from feedback

#34 in reply to: ↑ 33 @afragen
9 months ago

43992.15.diff based upon feedback below. Comments inline.

Replying to 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.

done

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

Shortened array to only 2 essential components.

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

We can discuss the precedence. As indicated in the comment blocks the precedence if for data in readme.txt with a fallback to new plugin headers.

  1. When calling get_plugin_data, can we disable $markup and $translate?

done

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

return type is documented as array, extraneous headers are no longer queried.

  1. Consider making the return type less ambiguous by returning requires_wp instead of just requires.

$requires is parameter passed into the is_php_compatible() or is_wp_compatible() functions. Using a more generic parameter simply made the function and code more similar.

  1. I'd update validate_plugin_requirements() to return true|WP_Error. The error would detail which requirements weren't met.

I think we'll have to agree to disagree. Returning a boolean for makes more sense to me as there is no error to be generated. If the validation fails, a WP_Error is generated.

  1. 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?

I changed this to unmet_requirements

@afragen
9 months ago

test for actionable data

#35 @afragen
9 months ago

Based upon a Twitter conversation, https://wordpress.slack.com/archives/C60K3MP2Q/p1552875771433600?thread_ts=1552875627.432000&cid=C60K3MP2Q

43992.16.diff tests for actionable data and replaces empty data in the readme.txt file with data from the plugin headers, if present.

This still give precedence to data in the readme.txt.

@afragen
9 months ago

simpler logic

#36 @TimothyBlynJacobs
9 months ago

Updated patch looks good to me.

I'm not sure what the right solution is for the validate_plugin_requirements function. It seems like it'd be helpful for that to return which requirement failed. I agree WP_Error doesn't semantically make sense.

#37 @desrosj
9 months ago

  • Owner set to desrosj
  • Status changed from new to reviewing

#38 follow-ups: @desrosj
9 months ago

  • Keywords 2nd-opinion added

This is testing pretty well for me. After some of the items below are solidified I can add some unit tests.

At first look, the thought that "we should pass a $context of plugin or plugin_validation to the get_file_data() call in get_plugin_validation_data()" came to mind. This would allow extra headers to be added and detected. But, if this was added, then a filter would need to be added to the end of get_plugin_validation(). Otherwise, detecting any additional headers would be useless. I can't think of a good use case right now, though, so let's leave it as is.

In the current state, any empty headers in the readme.txt will be ignored in favor of the plugin's headers, even if they are defined and empty. Just confirming that this is intended.

Can you confirm that I am understanding the precedence correctly:

  • Non empty values defined in readme.txt.
  • Plugin file header values when readme.txt does not exist.
  • When readme.txt exists but has empty (or undefined) values for either header, the empty values will fall back to the plugin file headers.

I am also a little concerned with the function names is_wp_compatible() and is_php_compatible() being too generic. I did some brief searching around, and is_wp_compatible() seems to be pretty common among plugins. I am mostly seeing is_wp_compatible() as private or protected class methods, but I'd like a few more opinions on whether we should adjust the names a bit.

For the unmet_requirements error, maybe the approach could be:

  • Add a new function that returns a boolean indicating a plugin can be activated.
  • validate_plugin_requirements() returns an array indicating if PHP passed, WP passed, and if either fails, a string with the correct contextual error message.

Something like this could let us have different messages for each scenario. Examples: Plugin does not meet minimum WordPress requirements., Plugin does not meet minimum PHP requirements., Plugin does not meet minimum WordPress and PHP requirements..

Some other minor items:

  • @uses should no longer be used within PHP docblocks. get_plugin_validation_data() description needs to be revised to be more clear about priority that data is used.
  • Can the short description for get_plugin_validation_data() be more specific about what is being validated?

#39 in reply to: ↑ 38 @afragen
9 months ago

Replying to desrosj:

This is testing pretty well for me. After some of the items below are solidified I can add some unit tests.

At first look, the thought that "we should pass a $context of plugin or plugin_validation to the get_file_data() call in get_plugin_validation_data()" came to mind. This would allow extra headers to be added and detected. But, if this was added, then a filter would need to be added to the end of get_plugin_validation(). Otherwise, detecting any additional headers would be useless. I can't think of a good use case right now, though, so let's leave it as is.

I only added the headers we need to check. At some point we could add a filter to this array if it's necessary. But I also not sure of a use case.

In the current state, any empty headers in the readme.txt will be ignored in favor of the plugin's headers, even if they are defined and empty. Just confirming that this is intended.

Can you confirm that I am understanding the precedence correctly:

  • Non empty values defined in readme.txt.
  • Plugin file header values when readme.txt does not exist.
  • When readme.txt exists but has empty (or undefined) values for either header, the empty values will fall back to the plugin file headers.

So both get_file_headers() and get_plugin_headers() will return an empty string if the header is missing or has no value.

Given that readme.txt files are required for the plugin directory any data existing here takes precedence. If a value exists in readme.txt it will be used. If a value doesn't exist in readme.txt then we look to the plugin headers to see if a value exists. If it does then we will use it. If no value exists in either place the return value would be an empty string.

Currently we are very permissive and an empty string automatically denotes a valid compatibility test. We can always change this in the future via the functions below.

I am also a little concerned with the function names is_wp_compatible() and is_php_compatible() being too generic. I did some brief searching around, and is_wp_compatible() seems to be pretty common among plugins. I am mostly seeing is_wp_compatible() as private or protected class methods, but I'd like a few more opinions on whether we should adjust the names a bit.

A search of WPDirectory for is_wp_compatible shows instances of the function name in only 20 different plugins and all seem to be namespaced.

A search of WPDirectory for is_php_compatible shows instances of the function name in only 17 different plugins and all seem to be namespaced.

For the unmet_requirements error, maybe the approach could be:

  • Add a new function that returns a boolean indicating a plugin can be activated.
  • validate_plugin_requirements() returns an array indicating if PHP passed, WP passed, and if either fails, a string with the correct contextual error message.

Something like this could let us have different messages for each scenario. Examples: Plugin does not meet minimum WordPress requirements., Plugin does not meet minimum PHP requirements., Plugin does not meet minimum WordPress and PHP requirements..

Let me look into this.

Some other minor items:

  • @uses should no longer be used within PHP docblocks. get_plugin_validation_data() description needs to be revised to be more clear about priority that data is used.
  • Can the short description for get_plugin_validation_data() be more specific about what is being validated?

OK

@afragen
9 months ago

Update docblock

#40 in reply to: ↑ 38 @afragen
9 months ago

Replying to desrosj:

For the unmet_requirements error, maybe the approach could be:

  • Add a new function that returns a boolean indicating a plugin can be activated.
  • validate_plugin_requirements() returns an array indicating if PHP passed, WP passed, and if either fails, a string with the correct contextual error message.

Something like this could let us have different messages for each scenario. Examples: Plugin does not meet minimum WordPress requirements., Plugin does not meet minimum PHP requirements., Plugin does not meet minimum WordPress and PHP requirements..

If more granular error messaging is desired I think that's very achievable for 5.2.1. I agree that it's likely to require a function that returns the correct messaging.

#41 @desrosj
9 months ago

  • Keywords needs-refresh added

I think more granular error messaging in 5.2.1/5.3 can work.

For the functions, let's use wp_is_wp_compatible() and wp_is_php_compatible().

@afragen
9 months ago

update function names to wp_is_wp_compatible() and wp_is_php_compatible()

#42 @afragen
9 months ago

  • Keywords needs-refresh removed

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


9 months ago

@afragen
9 months ago

add plugin name to data returned, prep for better messaging

#44 @desrosj
9 months ago

  • Priority changed from normal to high

This is required prior to beta. Marking as high priority to receive a 2nd opinion.

#45 follow-up: @SergeyBiryukov
9 months ago

  • I'd like to see specific error messages for not meeting minimum WP version requirement vs. PHP version, rather than "WordPress and/or PHP". validate_plugin_requirements() could return WP_Error on error, I agree with @TimothyBlynJacobs in comment:33 here. That can probably be adjusted after beta though.
  • Introducing wp_is_*_compatible() wrappers doesn't seem to bring a huge benefit at a glance, as there are only two or three of these checks in core. Maybe it will be easier to see once the other instances are updated to use the wrappers. I agree they should be prefixed with wp_, just in case.

Looks good otherwise.

Last edited 9 months ago by SergeyBiryukov (previous) (diff)

#46 in reply to: ↑ 45 @afragen
9 months ago

Replying to SergeyBiryukov:

  • I'd like to see specific error messages for not meeting minimum WP version requirement vs. PHP version, rather than "WordPress and/or PHP". validate_plugin_requirements() could return WP_Error on error, I agree with @TimothyBlynJacobs in comment:33 here. That can probably be adjusted after beta though.

It was my plan to fix this during beta. Do you want me to try and do it before commit?

  • Introducing wp_is_*_compatible() wrappers doesn't seem to bring a huge benefit at a glance, as there are only two or three of these checks in core. Maybe it will be easier to see once the other instances are updated to use the wrappers. I agree they should be prefixed with wp_, just in case.

Search core for $compatible_wp and $compatible_php. It will also become most beneficial if/when the decision is made to require the Requires at least and Requires PHP headers in the readme. Then all plugin will be appropriately tested as opposed to allowing those without the headers to pass on through as valid.

Looks good otherwise.

Thanks.

@afragen
9 months ago

granular messaging added

@afragen
9 months ago

oops, missed @param in docblock

@afragen
9 months ago

now actually include the last fix in the patch :facepalm:

#47 @SergeyBiryukov
9 months ago

For the first iteration, I'd like to simplify things a bit.

43992.23.diff reads the Requires at least and Requires PHP headers from both readme.txt and the main plugin file, with readme.txt taking precedence.

Per comment:23, this was done for plugins not hosted on w.org that may not have a valid readme.txt file.

However, on w.org these headers are specific to readme.txt, adding them to the plugin file does not have any effect.

Since we don't generally have any special treatment for plugins not hosted on w.org anywhere else in core, I wonder if by reading the headers from both places in this particular function (and advertising them as plugin headers vs. readme headers) we make things more complicated and confusing to plugin authors.

43992.24.diff is a simpler implementation that only reads the headers from readme.txt and makes validate_plugin_requirements() more consistent with validate_plugin(). For Beta 1, I think we could go with that, and then iterate further as needed.

#48 @SergeyBiryukov
9 months ago

In 44978:

Plugins: Block plugin activation if it requires a higher version of PHP or WordPress.

Introduce validate_plugin_requirements() for validating a plugin's WordPress and PHP version requirements.

Introduce wp_is_wp_compatible() and wp_is_php_compatible() for checking compatibility with the current WordPress or PHP version.

Props afragen, joyously, DrewAPicture, TimothyBlynJacobs, desrosj, flixos90, SergeyBiryukov.
See #43992.

#49 @SergeyBiryukov
9 months ago

In 44979:

PHPCS: Fix WPCS violations in [44978].

See #43992.

#50 @SergeyBiryukov
9 months ago

In 44981:

Plugins: Remove wp_is_wp_compatible() and wp_is_php_compatible() functions added in [44978] for now, to discuss use cases and better naming.

See #46599, #43992.

#51 @desrosj
9 months ago

  • Keywords dev-feedback needs-testing removed

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


9 months ago

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


8 months ago

#54 @JeffPaul
8 months ago

Pinging @joshuawold for input/opinion as the Plugins component maintainer.

This ticket was mentioned in Slack in #core-php by schlessera. View the logs.


8 months ago

#56 @schlessera
8 months ago

Looks good and can be closed as far as the core-php is concerned.

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


8 months ago

#58 @afragen
8 months ago

  • Keywords close added
  • Resolution set to invalid
  • Status changed from reviewing to closed

See #46938

#59 follow-up: @johnbillion
8 months ago

  • Resolution changed from invalid to fixed

#60 in reply to: ↑ 59 @afragen
8 months ago

Replying to johnbillion:
Thanks, I didn’t seem to have the option to set to fixed. 😉

#61 @spacedmonkey
6 months ago

  • Component changed from Plugins to Site Health

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


5 months ago

Note: See TracTickets for help on using tickets.