Gutenberg: Reusable blocks creating infinite loops: Published posts front-end, Post list in Calypso, and Editor not loading. 500 errors present.

[aleone89]

Steps to reproduce

Frontend:
https://lescarnets.home.blog/ > click on continue reading on a post > no post loads > Console: https://d.pr/i/2gM188

Backend
https://lescarnets.home.blog/ > /wp-admin > Posts > click edit on a post that is published > Console: https://d.pr/i/P7a5WF

What I expected

Frontend > to see the post content

Backend > to see the post content

What happened instead

Frontend > Site is visible, the post title is visible, the post content does not load.

Backend > Nothing loads, just a white screen is visible.

Browser / OS version

Chrome 87
FF 84.0.2

Screenshot / Video

Frontend - example site: https://lescarnets.home.blog/

backend - example site: https://lescarnets.home.blog/

Context / Source

Reported on public forums here: https://wordpress.com/forums/topic/how-come-when-i-go-to-my-blog-and-see-the-posts-and-click-continue-reading-it-only-shows-the-title-of-the-post-2/

Example sites reported (so far):

https://lescarnets.home.blog/
https://backyardhobbyfarm.home.blog/

[JoshuaGoode]

These sites all have at least one reusable block that calls back to itself, creating an infinite loop that then crashes the editor, Calypso page/post list, and front end. The GETs related to the posts fail with 500.

The question is, have the sites always had these infinite loops but it just started causing issues after an update? Or, did something change within the editor that makes it easier to edit a block and create these loops?

A longer discussion of the issue here with @nickpagz and @cathymcbride : p1610986104013800-slack-C02FMH4G8

We haven't been able to report our findings just yet as we've both been chatting.

Identifying the loop
To find the broken block, one can navigate to wp-admin/edit.php?post_type=wp_block. There, open the blocks in the Classic Editor. Then, look for reusable blocks calling themselves. For example, reusable block with ID 41 would be having the issue if its content was <!-- wp:block {"ref":41 } /-->

[JoshuaGoode]

Reusable blocks don't appear to have a revision history so I can't easily tell if the blocks have been like this for some time and just now started causing the 500s after an update -- or if a change was made that makes accidentally editing these reusable block easier.

In a test, it was very easy for me to add a reusable block and then accidentally add it to itself.

I also just updated the title to be a bit closer to describing the issue at hand.

[sirreal]

This looks like an example of WordPress/gutenberg#18704, which is a known issue.

Note that the block need not reference itself. Larger loops will trigger the problematic behavior.

[JoshuaGoode]

Highlighting that we just started getting these specific reports starting around January 15th and this completely breaks the Post/Page lists in Calypso and prevents post and reusable block editing on the impacted posts.

I suspect that it must now be easier to accidentally edit reusable blocks and create such loops.

The steps to fix these sites is to access the reusable block list in the site's wp-admin at wp-admin/edit.php?post_type=wp_block, edit the blocks using the Classic Editor, identify the block(s) causing the loop, and remove the reference.

[JoshuaGoode]

Other sites that started having the issue just recently:

3655949-zen: scarletsmods.com
24860869-hc & 3661010-zen: travelwithintent.wordpress.com

The reusable blocks causing the issue were identified and repaired. Discussed internally at p1610986104013800-slack-C02FMH4G8

[sirreal]

For reference:

• Gutenberg 9.6 was activated on 2021-01-11 r219216-wpcom
• Gutenberg 9.7 was activated on 2021-01-14 r219435-wpcom

[JoshuaGoode]

Related to #38929 & WordPress/gutenberg#18704 -- however, we're seeing an unusual influx of new reports and it does appear to be due to how easy it is to edit and add content within a reusable block. Once a user does this, Calypso, the editor, and the post's front end all break and generate 500 errors.

Comparison of Current vs Previous Reusable Block Editing
I've recorded a quick demonstration of how easy it is to edit reusable blocks when creating a new post after recent updates (includes audio commentary): https://d.pr/v/hGhS3L

Here's how things are handled in WP Core, without the Gutenberg plugin active, and on an Atomic site with 9.5.2. It's much harder to create such a loop and the user has to intentionally edit the reusable block:
https://d.pr/v/Ok1cEj

[JoshuaGoode]

@glendaviesnz mentioned there was a recent reusable block refactor: WordPress/gutenberg#27887

Seems to have made some good usability improvements to reusable blocks; however, it has also made it very easy to create these loops.

[Copons]

I gave this a quick try and I agree that this is caused by reusable blocks referencing themselves, and that it also happens on Core Gutenberg.
I'm not exactly sure how folks have managed to get a reusable block to self-ref, as whenever I've tried it, it basically crashed my browser before I had a chance to save the block. 😅

Either way, this needs to be fixed from Core, by preventing the loop in the first place.

I've added [Pri] Normal as I'd argue that while this is a very nasty issue, it will hardly affect a large number of sites.

---

I've checked the various sites reported in this issue, and AFAICS only backyardhobbyfarm.home.blog has still troubles (cc @aleone89).
The site only has one reusable block, which indeed references itself.
Its content is literally only the self-reference, so my recommendation for a quick fix would be to delete the reusable block, which would result in the block not rendering anything, without breaking the site.

[JoshuaGoode]

Thanks, @Copons!

Looks like it depends on the content of the reusable block. In the cases I examined, the culprit was often a reusable customized Spacer block that doesn't seem to crash the browser when self-referenced and allows users to Update/Publish their changes.

An example of this was in my comparison video, I didn't encounter a browser freeze/crash but it was slow for a moment.

[nickdaugherty]

A longer discussion of the issue here with @nickdaugherty and @cathymcbride : p1610986104013800-slack-C02FMH4G8

@JoshuaGoode you may have meant to tag @nickpagz...unless I just have a really bad memory...

[tbradsha]

3660798-zen

[nagpai]

3663909-zen

[sirreal]

There's very good feedback here that we need to surface to the Gutenberg project. The struggles that users have and demonstrations like these can help to inform the design and development.

@inaikem is that something you'd like to work on as a product ambassador? I'm happy to assist.

[kdevnel]

I just had this come up again in 27132890-hc

The issue here was that we had to remove the content from the reusable block so they could edit it and restore the actual content. Trouble is, every time they tried to edit it the block broke again. Getting them to edit directly in the reusable block editor seems to have worked.

[Copons]

A couple of updates from Core:

• There is a relatively recent PR open to fix the infinite loop.

• The confusing UI is recognized, and there are talks to make it consistent with the FSE's template part blocks (basically add an outline on hover/focus/selection).
  A stop-gap PR that adds simple outline to the parent block when a child is selected was merged and will be included in Gutenberg 9.9.

[Nic-Sevic]

Again here and resolved
3666143-zen

[Nic-Sevic]

3656219-zen
cleaned up references and seems resolved

[kelasante]

3667493-zen removed references. Seems resolved.

[xpurichan]

3643465-zen seems like it may be related but I haven't gotten to the bottom of it yet. From my understanding there is at least one reusable block that is blank (but it should have content) and some reusable blocks duplicate content (unclear if they duplicate their own content or other content) and cause issues when trying to save and leave the page.

I'm working to get more clarity on this one so we can start investigating.

[scosgro]

Just had 2 more of these show up in Slack from chat support.

If anyone makes their way here, and are looking for a solution to the crashing, you can view/delete the reusable blocks from WP-Admin, here:

/wp-admin/edit.php?post_type=wp_block

Then edit in the Classic Editor, using:

/wp-admin/post.php?post=24479&action=edit&classic-editor

Where the ID# in the URL is the ID# for the block.

Or possibly Calypso (doesn't always work), here:

https://wordpress.com/types/wp_block/

It requires removing the reusable block entirely, or editing it (if it allows you).

[donalirl]

Occurred in #3658435-zen

[happychait]

Another instance in 27179267-hc

[thabotswana]

Another report here: 3687664-zen

[philnick206]

Another report here: #3676255-zen

[scosgro]

Another one - #3670104-zen

[kristarella]

23391318-hc

Sending block to Trash, and then restoring (which goes to Draft), and then editing as draft worked.

[TeniCola]

Another report -- #27408256-hc

[JoshuaGoode]

Encountered on 23372432-hc

[donalirl]

#3701283-zen

[donalirl]

#27436081-hc

[jackiejade]

#10834155-hc

[philnick206]

#3706291-zen

[yashitamittal11]

#3710575-zen

[rachelwinspear]

Another report here: #3711599-zen

[desnum]

hc-26238505

[sirreal]

Some mitigation with styling D56058-code deployed in r220537-wpcom

[kriskarkoski]

3719126-zen had this issue on 3 blocks

[carinapilar]

Another one on 27460617-hc with 2 Reusable blocks.

[donalirl]

#18659345-hc

[dolgelukkig]

#27618315-hc

[rachelwinspear]

#27620402-hc

[vinnykaur]

#27639197-hc

[scosgro]

#11656743-hc

[villanovachile]

Another #3726284-zen

[isocialtish]

This came up in #28206056-hc. It was such a problem it was affecting their launch and I needed to offer a refund for a month of their Business plan

[cathymcbride]

@isocialtish I believe this should have been fixed with Gutenberg 9.9. Do you happen to know what your user was using?

[simison]

We can probably close and let's re-open if we get any reports, or open a new issue if this happens, because it's likely unrelated. Upstream issue: WordPress/gutenberg#18704

cc @WunderBart @fullofcaffeine who were working on shipping fixed Gutenberg.