[wp-trac] [WordPress Trac] #64314: Fatal error when enabling revisions for post meta of type array/object

[WordPress Trac]

#64314: Fatal error when enabling revisions for post meta of type array/object
--------------------------+--------------------------
 Reporter:  LAPSrj        |       Owner:  westonruter
     Type:  defect (bug)  |      Status:  reviewing
 Priority:  normal        |   Milestone:  7.0
Component:  Revisions     |     Version:  6.8.3
 Severity:  critical      |  Resolution:
 Keywords:  has-patch     |     Focuses:
--------------------------+--------------------------

Comment (by manhphucofficial):

 I was able to reproduce the fatal error on my local environment using the
 trac64314.zip reproducer plugin.

 Environment:
 - WordPress 6.8.3
 - PHP 8.2.24

 When saving a post that contains array/object postmeta, the editor
 displays “Updating failed.” and the REST API request returns an HTTP 500
 error. The PHP error log shows the following fatal error:

 [29-Nov-2025 14:44:42 UTC] PHP Fatal error:  Uncaught TypeError: trim():
 Argument #1 ($string) must be of type string, array given in /var/www/html
 /wordpress-test/wp-includes/formatting.php:5499
 Stack trace:
 #0 /var/www/html/wordpress-test/wp-includes/formatting.php(5499): trim()
 #1 /var/www/html/wordpress-test/wp-includes/revision.php(190):
 normalize_whitespace()
 #2 /var/www/html/wordpress-test/wp-includes/revision.php(116):
 wp_save_post_revision()
 #3 /var/www/html/wordpress-test/wp-includes/class-wp-hook.php(326):
 wp_save_post_revision_on_insert()
 #4 /var/www/html/wordpress-test/wp-includes/class-wp-hook.php(348):
 WP_Hook->apply_filters()
 #5 /var/www/html/wordpress-test/wp-includes/plugin.php(517):
 WP_Hook->do_action()
 #6 /var/www/html/wordpress-test/wp-includes/post.php(5831): do_action()
 #7 /var/www/html/wordpress-test/wp-includes/rest-api/endpoints/class-wp-
 rest-posts-controller.php(1042): wp_after_insert_post()
 #8 /var/www/html/wordpress-test/wp-includes/rest-api/class-wp-rest-
 server.php(1292): WP_REST_Posts_Controller->update_item()
 #9 /var/www/html/wordpress-test/wp-includes/rest-api/class-wp-rest-
 server.php(1125): WP_REST_Server->respond_to_request()
 #10 /var/www/html/wordpress-test/wp-includes/rest-api/class-wp-rest-
 server.php(439): WP_REST_Server->dispatch()
 #11 /var/www/html/wordpress-test/wp-includes/rest-api.php(459):
 WP_REST_Server->serve_request()
 #12 /var/www/html/wordpress-test/wp-includes/class-wp-hook.php(324):
 rest_api_loaded()
 #13 /var/www/html/wordpress-test/wp-includes/class-wp-hook.php(348):
 WP_Hook->apply_filters()
 #14 /var/www/html/wordpress-test/wp-includes/plugin.php(565):
 WP_Hook->do_action()
 #15 /var/www/html/wordpress-test/wp-includes/class-wp.php(418):
 do_action_ref_array()
 #16 /var/www/html/wordpress-test/wp-includes/class-wp.php(818):
 WP->parse_request()
 #17 /var/www/html/wordpress-test/wp-includes/functions.php(1342):
 WP->main()
 #18 /var/www/html/wordpress-test/wp-blog-header.php(16): wp()
 #19 /var/www/html/wordpress-test/index.php(17): require('...')
 #20 {main}
   thrown in /var/www/html/wordpress-test/wp-includes/formatting.php on
 line 5499

 This confirms the issue described in this ticket: normalize_whitespace()
 calls trim(), which only accepts strings, but receives an array from
 $post->$field in wp_save_post_revision().

 After applying the proposed fix from PR 10560 and updating the comparison
 to serialize the values:

 foreach ( array_keys( _wp_post_revision_fields( $post ) ) as $field ) {
     if ( normalize_whitespace( serialize( $post->$field ) ) !==
 normalize_whitespace( serialize( $latest_revision->$field ) ) ) {
         $post_has_changed = true;
         break;
     }
 }

 the fatal error no longer occurs.

 Results after applying the patch:
 - The post saves successfully with no “Updating failed.” notice
 - No more PHP fatal errors
 - Revisions are created correctly when array/object meta values change
 - I tested creating new posts and repeatedly modifying the meta, and
 everything continues to work as expected
 - No regressions observed in my testing

 Based on my results, the patch in PR 10560 fully resolves the issue and
 appears safe to include.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64314#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform