wp_strip_inline_note_markers( string $block_content ): string
- Since
- 7.1.0
- Source
wp-includes/comment.php:4575
Description
Inline notes - notes anchored to a text selection within a block rather than the whole block - are anchored in raw block content with <mark class="wp-note" data-id="N">...</mark> so the marker survives edits, but the public HTML should not expose note metadata. This filter unwraps the marker entirely - dropping the <mark> open tag and its matching closer while keeping the marked text - so nothing leaks to the front end. The raw post_content (and the REST raw view, revisions, exports) keeps the marker so the editor can re-attach it on reload.
Only note markers are unwrapped: WP_HTML_Tag_Processor::has_class() matches the wp-note class by exact token, so a <mark> a user or plugin added (e.g. a core/text-color highlight, or an unrelated wp-note-foo class) is never flagged and survives byte-for-byte with all of its attributes intact. A naive regex would be wrong here: a \bwp-note\b word boundary also matches wp-note-foo, which is why the class check goes through the HTML API instead.
The HTML API has no public token-removal method yet, so an anonymous WP_HTML_Tag_Processor subclass unwraps each note <mark> and its matching closer directly on the parsed token stream. Walking tokens - rather than matching <mark> with a regex - means a </mark>-looking sequence inside a comment or attribute value can never be mistaken for a real tag, and a nesting stack keeps each note opener paired with its own closer so overlapping notes and any user highlight <mark> left intact still resolve correctly.
The low-level WP_HTML_Tag_Processor is used deliberately, rather than the tree-building WP_HTML_Processor. Note markers live in user-editable content, so the markup is not guaranteed to be well formed. On certain ill-formed nesting the tree builder aborts, which would leave note markers - and their metadata - in the rendered output. Scanning tokens instead removes every wp-note marker it encounters and degrades gracefully: an unbalanced or stray tag is left exactly as it was rather than corrupting surrounding markup.
Compatibility
- WordPress
- since 7.1.0
- PHP
- 7.4–8.6-dev
- 6.7.7
- 6.8.8
- 6.9.7
- 7.0.4
- 7.1.0
Present in 1 of the 5 tracked releases, added in 7.1.0, and compiles on PHP 7.4 through 8.6-dev.
Parameters
$block_contentstring- Rendered block HTML.
Return value
string- Block HTML with
wp-notemarkers unwrapped.
Performance profile
How much work a call to wp_strip_inline_note_markers() does, and what it touches: the algorithmic scaling, the Zend instruction count per call across PHP versions, the hooks it hands control to, and the core code that calls it. Measured from the compiled opcodes, not a stopwatch, so every number is identical on any machine running the same PHP version, and every function in core is ranked by cost.
- Cost class
- Light
- Scaling
- Scales with input
- Instructions
- 4–18
- Plugin surface
- None
- Called by
- 0
Touches nothing outside its own arguments.
The body loops, so the work grows with what you pass in.
Executed per call on PHP 8.5, depending on the branch taken. The body compiles to 37.
Nothing here hands control to plugin code.
Nothing in core calls this; the cost is only what you spend yourself.
What one call costs · 2 distinct outcomes
One number would be a lie: the work depends on which branch runs. These are every distinct cost wp_strip_inline_note_markers() can have, taken from its control-flow graph on PHP 8.5.
| When | Instructions | Calls it makes |
|---|---|---|
!$block_content | 4 | none |
$block_content && !->next_tag() | 18 | ->next_tag(), ->get_updated_html() |
Across PHP versions
| PHP | Compiled | Executed | Branches | Notes |
|---|---|---|---|---|
| 8.6-dev | 37 | 4–18 | 4 | |
| 8.5 | 37 | 4–18 | 4 | |
| 8.4 | 37 | 4–18 | 4 | 3 fewer instructions than PHP 8.3 |
| 8.3 | 40 | 7–21 | 4 | |
| 8.2 | 40 | 7–21 | 4 | |
| 8.1 | 40 | 7–21 | 4 | |
| 7.4 | 40 | 7–21 | 4 |
An instruction is not a fixed amount of time, so a matching count is not necessarily the same speed; what it rules out is a difference in the work itself.
Uses · 2
- str_contains()Polyfill for `str_contains()` function added in PHP 8.0.
- class@anonymous::__construct()
Source code
function wp_strip_inline_note_markers( $block_content ) { if ( ! str_contains( $block_content, 'wp-note' ) ) { return $block_content; } /* * Anonymous subclass exposing token removal, which WP_HTML_Tag_Processor * does not provide publicly yet. Removing the current token via its bookmark * span unwraps the `<mark>` (opener or closer) while keeping the text it * wraps. */ $processor = new class( $block_content ) extends WP_HTML_Tag_Processor { /** * Removes the current token, keeping any text it wraps. */ public function remove_token(): void { // Always called after next_tag() returned true, so the bookmark is set. $this->set_bookmark( 'here' ); $span = $this->bookmarks['here']; $this->lexical_updates[] = new WP_HTML_Text_Replacement( $span->start, $span->length, '' ); } }; /* * Walk every `<mark>`, tracking note nesting on a stack so each note opener * pairs with its own closer, and unwrap only the note markers. */ $mark_stack = array(); $query = array( 'tag_name' => 'MARK', 'tag_closers' => 'visit', ); while ( $processor->next_tag( $query ) ) { if ( $processor->is_tag_closer() ) { $is_note = array_pop( $mark_stack ); } else { $is_note = $processor->has_class( 'wp-note' ); $mark_stack[] = $is_note; } if ( true === $is_note ) { $processor->remove_token(); } } return $processor->get_updated_html();}Changelog
Introduced in 7.1.0.
Signature, return type and hooks compared across 1 parsed release.
About this page
- Parsed data
- Generated from the wordpress-develop 7.1.0 tag, from
src/wp-includes/comment.php, and regenerated for each WordPress release so it tracks the code rather than a snapshot of it. - Corrections
- Something wrong on this page? Report it and it gets fixed in the next regeneration.