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

[DavidAnderson]

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.

[DavidAnderson]

Define WP_VERSION

[stevegrunwell]

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?

[DavidAnderson]

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.

[thomaswm]

Define WP_VERSION constant in wp_initial_constants()

[thomaswm]

30499.diff​ is a refreshed patch.

[swissspidy]

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