Flag any manual construction of inline `<script>` tags

[westonruter]

Is your feature request related to a problem?

Manually constructing inline script tags is no longer necessary with the introduction of wp_get_inline_script_tag() and wp_print_inline_script_tag()in Core-39941. Importantly, these functions allow for the attributes to be filtered via the wp_inline_script_attributes. This allows for a nonce attribute to be added to make scripts compatible with Strict CSP (Content Security Policy), which a plugin can enforce (for example). These functions are now used on the frontend and on the login screen as of Core-58664, although not yet in the admin per Core-59446. Some bundled themes are also manually constructing script tags, per Core-63806. By having a sniff that flags these in WPCS, we can start fixing instances of manual script construction in the WP admin while at the same time getting the ecosystem to also adopt this better way to construct script tags.

Describe the solution you'd like

The WordPress.WP.EnqueuedResources sniff already flags construction of external script tags with a NonEnqueuedScript error. This existing sniff (or a new one, like WordPress.WP.InlineResources) should flag the construction of inline script tags.

So instead of:

<?php
function my_theme_supports_js() {
        echo '<script>document.body.classList.remove("no-js");</script>'; // ❌ DO NOT DO THIS 👎
}
add_action( 'wp_footer', 'my_theme_supports_js' );

This should be done instead:

<?php
function my_theme_supports_js() {
        wp_print_inline_script_tag( 'document.body.classList.remove("no-js");' ); // ✅ Do this instead 👍
}
add_action( 'wp_footer', 'my_theme_supports_js' );

Additional context (optional)

Relates to:

• Flag any echos inside of <script> tags if wp_json_encode() not used and ensure JSON is encoded with the best flags #63

[kkmuffme]

Good point!

It would be great though, if it wouldn't report for constructs like:

ob_start(); ?>
<script>
<?php
ob_end_clean(); // when using it with wp_add_inline_script() this would be an ob_clean();

which I often use to allow for IDE/eslint/tsc analysis of the JS, even if it's just a few lines of JS.

---

These functions definitely also needs to get on the list of outputting functions (like trigger_error, print,... already are), otherwise this is going to end up with tons of XSS issues in plugins.

[westonruter]

@kkmuffme yes, that's a very good point! In fact, I added the wp_remove_surrounding_empty_script_tags() function for this exact purpose in r56748. See also Core-59444.