Some SPT (~Single~Starter Page Template) blocks are invalid and should be fixed.
/wp-admin/post-new.php?post_type=page
You may want to filter console messages like Block validation: Block validation failed for
There appear to be two affected blocks:
core/embed
- rearranged classes and missing saved wp-block-embed-youtube
class.core/media-text
- rearranged classesExample errors:
Block validation: Block validation failed for `core/embed` (Object).
Content generated by `save` function:
<figure class="wp-block-embed alignfull is-type-rich is-provider-youtube wp-block-embed-youtube wp-embed-aspect-16-9 wp-has-aspect-ratio"><div class="wp-block-embed__wrapper">
https://www.youtube.com/watch?v=pB5gaJloeRU
</div></figure>
Content retrieved from post body:
<figure class="wp-block-embed-youtube alignfull wp-block-embed is-type-rich wp-embed-aspect-16-9 wp-has-aspect-ratio"><div class="wp-block-embed__wrapper">
https://www.youtube.com/watch?v=pB5gaJloeRU
</div></figure>
Block validation: Block validation failed for `core/media-text` (Object).
Content generated by `save` function:
md5-003a0106afd364075ff9ac6bb7cdd2ae
Content retrieved from post body:
md5-7a3f7dbcdfec80584c95160c00a44025
There are many successful migrations which should be updated (https://github.com/Automattic/wp-calypso/issues/46269), but that's a lower priority issue with a different fix.
props: @fullofcaffeine (p1602108571422000-slack-C015AL3QL7M testin p7DVsv-9rP-p2)
How come Gutenberg doesn't migrate these blocks automatically? Is there transformation missing in core for wp-block-embed-youtube
→ wp-block-embed is-provider-youtube
?
How come Gutenberg doesn't migrate these blocks automatically?
I'm not sure, but it sure is annoying!
I did not get finished, but I believe that we're in a good place for fixing these. Here are some things I learned:
templates
API endpoint, caches stuff, and inlines them, all from PHP. This makes trying to debug whether your changes are successful incredibly difficult. The fetching logic is here and gets dumped on the page inside the starterPageTemplatesConfig
JS var. There is no way that I can tell to test changes on a sandbox before deploying, as you can't sandbox the REST API from your sandbox itself.I am heading out for the weekend soon and don't feel comfortable deploying, but here's handing the baton with what needs doing.
These are the same steps we'll need for #46269
Build and deploy the Headstart annotation for the Leven theme
This part should be done, at least. :) I deployed it a few hours ago when we discovered this.
Per my gardening goals, I tried to navigate through the path of block loading / block validation / Starter Page Templates if only to understand what this issue was about for my own learning.
I believe I found the offending embed markup in the Portfolio template, or hopefully at least found something useful to share:
https://d.pr/i/Bl5jOL
https://d.pr/i/eT2Po8
@ianstewart Is it safe to assume this can be picked up by the View team?
the offending embed markup in the Portfolio template
That's been updated on the source site for that template, I believe. (I updated the page yesterday.) Wiebe's list above will still need working through, however.
cc @apeatling
- Build and deploy the new SPT annotation file with instructions in PCYsg-m0L-p2 (you only need to generate the JSON annotation file). (You will not be able to test the new annotations for reasons detailed above. It should work.)
Done as part of code-D51261 although trying to verify it has worked is proving difficult? Smoke tests indicate no functionality has changed/broken though.
Is there a way to ensure I am not getting a cached response?
cc @ianstewart @mattwiebe
Is there a way to ensure I am not getting a cached response?
I think we might have to modify the PHP sourcecode in the editing toolkit and make sure that is synced to the sandbox
Is there a way to ensure I am not getting a cached response?
If you the site is sandboxed and you have WP_DEBUG
defined to true and have deployed the annotations, you should get fresh results. Here's the code of interest.
I spent most of my day on this issue. Here's where we're at.
I deployed code-D51261 to wpcom, and verified that we are seeing fewer block validation errors. Thanks for generating this @autumnfjeld!
Then, I noticed we had several other errors which I narrowed down to two themes.
One is an issue with the columns block in the leven layout. Specifically, the homepage annotation includes an encoded space character, which is causing the block validation issue.
Here are the steps I took to fix that issue:
This leaves one final issue with the seedlet homepage:
Specifically, the problem is that the media-text
block contains an attribute for a URL, which is set to the seedlet demo site. However, when the headstart annotation was generated, the URL was stripped from the HTML markup (and changed to #
), but the URL was not changed in the accompanying block attribute. Basically, the block attribute and accompanying rendered HTML markup do not match. I found this out by comparing the _invalid_ text in SPT, and the apparently valid text in the seedlet demo site:
I thought originally this was an issue with the annotation generator, but after a lot of debugging, I accidentally realized that the seedlet annotation simply hasn't been updated in a while.
I generated the seedlet headstart annotation in this diff: D51460-code. If you look carefully, you'll notice that the generated markup for the homepage no longer contains the issue where the media-text attribute and the href are mismatched. I've confirmed that by pulling this annotation into the API endpoint, it fixes the issue in SPT.
I deployed D51460-code, and the cache is still referencing a correct version of the file, so I think we're good to go. If you are still experiencing issues, they will likely be resolved as the caches update over the next 24 hours. Let me know if you notice anything else!
I've just verified that there are no block validation errors in SPT any longer: