How these pages are built
A reference is only worth reading if you can tell where it got its facts. Nothing here is copied from another documentation site: every signature, parameter, return type and @since line comes from parsing the WordPress source at a release tag. This page sets out how that happens, and where it stops.
The source
Each release is taken from the wordpress-develop tag that matches it — 7.1.0 means the 7.1.0 tag, not trunk and not a nightly. That is what lets a page state a fact about a specific release instead of about “current WordPress”, which is a moving target and is usually not the WordPress you are running.
The parser
Parsing is done with WordPress’s own documentation parser, the same WP-Parser lineage that produces the official reference, run over the whole src/ tree. It reads the PHP itself rather than the rendered docs, so what comes out is structured: for each file, its functions and their arguments, its classes with their properties and methods, the hooks fired inside each function in the order the code fires them, and the docblock tags attached to all of it.
What is derived, not parsed
Some of the most useful things on a symbol page are not in any docblock. They are computed from the parsed output across the whole codebase, which is why they can exist here at all:
- Hooks fired, in execution order
- Taken from the hook calls found inside the function body, in source order, so you can see what has already run by the time your callback is reached.
- Callers
- Every place in core that calls the symbol, found by matching call sites across all parsed files rather than by trusting a
@seetag. - Release history
- Each release is parsed separately and the results are compared, so “added in”, “signature changed” and “removed” are the result of a diff between two parses, not a reading of
@since. - One page per symbol
- A symbol keeps a single URL across every release covered here, with a version switch on the page. Per-release URLs would split the same function into five pages competing with each other and force you to guess which one applies to you.
Releases covered
Counts are what the parser found in that release’s source, and each is dated with the day that parse ran.
- WordPress 7.1.0 — currently shown
- 15,723 symbols · parsed 22 Aug 2026
- WordPress 7.0.4
- 15,519 symbols · parsed 22 Aug 2026
- WordPress 6.9.7
- 14,579 symbols · parsed 22 Aug 2026
- WordPress 6.8.8
- 14,252 symbols · parsed 22 Aug 2026
- WordPress 6.7.7
- 14,187 symbols · parsed 22 Aug 2026
Written material
Descriptions, examples and the common-problem answers are written material sitting on top of the parsed data, and they are tied to the shape of the symbol rather than to a release number. What counts as the shape is deliberately narrow: parameters, return type, visibility, deprecation, the hooks fired, and for a class its properties and methods. A new line number, a fresh @since or a reworded docblock does not change it.
That is what makes the reference maintainable across 5 releases at once. Most symbols are identical in shape from one release to the next, so their written material is carried forward untouched, and only the symbols whose signature genuinely moved are rewritten. When the parsed basis for a page does change, the written material on it is flagged as stale rather than left to quietly disagree with the code above it.
Runnable examples
Examples are not illustrative pseudocode. They run against a real WordPress booted in your browser on WebAssembly, seeded with fixed content so an example that prints a post title prints an actual one. Examples are written against that fixed content, and each named environment is verified per release, so a WordPress release that breaks an example surfaces as a failure rather than as a snippet that quietly stops working.
What this method cannot see
Static parsing has real limits, and it is better to state them than to imply completeness:
- Dynamic names
- Core assembles some hook names at runtime. Those are listed under the literal part of the name, and where the name is built from an expression the parser cannot resolve it at all.
- Conditional declarations
- A symbol declared inside a conditional, or built dynamically, can be missed. Counts on this site describe what parsing produced, which is not quite the same claim as what WordPress contains.
- Runtime behaviour
- Callers are call sites in core source. A function reached only through a variable callback, or from a plugin, does not appear in that list.
- Core’s own docblocks
- Where a docblock in WordPress is wrong or out of date, the page repeats it. The parsed signature above it is the part that is always the code.
Corrections
If a page is wrong, say which symbol and which release. Because pages are generated per release from one basis, a correction can be applied to every version that shares the same signature at once. Background on the project is on the about page.