Recommended Free Tools
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
If a JavaScript regex works in the editor but fails on the published page, don’t assume WordPress changed the ampersand—or that the regex itself is invalid. Find the first point where the exact code differs: the editor, saved post content, delivered page source, parsed browser DOM, or runtime value. That comparison tells you which part of the publishing path to investigate.
First, locate where the code changes
WordPress editing, saving, server-side rendering, and browser parsing are separate stages. Compare the same regex at each stage rather than trying fixes based on how the symptom sounds.
- Copy the exact pattern from the editor. Include its delimiters and flags, and note whether it is a regex literal such as
/a&b/or a string later passed toRegExp. - Inspect the saved post or block content. If the pattern or its surrounding markup changed or disappeared after saving, investigate the editor, block type, user permissions, and save-time sanitization.
- Inspect the published page’s source. Use the browser’s View Source feature and search for the exact pattern. This shows the HTML response before browser DOM normalization.
- Inspect the parsed DOM and runtime separately. If View Source still has the expected code, but the DOM or regex value does not, look at browser parsing, script construction, and application code.
- Compare the first differing stage. If saved content is intact but View Source differs, focus on server-side rendering: shortcode callbacks, templates, theme or plugin filters, and the output context.
This is a diagnostic sequence, not proof that any specific WordPress component rewrote the ampersand. The reported symptom alone does not identify a cause.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Check what kind of content path you are using
Custom HTML block and permissions
WordPress’s Custom HTML block documentation says that, beginning with WordPress 7.0, the block has separate HTML, CSS, and JavaScript editing panels. The CSS and JavaScript panels are available only to users with the unfiltered_html capability. The documentation also says that without this capability, WordPress can sanitize block content with wp_kses() when a post is saved or updated, stripping disallowed tags such as <script>.
#1 Best Overall
That behavior depends on the installed version, the user’s capability, and the editing surface. Check those details before concluding the saved code is unchanged. If markup is missing after saving, compare the saved block content and the user account’s permissions.
Classic Editor and other editing surfaces
The Classic Editor documentation explains that its Visual and HTML editing modes handle code differently, and notes that behavior can vary with WordPress version, editor, and plugins. It documents ampersand entity spellings such as & and &. An entity spelling in stored content is a clue to inspect the surrounding context and later output; by itself, it does not establish that WordPress broke a JavaScript regex.
Rank #2
If you use a page builder, template, or externally loaded script rather than a Custom HTML block, inspect that specific output path as well. The title does not identify a particular editor, builder, plugin, or theme.
If a shortcode or PHP template emits the script
WordPress processes registered shortcodes when the_content is displayed. The Shortcode API documentation states: “The return value of a shortcode handler function is inserted into the post content in place of the shortcode macro.”
Inspect the callback’s returned string, then check any filters applied to the content after the callback runs. For enclosing shortcodes, the callback is responsible for escaping or filtering content it includes when required. The correct handling depends on where the value goes—HTML text, an attribute, JavaScript, or a data payload—not merely on the fact that it contains an ampersand.
Match escaping to the output context
WordPress’s esc_attr() reference says the function encodes characters including & for HTML attributes such as alt, value, and title. It is not a general-purpose JavaScript-source escaping function. If PHP emits a value into an attribute, escape it for that attribute; do not apply esc_attr() indiscriminately to a whole script.
Rank #4
The context matters because HTML text, an HTML attribute, JavaScript source, and structured data are different output contexts. Trace the value to the exact place it is inserted, then use an encoding approach appropriate to that destination.
Don’t assume HTML entities are decoded inside scripts
The WordPress HTML Tag Processor reference describes SCRIPT contents as raw plaintext, unlike TITLE and TEXTAREA, where character references are decoded. It also documents specific script-content safety behavior that can affect source-level spellings, with exceptions including RegExp.prototype.source. That specialized behavior is not evidence of a general ampersand rewrite in every script.
So if View Source contains an entity-looking sequence such as & inside script text, inspect the exact delivered source and the code that produced it. Don’t assume the browser will decode it as it would in ordinary HTML text.
Why wpautop() is a weaker suspect
The wpautop() reference describes paragraph and line-break formatting. It says line breaks inside <script>, <style>, and <svg> tags are not affected. That makes wpautop() a less likely explanation for a literal ampersand changing, though the actual rendering path still needs to be checked.
Once rendering is the first point of divergence
If the saved content matches the editor but View Source does not, isolate the rendering path on a staging copy. Check the shortcode callback or template first, then investigate relevant theme and plugin filters. Disable or narrow components methodically and compare the exact source after each change. Avoid editing the live site while testing changes that could affect visitors.
Free tools Windows power users keep installed
One-click scans. No signup required.
If the source is unchanged but execution still fails, test the same pattern in a minimal page or a separate JavaScript file on staging. That helps distinguish a content-pipeline issue from a problem in the regex, script construction, or surrounding application code. A literal & in a JavaScript regex is not, on its own, evidence of invalid regex syntax; inspect the exact pattern and flags before diagnosing a regex error.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
