WordPress.org

Make WordPress Core

Opened 4 years ago

Last modified 17 months ago

#30499 new enhancement

define WP_VERSION, to prevent having to code around plugins which change $wp_version

Reported by: DavidAnderson Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: General Keywords: has-patch needs-testing
Focuses: Cc:

Description

There are plugins, like this one - https://wordpress.org/plugins/replace-wp-version/ - which over-write $wp_version.

Allegedly in the name of security (as if an external probe couldn't work out the WP version in 101 other ways).

Unfortunately, their existence means that if another plugin wants to _really_ know the WP version, they have to do something ugly, and re-include wp-includes/version.php, like so:

global $wp_version;
include(ABSPATH.WPINC.'/version.php');

The WP version really should not change, and there should be a more elegant way to know it is. The PHP way is via a constant; thus, the attached patch defines WP_VERSION, in order to provide coders with a reliable way of knowing the real WP version without having to use ugly work-arounds.

Attachments (2)

define-version.patch (326 bytes) - added by DavidAnderson 4 years ago.
Define WP_VERSION
30499.diff (745 bytes) - added by thomaswm 2 years ago.
Define WP_VERSION constant in wp_initial_constants()

Download all attachments as: .zip

Change History (8)

@DavidAnderson
4 years ago

Define WP_VERSION

#1 @helen
4 years ago

  • Version trunk deleted

#2 follow-up: @stevegrunwell
4 years ago

I agree that this constant would be useful (as the version shouldn't need to be able to change), but I question whether or not it makes sense to add without actually combing through core and using WP_VERSION instead of the current $wp_version global (though the global might need to stick around for legacy reasons). At the very least, it would probably make more sense to add it to wp-load.php just after version.php is included (to keep that file clean):

  define( 'WP_CONTENT_DIR', ABSPATH . 'wp-content' );
  require_once( ABSPATH . WPINC . '/version.php' );
+ define( 'WP_VERSION', $wp_version );

  wp_check_php_mysql_versions();

The case you've described seems like a major edge-case: the site needs to load the (accurate) WordPress version yet is running a disruptive plugin like the one you mentioned? Wouldn't the simplest path be to a) create the constant yourself before plugins are loaded or b) not use plugins like that as they could have serious repercussions on things like core upgrades and caching?

#3 in reply to: ↑ 2 @DavidAnderson
4 years ago

Replying to stevegrunwell:

The case you've described seems like a major edge-case: the site needs to load the (accurate) WordPress version yet is running a disruptive plugin like the one you mentioned? Wouldn't the simplest path be to a) create the constant yourself before plugins are loaded or b) not use plugins like that as they could have serious repercussions on things like core upgrades and caching?

I was coming from the angle of a plugin author. As a plugin author, I can't mandate what other crazy plugins users of my plugins might install on their sites, or force them to add an mu-plugin. Currently, the fact that $wp_version might not actually contain the WP version is something that each plugin author who uses that variable has to learn the hard way, as they lose time on support issues caused by it.

#4 @swissspidy
3 years ago

  • Keywords has-patch needs-refresh added

@thomaswm
2 years ago

Define WP_VERSION constant in wp_initial_constants()

#5 @thomaswm
2 years ago

  • Keywords needs-testing added; needs-refresh removed

30499.diff is a refreshed patch.

#6 @swissspidy
17 months ago

A few places directly include version.php to load an unmodified version. These could be updated to use the constant instead.

Note: See TracTickets for help on using tickets.