#484 closed enhancement (fixed)
WordPress version should come from parsed wp-includes/version.php version
Reported by: | keesiemeijer | Owned by: | coffee2code |
---|---|---|---|
Milestone: | Priority: | normal | |
Component: | Developer Hub | Keywords: | has-patch needs-testing |
Cc: |
Description
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.
Attachments (1)
Change History (12)
#2
@
10 years ago
WP_CORE_LATEST_RELEASE will still be used if it's defined and not empty. This lets you use the theme locally where it's probably not defined. Also from now on the parser creates an option with the correct version for the reference.
#3
@
10 years ago
- Owner set to coffee2code
- Status changed from new to accepted
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.
#5
@
10 years ago
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.
#6
@
10 years ago
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?
#9
@
10 years ago
@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).
#10
@
10 years ago
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.
#11
@
10 years ago
The root directory and timestamp options are added to the parser. See https://github.com/rmccue/WP-Parser/pull/109
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".