WordPress / WordPress/WordPress-Coding-Standards

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

Open
#2,575 2 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Component: Core Focus: Security Type: Enhancement
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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.