Make WordPress Core

Opened 3 years ago

Last modified 3 years ago

#53723 new defect (bug)

503 Errors in Posts with Complex Gutenberg Content

Reported by: aut0poietic's profile aut0poietic Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Editor Keywords:
Focuses: Cc:

Description

Trying to track down the source of an error I'm seeing across the sites/servers I host that appeared after the 5.8 upgrade.

Symptoms so far are either:

  • A 503 Service Unavailable error
  • A Blank page. Server cutting off output at random point on each site, often in the middle of tag names or attributes (where there's no PHP, static content).

This is happening on specific pages/posts. It is happening when viewing the page/post on the front end AND if you try to edit the post/page in the editor via the WP Admin.

In both error cases, there are no PHP errors displayed, outside of the servers that were displaying the 503 error.

In narrowing down the error, I tried removing filters from the_content on a hunch and found that if I removed the filter below, the pages started working without error:

remove_filter( 'the_content', 'do_blocks', 9 );

Once there, I tried setting wp_posts.post_content manually and narrowed the issue down to specific sets of blocks: Nested blocks with an HTML block that contains SVGs that have large-ish paths. Here's a gist with 3 different post_content HTML.

https://gist.github.com/aut0poietic/9df32c4383bd8934db59671b77a673ee

The example post_content-broken.html triggers the error consistently on all of my sites across multiple servers. The other examples are the same block content, with minor changes that DO NOT trigger the error.

Our Ops folks could find almost nothing in the logs, spare this FastCGI error:

[Tue Jul 20 15:36:00.465094 2021] [proxy_fcgi:error] [pid 3207915:tid 140096612689664] [client 172.31.1.17:58998] AH01067: Failed to read FastCGI header

Digging around, it seems like WP_Block_Parser may be having issues with the content.

For giggles, I tried adding this code to a fresh site on a completely unrelated server (Flywheel Local) and couldn't trigger the issue. So there's obviously something on these servers that are contributing to the issue, I just can't narrow down what that could be.

The server info from Site Health is pretty standard:

server_architecture: Linux 4.18.0-240.22.1.el8_3.x86_64 x86_64
httpd_software: Apache
php_version: 7.2.24 64bit
php_sapi: fpm-fcgi
max_input_variables: 4000
time_limit: 600
memory_limit: 256M
max_input_time: 300

I can post the full site health if needed. It goes without saying that I used the standard troubleshooting practices to test, including:

  • Disable all plugins
  • Set the theme to twentytwenty
  • Reset Permalinks

Not sure where to go with this next. Help?

Examples demonstrating the content from the Gist in action:

https://help.okfosters.org/testing-broken/
https://help.okfosters.org/testing-working-remove-group/
https://help.okfosters.org/testing-working-remove-line-15/

If you need any more information, please let me know.

Change History (1)

#1 @aut0poietic
3 years ago

  • Component changed from General to Editor

Just to follow up, PHP 7.2 may be the problem. I don't have the resources to create a perfect mirror, but an updated server with similar configuration with 7.4 instead of 7.2 doesn't exhibit the bug.

I haven't been able to confirm, but I suspect the issue lies with a regex in WP_Block_Parser.

https://github.com/WordPress/WordPress/blob/270f2011f8ec7265c3f4ddce39c77ef5b496ed1c/wp-includes/class-wp-block-parser.php#L412

Note: See TracTickets for help on using tickets.