Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#484 closed enhancement (fixed)

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

Reported by: keesiemeijer's profile keesiemeijer Owned by: coffee2code's profile coffee2code
Milestone: Priority: normal
Component: Developer Hub Keywords: has-patch needs-testing


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)

484.diff (1.7 KB) - added by keesiemeijer 9 years ago.

Download all attachments as: .zip

Change History (12)

9 years ago

#1 @Otto42
9 years ago

WP_CORE_LATEST_RELEASE is always defined on 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 runs on trunk. Therefore $wp_version is currently "4.0-alpha".

#2 @keesiemeijer
9 years ago

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.

Last edited 9 years ago by keesiemeijer (previous) (diff)

#3 @coffee2code
9 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.

#4 @keesiemeijer
9 years ago

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.

#5 @coffee2code
9 years ago

True, but at that point it's a bit of an edge case (or will be). This concern only affects 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 @keesiemeijer
9 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?

#7 @coffee2code
9 years ago

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

#8 @coffee2code
9 years ago

  • Resolution set to fixed
  • Status changed from accepted to closed

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

#9 @coffee2code
9 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 @keesiemeijer
9 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 @keesiemeijer
9 years ago

The root directory and timestamp options are added to the parser. See

Note: See TracTickets for help on using tickets.