Formatting: Fix wptexturize encoding ampersands inside script/pre/code when content contains < - #12694
Conversation
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the Core Committers: Use this line as a base for the props when committing in SVN: To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
Test using WordPress PlaygroundThe changes in this pull request can previewed and tested using a WordPress Playground instance. WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser. Some things to be aware of
For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation. |
There was a problem hiding this comment.
Pull request overview
This PR fixes a wptexturize() edge case where ampersands inside no-texturize blocks (notably <script>, and also <pre>/<code>) could be incorrectly encoded when the block content contains a raw <, due to the HTML-splitting step misclassifying part of the content as an element delimiter.
Changes:
- In
wptexturize(), only perform&→&encoding for HTML delimiters when not currently inside a no-texturize tag stack. - Add PHPUnit coverage to prevent regressions for
<script>,<pre>, and<code>cases, plus a check that&in real HTML attributes is still encoded.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
src/wp-includes/formatting.php |
Guards ampersand-encoding in HTML delimiters so script/pre/code content isn’t corrupted when raw < causes mis-splitting. |
tests/phpunit/tests/formatting/wpTexturize.php |
Adds regression test coverage for the no-texturize + raw < + & behavior and preserves attribute-encoding expectations. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| /* | ||
| * Replace each & with & unless it already looks like an entity, | ||
| * but only when outside no-texturize tags like <script> and <pre>. | ||
| * | ||
| * When a no-texturize tag contains a raw '<' character (e.g. JavaScript | ||
| * like `if(a<b)`), wp_html_split() misidentifies that content as an HTML | ||
| * element delimiter. Encoding & inside such a token would corrupt the | ||
| * script or preformatted content. | ||
| */ |
| * @ticket 43785 | ||
| * @covers ::wptexturize | ||
| */ | ||
| public function test_no_texturize_ampersand_inside_script_with_less_than() { |
…e when content contains < When a no-texturize tag (script, pre, code, etc.) contains a raw '<' character — as in JavaScript like `if(a<b)` — wp_html_split() misidentifies the content after that '<' as an HTML element delimiter. Previously, the texturize loop would encode '&' characters in that false delimiter (e.g. '&&' became '&WordPress#38;&WordPress#38;'), corrupting script content. Fix: only run the '&' → '&WordPress#38;' substitution when we are not already inside a no-texturize tag stack. Real HTML tag attributes (e.g. <a href="foo&bar">) are only encountered at the top level, so the fix does not affect them. This became more user-visible in WordPress 7.0, which introduced a dedicated JavaScript panel in the Custom HTML block where users enter code that can contain '<' comparisons. Fixes #43785.
da9307a to
fcc0f49
Compare
Summary
wptexturize()corrupts&characters inside<script>,<pre>, and<code>blocks when the block content contains a raw<character (e.g. JavaScript likeif(a<b)).Root cause
wp_html_split()splits content at every<it recognises as an HTML tag boundary. When a no-texturize block contains<— as in<script>if(a<b)window&&document</script>— the split produces a token like<b)window&&document</script>. Thewptexturize()loop then treats that token as an HTML element delimiter and encodes&&→&&, corrupting the output.This was introduced in [36036] and became significantly more user-visible in WordPress 7.0, which added a dedicated JavaScript panel to the Custom HTML block. Valid JS entered there (e.g.
if (1 < 2 && 2 < 3) { … }) can silently break on the frontend.Fix
Only run the
&→&substitution when theno_texturize_tags_stackis empty (i.e. we are not already inside a<script>,<pre>,<code>, etc. block). Real HTML tag attributes are only encountered at the top level, so this change has no effect on them.Tests
Added
test_no_texturize_ampersand_inside_script_with_less_than()with 5 assertions covering<script>(with and without attributes),<pre>,<code>, and a regression assertion that&in real HTML attributes is still encoded correctly.Fixes https://core.trac.wordpress.org/ticket/43785