Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
bobbingwide opened this issue Nov 10, 2020 · 14 comments
Assignees
Labels
bug Something isn't working

Comments

@bobbingwide
Copy link
Owner

bobbingwide commented Nov 10, 2020

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

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

@bobbingwide bobbingwide added the bug Something isn't working label Nov 10, 2020
@bobbingwide bobbingwide self-assigned this Nov 10, 2020
@bobbingwide
Copy link
Owner Author

This problem was mentioned in WordPress/gutenberg#22080 (comment)

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
Copy link
Owner Author

bobbingwide commented Nov 10, 2020

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
Copy link
Owner Author

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
Copy link
Owner Author

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
Copy link
Owner Author

bobbingwide commented Nov 10, 2020

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
Copy link
Owner Author

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
Copy link
Owner Author

Having developed a fix for bobbingwide/oik#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
Copy link
Owner Author

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.

image

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
Copy link
Owner Author

bobbingwide commented Nov 11, 2020

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
Copy link
Owner Author

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
Copy link
Owner Author

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
Copy link
Owner Author

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
Copy link
Owner Author

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
Copy link
Owner Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant