Hi @enricocarraro, welcome to this repo! Thanks for the PR.

Checklist of things to do before this PR will be properly reviewed:

• Add unit tests.
  Please make sure they also contain good code samples testing against false positives and false negatives.
• Add XML documentation for the sniff to the WordPress/Docs directory.
• The build needs to pass.

Please feel free to ask for as much guidance as you need from me and the others in the team.

In my case, my remarks will often presume you know what you're doing with PHPCS (as why would you send in a sniff otherwise?), please don't let that intimidate you and ask for as much clarification as you need.

I've had a quick look at it so far and to me it's unclear what this sniff is looking for based on the PR description, so I can't review the code to see if the sniff actually does what it is supposed to do.

Aside from that, the PR description refers to a function which won't be introduced in WP until version 5.7. That implies that the sniff will need to support the $minimum_supported_version property, as WPCS is used by both Core, as well as plugins and themes which often support multiple WP versions.

Other notes:

• The (complex) regex should probably be a class constant and should be properly documented.
• Is WP the right category for this sniff or should this sniff be in the Security category ? I honestly don't know at the moment, but would like to see this discussed.
• We're not a fan of duplicate code and most of this sniff seems to be copied from another sniff.
  1. Should this check be added to that other sniff instead ?
  2. If not, should (part of) the duplicate code be abstracted out ?
• The sniff has now been added to Extra. As the description mentions fixing this in WP Core, should the sniff be part of the Core ruleset ?

Oh and from looking at the PRs for Core, we will need to verify if there are any other sniffs looking at the content of inline scripts and see if these need adjusting to allow for this new way of adding inline scripts, as looking for the <script> tag will no longer work.

Hi @jrfnl, thanks for taking the time to look into this PR and pointing out what is not clear about it.

I've had a quick look at it so far and to me it's unclear what this sniff is looking for based on the PR description, so I can't review the code to see if the sniff actually does what it is supposed to do.

The sniff is looking for script tags that contain inline JavaScript, since the EnqueuedResources sniff only looks for script loaders tags (script tags with the src attribute).

• Is WP the right category for this sniff or should this sniff be in the Security category ? I honestly don't know at the moment, but would like to see this discussed.

I am not sure what the most appropriate category would be; I placed it into WP since, as you mentioned, TemplatedScripts is similar to EnqueuedResources. In WordPress 5.7 enqueued scripts will be printed using the new functions that enable strict CSP-compatibility.

Aside from that, the PR description refers to a function which won't be introduced in WP until version 5.7. That implies that the sniff will need to support the $minimum_supported_version property, as WPCS is used by both Core, as well as plugins and themes which often support multiple WP versions.

I will make sure to include the property in the next commits.

1. Should this check be added to that other sniff instead ?

In retrospect, I think it would be better to add this new sniff under EnqueuedResourcesSniff, if there is a way to attach the $minimum_supported_version property only to script tags checks.

The sniff has now been added to Extra. As the description mentions fixing this in WP Core, should the sniff be part of the Core ruleset ?

In my opinion, both NonEnqueuedScript and NonTemplatedInlineScript should be moved to the Core ruleset to prevent strict CSP-compatibility backsliding effectively starting from WordPress 5.7.

Oh and from looking at the PRs for Core, we will need to verify if there are any other sniffs looking at the content of inline scripts and see if these need adjusting to allow for this new way of adding inline scripts, as looking for the <script> tag will no longer work.

Good point, @jrfnl !
I think looking for new the functions' names (wp_get_script_tag and wp_print_script_tag) should do the job.

While it would be nice to have a sniff for this, the PR as-is is not mergable as there are open questions and the sniff isn't accompanied by tests. No action has been taken on this in over two years, so I'm going to close this PR.