This is another conflict caused by the usual terribly coded "prototype-core.ashx" used on the shopping cart functionality through BC 
, however the implementation of Google's LD+JSON seems quite impossible with the problems coming all the time regards BC scripting.
I am using the following piece of code in the "products_large" template:
<script type="application/ld+json">
{
"@context": "http://schema.org/",
"@type": "Product",
"name": "{{name}}",
"image": "http://http://www.bestkilts.com{{largeImageUrl}}",
"description": "{{description | strip_html | truncatewords: 40, "..." }}",
"mpn": "{{id}}",
"brand": {
"@type": "Thing",
"name": "Best Kilts"
},
"offers": {
"@type": "Offer",
"url": "{{urlWithHost}}",
"priceCurrency": "{{countryCurrencyFormat}}",
"price": "{{salePrice}}",
"availability": "http://schema.org/InStock",
"priceValidUntil": "{{expiryDate}}",
"itemCondition": "New",
"seller": {
"@type": "LocalBusiness",
"name": "Best Kilts"
}
}
}
}
</script>
Everything works just fine without the above but once its added to the head or body of the template I just get errors once clicked on "addToCart" custom scripts wont run.
Everything is clear of conflicts but regards this specific JSON from Google things don't go well, even worse you cannot add javascript to the ld+json script it becomes unrecognised and wont render by Google.
Please check the demo: Dropbox - BC and Google LD+JSON Conflict.mp4
1 Correct answer
In response to OP, in case anyone else comes searching for the same error:
BC will attempt to 'eval' inline scripts when redrawing the product after adding to cart, which will break on "application/ld+json" types. To resolve this I include an override of the BC function the excludes that type:
ProcessJS = function (ele) { for (var t = "", x = ele.getElementsByTagName("script"), i = 0; i < x.length; i++) { if (x.getAttribute("type") !== "application/ld+json") t = t + "\n" + x.text; } ...
17
Replies
Hi Ricardo
I did the same few months ago and I remember I got these error messages too 
What I´ve done on the product_large template
<script type="application/ld+json">{"@context": "http://schema.org/","@type": .....</script>
<script type="text/javascript" src="/CatalystScripts/Java_OnlineShopping.js" defer></script>
<script type="text/javascript" src="/js/Java_Cookies.js" defer></script>
<script type="text/javascript" src="/js/prototype-core.js" defer></script>
<script type="text/javascript" src="/js/CMS.CatalogueRetrieve_Catalyst.Web.CMS.js" defer></script>
* Note
- Marked /js/ are downloaded and minified with Closure Compiler from Google
- I have also checked No HEAD elements on Page Templates
Two live examples
- Galleri GEO - Large product link /// Structured data: Testing link
- Janne & Julia - Large product link /// Structured data: Testing link
My ld+json markup: in <head> section
My ld+json also have a {% if instock > 0 %}.... {% endif%}
<script type="application/ld+json">
{"@context": "http://schema.org/",
"@type": "Product","name": "{{name}} by {{custom1}}",
"image": "http://gallerigeo.no{{largeImageUrl}}",
"description":"{tag_productmetadescription}",
"brand":{"@type": "Person","name": "{{custom1}}"},
"offers":{"@type": "Offer",
"priceCurrency": "{{countryCurrencyFormat}}",
"price":"{{salePrice|round}}",
"availability": "{% if instock > 0 %}http://schema.org/InStock{% else %}http://schema.org/OutOfStock{%endif%}",
"seller":{"@type":
"ArtGallery","name": "Galleri GEO"}}}
</script>
The reason for why I wanted to no HEAD elements on page template for my Shop is mainly because i also want a good score on Google pagespeed... I just tested Janne & Julia on category for 97 of 100 
I also feel products have a better focus when you don´t see that buy button on category level.
Hi Alex, thanks for taking the time on your answer, unfortunately the problem is with the addToCart() function conflicting with LD+JSON on your sites you use BuyNow so it jumps straight to cart rather than adding them to cart and keep in the same page.
Although I tried your process just in case it could work but nothing changed once addToCart() is clicked the world ends! 
I´m only using one template.
I always try putting custom code+CSS only where it´s needed (ex. put the form CSS on the contact page only) keep the core CSS and master template to a minimum. My default pre-production CSS is around 200 lines atm. I´m always working on how to minify and build a better HTML+CSS platform for production. Tip! You can event use liquid markup inside the catalogue description field in admin
AMP HTML and Adobe BC are even better companions on this issue.
We almost only code HTML AMP these days 
Very surprised you are not doing any of this yet. No one above here is doing any render blocking improvements as well which you should all look at, defer on the scripts themselves is still in process to be finalised and not going to be 100% till next year, its all browser determination and there are errors with that in chrome for example. Alex - you actually have those.
You also have the issue Ricardo is reporting, you just do not notice it as you have the buy now purchase method rather then add to cart so with what you said does not fix the problem.
Everyone is ignoring me here, thats fine, take or leave advice, but like I said - Tag Manager is actually where things are at for more reasons then this but through that:
Only passing some information in here at the moment for reasons I will not go into but you can see that structured data very much there with google tag manager datalayer.
Things move faster and faster and it is crazy to keep up but I love always doing new things.
The ultimate thing is rewriting the BC scripts entirely and using your own like I do , but I am nuts and that took time to all do, lol.
Yeah.. you are right... I see it 
This is a great tip! I must check it out. I´m planning to build my AMP HTML shop in the near future, but I´m not sure if I will do this on BC. We try avoid most shop customers and leave those for bigger companies. Only four of us at FUNBIT. We feel it´s better to sell two easy peasy sites than one shop, these days. $$$
If the time comes and BC wont work in a pure logic way.. (like Ricardo´s code above) and we are forced to write our own scripts or use 3rd party fixes, like Google Tag Manager (a great tip btw), we will probably look around for other plattforms. I hope this will not happen, because I love the Adobe "name" ❤️
I think it´s great opportunity for small companies to offer an Adobe solution when they compete against other bigger one´s offering a Word Press solution. It easy to sell and that is the most important factor.
The brutal fact is that it is more than two years since you suggested some improvements to the module_data and nothing have happened? (It´s the most wanted new idea.. been for super long time). There are tons of reported bugs and progress is very slow. And if BC dont have real https in aprox 2 years (I´m waiting... hehe), nothing else matters.... for me. 
AdChoices