Sanitize checks fail if semi-colons are in strings

[Otto42]

https://wordpress.org/support/topic/add_setting-check-can-fail-even-if-callback-specified

Example to trigger:

$wp_customize->add_setting('foofoo', array(
  'foo'=>'string containing ; here',
  'sanitize_callback'=>'bar'
) );

Workaround for now: move the string into a variable outside the function call:

$str = 'string containing ; here';
$wp_customize->add_setting('foofoo', array(
  'foo'=>$str,
  'sanitize_callback'=>'bar'
) );

Fix: Regex in customizer.php check needs to be more robust.

[grappler]

What about /\$wp_customize->add_setting\((.*\)(?=;))/Us?

[Otto42]

With the proposed change, inserting ) followed by ; into a string causes a fail.

I realize there is no perfect answer while using regexp. Perhaps a different approach? Thinking of making the tokenized file data available to all checks as a fourth parameter or something, rather than having each check that uses it do their own tokenization.

[Otto42]

Also, note that $wp_customize is just a convention. Themes can, in theory, name this variable they're being passed something else entirely. So even with tokenization, there's no perfect check here.

[grappler]

We can only catch the bigger offenders. I don't fully understand what you mean with tokenization?

I wonder if we could build on top of WordPress-Coding-Standards

[Otto42]

Some of the checks, like the textdomain.php one, tokenizes the PHP code and searches through it that way to find the translation function calls.

Tokenizing is basically using the PHP parser to convert a PHP file into the equivalent tokens. So, instead of just an underscore followed by the letter e _e, you get things like T_STRING and other identifiers. You can parse through the code somewhat more easily this way, since it's been pre-parsed by the PHP engine for you. This all relies on https://secure.php.net/manual/en/function.token-get-all.php

Now, if the main engine tokenized all the PHP in advance, then it could make that available to all of the checks, without having each check that uses it do it themselves. This would simplify some of the checks and reduce the amount of regexp being run. It would make them a bit longer, but probably quite a bit faster for some cases.

[jrfnl]

Looking at this check, this should be moved to WPTRTCS in the form of a sniff which will make checking this much easier & more accurate.

[jrfnl]

For the time being, it could be partially mitigated by adjusting the regex to /\$wp_customize->add_setting\(([^;]+)\);/, though @Otto42's remark in https://github.com/WordPress/theme-check/issues/36#issuecomment-218188784 still applies even then.