WordPress / WordPress/WordPress-Coding-Standards
Flag any manual construction of inline `<script>` tags
Nobody has claimed this yet.
- Dominant language
- PHP
- Stars
- 2.8k
- Forks
- 521
- Avg merge
- 5d 20h
- Merged PRs (30d)
- 1
Description
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:
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with WordPress/Sniffs/WP/EnqueuedResourcesSniff.php, especially its existing NonEnqueuedScript handling. Compare that sniff with the inline script construction examples in the issue, then determine the appropriate sniff location and detection behavior; the work is done when manual inline script tags are flagged while the recommended helper usage is supported.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- php
- Domain
- tooling
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100