@aduth you can amend to the existing wpApiSettings object by using wp_add_inline_script() like so:

wp_add_inline_script( 'wp-api', sprintf( 
    'wpApiSettings.cacheSchema = true; wpApiSettings.schema = %s;',
    wp_json_encode( $schema_response->get_data() ) 
) );

@westonruter Thanks, that works, updated in aa093eb. Not so nice to inject hand-written property setting like that, but feels a bit less error-prone overall.

@aduth as part of this, should this PR also include the revert of 7780764?

@aduth as part of this, should this PR also include the revert of 7780764?

No, I don't think so. Remarked also in original comment, but it can serve as a fallback behavior if the server-side bootstrapping fails. Since the callback will shortcut itself if a schema is already present.

Since the callback will shortcut itself if a schema is already present.

Seems the lack of network request could be attributed to session storage of the schema, not that it was picking up the schema from the API settings 😞 Certainly seems like an improvement which could be made to the client.

Actually, it does detect the schema. The issue was ordering: The default of wp_add_inline_script is to include the snippet after the script. At that point the initialization has already run, and since we've not set the global at that point, assumes the schema is not preloaded. Simply adding the 'before' parameter is enough to ensure that the settings property is assigned during initialization.

One worry is whether window.wpApiSettings could be undefined at the time we start setting properties on it. We might consider at least adding some checks here, but given that the wp-api handle is localized immediately upon being registered, I don't think we need to worry about this ordering.

Seems like a reasonable solution for now, but this call is much slower than expected and we should seek to get rid of it as soon as possible. See https://core.trac.wordpress.org/ticket/40988 for reference.