WordPress’s wptexturize filter is silently mangling inline JavaScript, turning the logical && operator into the HTML entity && and breaking scripts that run inside shortcodes.
The problem surfaced for a developer who maintains a set of calculator shortcodes. After weeks of flawless operation, the submit buttons stopped responding. No PHP warnings, no console errors, and the HTML inspected clean—until the rendered source revealed if (!isNaN(bf) && bf > 0). The single syntax error prevented the entire script block from executing.
Why the filter matters
WordPress processes post content through a series of filters before it reaches the browser. wptexturize is the first of those filters; it converts straight quotes to typographic curly quotes, replaces multiple hyphens with em-dashes, and sanitises ampersands. The filter assumes it is dealing with prose, not code. When a shortcode injects an inline <script> tag, the filter still runs, treating the JavaScript as ordinary text. The ampersand in && is therefore escaped to &, which the browser interprets as a literal string rather than the logical AND operator.
Developers who embed any JavaScript directly in post content—calculators, form validators, interactive widgets—are vulnerable. The issue is not limited to calculators; any inline script that uses &&, &, or similar characters can be corrupted. Because the transformation happens server-side, the browser never sees the original code, and the error does not surface as a typical JavaScript exception.
Who is affected and what they lose
- Site owners: a broken calculator or form can frustrate visitors, increase bounce rates, and erode trust.
- Developers: hours spent hunting “ghost” bugs that leave no trace in logs or console output.
- Content editors: may unknowingly break functionality while editing pages that contain shortcodes.
The cost is not just time; it can translate into lost conversions, especially on sites that rely on custom calculators for pricing, loan estimates, or health assessments.
What the filter does, in plain terms
- Detects straight quotes – replaces
'and"with ‘smart’ typographic versions. - Cleans ampersands – converts
&to&unless it already forms a valid HTML entity. - Applies to the entire content string – including anything inside
<script>tags that are generated by shortcodes.
When the filter encounters &&, it sees two ampersands that are not part of an existing HTML entity, so it escapes each one individually, resulting in &&.
How to stop the corruption
1. Turn off the filter for pages that contain code
add_action( 'template_redirect', function () {
if ( is_page() ) {
remove_filter( 'the_content', 'wptexturize' );
remove_filter( 'widget_text_content', 'wptexturize' );
}
} );
This snippet disables wptexturize only on page templates, preserving the typographic improvements for posts and other content types. It also removes the filter from widget text, which can be a secondary source of inline scripts.
2. Rewrite logic to avoid &&
If removing the filter is not desirable, refactor the JavaScript so that the logical AND operator is not needed:
// Original
if (a && b) { … }
// Refactored
var ok = a;
if (ok) { ok = b; }
if (ok) { … }
While this adds a few extra lines, it eliminates the ampersand that triggers the filter. The approach works for simple conditions but can become unwieldy for complex expressions.
3. Externalise all scripts
The most robust solution is to enqueue JavaScript files instead of embedding code inline:
wp_enqueue_script( 'my-calculator', get_template_directory_uri() . '/js/calculator.js', [], null, true );
Enqueued scripts bypass the_content filters entirely. They also benefit from browser caching and can be minified or bundled with other assets.
Detecting the issue in the wild
When a script stops running without obvious errors, view the page source (not the DOM inspector) and search for &. If you find it inside a <script> block, the filter is the culprit. The problem will not appear in the console because the browser never receives a syntactically valid script to parse.
Counterpoint: why keep wptexturize?
wptexturize improves readability on the front end. Curly quotes and proper dash characters give prose a polished look, and many site owners consider that a non-negotiable aesthetic feature. Removing the filter globally would revert text to its raw, typographically plain state.
The compromise is selective disabling: turn the filter off only where code lives, or use a custom shortcode that explicitly marks its output as safe from texturizing. WordPress already provides wp_kses_post and other sanitisation helpers; developers can combine those with remove_filter calls to keep the best of both worlds.
What to watch next
WordPress core has not announced a change to wptexturize that would automatically exempt <script> tags. Until such a change lands, developers must guard their inline code manually. Keep an eye on the core development tracker for any proposals to make the filter context-aware. In the meantime, audit any shortcode or page builder element that injects JavaScript and apply one of the three fixes above.
Bottom line: if your WordPress site runs inline JavaScript, verify that wptexturize isn’t silently rewriting it. A single escaped ampersand can render an entire feature inert, and the fix is usually a few lines of PHP or a shift to external scripts.