_print_scripts should use the wp_inline_script_attributes filter

[galaxor]

On my site, we want to use a ​content-security-policy. And in this policy, we would like to not include support for 'unsafe-inline' scripts.

We can include inline scripts, as long as they have a nonce in them. That is, instead of just a <script> tag, if they included a <script nonce="xxxxxxx">, where the nonce is generated on every page load, and if our Content-Security-Policy contains script-src 'nonce-xxxxxxxx'.

Some of the scripts generated by WordPress core—and, indeed, by plugins—print themselves out using the wp_get_inline_script_tag function. When a script does that, then our theme can add a filter on the wp_inline_script_attributes hook, which adds the nonce according to our own logic.

However, there are some inline scripts printed by WordPress core that do not use wp_get_inline_script_tag, and with these scripts, there is no way to for our theme to add a nonce to the script tag, and therefore no way to allow these scripts to run in the context of a Content-Security-Policy that does not allow 'unsafe-inline' scripts.

The scripts added by WordPress core are at least those that are added by wp_default_scripts. Ultimately, these are printed out using the function _print_scripts, in wp-includes/script-loader.php. It prints the script tag using

echo "\n<script{$type_attr}>\n";

where $type_attr is either the empty string or "type='text/javascript'".

I propose that _print_scripts be changed so that instead of echoing the script directly, it constructs the code it wants to output, and prints it onto the page using wp_get_inline_script_tag, so that themes or plugins can add filters on the wp_inline_script_attributes hook to add a nonce (or do anything else).

Is that a good approach? If so, I can submit a pull request.

If there's another approach that would be better, I could do that. Perhaps we want to have a different hook here for some reason.

[sabernhardt]

Related: #58664