WordPress version should come from parsed wp-includes/version.php version

[keesiemeijer]

The WordPress version returned with get_current_version() will always be 3.9.0 if 'WP_CORE_LATEST_RELEASE' isn't defined. It should be the version imported by WP Parser in the option 'wp_parser_imported_wp_version' or the global $wp_version from the reference itself.

See ​https://github.com/rmccue/WP-Parser/pull/108

[Otto42]

WP_CORE_LATEST_RELEASE is always defined on WordPress.org. It's an internal constant to the site, used for a number of things, including the main release system.

Including the versions.php file or using the $wp_version global will give you the wrong value, because WordPress.org runs on trunk. Therefore $wp_version is currently "4.0-alpha".

[keesiemeijer]

WP_CORE_LATEST_RELEASE will still be used if it's defined and not empty. This lets you use the theme locally or somewhere else where it's probably not defined. Also from now on the parser creates an option with the correct version for the reference.

[coffee2code]

I have a patch about to land that already takes into account using 'wp_parser_imported_wp_version', but I'll integrate your suggestion to use $wp_version rather than the hardcoded value.

[keesiemeijer]

Cool. Maybe we should not even use $wp_version, but return an empty string if the version is not defined and the option doesn't exist. #447 and #176 have to rely on the version being correct.

[coffee2code]

True, but at that point it's a bit of an edge case (or will be). This concern only affects non-developer.wordpress.org installs, which would generally be local devs.

For the approach that also uses $wp_version to fail, the site would have to be non-dotorg (thus no constant), running an older version of the parser or still using older parsed data (thus no option defined), and probably using trunk for their local devhub site (leading to an invalid version). All are possible for the handful of devs currently involved.

However, returning an empty string won't make things much better. Not unless we account for that whenever get_current_version() is called.

I would rather return a hardcoded value that is known to be valid (e.g. "3.9.1") rather than an empty string. Everything would thus still work, even if the version number doesn't correspond to what was actually parsed.

We could check to see if $wp_version has a dash, which would indicate a non-release version. In which case we'd fall back to a hardcoded value.

[keesiemeijer]

I agree.

On a side note, are you in favor the parser should also create an option for the root directory of the parsed files?

[coffee2code]

In 638:

Code Reference: Separate get_current_version() into functions to retrieve actual version and one to retrieve its term object. See #484.

• get_current_version() now returns a string of the actual version of parsed WP code (or best effort)
• Prefer 'wp_parser_imported_wp_version' option value as set in newer version of parser
• Add get_current_version_term() to return wp-parser-since term object for the major version of parsed WP code
• Add argument to permit get_current_version_term() to return term object for actual version

[coffee2code]

In 640:

Code Reference: In get_current_version(), use the global wp_version instead of a hardcoded version number, unless wp_version isn't a release version. Fixes #484. props keesiemeijer

[coffee2code]

@keesiemeijer: What's the use case you have in mind for knowing the root directory of the parsed files? Just curious.

One thing that would be nice to have would be a timestamp of when the data was last parsed. Probably most useful for those tweaking out WP-Parser who may want to know when it was last run (since the other gauge, the 'wp_parser_imported_wp_version' won't change between different runs of the parser on the same set of files).

[keesiemeijer]

For example, ABSPATH is used in in #176 to get content from a file. The parser could have parsed a different source directory. A timestamp would also be good data to have. I will try to get them implemented in the parser.

[keesiemeijer]

The root directory and timestamp options are added to the parser. See ​https://github.com/rmccue/WP-Parser/pull/109