Script Modules: Add data server->client data passing

[sirreal]

See https://make.wordpress.org/core/2024/05/06/proposal-server-to-client-data-sharing-for-script-modules/

Includes #6452
Requires WordPress/gutenberg#60952 (this PR builds and registers the @wordpress/api-fetch module).

Trac ticket:

---

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• The Plugin and Theme Directories cannot be accessed within Playground.
• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[anomiex]

Any reason not to include JSON_UNESCAPED_SLASHES here too? I suspect URLs of endpoints will be relatively common data, and avoiding the leaning toothpick syndrome would be nice. Having JSON_HEX_TAG should be sufficient to avoid problems with </script> that the default escaping of slashes was added to avoid.

JSON_UNESCAPED_UNICODE is another one to consider, but that would need testing for whether it breaks if pages are served with an encoding other than UTF-8.

[sirreal]

I didn't consider this at all, it's copied from how the Interactivity API implements the same thing:

wordpress-develop/src/wp-includes/interactivity-api/class-wp-interactivity-api.php

Lines 170 to 179 in 473e255

	wp_print_inline_script_tag(
	wp_json_encode(
	$interactivity_data,
	JSON_HEX_TAG | JSON_HEX_AMP
	),
	array(
	'type' => 'application/json',
	'id' => 'wp-interactivity-data',
	)
	);

I did some testing and it seems like we should be able to add JSON_UNESCAPED_SLASHES in both of these places, thanks!

[sirreal]

JSON_UNESCAPED_UNICODE might also be nice to add, but as you mention it might need to be behind a UTF-8 check:

$opts = JSON_HEX_TAG | JSON_HEX_AMP | JSON_UNESCAPED_SLASHES;
if ( get_bloginfo( 'blog_charset' ) === 'UTF-8' ) {
  $opts |= JSON_UNESCAPED_UNICODE;
}

It looks like it would certainly improve readability and potentially size:

<?php
$opts = 0;
$t = '🏴󠁧󠁢󠁥󠁮󠁧󠁿';
var_dump(
    $t,
    strlen($t),
    json_encode($t, $opts),
    strlen(json_encode($t, $opts)),
    json_encode($t, $opts | JSON_UNESCAPED_UNICODE),
    strlen(json_encode($t, $opts | JSON_UNESCAPED_UNICODE)),
);

string(28) "🏴󠁧󠁢󠁥󠁮󠁧󠁿"
int(28)
string(86) ""\ud83c\udff4\udb40\udc67\udb40\udc62\udb40\udc65\udb40\udc6e\udb40\udc67\udb40\udc7f""
int(86)
string(30) ""🏴󠁧󠁢󠁥󠁮󠁧󠁿""
int(30)

[sirreal]

I'll follow up for Interactivity API here: #6520

[anomiex]

In some quick experimenting, I find Firefox 125 and Chromium 124 both do need the document to be utf-8 to interpret unescaped Unicode properly.

Also they seem to use the actual Content-Type HTTP header over <meta> tags if both specify a different charset, but they'll use <meta> tags if the HTTP header doesn't specify a charset. The deprecated charset attribute on a <script> tag doesn't seem to be used by either.

[westonruter]

It is vital that JSON_UNESCAPED_SLASHES not be added, as it avoids a security vulnerability when encoding a string that includes </script>. When slashes are escaped, this becomes <\/script> and the browser won't prematurely close the script tag.

[sirreal]

Thanks for flagging that! I'd like to continue discussing on #6520 (comment), where I've replied. That PR is likely to land sooner, and whatever implementation is used there should also be used here. (In fact, I'd expect Interactivity API to use this proposal to print its data.)

[anomiex]

@westonruter I already addressed that concern

Having JSON_HEX_TAG should be sufficient to avoid problems with </script> that the default escaping of slashes was added to avoid.

Is there any reason to think that's not accurate?

[westonruter]

Ah, yes. As long as JSON_HEX_TAG is present, then it seems safe to include JSON_UNESCAPED_SLASHES. Sorry I missed that. Maybe add a comment explaining why the particular set of flags are used, noting the security implications.

[sirreal]

This proof of concept is superseded by #6682.