Introduce helper function get the unmodified value of `$wp_version`.

[peterwilsoncc]

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.

[afragen]

I know it sounds a bit redundant but perhaps wp_get_wp_version()?

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.

[costdev]

Tests

[costdev]

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.

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

Hi @peterwilsoncc , I have addressed your feedback, please let me know, if I have missed out on something. Thanks :-)

[peterwilsoncc]

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

In 58813:

General: Introduce wp_get_wp_version() to get unmodified version.

Introduces wp_get_wp_version() to get an unmodified value of $wp_version from wp-includes/version.php. Some plugins modify the global in an attempt to improve security through obscurity. This practice can cause errors in WordPress so the ability to get an unmodified version is needed.

Replaces instances within the code base in which version.php was required in order to get an unmodified value. script-loader.php is intentionally excluded from the replacements as the function is not always available to the file.

Props debarghyabanerjee, afragen, costdev.
See #61627.

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.

[afragen]

@peterwilsoncc why would it break the tests for is_wp_version_compatible()?

I haven’t run them to see.

[peterwilsoncc]

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.

[themearts]

I can see the wp-includes/version.php is being shared through WordPress Cores.

[afragen]

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.

[afragen]

@peterwilsoncc I see the issues. I’ll try to take a closer look tomorrow.

[peterwilsoncc]

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

Thanks @peterwilsoncc :-)

[SergeyBiryukov]

In 58826:

General: Move wp_get_wp_version() to a more appropriate place.

This places the function in a more predictable location, next to the is_wp_version_compatible() and is_php_version_compatible() functions.

Follow-up to [58813].

See #61627.

[SergeyBiryukov]

In 58827:

General: Memoize the return value in wp_get_wp_version().

This aims to optimize performance by saving the return value to a static variable, so that the version.php file is not unnecessarily required on each function call.

Follow-up to [58813].

Props Cybr, debarghyabanerjee, mukesh27.
Fixes #61782. See #61627.

Trac ticket: https://core.trac.wordpress.org/ticket/61627

[peterwilsoncc]

I've created a ​pull request with some additional locations that it would be good to be sure the version number is correct:

• upgrade data sent to the API
• caching functions
• block theme exporter
• wpdb

Anything further can be done in future releases.

[davidbaumwald]

@peterwilsoncc For the other pieces of code you mentioned above, are those doable in 6.7? Should we convert this to a Task (Blessed) for the remainder?

[peterwilsoncc]

@davidbaumwald Yes, I think the follow up pull request is doable for 6.7 & low risk. I'm happy for this to be converted to a task for the follow up but didn't want to do so myself as I opened the ticket. I've done that now.

[peterwilsoncc]

In 59159:

General: Expand use of wp_get_wp_version().

Expands the use of wp_get_wp_version() to get an unmodified value of the current WordPress version in various locations in which it would be unhelpful if a plugin has modified the global $wp_version.

This includes:

• Theme and plugin compatibility tests
• During the upgrade process of WP Core
• Debug and site health data reports of the current version
• Version number display in the dashboard
• Block theme export and caching utilities
• The WPDB class

Props peterwilsoncc, hellofromtonya.
See #61627.

r59159 / ​https://github.com/WordPress/wordpress-develop/commit/03834fec6848fe433045a3b19b1b45236140c3e4

[jorbin]

Related: #62165

[peterwilsoncc]

@fabiankaegy Thanks for the dev note reminder. I think this can go in the miscellanious developer improvements dev note rather than requiring a dedicated note.

I'm happy for it to be edited but how about something along the lines of:

The function wp_get_wp_version() has been introduced to allow developers to get an unmodified version of the WordPress version. Previously WordPress used the $wp_version global which could be modified by themes and plugins causing unexpected side effects.

WordPress uses the function in a number of locations in which a theme or plugin modifying the value could be problematic. This includes for version comparisons, during upgrade routines, in site health and debug reports. See #61627.

Additionally, I've closed this as fixed as I can't see the need to further expand the use of the function during the current release cycle. If anything is found to be broken, it can be fixed on a follow up ticket.

[fabiankaegy]

Thanks for the draft @peterwilsoncc 🚀 Will get that included 👍