amphtml: 'src' attribute set to invalid in amp-mustache script
What’s the issue?
By simply including the amp-mustache
script tag <script async custom-template="amp-mustache" src="https://cdn.ampproject.org/v0/amp-mustache-0.2.js"></script>
I am seeing an error from the AMP extension stating The attribute 'src' in tag 'amp-mustache extension .js script' is set to the invalid value
.
How do we reproduce the issue?
Can’t replicate this inside of a jsbin but even by simply using amp-mustache
in the playground (https://ampbyexample.com/playground/) you can see this error in the chrome extension
- Go to http://jsbin.com/vobolelage/edit?html,output
- Copy the code on the left side of the bin and past into https://ampbyexample.com/playground/
What browsers are affected?
As of right now I only see the error on Chrome on Desktops
Which AMP version is affected?
<script async src="https://cdn.ampproject.org/v0.js"></script>
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 34 (18 by maintainers)
Versions should not be introduced and deprecated in the same release cycle for many reasons.
As @jamesshannon has kind of mentioned.
It is absolutely not OK to be notified of deprecation events solely via emails generated by GSC. I’m not sure if it was documented somewhere else and I perhaps missed it, but if there isn’t a deprecation timeline map available, we definitely need one.
I mention this again because our app converts 1000s of customers pages into AMP, and when they receive a “Warning - you are about to be penalized in search results” (paraphrased) email, they rightfully flood our customer support with messages that could have certainly been avoided.
Thank you for the update. I think it’s now been addressed that there was a screwup. Looking forward to improved standards moving forward.
Cheers
Hi.
Since yesterday I’m getting a lot of errors in search console and it’s referencing the URL to
amp-mustache
v0.2 version:The AMP validator in chrome is saying that everything is ok.
As part of the post-mortem action items, we’ve updated and clarified our versioning policy in #17370.
Moving forward, all extension version deprecations will follow a strict deprecations process including announcement on public channels, community discussion, and constrained timelines to deprecation/invalidation. For example:
amp-mustache’s version notes have also been updated with more details.
Please see the attached post mortem on this issue.
Post-Mortem-amp-mustache-0.2.pdf
Please publish an article about this, I’m being inundated with complaints by users experiencing this. We have an app that converts pages into AMP. We updated to 0.2 per the error. We need a link to send them saying this is Google’s fault. Help.
Oh. Another thing around this:
The version notes aren’t particularly helpful in for the purposes of deprecation.
First, how relevant is the version notes for a particular library? It looks like version notes are only used for minor releases (and not patches). But functionality is regularly added to libraries via “patches”. Certainly it woudln’t be surprising if
<svg>
features were added and the bundle size was reduced without a major or minor version, and thus that wouldn’t typically get added to the Version Notes. If that’s the case, then what’s the point of having Version Notes at all? Maybe they should be deprecation notes?The bundle size comment was confusing. I assumed that that referred to something similar to the the 50kb CSS limit. The actual gzipped JS library size doesn’t seem relevant enough for this.
Last but not least – if I have dozens or hundreds of AMP pages which I’m responsible for, the description (“Internal improvements may cause minor breaking changes”) doesn’t really help me migrate to v0.2. What should I be looking for? On which pages? I wouldn’t expect that a “minor breaking change” – especially to mustache templates – would be immediately visible. With
amp-bind
and other components, a lot of functionality is hidden under actions. Do I need to (manually) test every action on every page? How do I know that just because I’ve noticed one discrepancy there might not be others? The Deprecation Notes should describe exactly what might happen, and how that might occur. Should I look for unreplaced variables? Or text that’s suddenly backwards?Please email me the URL you are testing (same username @google.com)
I really need some confidence that this is being fixed, or a timeline on when…
If we revert back to 0.1, will the warning still show? It says that a commit was pushed to remove the deprecation warning but other users seem to be still experiencing warnings.
Please advise ASAP.