Opened 13 months ago
Closed 12 months ago
#59841 closed defect (bug) (invalid)
Post 6.4 Upgrade Fatal:
Reported by: | rebasaurus | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | |
Component: | REST API | Keywords: | |
Focuses: | Cc: |
Description
After upgrading to 6.4, this fatal occurs:
PHP message: Fatal error: Uncaught TypeError: Cannot access offset of type string on string in /var/www/wp-includes/rest-api.php:3082 Stack trace: #0 /var/www/wp-includes/rest-api.php(3104): rest_default_additional_properties_to_false('string') #1 /var/www/wp-includes/rest-api/fields/class-wp-rest-meta-fields.php(484): rest_default_additional_properties_to_false(Array) #2 /var/www/wp-includes/rest-api/fields/class-wp-rest-meta-fields.php(511): WP_REST_Meta_Fields->get_registered_fields() #3 /var/www/wp-includes/rest-api/endpoints/class-wp-rest-revisions-controller.php(768): WP_REST_Meta_Fields->get_field_schema() #4 /var/www/wp-includes/rest-api/endpoints/class-wp-rest-controller.php(388): WP_REST_Revisions_Controller->get_item_schema() #5 /var/www/wp-includes/rest-api/endpoints/class-wp-rest-controller.php(343): WP_REST_Controller->get_context_param() #6 /var/www/wp-includes/rest-api/endpoints/class-wp-rest-revisions-controller.php(783): WP_REST_Controller->get_collection_params() #7 /var/www/wp-includes/rest-api/endpoints/class-wp-rest-revisions-controller.php(97): WP_REST_Revisions_Controller->get_collection_params() #8 /var/www/wp-includes/rest-api.php(250): WP_REST_Revisions_Controller->register_routes() #9 /var/www/wp-includes/class-wp-hook.php(324): create_initial_rest_routes(Object(WP_REST_Server)) #10 /var/www/wp-includes/class-wp-hook.php(348): WP_Hook->apply_filters(NULL, Array) #11 /var/www/wp-includes/plugin.php(517): WP_Hook->do_action(Array) #12 /var/www/wp-includes/rest-api.php(593): do_action('rest_api_init', Object(WP_REST_Server)) #13 /var/www/wp-includes/rest-api.php(417): rest_get_server() #14 /var/www/wp-includes/class-wp-hook.php(324): rest_api_loaded(Object(WP)) #15 /var/www/wp-includes/class-wp-hook.php(348): WP_Hook->apply_filters(NULL, Array) #16 /var/www/wp-includes/plugin.php(565): WP_Hook->do_action(Array) #17 /var/www/wp-includes/class-wp.php(418): do_action_ref_array('parse_request', Array) #18 /var/www/wp-includes/class-wp.php(813): WP->parse_request('') #19 /var/www/wp-includes/functions.php(1336): WP->main('') #20 /var/www/wp-blog-header.php(16): wp() #21 /var/www/index.php(17): require('/var/www/wp-blo...') #22 {main} thrown in /var/www/wp-includes/rest-api.php on line 3082
I suspect introduced in https://core.trac.wordpress.org/changeset/56819. When $schema
is of the below format and is passed into https://github.com/WordPress/WordPress/blob/436d55fa51a2f46ad6ac7e16fcb4e83618afb030/wp-includes/rest-api.php#L3081:
array ( 'type' => 'array', 'items' => array ( 'type' => 'string', ), )
It recursively calls itself again at https://github.com/WordPress/WordPress/blob/436d55fa51a2f46ad6ac7e16fcb4e83618afb030/wp-includes/rest-api.php#L3104 with the 'items' array and throws the fatal. An example post type is attachment
where I'm seeing it occur on.
Change History (12)
#2
@
13 months ago
Sure, you can simply shell in and do:
rest_default_additional_properties_to_false( [ 'type' => 'array', 'description' => 'array of strings for screenshot URLs', 'default' => [], 'items' => 'string' ] );
To be clear this happens on WP 6.3, when you directly call the function, but I noticed that class-wp-rest-template-revisions-controller.php
was newly added on 6.4. In that class, get_registered_fields()
is called now, which calls rest_default_additional_properties_to_false()
. I wasn't sure if ya'll wanted to do any additional handling for unexpected formatted schemas passed into register_post_meta()
now?
register_post_meta( 'example_post_type', 'example_meta_key', array( 'type' => 'array', 'description' => 'Array of strings', 'sanitize_callback' => function ( $urls ) { return array_map( fn( $url ) => sanitize_text_field( $url ), $urls ); }, 'show_in_rest' => array( 'schema' => array( 'type' => 'array', 'items' => 'string', ), ), ) );
#3
@
13 months ago
I copied and pasted the wrong example in the original description :facepalm:. I meant for the below $schema
to be where it triggers the fatal:
array (size=4) 'type' => string 'array' (length=5) 'description' => string 'Array of strings for the screenshot URLs' (length=40) 'default' => array (size=0) empty 'items' => string 'string' (length=6)
When rest_default_additional_properties_to_false()
gets recursively called, it assumes $schema['items']
is an array, but in this case, it's a string.
#4
@
13 months ago
- Milestone changed from Awaiting Review to 6.4.1
Hello @rebasaurus,
Welcome back to WordPress Core's Trac :) Thank you for reporting this issue.
Moving it into 6.4.1, dropping it into the Make/Core #core
slack channel for more immediate awareness, and pinging some of the REST API maintainers @TimothyBlynJacobs @kadamwhite @spacedmonkey.
This ticket was mentioned in Slack in #core by jorbin. View the logs.
13 months ago
#6
@
13 months ago
Summary of discussion in Make/Core slack:
@TimothyBlynJacobs noted:
This looks like user error to me.
'schema' => array( 'type' => 'array', 'items' => 'string', ),That is an invalid JSON schema.
Restoring this back to Awaiting Review
.
Timothy also noted:
We could probably consider hardening those functions to behave better with invalid schemas along the lines of some of the other PHP 8 related changes we are making.
#8
@
13 months ago
- Milestone changed from Awaiting Review to 6.4.2
Moving to 6.4.2 so we can consider follow up but based on the comment above, it's not urgent.
#9
@
12 months ago
- Keywords reporter-feedback added
Adding reporter feedback
since we are still waiting, but barring any I think this should be closed as invalid
. I think the absence of widespread reports of this issue means the assumption that it is an implementation error is correct.
This ticket was mentioned in Slack in #core by jorbin. View the logs.
12 months ago
#12
@
12 months ago
- Keywords reporter-feedback removed
- Milestone 6.4.3 deleted
- Resolution set to invalid
- Status changed from new to closed
With no further information, I'm closing this as invalid
. If there is new information, then this should be reconsidered but as of now, the assumption is that this is an implementation error rather than a core issue.
Hi @rebasaurus, thanks for reporting the issue. Could you please share replication steps on how to reproduce this Fatal error?