Gutenberg: browser becomes unresponsive when inserting post content block within a template

[skorasaurus]

Describe the bug
Very similar to what @carolinan and @johnstonphilip reported in https://github.com/WordPress/gutenberg/issues/22080

My browser becomes unresponsive when I attempt to add a post content block;

in my case, it occurs even when I try to add it to a post type of template within the editor.

To reproduce
Steps to reproduce the behavior:

1. create new site;
2. build gutenberg from source
3. enable plugin
4. sitename.test/wp-admin/admin.php?page=gutenberg-experiments - enable full site editing
5. create new template at http://sitename.test/wp-admin/post-new.php?post_type=wp_template
6. open block directory, type in post content, click on its icon so it can be insert.

Expected behavior
the block would appear in the template even a square with a placeholder value so I know that the post content will appear when I use this template.

Screenshots
If applicable, add screenshots to help explain your problem.

Editor version (please complete the following information):

• WordPress version: 5.4.2
• Does the website has Gutenberg plugin installe - yes,
• uses gutenberg that was built from master branch, earlier today (2020-07-07) its most recent commit was 51256763abb2f54fa66ebfa7b6e1e5efb6eb5210

Desktop (please complete the following information):

• ubuntu 18.04
  chrome and firefox

[epiqueras]

Is this still happening on master? There's been a lot of related changes recently. @ockham @Addison-Stavlo @noahtallen

[Addison-Stavlo]

Is this still happening on master?

@epiqueras - I just did a test on my local environment. Adding it to a template while in the site editor doesn't seem to error, but if you are in the template post editor 'Appearance -> Templates -> etc.' it errors. This seems to be the same as #22080 - adding 'Post Content' block in any instance of the old editor seems to crash it.

[skorasaurus]

Is this still happening on master? There's been a lot of related changes recently. @ockham @Addison-Stavlo @noahtallen

yes

[epiqueras]

Ahh, it's infinite looping. Should we just hardcode it, so it doesn't work with the wp_template template type?

[skorasaurus]

In pre-Gutenberg world with a PHP template, developers would use the_content() to represent a post object's `post_content . wouldn't the post content block be the new way to do this?

I'm unclear why any reference to the post content would now be removed from a template within gutenberg.

[ockham]

Ahh, it's infinite looping. Should we just hardcode it, so it doesn't work with the wp_template template type?

Doesn't it need to be the other way round -- work only _within_ wp_templates? #24006 is my WIP attempt to address this in the UI (remove the Post Content block from the inserter), but yeah, we likely also need to change the Post Content's code. @Addison-Stavlo has a PR here: #24010. We might also need to modify the block's server side code tho, since the frontend is likely also affected :thinking:

[epiqueras]

What I mean is that the post content block should render a placeholder if it's context's postType === wp_template.

More generally, we could detect that the block's context references the same post that contains it and break the loop with a placeholder. That would solve the issue everywhere.

[Addison-Stavlo]

What I mean is that the post content block should render a placeholder if it's context's postType === wp_template.

Thats one thing I was suggesting in that WIP PR @ockham mentioned.

Another question is, do we need the ability to edit wp_templates in the old editor? Is Appearance -> Templates necessary, or can the Site Editor be the 1 stop shop for Template editing as well?

[epiqueras]

Yes, it's analogous to focusing on a single template. The path there will probably change, but the functionality will still be there somewhere.

[vindl]

Another question is, do we need the ability to edit wp_templates in the old editor? Is Appearance -> Templates necessary, or can the Site Editor be the 1 stop shop for Template editing as well?

I was thinking about this too. It's not clear why we need this separate way of accessing them, when they can in theory be edited from site editor directly? While it makes sense to provide CPT listings in general, in FSE's case it's an implementation detail that we might want to hide from end users.

[noahtallen]

More generally, we could detect that the block's context references the same post that contains it and break the loop with a placeholder

I agree with this solution. 👍 We should also fix it on posts/pages/etc. (even if we end up hiding it from the inserter there in the future)

[ockham]

More generally, we could detect that the block's context references the same post that contains it and break the loop with a placeholder

In a DM with @vindl, we were wondering if there could still be edge cases like _two_ posts with a Post Content block each, and each referencing the other, leading to another infinite recursion. Re-reading the block context docs however, that might not be an actual issue, since a block can currently only use its own attributes as the source for a context value it provides for another block.

[carlomanf]

Another question is, do we need the ability to edit wp_templates in the old editor? Is Appearance -> Templates necessary, or can the Site Editor be the 1 stop shop for Template editing as well?

I was thinking about this too. It's not clear why we need this separate way of accessing them, when they can in theory be edited from site editor directly? While it makes sense to provide CPT listings in general, in FSE's case it's an implementation detail that we might want to hide from end users.

I find Appearance > Templates is useful for editing templates that don't get used. For example, if the site has no posts (yet) then I believe the single template can't be edited through the site editor until a post is published, but it can be edited through the CPT implementation.

[noahtallen]

That is a good example. I think ideally, we have support for that directly in the site editor, but we should also fix it for these editors for now too :)

btw, this PR #24010 should fix everything.