[wp-trac] [WordPress Trac] #61151: Fatal error in wp_apply_custom_classname_support()

[WordPress Trac]

#61151: Fatal error in wp_apply_custom_classname_support()
--------------------------+-----------------------------
 Reporter:  caercam       |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Editor        |    Version:  6.5
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 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
 [https://wordpress.org/support/topic/critical-error-on-this-website-39/ 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!

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/61151>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform