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 @see tag.
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.

Cost profiles

The cost section on a symbol page is measured, not estimated, and it deliberately contains no milliseconds. A millisecond describes the machine that produced it. The unit used instead is the Zend VM instruction, which is the same count on every machine running the same PHP version.

Each function or method body is compiled by the official PHP images with OPcache asked to print its optimised opcode array — the instructions the engine actually executes, after the optimiser, not a reading of the source text. Nothing is run: the file only declares the function, and the listing is produced at compile time.

Every jump in that listing names its target, so the control-flow graph comes back exactly. Walking it yields every distinct way one call can run, and each conditional edge is labelled by looking at the instruction that computed the value being tested, so a branch reads as is_multisite() or $ms_locale === falserather than as a line number.

Paths that make the same sequence of calls cost the same, so they collapse into one outcome, and the conditions kept for that outcome are only the ones true on every path in it. This is why a function is never reduced to a single figure. get_locale()has sixty-five paths and five real costs, and one of them reads two options rather than one: on multisite, when the blog option is unset, it calls get_option() and then get_site_option(). A single “one query” claim would be wrong there, and the table says so with the condition attached.

Because every body is compiled by every PHP version in the matrix, a body that will not compile on an older one identifies the minimum PHP that code requires, with no hand-maintained list involved.

What is stored, and what makes it stable

Three tables, split by what can invalidate them. The body analysis is keyed by a hash of the source, so a function identical across releases is compiled once and read many times. The opcode analysis is keyed by that hash and the PHP version, since the compiler is the only other input. Only the call-graph facts are keyed by WordPress version, because those are the ones core changes around a symbol.

A new WordPress release therefore re-reads every symbol, hashes every body, and compiles only the ones whose bytes actually moved. Numbers on a page do not drift between releases unless the code did.

Distinct bodies analysed: 14,803 covering 56,958 symbol and release combinations · each analysis reused 3.8 times
PHP 7.4: 14,769 bodies compiled
PHP 8.1: 14,769 bodies compiled
PHP 8.2: 14,769 bodies compiled
PHP 8.3: 14,769 bodies compiled
PHP 8.4: 14,769 bodies compiled
PHP 8.5: 14,769 bodies compiled
PHP 8.6-dev: 14,769 bodies compiled

Where a PHP version is missing from that list, its column is still being built and the version table on a symbol page shows only the versions already measured.

What the numbers do not say

An opcode is not a fixed amount of time, and one call into the database outweighs a hundred assignments, which is why every outcome carries the calls it makes beside its instruction count. Loops are walked once, so a body that loops is reported as scaling with its input rather than given a number that pretends otherwise. A body with more branch combinations than are worth enumerating is sampled, and the page says so instead of implying the table is complete.

The cost class counts only I/O performed by the symbol or its own callees. Follow enough calls and everything in WordPress reaches the database eventually, usually down an error path a normal call never takes; grading on the full closure marks the entire reference “heavy” and tells a reader nothing. Anything deeper than that is reported separately, as reach and worst case.

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.