Wp-calypso: SPT: Some blocks are invalid

Created on 8 Oct 2020  Â·  10Comments  Â·  Source: Automattic/wp-calypso

Some SPT (~Single~Starter Page Template) blocks are invalid and should be fixed.

Steps to reproduce

  1. Load the SPT page editor for a Simple site: /wp-admin/post-new.php?post_type=page
  2. Observe _block validation failure_ errors reported in the console.

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 classes

Example 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.

Context / Source

props: @fullofcaffeine (p1602108571422000-slack-C015AL3QL7M testin p7DVsv-9rP-p2)

Blocks Editing Toolkit [Pri] High [Type] Bug

All 10 comments

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:

  1. SPT plugin loads the templates by calling the 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.
  2. The offending blocks appear to have been in the Portfolio layout (already updated on the master templates site), and also from the Seedlet and Leven. The Leven one is already deployed.

I am heading out for the weekend soon and don't feel comfortable deploying, but here's handing the baton with what needs doing.

  1. ~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.)~ - https://github.com/Automattic/wp-calypso/issues/46268#issuecomment-712124318
  2. ~Build and deploy the Headstart annotation for the Leven theme~ Already done.
  3. Translations are trickier. Nothing technically needs translating as this update will only change some markup. Probably just some tedious work in a text editor.

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

  1. 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.

Leven homepage

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.

Screen Shot 2020-10-19 at 12 40 00 PM

Here are the steps I took to fix that issue:

  1. Removed the offending space character in the code editor of the leven theme demo site.
  2. Regenerated the leven theme headstart annotation.
  3. Tested, committed, and deployed the update to the leven theme. (D51444-code)
  4. Reset the wp object cache for the leven theme's "homepage template" in the template-first-themes code.
  5. Verified that I no longer see issues for the leven homepage block invalidation!

Seedlet homepage

This leaves one final issue with the seedlet homepage:

Screen Shot 2020-10-19 at 12 36 35 PM

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:

Screen Shot 2020-10-19 at 1 13 56 PM

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.

Next steps:

  1. Get more eyeballs on D51460-code. Since there are a lot of unpublished changes, we should run this by the team responsible for the team.
  2. Commit and deploy that diff.
  3. Bust the cache for the seedlet homepage.

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:

Screen Shot 2020-10-20 at 11 33 06 AM

Was this page helpful?
0 / 5 - 0 ratings