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.
Der Kompromiss liegt in der selektiven Deaktivierung: Schalten Sie den Filter nur dort aus, wo Code enthalten ist, oder verwenden Sie einen benutzerdefinierten Shortcode, der seine Ausgabe explizit als vor der Texturierung geschützt kennzeichnet. WordPress stellt bereits wp_kses_post und andere Bereinigungs-Helfer zur Verfügung; Entwickler können diese mit remove_filter-Aufrufen kombinieren, um das Beste aus beiden Welten zu erhalten.
Worauf Sie achten sollten
Der WordPress-Core hat keine Änderung an wptexturize angekündigt, die <script>-Tags automatisch ausnehmen würde. Bis eine solche Änderung implementiert wird, müssen Entwickler ihren Inline-Code manuell schützen. Behalten Sie den Core-Development-Tracker im Auge, um etwaige Vorschläge zu verfolgen, den Filter kontextsensitiv zu machen. Überprüfen Sie in der Zwischenzeit jeden Shortcode oder jedes Page-Builder-Element, das JavaScript injiziert, und wenden Sie eine der drei oben genannten Lösungen an.
Fazit: Wenn Ihre WordPress-Seite Inline-JavaScript ausführt, stellen Sie sicher, dass wptexturize dieses nicht stillschweigend umschreibt. Ein einziges maskiertes Ampersand kann eine gesamte Funktion unbrauchbar machen, und die Lösung besteht meist aus ein paar Zeilen PHP oder dem Wechsel zu externen Skripten.