Purpose-Built Templates

ZU2B Blueprints

Business in a Box

  • Purpose-built launch kits for local service businesses — website, copy, prompts, SEO, and more.
  • Local Launch Kits →

Website Widgets

  • Working features you install once and own outright — no plugin, no subscription.
  • Chat Widget — Coming Soon

Reference

ZU2B Pulse™

See what visitors experience before they leave — paste any public URL and get a plain-English performance report in seconds.

Scan Your URL Free

WordPress wptexturize Breaks JavaScript in Custom HTML Blocks

Field Note #182
🔬 Resolved 🟡 Intermediate ⏱ 30 Minutes ✓ Observation from Experience

⚡ Quick Fix (TL;DR)

The Fix: 1. View the page source and find the “ block.
2. Look for curly quotes (`'` `'` or `"` `"`) where straight quotes should be.
3. Check whether the block is inside a WordPress template part or footer — these pass through the same wptexturize filter.
4. Check the browser console for a `SyntaxError` on script evaluation.
Base64-encode the entire JavaScript block and load it via `eval(atob("…"))`. Since the encoded string contains no quote characters, wptexturize has nothing to mangle.
The pattern:

```html
<script>eval(atob("BASE64_ENCODED_JS_HERE"))</script>
```

Encode in Python: `base64.b64encode(js.encode('utf-8')).decode('utf-8')`
Was this helpful? Thanks for the feedback!
The symptom
A contact/support widget pasted into a WordPress Custom HTML block appeared to save correctly in the editor but failed to open on the live front end. Clicking the launcher button produced no response.

Initial assumption
The first instinct was a z-index conflict or a positioning issue with another fixed-position element on the page.

Investigation
The widget rendered fine in the WordPress editor preview. On the live site, the JavaScript was silently broken. Inspecting the source revealed that WordPress’s `wptexturize` filter had converted straight single quotes (`’`) inside the `<script>` block into curly/smart quotes (`’` `’`), which are not valid JavaScript string delimiters. The browser’s JS engine threw a parse error and the entire script failed before execution.

What to check
When a widget or script works in the editor but does nothing on the live site:
 
1. View the page source and find the `<script>` block.
2. Look for curly quotes (`’` `’` or `”` `”`) where straight quotes should be.
3. Check whether the block is inside a WordPress template part or footer — these pass through the same wptexturize filter.
4. Check the browser console for a `SyntaxError` on script evaluation.

Resolution
Base64-encode the entire JavaScript block and load it via `eval(atob(“…”))`. Since the encoded string contains no quote characters, wptexturize has nothing to mangle. The pattern:
 
“`html
<script>eval(atob(“BASE64_ENCODED_JS_HERE”))</script>
“`
 
Encode in Python: `base64.b64encode(js.encode(‘utf-8’)).decode(‘utf-8’)`

Troubleshooting lesson
Any JavaScript placed inline in a WordPress Custom HTML block is subject to wptexturize processing. This is not limited to shortcodes or post content — it applies to template parts and footer blocks too. Base64 encoding is the reliable fix, not quote-escaping, because wptexturize can re-process escaped content on subsequent saves.
 
**Do not assume the editor preview reflects live behavior.** The Site Editor preview canvas does not run wptexturize the same way the front end does.

Tagged in :

More from the field