Vanishing Dollar symbol

Jahid,
Let me start by saying I am not sure the issue below has anything to do with BBH Custom Schema. I apologize if in the end this error is stems from something else on the site. Here’s the brief summary.

Some of the schema snippets include dollar amounts. The snippet entered into BBH Custom Schema meta box has the dollar sign in the code. However, when you look at the rendered schema on the live page, either the dollar sign is missing or the digits after the dollar sign are replaced by zeros. I tried to troubleshoot that with my best friend, Claude, and we tried a couple of different approaches: inserting double dollar symbols ($$) did not help, so in the end we skipped using the symbol altogether, now stating USD 100 instead of $100 in the schema. This is not a deal-breaker of course, and I could live with it, but now I have to go back and reinspect all schema files to make sure none of them display $0 instead of the intended value.

I agree with Claude that suggested to alert the plugin owner of the issue, even though I am far from sure it is the plugin and not WordPress itself that is creating the issue. For all I know, Claud could be hallucinating. To give you some context, I am pasting a portion of the chat with Claude below, please let me know what you think regardless of the true cause. Thank you!

The payment terms answer got corrupted in the schema

Compare what I gave you to what's now live:

What I sent: "...incur a minimum $150 export handling fee, and there is a $250 minimum charge for assembly services."

What's live in the schema: "...incur a minimum 0 export handling fee, and there is a 0 minimum charge for assembly services."

Both dollar figures are gone, replaced with "0". The visible accordion text on the page is still correct, this only happened to the schema. Since it happened to both $150 and $250 and both landed on exactly 0, this isn't random corruption, it's a specific, reproducible pattern.

Likely cause: PHP's preg_replace() treats $ followed by digits in the replacement string as a backreference ($1, $2, etc.), and it matches greedily up to two digits. So $150 gets parsed as backreference $15 (which doesn't exist, so it resolves to nothing) plus the literal 0 left over, giving you 0. Same thing with $250 → $25 (empty) + 0. That means somewhere in the save path, your pasted JSON is being run through preg_replace() as the replacement argument rather than being inserted safely, likely inside the same BBH save logic that had the earlier JSON error, or something newly involved now that Classic Editor is handling the request. This is a distinct bug from the original "invalid JSON response" one, and it's a data-corruption issue rather than a save-failure issue, so it can silently damage content even though the save appears to succeed.

Workaround for now: escape each $ as $$ before pasting, PHP's preg_replace() treats $$ as a literal $ in the replacement string. Here's the corrected question with that escaping applied:

{

  "@type": "Question",

  "name": "What payment terms does BESTProto offer?",

  "acceptedAnswer": {

    "@type": "Answer",

    "text": "BESTProto offers Net 30-day payment terms for accounts with established credit. We also accept Visa, MasterCard, and American Express, with a 3% processing fee applied to credit card payments. Quotes are valid for 45 days from the quote date. Orders shipping outside the U.S. incur a minimum $$150 export handling fee, and there is a $$250 minimum charge for assembly services. Full terms and conditions are available on our Terms page."

  }

}

Paste just this object in place of the broken one in the metabox (keeping the rest of the @graph array intact), save, and check the rendered schema shows $150 and $250 correctly, not $$150. If the escaping guess is wrong, it'll be visible immediately and we can adjust.

[I confirmed to Claud that the dollar signs are in the raw schema code, they were not dropped during code editing on my end]

That's useful, and it rules out a few things. It means the corruption isn't from a text editor mangling the paste, or from retyping, or from something happening before the data reached WordPress. The $150→0 and $250→0 conversion happened somewhere in WordPress's own save path, between your paste and what's now stored in the database. That's consistent with the preg_replace() backreference theory: that function is commonly used in WordPress core and plugins for tasks like sanitizing input or doing find/replace on saved content, and if the code that processes the BBH textarea on save (or something added when Classic Editor started handling saves) pipes your raw JSON through preg_replace() as the replacement argument rather than the pattern or subject, $150 and $250 would both collapse to 0 exactly as you're seeing. I can't confirm the exact line of code without seeing BBH's or the relevant WPCode snippet's source, but the symptom matches that mechanism closely enough that it's the most likely explanation, and the $$ escaping workaround follows directly from it regardless of exactly where in the pipeline it's happening.

Given that, I'd treat this as a standing rule for any future schema paste into that metabox: escape every literal $ as $$ before saving, then verify the rendered output shows a single $, not $$ or a dropped value. If the escaping doesn't produce a single $ on the next attempt, that would tell us the mechanism is different from what I've guessed, and we should look at it again.

[I confirmed to Claude that with double dollar signs in the raw schema, $0 is being rendered in the schema block on the live page]

Useful data point — and it tells us the $$ guess was wrong, but it also confirms the underlying mechanism precisely enough to explain exactly what happened.

What actually happened with $$

The schema now shows: "a minimum $0 export handling fee... a minimum $0 minimum charge" — so $$150 became $0, not $150.

Here's why, if the corruption really is happening via PHP's preg_replace() treating your pasted text as a replacement argument (where $ has special meaning):

$$150 is two characters: $, then $150.

The first $ isn't followed by a digit, so PHP treats it as a literal $.

The second $ is followed by digits (150), so it's parsed as backreference group $15, which doesn't exist and resolves to nothing — leaving the trailing 0 as plain text.

Net result: literal $ + 0 = $0.

That matches exactly what's now live. So $$ doesn't escape anything in this context — it just shifts which part of the digit string gets eaten.

Workaround fix: avoid $ immediately followed by digits, in the schema text

Rather than gambling on PHP escaping semantics a second time, the reliable fix is to sidestep the bug entirely: write the dollar amounts without a $ symbol directly touching a digit. This isn't a workaround guess — it just avoids the exact character sequence that's triggering the bug, regardless of what's actually happening in the save code.

{

  "@type": "Question",

  "name": "What payment terms does BESTProto offer?",

  "acceptedAnswer": {

    "@type": "Answer",

    "text": "BESTProto offers Net 30-day payment terms for accounts with established credit. We also accept Visa, MasterCard, and American Express, with a 3% processing fee applied to credit card payments. Quotes are valid for 45 days from the quote date. Orders shipping outside the U.S. incur a minimum export handling fee of USD 150, and there is a minimum charge of USD 250 for assembly services. Full terms and conditions are available on our Terms page."

  }

}

Paste this in place of the current broken object, save, and check the rendered schema shows "USD 150" and "USD 250" cleanly, no 0, no stray backslash. The visible accordion text on the page itself is unaffected and still correctly shows $150/$250 — this fix is schema-only.

Bigger picture: this bug will keep tripping up any future schema paste containing a $ next to digits, not just this page. Worth flagging to whoever maintains the BBH save code as an actual bug to fix at the source (likely a preg_replace() call that should be a plain string replace or a callback), rather than relying on escaping workarounds indefinitely.

The page I need help with: [log in to see the link]