![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
#61151 closed defect (bug) (fixed)
Fatal error in wp_apply_custom_classname_support()
| Reported by: | caercam | Owned by: | SergeyBiryukov |
|---|---|---|---|
| Priority: | normal | Milestone: | 6.6 |
| Component: | Editor | Version: | 6.5 |
| Severity: | normal | Keywords: | has-patch |
| Cc: | Focuses: |
Description
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.
Solution
Simply check that WP_Block_Supports::$block_to_render['attrs'] is present and is indeed an array.
Notes
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.
2 years ago
#1
- Keywords has-patch added
#2
@
2 years ago
- Milestone Awaiting Review → 6.6
Hi there, thanks for the detailed explanation and steps to reproduce! The suggested fix looks good to me.
@SergeyBiryukov commented on PR #6507:
2 years ago
#4
Thanks for the PR! Merged in r58112.
Add an additional check to
WP_Block_Supports::apply_block_supports()to make sureWP_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: https://core.trac.wordpress.org/ticket/61151