![\"The](\"https:\/\/make.wordpress.org\/core\/files\/2026\/02\/image-2.png\")
<\/a>wp_interactivity()<\/code> over the past two years.<\/figcaption><\/figure>\n\n\n\n![\"In](\"https:\/\/make.wordpress.org\/core\/files\/2026\/02\/image-1024x379-1.png\")
<\/a>Source block for wp_interactivity()<\/code> after the update.<\/figcaption><\/figure>\n<\/figure>\n\n\n\nThis work was the result of collaboration between many people, most of whom have never worked with this process in the past. @<\/span>dd32<\/a>, @<\/span>dmsnell<\/a>, @<\/span>johnbillion<\/a>, @<\/span>jonsurrell<\/a>, and @<\/span>tmdk<\/a> all worked on various approaches to restoring the ability to parse WordPress\u2019 source code; and @<\/span>dd32<\/a> and @<\/span>coffee2code<\/a> made sure that the updates reached the public website; and of course, numerous people in the #<\/span>docs<\/a> team reported and triaged bug reports that were symptoms of this process breakdown.<\/p>\n\n\n\nThere is still significant work to do, as there is no way (at the time of writing this note) to generate the documentation for the upcoming WordPress 7.0 release, but as the new issues are ironed out, you can expect the updates to come much sooner than 2028 \ud83d\ude09<\/p>\n\n\n\n
There still remain a number of known issues, particularly related to PHPStan type annotations. Work is ongoing to improve the overall build process and try to reduce the feedback loopLoop<\/span> The Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https:\/\/codex.wordpress.org\/The_Loop<\/a><\/span><\/span><\/span> between making code changes and seeing those reflected in the documentation online.<\/p>\n\n\n\n\n\n\n\nTimeline<\/h2>\n\n\n\n\n- August 1, 2023 \u2014 [56345]<\/a> introduces a code-styling change to replace
array_key_exists()<\/code> with isset()<\/code> while indexing a class constant. This was known to be unsupported by the docs parser<\/a> but there was no indication that the updating process was broken. Because of a parsing error the process was blocked; the documentation generator needed to update its underlying dependency on nikic\/php-parser<\/code> so that it could understand the new syntax in the underlying source code.<\/li>\n\n\n\n- April 15, 2024 \u2014 [58009]<\/a> introduces type annotations for optional types,
?array<\/code> instead of array<\/code>, which the updated parser could parse, but which phpDocumentor\/Reflection<\/code> did not recognize. The Reflection<\/code> library extracts useful information from the parsed form of the source code, but had no code path for nullable types. Once the new syntax appeared in the source code, it needed to be updated <\/a>to add the missing handling.<\/li>\n\n\n\n- June 3, 2024 \u2014 [58304]<\/a> introduces a shorthand syntax for calling a
Callable<\/code> stored in a variable. This should<\/em> be supported by the PHPPHP<\/span> The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher<\/span><\/span><\/span> parser and Reflection<\/code>, but it isn\u2019t. It would need an update at least to the Reflection<\/code> library to handle. Given that it is an odd construct with a semantically-equivalent counterpart, it was modified in [61624]<\/a> to prevent it from becoming an immediate issue going forward.<\/li>\n\n\n\n- August 27, 2025 \u2014 [60684]<\/a> introduces anonymous classes, which leads to a crash when
Reflection<\/code> tries to extract its name. There is no name, so it must make one up: class@anonymous<\/code>.<\/li>\n<\/ul>\n\n\n\nThere have only been four kinds of new syntax that broke the documentation generation since WordPress 6.4, but the code in WordPress 7.0 introduces several new syntax forms which need updating before the documentation can be regenerated:<\/p>\n\n\n\n
\n- The AI client introduces visibility on class constants and nullable types for class properties.<\/li>\n\n\n\n
- The collaboration feature\u00a0introduce array initialization of class properties.<\/li>\n<\/ul>\n\n\n\n
Work has already been explored for making another incremental step to update the underlying PHP parser, and this should hopefully resolve these new breakages.<\/p>\n\n\n\n
The underlying PHP parser is somewhat comprehensive, but the adapter layer is more as-needed<\/em>. When syntax forms aren\u2019t present in the WordPress codebase there\u2019s no need for them to exist in the documentation generator. Typically, when these new forms appear it shouldn\u2019t take too much effort to update the adapter to add support for them. It can<\/em> be harder though when updating PHP versions introduces new deprecations and when dependency updates involve backwards-incompatible changes. For example, updating to the next version of the phpDocumentor\/Reflections<\/code> library would require an almost complete rewrite of the adapter layer.<\/p>\n\n\n\n\n- July 13, 2025 \u2014 Work starts in PR#247<\/a> to rewrite the documentation generation with a new parser, a new adapter, and a new runner. This work incorporates PHPStan so that the more advanced types appear in the documentation.<\/li>\n\n\n\n
- September 28, 2025 \u2014 An attempt is made in PR#248<\/a> to filterFilter<\/span> Filters are one of the two types of Hooks https:\/\/codex.wordpress.org\/Plugin_API\/Hooks<\/a>. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output.<\/span><\/span><\/span> out unsupported syntax using PCRE patterns.<\/li>\n\n\n\n
- February 11, 2026 \u2014 Minimal updates are proposed in PR#250<\/a> (and in PR#249<\/a> and PR#251<\/a>) to update the underlying
nikic\/php-parser<\/code> dependency and liberate the process. The Reflection<\/code> library is forked from its older version to adopt only those changes necessary to upgrade far enough to support CoreCore<\/span> Core is the set of software required to run WordPress. The Core Development Team builds WordPress.<\/span><\/span><\/span>\u2019s code (in PR#721<\/a>).<\/li>\n\n\n\n- February 17\u201319, 2026 \u2014 The JSONJSON<\/span> JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML.<\/span><\/span><\/span> blob which represents the content of the documentation is generated from
6.9.1<\/code> and differences from the latest-working version are ironed out.<\/li>\n\n\n\n- February 23, 2026 \u2014 https:\/\/developer.wordpress.org\/reference is updated with documentation for WordPress as of
6.9.1<\/code>.<\/li>\n<\/ul>\n\n\n\nFuture direction<\/h2>\n\n\n\n
What comes next is making sure that WordPress 7.0 can ship with updated reference documentation. That\u2019s essential.<\/p>\n\n\n\n
After that, work will continue on supporting PHPStan type annotations and on being able to generate documentation previews. The existing process is tightly coupled to the production system which hosts the documentation. It needs to be isolated into a Playground blueprint, at which point a preview can be generated on every PR and developers will be able to see the impact of changes before the WordPress release, and hopefully notice and fix any issues that arise before they are published publicly.<\/p>\n\n\n\n
The process for generating and deployingDeploy<\/span> Launching code from a local development environment to the production web server, so that it's available to visitors.<\/span><\/span><\/span> documentation updates is in dire need of its own documentation. A challenge in this current crisis has been knowing where to run updates and what updates to run. It\u2019s one thing to parse the source code and produce the raw content, but another thing to have access to and awareness of the public servers.<\/p>\n\n\n\nA contributing factor to this breakdown was a failure to notify developers when source code changes broke the documentation generation process. A new CI job to run the parser could highlight these issues and raise awareness before problems escalate or cascade. That hopefully will not involve too much work, but needs to be undertaken by someone willing to push through the changes.<\/p>\n\n\n\n
Finally, there is a backlog of feature requests for the documentation: new alerts, supporting pass-by-reference parameters, improving recognition of rarer code patterns, etc\u2026 Once the process is running smoothly and developers are able to recreate the system locally, the normal develop cycle should resume.<\/p>\n\n\n\n
Props<\/h2>\n\n\n\n
Thanks to @<\/span>jonsurrell<\/a> for reviewing this post prior to publishing.<\/p>\n