Make WordPress Core

Opened 3 weeks ago

Closed 3 weeks ago

Last modified 3 weeks ago

#61151 closed defect (bug) (fixed)

Fatal error in wp_apply_custom_classname_support()

Reported by: caercam's profile caercam Owned by: sergeybiryukov's profile SergeyBiryukov
Milestone: 6.6 Priority: normal
Severity: normal Version: 6.5
Component: Editor Keywords: has-patch
Focuses: Cc:


This is a follow-up to #56801. Issue is still present despite being fixed in #56799.

What's happening

The mentioned tickets clearly describe the issue, particularly this comment from ticket:#56799#comment:9 by @hellofromTonya, which summarizes the observed behavior and the proposed fix. The problem with this fix is that, while it does indeed ensure that WP_Block_Supports::$block_to_render contains a attrs key, which addresses the raised bug, it does not verify that it is indeed an array: a mistake in the attributes of a block is enough to generate an invalid JSON, which then becomes null when the block is parsed, causing the error.

Steps to reproduce

I noticed the issue with a custom block, but it can easily be reproduced using the latest-posts block: create a new post, open the Code editor and paste this:

<!-- wp:latest-posts {"categories":[{"id":}]} /-->

The latest-posts blocks has a registered categories attribute of type array, meant to contain a list of category objects. The above code contains an invalid object with an empty id, causing an invalid JSON to be saved to the post content, resulting in a the Fatal error.

The worst part is that now we've messed up both the backend and the frontend: the block editor fails to load, meaning we can't even edit the post anymore, and the post on front crashes the site.


Simply check that WP_Block_Supports::$block_to_render['attrs'] is present and is indeed an array.


I've been seeing this bug on my sites for months now, but it took me quite a while to figure out where the issue was. Not sure exactly why, but the issue would not show on my posts, as the invalid JSON was actually in revisions and not the post itself. That's a vicious one, you may think to check the post content through PhpMyAdmin as I did, but not the revision... And whenever you cleanup your site, revisions disappear, and so does the bug and your chances to track it. I haven't seen much reports of that bug, but it has made at least one appearance in the support forum. I guess it does not show up very often as you have to 1/ edit blocks' attributes manually with the code editor 2/ mess up doing so to trigger it. Fortunately I did both!

Change History (4)

This ticket was mentioned in PR #6507 on WordPress/wordpress-develop by @caercam.

3 weeks ago

  • Keywords has-patch added

Add an additional check to WP_Block_Supports::apply_block_supports() to make sure WP_Block_Supports::$block_to_render['attrs'] is present and is an array. This prevents a Fatal error when a block contains an invalid JSON attributes.

Trac ticket:

#2 @SergeyBiryukov
3 weeks ago

  • Milestone changed from Awaiting Review to 6.6

Hi there, thanks for the detailed explanation and steps to reproduce! The suggested fix looks good to me.

#3 @SergeyBiryukov
3 weeks ago

  • Owner set to SergeyBiryukov
  • Resolution set to fixed
  • Status changed from new to closed

In 58112:

Editor: Check that attrs is an array in WP_Block_Supports::apply_block_supports().

This prevents a fatal error in wp_apply_custom_classname_support(), which expects an array data type for block attributes, and makes sure the block editor can still load if there is a mistake in the attributes of a block.

Follow-up to [54498].

Props caercam.
Fixes #61151.

@SergeyBiryukov commented on PR #6507:

3 weeks ago

Thanks for the PR! Merged in r58112.

Note: See TracTickets for help on using tickets.