Fatal error: memory exhausted viewing a post containing a `core/post-content` block

[bobbingwide]

A similar problem to #7 occurred when I tried to document the core/post-content block. In the editor, the block was displayed as:

On the front end, the logic that attempts to prevent infinite recursion didn't kick in.

[bobbingwide]

This problem was mentioned in https://github.com/WordPress/gutenberg/issues/22080#issuecomment-628386386

In the standard block editor, trying to view an already saved post with a post content block: Fatal error: Allowed memory size of 268435456 bytes ...

It's not that easy to fix the logic. If you return when you find that the post you're trying to process is the current one

if ( get_the_ID() === $block->context['postId'] )

then none of the blocks in the content are processed. This shortcircuit is too early.

I had to deal with a problem like this in oik's [bw_pages] shortcode.

I imagine that the core/post-excerpt block has exactly the same problem. Will need to check.

[bobbingwide]

While testing a solution for issue #27 I started changing the home-query.html template. I wanted to use the metadates.html template part to replace the rather complicated (and ugly ) columns block. I noticed that for the second and subsquent posts in the query-loop the [post-edit] shortcode worked but the [bw_fields] ones did not. get_edit_post_link() calls get_post(). The logic for [bw_fields] currently prevents the shortcode from doing anything when the current post is not the global post. If we extend bw_fields to work when the id attribute is '.' then this might resolve this problem

[bobbingwide]

If we extend [bw_fields] to work when the id attribute is '.' then this might resolve this problem

Yes, it might. But we can also use the [bw_field] shortcode which doesn't perform the single post checks. That was a side issue ( #28 ). Then when I tried testing the first fix for this problem on another site I got a different problem. This was associated with the core/post-hierarchical-terms block ( #29 ) .

But now I'm back on this one and thinking up dastardly tests which will potentially cause recursion problems with core/post-content, core/template-part and even core/post-excerpt and combinations of these blocks and posts which use them.

I believe there's already been some work done on reusable blocks that go recursive.

Here are some scenarios.

Scenario	Current result	Expected result	Fix developed?
core/post-content used directly	Loop	Some message saying don't do this	Yes
core/post-content used in identical post found by core/query

[bobbingwide]

I imagine that the core/post-excerpt block has exactly the same problem.

I checked and got an unexpected result. core/post-excerpt seems to ignore the core/more block. Looks like I'll have to raise another issue. Post excerpt block ignores the core/more block.

[bobbingwide]

Re: scenario 2. core/post-content used in identical post found by core/query I didn't get as far as testing the output on the front end. The first error happened in the editor with a 500 error code in response to:

https://s.b/wp55/tt1/wp-json/wp/v2/posts?
offset=0&order=desc&orderby=date&per_page=3&exclude%5B0%5D=58&context=edit&_locale=user

This problem occurred because I had not yet fixed the problem for the first scenario. Once that was resolved I was able to edit the new post.

I created two identical posts containing a query for the 3 most recent posts. each displayed the post title and post content. Then I viewed one of the posts. It timed out.

[bobbingwide]

For scenario 2. I decided to try to create an easier to understand set of pages which would exhibit the problem, using both core/post-content blocks and my shortcode equivalent [bw_pages].

Setup

Pages involved in the test

Title	Content
A	query showing post-content / shortcode
B	normal content
C	query showing post-content / shortcode
D	normal content

• Set numberposts = 4
• Allow the default exclude= attribute to be applied
• test with Excerpts first
• then with Content

This is now raised as bobbingwide/oik/issues/166

[bobbingwide]

Having developed a fix for https://github.com/bobbingwide/oik/issues/166 I should now be able to recreate the scenario using core/query blocks. Then I can fiddle with the code until it produces the same output. The requirements are to be able to create the same solution in my FSE environments as for [bw_pages].

I'll attempt to recreate and fix the problem using Twenty Twenty-One Blocks and Gutenberg source. I'll start from fix/26593 since I reckon the underlying problem is the same.

BTW: The next stage would be to extend the logic to detect infinite recursion in template parts... assuming that's an issue as well. To be tested.

[bobbingwide]

It was easier to use the run time version of Gutenberg to develop a working version. Here's a screen capture for the equivalent content.

Note: In order to get this output I needed to eliminate the more block from each post's content. Interestingly the post-excerpt block appeared more like the post-content block and vice-versa.

[bobbingwide]

Interestingly the post-excerpt block appeared more like the post-content block and vice-versa.

Well, the post-content block appeared more like an excerpt than post content. In order to fix this I had to change the core function get_the_content() to set $elements['more'] to true, since generate_postdata() hadn't.

Not surprisingly this didn't resolve the problem with the post-excerpt ignoring the more block.

[bobbingwide]

BTW: The next stage would be to extend the logic to detect infinite recursion in template parts... assuming that's an issue as well. To be tested.

[bobbingwide]

I'll start from fix/26593 since I reckon the underlying problem is the same.

No I won't. I developed the fix against Gutenberg runtime since it's quicker to develop the code in the build folder rather than wait for it to be rebuilt by npm run dev. Now I've got it working for core/post-content I'll create a new branch - fix/26923 - and develop it there.

But first I'll try to create a problem with recursive template parts.

[bobbingwide]

But first I'll try to create a problem with recursive template parts.

That wasn't hard. Now to raise a separate issue as I've realised that it could be more complicated since template parts can get loaded up in a variery of methods at present using: postId, theme and slug.

[bobbingwide]

After refactoring I noticed that core/post-content was being rejected with a recursion error when using get_the_ID() as the $id parameter to fizzie_process_this_content. Changing it to $block->context['postId'] ) appeared to resolved the problem. But needs retesting. Check

[bobbingwide]

But needs retesting. Check

I haven't experienced problems like this for a while. I couldn't be bothered to retest but did revisit my documentation for the post-content block and found it needed updating.

I had to correct the query-loop block to post-template then chose a better query for the example. The screenshot of the example is a bit iffy though.

I also updated the notes and included the post-content block directly into the post in order to demonstrate that the Fizzie theme implements its own recursion detection.