Runnable Code Examples Are Now Live in the Code Reference
🔗 **Source:** [Runnable Code Examples Are Now Live in the Code Reference](https://make.wordpress.org/core/2026/09/04/runnable-code-examples-are-now-live-in-the-code-reference/)
> [!note]+ Document Notes
> tags: [wordpress-core, code-reference, wordpress-playground, developer-documentation, interactive-examples]
> author: make.wordpress.org
> source: Make WordPress Core
> reference: https://make.wordpress.org/core/2026/09/04/runnable-code-examples-are-now-live-in-the-code-reference/
> date created: 2026-09-10
>
> > [!info] Generated analysis — not the author's words. Sections below are machine-written
> > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author.
> > Do not quote or attribute any other line to the named author.
>
> # 🏷️ Title: Runnable code examples are now live in the Code Reference
>
<!-- deep-read:sections start -->
## 🧭 Table of Contents
- [📝 Summary](#-summary)
- [📖 Main Content](#-main-content)
- [🗒️ Notes](#️-notes)
- [📚 References](#-references)
- [🗣️ Paraphrase](#️-paraphrase)
- [📰 Newsletter](#-newsletter)
- [✅ Action Items](#-action-items)
- [🧪 Hypotheses](#-hypotheses)
- [📊 Methodology](#-methodology)
- [❓ Questions](#-questions)
- [🔮 Future Research](#-future-research)
- [💡 Implications](#-implications)
- [🧠 Learning Styles Assessment](#-learning-styles-assessment)
- [📊 Accessibility Assessment](#-accessibility-assessment)
- [🌍 DEIB Assessment](#-deib-assessment)
- [✅ Logical Validity](#-logical-validity)
- [🛡️ DARVO Analysis](#-darvo-analysis)
- [🎯 Conclusion](#-conclusion)
- [🔄 Refactor Appendix](#-refactor-appendix--runnable-code-examples-are-now-live-in-the-code-reference)
### 🔗 References
- [✅ Action Items — Documentation and Training specifics](#-action-items)
- [📊 Accessibility Assessment — open question on the Run button](#-accessibility-assessment)
- [🔄 Refactor Appendix — atoms and permanent candidate](#-refactor-appendix--runnable-code-examples-are-now-live-in-the-code-reference)
## 📝 Summary
- **What happened.** WordPress 7.1 shipped the first two runnable code examples inside the Code Reference, executed in-browser via WordPress Playground. Only one is named: the `WP_HTML_Processor::class_list()` page, where a **Run** button executes the DocBlock example live. More examples are promised for 7.2.
- **Why it matters.** The example is authored as a fenced code block (`` ```php interactive ``) directly inside the method's DocBlock in the wordpress-develop source, not as separate content on the Code Reference website. That changes who can add one and how: it's a core patch to a PHP comment, reviewed like any other code change, not a documentation-site edit.
- **Key stakeholders.** Named credits go to three contributors — @jonsurrell, @dmsnell, @westonruter — via WordPress.org profile links. The post cross-links to both the Docs team (`+make.wordpress.org/docs/`) and the Playground team (`+make.wordpress.org/playground/`), the two teams whose review chain this feature runs through.
- **Risks and tradeoffs.** The authoring syntax has no published rules yet — the post states a handbook page "will be published shortly," meaning anyone attempting a second or third example today has only the one shipped `class_list()` case to reverse-engineer from. Coverage is also minimal: two examples total across the whole Code Reference as of this post.
- **Bottom line.** A real, working feature — not a proposal — but narrow in current scope (one confirmed method, syntax undocumented) and best treated as a preview of a direction rather than a general Code Reference capability yet.
## 📖 Main Content
The post is a short, factual Make WordPress Core announcement: WordPress 7.1 shipped the first two runnable code examples in the Code Reference, and WordPress Playground supplies the execution — the same Playground engine documented in its [PHP code snippets guide](https://developer.wordpress.org/playground/handbook/guides/php-code-snippets/). Only one example is named directly: the `WP_HTML_Processor::class_list()` Code Reference page, where selecting **Run** executes the snippet in the visitor's browser. The post doesn't name the second 7.1 example — an unstated gap, not an inference (see Questions).
The mechanism is the more interesting fact for anyone doing documentation or training work. A runnable snippet isn't hosted separately from the code it documents — it's [defined directly in the method's DocBlock](https://github.com/WordPress/wordpress-develop/blob/0c037b0de946ad08c8614e36b53193b84bb55e5f/src/wp-includes/html-api/class-wp-html-processor.php#L5433-L5444) in the WordPress core codebase, using a fenced block tagged `` ```php interactive `` instead of the plain `` ```php `` used for ordinary (non-runnable) examples elsewhere in the Code Reference. The shipped example:
````php
<?php
/**
* Generator for a foreach loop to step through each class name for the matched tag.
*
* ```php interactive
* $p = new WP_HTML_Tag_Processor( "<div class='free <egg>\tlang-en'>" );
* $p->next_tag();
* foreach ( $p->class_list() as $class_name ) {
* echo "{$class_name} ";
* }
* // Outputs: "free <egg> lang-en "
* ```
*/
public function class_list() {}
````
The example demonstrates `class_list()`'s HTML-entity decoding: the class attribute contains a literal `<egg>` substring, and the generator yields it decoded (`<egg>`) alongside the other class tokens. It's a genuinely instructive choice of example — it shows non-obvious parser behavior, not just syntax — but its complexity also means it isn't a trivial template a documentation contributor could copy for an unrelated method without understanding both the target method and the interactive-fence syntax.
The post closes by stating that a handbook page documenting the full authoring syntax "will be published shortly" — meaning that as of this post, the syntax rules exist only as this one worked example and whatever is inferable from it. No security, scope, or style guidance for authors is stated or linked.
## 🗒️ Notes
- **Feature scope, exact:** two runnable examples exist as of WP 7.1; only `WP_HTML_Processor::class_list()` is named. "More are coming in 7.2" is a stated roadmap commitment, not yet delivered.
- **Execution engine:** WordPress Playground (browser-based, WASM PHP+WordPress) — same engine used elsewhere for PR previews and blueprint demos, not a new server-side sandbox.
- **Authoring location:** inside the PHP DocBlock of the documented method, in the wordpress-develop repo — confirmed via the linked GitHub permalink to `class-wp-html-processor.php`, lines 5433–5444, at commit `0c037b0de946ad08c8614e36b53193b84bb55e5f`.
- **Authoring syntax:** the fence language tag is `php interactive` (vs. plain `php` for static examples). This is the single mechanical detail the post reveals about how to make an example runnable.
- **Governance signal:** props to three named contributors, and the post is explicitly cross-posted/pinged to the Docs and Playground teams — the two teams likely to own the not-yet-published authoring handbook page.
- **What's missing from the post:** the name of the second 7.1 example, a publish date or tracking ticket for the handbook page, and any statement about review or security criteria for what a runnable example is allowed to do.
## 📚 References
- [WP_HTML_Processor::class_list() — Code Reference](https://developer.wordpress.org/reference/classes/wp_html_processor/class_list/) — the one confirmed live runnable example.
- [WordPress Playground — PHP code snippets guide](https://developer.wordpress.org/playground/handbook/guides/php-code-snippets/) — the execution mechanism the post credits as "powered by."
- [DocBlock source, class-wp-html-processor.php#L5433-L5444 (GitHub)](https://github.com/WordPress/wordpress-develop/blob/0c037b0de946ad08c8614e36b53193b84bb55e5f/src/wp-includes/html-api/class-wp-html-processor.php#L5433-L5444) — the actual authored example, in source.
- [make.wordpress.org/docs/](https://make.wordpress.org/docs/) — Docs team, cross-posted.
- [make.wordpress.org/playground/](https://make.wordpress.org/playground/) — Playground team, cross-posted.
- [@jonsurrell — WordPress.org profile](https://profiles.wordpress.org/jonsurrell/)
- [@dmsnell — WordPress.org profile](https://profiles.wordpress.org/dmsnell/)
- [@westonruter — WordPress.org profile](https://profiles.wordpress.org/westonruter/)
- [Original post — Make WordPress Core, 2026-09-04](https://make.wordpress.org/core/2026/09/04/runnable-code-examples-are-now-live-in-the-code-reference/)
## 🗣️ Paraphrase
WordPress 7.1 adds the first runnable code examples to the Code Reference: on the `class_list()` method page, a Run button executes the DocBlock's example live in the browser through WordPress Playground, with a second (unnamed) example also shipped and more planned for 7.2. What makes an example runnable is a fence tag — `` ```php interactive `` instead of plain `` ```php `` — written directly into the method's PHP DocBlock in the core codebase, so the example ships with the same commit as the code it documents rather than living on a separate documentation page.
The post is candid about being incomplete: full authoring instructions don't exist yet ("will be published shortly"), so right now the only reference for how to write one of these is the single shipped `class_list()` case. Credit goes to three named contributors, and the announcement pings both the Docs and Playground teams, signaling this is a cross-team feature still finding its documented shape.
## 📰 Newsletter
Small but genuinely useful ship from WordPress core: the Code Reference now has its first two runnable code examples, powered by WordPress Playground — click Run on the `WP_HTML_Processor::class_list()` page and the example executes right in your browser, no local environment required. The trick is a `` ```php interactive `` fence written into the method's DocBlock in core itself, so the example lives with the code it documents. Coverage is still just two methods, and the authoring handbook page is "coming shortly" rather than live — worth watching if you write or teach against the Code Reference, since this changes both how examples get contributed (a core patch, not a docs-site edit) and how you can demo core APIs without spinning up a sandbox by hand. Props: @jonsurrell, @dmsnell, @westonruter.
## ✅ Action Items
#### DevRel
- **Developer advocacy:** Strong "show, don't tell" demo for talks and office hours — pull up the `class_list()` Code Reference page live and click Run instead of narrating a static snippet. Scope any public demo to that one confirmed method; don't imply broad coverage that doesn't exist yet.
- **Education:** Nothing to teach on the authoring side until the promised handbook page ships — flag it for follow-up rather than building content against an undocumented syntax now.
- **Developer experience:** Removes a real friction step — a contributor or learner reading the `class_list()` page can run the example without cloning wordpress-develop or building a local Playground blueprint themselves.
- **Developer marketing:** Worth a short "try it yourself" post or clip once coverage passes a handful of methods and the handbook page is live; premature at two examples.
- **Community management:** Not applicable — the post opens no discussion thread or feedback mechanism of its own.
- **Internal/external/cross-project:** The post is implicitly cross-posted to Docs and Playground (via the `+make.wordpress.org/docs/` and `+make.wordpress.org/playground/` footer links) — that's the review chain to loop in before proposing new interactive examples elsewhere.
#### OSPO
- Not applicable to this source — no licensing, SBOM, or governance-policy content; this is a documentation feature announcement.
#### Community
- Not applicable to this source — no maintainer, contributor-program, or sponsor content beyond standard props credit.
#### WordPress
- **Core:** The interactive fence is authored in a core PHP DocBlock and reviewed as a code patch (see the linked GitHub permalink) — Core should expect future interactive-example patches to route through normal code review, including scrutiny of what a runnable example is allowed to execute.
- **Playground:** Named as the execution engine ("powered by WordPress Playground"); the team is the natural owner of any sandboxing/security questions this raises as coverage grows.
- **Meta:** The Code Reference generator now needs to detect the `php interactive` fence and render a Run affordance — worth confirming whether that's DevHub-specific tooling other reference sites would need to replicate.
- **Documentation:** see the dedicated section below.
- **Training:** see the dedicated section below.
- **Accessibility:** The post gives no information on whether the Run control and its output are keyboard-operable or screen-reader-announced — flagged as an open question in the Accessibility Assessment below; worth a direct ask to the Playground/Meta teams before this pattern is taught or promoted as a teaching tool.
- All other WordPress subteams (Core Performance, Core AI, Core Program Team, Mobile, Community, Marketing, Support, Design, Photos, TV, Polyglots, CLI, Hosting, Tide, Openverse, Themes, Plugins) — not applicable to this source.
#### WordPress > Documentation
- **Contribution model changes.** An interactive example is authored as a `` ```php interactive `` fence inside a method's DocBlock in wordpress-develop, not as an edit on the Code Reference website. Contributing one now means a core patch/PR with props review — PHP and DocBlock familiarity plus a git workflow — a higher bar than a HelpHub-style content edit.
- **No style or security guidance exists yet.** The post states the authoring handbook "will be published shortly." Until it ships, anyone attempting a second example has only the one shipped `class_list()` case to work from, with no documented rules on scope, formatting, or what a runnable example should or shouldn't do.
- **Tooling dependency.** The Code Reference generator has to detect the `interactive` fence tag and render the Run control — worth confirming with Meta whether this is generic Code Reference tooling or specific to this one page template.
- **Trackable goal.** The post's own commitment ("more are coming in 7.2") is a natural metric to track — e.g., percentage of Code Reference method pages carrying a runnable example, checked again at 7.2.
#### WordPress > Training
- **Curriculum opportunity, once coverage grows.** A Learn WordPress lesson on the HTML API could link straight to the live `class_list()` Run button instead of maintaining a separate Playground blueprint or asking learners to set up a local environment — one fewer setup step for any lesson touching that specific method.
- **Premature to build a lesson around "the Code Reference is interactive" today.** Only `class_list()` is confirmed; the second 7.1 example isn't named. A lesson framed around broad interactivity would overstate current coverage — scope any lesson content to the specific methods confirmed live.
- **Same documentation gap blocks trainers.** The missing handbook page that blocks Documentation contributors also blocks trainers who'd want to author their own interactive snippets for lesson content — worth asking Docs/Playground whether the `interactive` fence syntax works outside a core DocBlock (e.g., in Learn WordPress lesson markup) or is core-only.
#### The WPOCC
- Not applicable to this source — no fellowship, funding, or governance content.
#### FAIR
- Not applicable to this source — no federation, provenance, or governance-artifact content.
## 🧪 Hypotheses
- H1: Coverage expands from 2 to a materially larger number of Code Reference pages by the WordPress 7.2 release, matching the post's stated commitment.
- H2: The DocBlock-patch contribution path produces fewer new interactive examples per release than a hypothetical direct-edit path on the Code Reference site would, because it requires a core PR rather than a documentation-site edit.
- H3: Publishing the promised authoring handbook page measurably increases the rate of new interactive-example patches from contributors who are not committers.
- H4: Learners using the live Run button on a Code Reference page complete the demonstrated task faster, or with fewer setup-related support questions, than learners using the equivalent static code block plus a separately-built Playground blueprint.
- H5: The Run control and its rendered output meet WCAG 2.2 AA keyboard-operability and screen-reader criteria without additional work, because it reuses the existing WordPress Playground UI rather than introducing a new interactive component.
### 📊 Methodology
- H1: Count Code Reference method pages carrying a `php interactive` fence at 7.1 release and again at 7.2 release; compare against the "more are coming in 7.2" claim.
- H2: Compare merge rate and time-to-merge for interactive-example patches vs. ordinary DocBlock/documentation patches over the same period, once enough interactive-example patches exist to sample.
- H3: A/B or before/after comparison of contribution volume from non-committer accounts in the weeks immediately before vs. after the handbook page publishes.
- H4: A moderated usability test — same task (understand and reproduce `class_list()`'s entity-decoding behavior) — timed and scored for two groups, one given only the Code Reference page, one also given a manually-built local or Playground-based test environment.
- H5: A direct keyboard-only and screen-reader pass (NVDA/VoiceOver) against the live `class_list()` Code Reference page's Run control, scored against WCAG 2.2 SC 2.1.1, 2.4.3, 4.1.2.
### ❓ Questions
- What is the second runnable example shipped in WordPress 7.1? The post confirms two exist but names only `class_list()`.
- Is there a tracked ticket or target date for the "shortly" handbook page, or is "shortly" the only commitment given?
- What review criteria, if any, apply to a proposed interactive example beyond normal code review — is there a security or scope checklist for what a runnable snippet is permitted to do inside the Playground sandbox?
- Does each Run click spin up an isolated Playground instance per visitor/session, or is execution state shared or cached in any way?
- Can the `` ```php interactive `` syntax be authored outside a core method DocBlock — e.g., in a plugin's own DocBlocks, or in Learn WordPress lesson content — or is it currently Code-Reference-and-core-only?
### 🔮 Future Research
- No stated plan for measuring or reporting interactive-example coverage growth over time; a simple tracked count (like the one proposed in Documentation Action Items above) doesn't yet exist.
- No accessibility statement for the Run control or its output — worth closing before this pattern is promoted more widely in training material (see Accessibility Assessment).
- No stated plan for whether other WordPress documentation surfaces (REST API Reference, Block Editor Handbook) will adopt the same `interactive` fence convention, which affects how durable this syntax choice is worth treating.
- No stated retention/versioning policy for interactive examples when the documented method's signature or behavior changes across releases — a static code block silently going stale is a known problem; an interactive one that silently starts producing wrong output is a sharper one.
### 💡 Implications
- **Practice (Documentation).** Contributing a runnable example now requires a core PR and PHP/DocBlock fluency, not a documentation-site edit — a real bar-raise for who can add one, worth naming explicitly in any onboarding guidance for new docs contributors, especially before the promised handbook page exists to lower that bar.
- **Practice (Training).** For the one confirmed method, live in-browser execution replaces a maintained local or Playground-blueprint demo — a genuine reduction in a trainer's setup burden, but not yet broad enough to redesign a course module around; treat it as a single strong example to point to, not a platform to teach from generally yet.
- **Practice (DevRel).** A concrete, low-effort live-demo moment for talks and office hours today, at the cost of only covering one named method — scope demos accordingly rather than implying the whole Code Reference is now interactive.
- **Policy/governance.** None stated in the source; no review-criteria or security-policy language accompanies the feature launch, which is itself a governance gap worth flagging to the Docs/Playground teams before the surface area grows.
- **Security.** Arbitrary PHP now executes client-side in a visitor's browser via Playground's WASM sandbox when they click Run — not a server-side risk, but worth a documented scope/review policy before the pattern scales past two hand-picked examples, since the post states none exists yet.
- **Education.** The single clearest exportable idea: pointing learners at a live, runnable reference page removes an entire category of "does your local setup even match mine" support friction — worth adopting as a standing preference for any WordPress teaching content that already has (or could get) a Code Reference page.
- **Funding models.** Not applicable to this source.
### 🧠 Learning Styles Assessment
- **Reading level estimate:** Flesch-Kincaid Grade Level ≈ 9. Basis: short declarative sentences, technical vocabulary (DocBlock, fence, generator) used without definition, and one inline code example — typical of a Make WordPress core-contributor announcement, not written for a general audience.
#### 👀 Visual learners
- **Present:** one code block showing the actual DocBlock/fence syntax.
- **Improve:** a screenshot of the actual `class_list()` Code Reference page with the Run button and its output visible — the post describes the UI but never shows it.
#### 🔊 Aural learners
- **Present:** none — text-only announcement, no audio or narrated version.
- **Improve:** a 60–90 second screen-recording walkthrough of clicking Run and reading the output would suit this format well, given how visual the actual feature is.
#### 🗣️ Verbal learners
- **Present:** the post defines the mechanism in one clear sentence ("The part that makes it interactive is the `` ```php interactive `` language tag on the code fence").
- **Improve:** a one-line definition of "DocBlock" for readers outside core-contributor circles; the term is used without explanation.
#### 🧩 Kinesthetic learners
- **Present:** this is the strongest-fit learning style for the feature itself — the Run button is a literal hands-on, try-it-now interaction, and it's the one thing the post is announcing.
- **Improve:** none needed for the feature; the post itself could more directly invite readers to go click it ("try it now" framing) rather than only describing that it exists.
#### 🧠 Logical learners
- **Present:** clear before/after logic (static examples vs. `interactive`-tagged ones) and a direct source-code citation for the mechanism.
- **Improve:** a short table contrasting the plain `php` fence vs. the `php interactive` fence would make the syntax distinction more scannable than prose alone.
#### 🧑🤝🧑 Social learners
- **Present:** props credit to three named contributors.
- **Improve:** no discussion prompt or call for feedback on the new syntax — inviting docs contributors to try authoring one and report friction would extend this into a social/community loop.
#### 🧘♀️ Solitary learners
- **Present:** fully self-serve — the described experience (click Run on a page, read the output) requires no coordination with anyone else.
- **Improve:** none needed; this is already well-suited to independent exploration.
#### 🌿 Naturalistic learners
- **Present:** none — no ecological or systems-in-nature framing in a documentation-tooling announcement.
- **Improve:** not a natural fit for this content; no changes recommended.
### 📊 Accessibility Assessment
*Assessed from the announcement text only — the actual Code Reference page and its Run control were not visually or interactively reviewed, and the source post makes no accessibility claims.*
#### Screen reader semantics
- **Not stated.** The post never describes whether the Run button is a properly labeled, focusable control, or whether the code output that appears after running is announced to assistive technology (e.g., via an ARIA live region) or requires the user to manually navigate to find it. **Open question — flag for direct review before this pattern is taught or promoted** (maps to WCAG 2.2 SC 4.1.2 Name, Role, Value; SC 4.1.3 Status Messages).
#### Keyboard navigation
- **Not stated.** No information on whether the Run button and any output panel are reachable and operable by keyboard alone, without a mouse. **Open question — the source gives no basis to confirm this either way** (maps to WCAG 2.2 SC 2.1.1 Keyboard; SC 2.4.3 Focus Order).
#### Contrast and readability
- **Not observed** — the post includes no screenshot of the rendered Run control or output panel, so contrast can't be assessed from this source (WCAG 2.2 SC 1.4.3, SC 1.4.11).
#### Text resizing and reflow
- **Not observed** — no information on how the Code Reference page's interactive panel behaves at 200% zoom or on narrow viewports (SC 1.4.4, SC 1.4.10).
#### Media and captions
- **Not applicable** — text-only announcement, no audio/video content of its own.
#### Forms and interactions
- **Partially described, not fully specified.** The Run button is a real interactive control (this is the entire feature), but the post describes only its function ("select Run... and the code example will run"), not its accessible implementation. Given the feature is specifically about a new interactive UI element embedded across Code Reference pages, this is the single most important accessibility gap to close before wider rollout (SC 2.5.3 Label in Name; SC 2.4.6 Headings and Labels for how the Run affordance is exposed).
#### Standards reference
- Gaps above map to WCAG 2.2 AA: 1.4.3, 1.4.4, 1.4.10, 1.4.11, 2.1.1, 2.4.3, 2.4.6, 2.5.3, 4.1.2, 4.1.3. Every item requires direct testing of the live `class_list()` Code Reference page — none of it can be confirmed from the announcement text alone, and the post does not address accessibility at all.
### 🌍 DEIB Assessment
#### Cultural breadth
- **Present:** none beyond a single English-language technical example; no multi-region or multilingual framing.
- **Improve:** not clearly applicable to a core-engineering announcement of this scope; no specific gap to flag.
#### Inclusive language
- **Present:** plain, gender-neutral technical language throughout; no idioms.
- **Improve:** none needed.
#### Neurodiversity support
- **Present:** short, consistently structured paragraphs; one clearly delimited code example.
- **Improve:** the post interleaves the mechanism explanation with the code block without a subheading separating "what shipped" from "how it works" — a short subheading split would aid scanning.
#### Representation
- **Present:** three contributors credited by WordPress.org handle only (@jonsurrell, @dmsnell, @westonruter); no names, pronouns, or other identity markers are stated or inferred here.
- **Improve:** not applicable to critique — handle-only crediting is the standard Make WordPress props convention, not a representation gap.
#### Psychological safety
- **Present:** neutral, low-stakes technical tone; no sensitive content.
- **Improve:** none needed.
### ✅ Logical Validity
#### Strong reasoning
- **Verifiable, falsifiable claims throughout.** "WordPress 7.1 shipped the first two runnable code examples" and "more are coming in 7.2" are concrete, checkable commitments (see Hypothesis H1) rather than vague marketing language — a strength for an announcement post, since readers can confirm or disconfirm both claims against future releases.
- **Direct source citation for the technical claim.** The statement that examples "can be defined in the DocBlock of each method directly in the WordPress codebase" is backed by a permalink to the exact file and line range — the claim isn't just asserted, it's pointed at its own evidence.
#### Fallacies
- **None identified.** This is a factual feature announcement with no persuasive argument, comparison, or claim of superiority to assess — there's no rhetorical structure here to critique. Noted explicitly rather than invented: forcing a fallacy analysis onto a status update would misrepresent the source.
#### Tone of voice
- Terse, factual, contributor-to-contributor register typical of Make WordPress team-blog posts — no marketing language, minimal hedging, ends with standard props credit and cross-team pings.
### 🛡️ DARVO Analysis
- **Deny:** Not applicable to this source — no accusation exists to deny; this is a feature-ship announcement.
- **Attack:** Not applicable to this source — no critic, accuser, or opposing party is named or addressed anywhere in the post.
- **Reverse victim/offender:** Not applicable to this source — no victim/offender framing of any kind appears in a documentation-tooling announcement. DARVO describes a rhetorical move by an accused party responding to an accusation; there is no accusation here for it to apply to.
## 🎯 Conclusion
WordPress 7.1 ships a real, working feature — one Code Reference page (`class_list()`, plus an unnamed second example) now runs its documented code example live in the browser via WordPress Playground, through a `` ```php interactive `` fence authored directly in the method's DocBlock. The mechanism is genuinely useful for teaching and demoing, but it's early: coverage is two examples, the authoring syntax has no published rules yet, and the post never addresses whether the Run control itself is keyboard- or screen-reader-accessible. Practical next step for documentation and training work: track coverage growth toward the stated 7.2 commitment, hold off building a full curriculum module around this until coverage broadens past one confirmed method, and raise the unanswered accessibility question with the Playground/Docs teams before promoting the Run button as a teaching pattern.
## 🔄 Refactor Appendix — Runnable code examples are now live in the Code Reference
> Density: 3 Literature atoms (H4), 1 Permanent candidate (H4).
> Konik claim-header rules: present tense, declarative, ≤10 words, searchable, unique.
> Atomicity: one declarative sentence per atom.
### 📚 Literature Atoms (H4)
#### [H1] First runnable Code Reference examples ship in WP 7.1
> [!quote]
> WordPress 7.1 shipped the first two runnable code examples in the Code Reference.
**Context & use**:
- Opening sentence of the post — states the headline fact the entire announcement is built around.
- Only one of the two examples is named (`class_list()`); the second is not identified anywhere in the source.
**Tags**: #xref
<!-- atomicity: 1 idea ✓ -->
#### [H2] Run button executes the example live in-browser
> [!quote]
> select Run button in the code snippet and the code example will run right there, in your browser.
**Context & use**:
- Describes the actual user interaction on the `WP_HTML_Processor::class_list()` Code Reference page.
- The mechanism this analysis's Accessibility Assessment flags as unaddressed by the source — no statement on keyboard or screen-reader operability of this control.
**Tags**: #xref
<!-- atomicity: 1 idea ✓ -->
#### [H3] Examples are authored inside the method's DocBlock
> [!quote]
> Runnable snippets can be defined in the DocBlock of each method directly in the WordPress codebase.
**Context & use**:
- Establishes that authoring location is core source code, not the documentation website — the fact driving the Documentation Action Items above (core-patch contribution path, no separate docs-site edit).
- Backed by a direct GitHub permalink to the exact DocBlock in `class-wp-html-processor.php`.
**Tags**: #xref #addendum
<!-- atomicity: 1 idea ✓ -->
### 🧠 Permanent Candidates (H4)
#### [P1] Docs co-located with source code outlast a separate handbook page
**Claim** (Courtney's voice): A code example authored inside the DocBlock of the function it documents stays synced with that function, because it ships in the same commit — a separate documentation-site example doesn't get that guarantee.
**Evidence pointer**: [[#H3]]
**Scope & conditions**: Holds for method/class-level API reference content with a runnable execution engine available (here, WordPress Playground); doesn't extend to conceptual or tutorial content that isn't anchored to a single function signature, and doesn't by itself guarantee the example is reviewed for accessibility or security — both were unaddressed in this source.
**Links** (≥1 with annotation):
- [[Docs-as-code]] — because extends: DocBlock-embedded runnable examples take docs-as-code one step further by making the co-located example executable, not just co-located.
- [[Contribution-barrier tradeoffs]] — because contrasts on: the same co-location that keeps examples in sync also raises the contribution bar from a documentation-site edit to a core PHP patch.
<!-- atomicity: 1 idea ✓ -->
### ✏️ Fleeting Queue
- [F1] Find out what the second WP 7.1 runnable example is — the post names only `class_list()`. — https://make.wordpress.org/core/2026/09/04/runnable-code-examples-are-now-live-in-the-code-reference/ #xref
- [F2] Once the promised authoring handbook page publishes, check whether the `` ```php interactive `` fence syntax works outside a core method DocBlock (e.g., in a plugin, or in Learn WordPress lesson content). — #addendum
### → Things 3 (max 2 actions)
- [ ] Ask the Docs/Playground teams (via make.wordpress.org/docs/ or make.wordpress.org/playground/) whether the Run control on Code Reference pages has been tested for keyboard operability and screen-reader announcement — context #accessibility #things
- [ ] Once the authoring handbook page ships, review it against this note's Documentation Action Items (contribution-bar, style/security gaps) and update this file's open questions — context #followup #things
<!-- deep-read:sections end -->
📄 **Full text:** [[Full Document Contents/Articles/Runnable Code Examples Are Now Live in the Code Reference.md|Runnable Code Examples Are Now Live in the Code Reference by WordPress Core Team]]
## Highlights
- select Run button in the code snippet and the code example will run right there, in your browser. ([View Highlight](https://read.readwise.io/read/01m25w2b410mt23mkfwgc4qc6p))
- Note: The post never says whether the Run button is keyboard-operable or screen-reader announced. Open question.
- Tags: xref, developer-documentation