Mar 23 (edited) • 😬 Ouch
OUCH! A WHOLE DAY WASTED FORMATTING for WordPress (and still no solution!)
Hi team. I can't believe I've wasted a whole day on this. I've worked with Claude Chat, Claude Cowork, Claude Chrome and ChatGPT and they've ALL FAILED to deliver a working solution; i.e a clean Google Doc output format path for a clean WordPress input format path. They had no restrictions on modules to use, or number of modules, but despite showing them the EXACTLY the output they needed from the input provided, I'm still no closer to success than when I started!
FYI, here is the Google Doc which I've shared publically for now: https://docs.google.com/document/d/1pziCm9wIIvtKvzt10IRc_jk-5pl1pn0rd8RVrjsBOLM/edit?usp=sharing
PS. Here is how Cowork described the clean input that is working inside the scenario: https://us2.make.com/93886/scenarios/4492233/edit?folder=63806
Note I don't know if the following IS the reason it works. All I know is that the single module scenario above with the clean "content" inside it, works.
Claude trying to self-diagnose:
"When you gave me the blueprint with the content already populated, it worked. Here's why:
The "content" value is plain HTML — but with a very specific character encoding approach. Here's what's actually in there: What it IS:
  • Raw HTML tags: <h1>, </h1>, <p>, </p>, <h2>, <ol>, <li>, <table>, <tr>, <td>, <br>, <hr>, etc.
  • All on a single continuous line — zero newlines, zero line breaks anywhere
  • No escaped characters like \" — double quotes simply don't appear inside the content value at all What it uses for special characters:
  • Named HTML entities for typographic characters: &ldquo; &rdquo; &rsquo; &ndash; &nbsp; &pound; &reg;
  • Numeric entity &#39; for apostrophes (instead of a literal ')
  • &gt; for > where needed
  • &quot; for quote characters where needed The critical difference from what LLMs produce: When an LLM (or a Make module) processes text from a Google Doc, it almost always produces one or more of these problems:
  1. Actual newline characters (\n) between HTML tags — which break the JSON string
  2. Literal curly quotes (", ", ') instead of HTML entities — which break the JSON structure entirely since " would close the JSON string prematurely
  3. Escaped quotes (\") — which is valid JSON but WordPress may not handle as expected
  4. Unicode characters (non-ASCII like £, –, ") passed through literally instead of as entities The working version has no literal newlines, no literal curly/smart quotes, no raw Unicode typographic characters — everything that could break JSON is expressed as an HTML entity, and the whole thing is one flat, unbroken string. So the reason no LLM workflow has replicated it is almost certainly that the Google Doc content contains curly/smart quotes and other typographic characters that need to be converted to HTML entities (&#39;, &ldquo;, etc.) before being dropped into the JSON body. Most approaches either leave them as Unicode (breaking the JSON) or escape them with backslashes (which WordPress may mishandle).
3
15 comments
Colin Clapp
5
OUCH! A WHOLE DAY WASTED FORMATTING for WordPress (and still no solution!)
Master AI Automation
skool.com/masterai
Launch Your AI Agency or Automate Any Business – Step-by-Step
Leaderboard (30-day)
Powered by