Invalid Stories due to i-amphtml-version

Note, I’ve spot checked many of my stories and they all have the same weird <style amp-runtime=”” i-amphtml-version=”0″></style>
So it’s just a matter of days until GSC flags all of them as invalid.

Something definitely happened.

Until this is fixed, I’ve edited the plugin to manually set a version number instead of 0 in AmpRuntimeCss.php…

Can’t live without web stories for a whole month!

How did you do that? I am seeing bunch of errors in all the amp stories too and they are not even indexing these days. This is all suddenly started from sitekit and webstory plugin. can you share the steps?

This is rather dangerous, unsupported, risky. You might break the whole plugin if you do something wrong. And this is not a fix. This is merely a workaround the AMP validation.

1. Go to Plugin Editor
2. Select Web Stories
3. Navigate to third-party > vendor > ampproject > amp-toolbox > src > Optimizer > AmpRuntimeCss.php
4. Add a new line after line 144
5. paste this: $version = “012103261048002”;

I would like to also confirm that GWS gives the following error:

The attribute ‘i-amphtml-version’ in tag ‘style[amp-runtime]’ is set to the invalid value ‘0’.

Waiting for the fix from Google.

Hi folks,

Thanks for your reports.

We generally advise to never ever directly edit plugin files due to the risk involved. Plus, any changes will be lost with the next update.

Please be assured that we’re treating this as a high priority issue and will fix this with our next release (slated for this week).

I’m sure of that, but between no valid web story which means no traffic, and a small hack to the plugin that keeps the traffic going, I know what I’d rather pick ????

However, since it started happening 2 days ago while the plugin hadn’t changed at all since the 1.5 update, I suggest that it’s a server-side issue in the way the plugin downloads the version number.
Surely it should be fixed server-side first before the plugin is also hardened?

> However, since it started happening 2 days ago while the plugin hadn’t changed at all since the 1.5 update, I suggest that it’s a server-side issue in the way the plugin downloads the version number.
> Surely it should be fixed server-side first before the plugin is also hardened?

Well yes and no.

The download can fail for various reasons, e.g. a timeout. To re-trigger a download, clear your transients & view a story on the frontend.

If the download fails, the plugin ought to have a fallback file with all the information, but this file was accidentally omitted in the current version.

So with the upcoming release (planned for this week) we’re adding back this fallback. So no matter if the download fails, the version will never be 0.

Quick update after the new version of the plugin was released.

1. Just updating the plugin did not fix the issue.
2. Clearing the transients after updating the plugin did fix the issue.

@damienmaurer We appreciate you reporting this topic and sharing the quick update! We’ll close this topic as resolved, but please don’t hesitate to reach out in a new support topic if you encounter further issues.