Opened 4 weeks ago
Last modified 7 days ago
#61627 new enhancement
Introduce helper function get the unmodified value of `$wp_version`.
Reported by: | peterwilsoncc | Owned by: | |
---|---|---|---|
Milestone: | 6.7 | Priority: | normal |
Severity: | normal | Version: | |
Component: | General | Keywords: | has-patch has-unit-tests |
Focuses: | Cc: |
Description
In a number of locations WordPress requires the version.php
file in order to get an accurate value for the current WordPress version. An example from the dashboard is:
<?php // Include an unmodified $wp_version. require ABSPATH . WPINC . '/version.php';
The reason Core is required to do this is because there is advice on a number of websites to hide the WordPress version by overriding the $wp_version
global in a plugin. The stated benefit is for security through obscurity but it will break WordPress functionality.
To avoid the need to repeat the code and to allow for ease of access to the real version of WordPress, I suggest a helper function be introduced:
<?php function wp_get_version() { // Include an unmodified $wp_version. require ABSPATH . WPINC . '/version.php'; return $wp_version; }
Suggestions for improving the name of the function are welcomed.
Attachments (1)
Change History (19)
This ticket was mentioned in PR #7013 on WordPress/wordpress-develop by @debarghyabanerjee.
4 weeks ago
#2
- Keywords has-patch added; needs-patch removed
Trac Ticket: Core-61627
## Summary:
- This pull request proposes the introduction of a helper function to retrieve the WordPress version accurately without relying on the version.php file directly. This enhancement aims to address issues where plugins override the $wp_version global variable, potentially breaking WordPress functionality.
## Problem Statement:
- In various scenarios, WordPress relies on the version.php file to obtain the correct WordPress version. However, some plugins advise overriding the $wp_version global variable to hide the WordPress version for perceived security benefits. This practice can lead to compatibility issues and disrupt core functionalities that depend on accurate version detection.
## Solution:
- Introduced a dedicated helper function that retrieves the current WordPress version reliably. This function will centralize version retrieval, ensuring consistent and accurate reporting of the WordPress version across different contexts without the risk of interference from plugins modifying global variables.
#3
@
2 weeks ago
- Keywords has-unit-tests added; needs-unit-tests removed
I've attached some tests for the new function in wp_get_wp_version-tests.diff. If there are additional ideas for testing the new function, we can build on these.
@peterwilsoncc commented on PR #7013:
2 weeks ago
#4
It would be good to implement this in a few places that are using the pattern already.
If you search the code base for require ABSPATH . WPINC . '/version.php';
you will find some suitable locations.
Ignore the following files as they either don't have access to the function or are used to populate the global:
- src/wp-settings.php
- src/wp-admin/load-scripts.php
- src/wp-admin/load-styles.php
- src/wp-includes/script-loader.php
@debarghyabanerjee commented on PR #7013:
10 days ago
#5
Hi @peterwilsoncc , I have addressed your feedback, please let me know, if I have missed out on something. Thanks :-)
#6
@
10 days ago
- Keywords commit added
- Milestone changed from Awaiting Review to 6.7
@debarghyabanerjee's pull request looks good for commit.
The pull request replaces all the instances of requiring version.php to get an unmodified value except for in script-loader.php as the function may not be available.
As there are other location in core in which an unmodified version of WP could prove helpful, I'll keep the ticket open after commit to allow for further work on this.
@afragen @costdev This would be helpful in is_wp_version_compatible()
but it would break the tests introduced in #59448 so it's unchanged for now.
@peterwilsoncc commented on PR #7013:
9 days ago
#8
Merged r58813 / https://github.com/WordPress/wordpress-develop/commit/c41304d73c32c968056abd2b1ffa19e83e9833a9
Thanks for your work on this, Debarghya.
It looks like WordPress 6.7 will be the first version in which you have been given props. Congratulations! The Core Contributor badge won't appear on your WordPress.org profile until after the release so please don't worry that it hasn't been added immediately.
#9
follow-up:
↓ 10
@
9 days ago
@peterwilsoncc why would it break the tests for is_wp_version_compatible()
?
I haven’t run them to see.
#10
in reply to:
↑ 9
@
9 days ago
- Keywords commit removed
Replying to afragen:
@peterwilsoncc why would it break the tests for
is_wp_version_compatible()
?
is_wp_version_compatible()
uses the $wp_version
global without making sure it's unmodified. A couple of the tests modify the $wp_version
global to ensure the function works as expected. See tests/phpunit/tests/functions/isWpVersionCompatible.php.
#12
@
9 days ago
It seems the only modification is to create a higher and lower version number to test.
Should we create a PR changing $wp_version
in the function and the tests to see if it passes?
Currently on mobile.
This ticket was mentioned in Slack in #core-upgrade-install by peterwilsoncc. View the logs.
8 days ago
#15
@
7 days ago
#61781 has been opened to manage the use of this function in is_wp_version_compatible()
.
I'll keep this open for focusing on expanding the use of the function within core.
@debarghyabanerjee commented on PR #7013:
7 days ago
#16
Thanks @peterwilsoncc :-)
I know it sounds a bit redundant but perhaps
wp_get_wp_version()
?