Add Theme forbidden PHP functions sniff + unit tests.

[jrfnl]

Initial setup for the forbidden functions sniff as described in issue #9.

[Edit] Changed over to use WordPress_Sniffs_Functions_FunctionRestrictionsSniff as the base class rather than Generic_Sniffs_PHP_ForbiddenFunctionsSniff.
This allows for better differentiation of the error messages, keeping it more in line with what people have come to expect from Theme Check.

[jrfnl]

Regarding the travis failure: this has to do with a double fix upstream in WPCS and in PHPCS. Once the up to date version of WPCS develop has been merged in, I'll rebase and the build will pass.

[ernilambar]

I propose adding create_function to the forbidden list. If not error then at least warning.

[grappler]

I would like to fully modularize the discouraged functions upstream before we merge this in. Ref: WordPress/WordPress-Coding-Standards#633

create_function is still a recommended method for registering widgets on Codex https://codex.wordpress.org/Widgets_API

Also https://twitter.com/grapplerulrich/status/759126711929798660

[Pross]

Its drafted for deprecation in 7.1
https://wiki.php.net/rfc/deprecations_php_7_1

[jrfnl]

But it's the only alternative to anonymous functions in PHP 5.2 and as WP is still not dropping 5.2 and the adoption of WP on 5.2 > than WP on 7.1....
In other words - yes, create_function() should be discouraged, but only when WP drops support for PHP 5.2 somewhere in the future.

[jrfnl]

Also: AFAICS looks like no vote has taken place yet and as PHP 7.1 is already in RC Beta phase, I doubt it will make it in in time, so deprecation will probably not happen in PHP 7.1.

[ernilambar]

When something hooked using create_function, that cannot be unhook/removed/modified from child theme. Thus making theme not fully child theme ready (which is against TRT guideline).

[justintadlock]

Are there any use cases for create_function() in a theme?

Like @ernilambar said, themes must be child-theme ready. Something like this is not child-theme compatible:

add_action(
    'wp_head',
    create_function( '', 'return some_function();' )
);

However, this is child theme compatible because the widget can be deregistered:

add_action(
    'widgets_init',
    create_function( '', 'return register_widget("My_Widget");')
);

At the very least, this should be a warning. More times than not, it's going to be an indication of some issue. Reviewers and theme authors should definitely be made aware of it.

[ernilambar]

paginate_links() is almost all the time used in the place where it can be replaced by the_posts_pagination(). I know paginate_links() is capable of paginating anything. But I cannot think any other use cases. May be we can add paginate_links() in discouraged functions list.
Any other use cases?

[justintadlock]

The two most likely use cases for paginate_links() are:

1. When you need to create pagination that the core the_posts_pagination() is not capable of.
2. When you're building special pagination for a plugin that your theme supports.

But, legit use cases are few and far between.

[grappler]

@jrfnl I think this can be merged? I don't see any reason not to.

[jrfnl]

eval should be removed here as it's a language construct, not a function (the dedicated token has since the original PR been removed from the parent sniff as well).
An upstream Squiz sniff should be added instead.
See: https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards/blob/develop/WordPress-Extra/ruleset.xml#L73-L77

[jrfnl]

This WPCS has since the original PR been deprecated. The WordPress\AbstractFunctionRestrictionsSniff should be used instead.

[jrfnl]

fuctions => functions

[jrfnl]

This group should be removed as it's already covered in the PHP\DiscouragedPHPFunctions sniff.
If the error level & message needs changing, this can be done from the ruleset.

[jrfnl]

Example should be removed (as it belong with the parent class) or updated.

[jrfnl]

This group should be removed as it's already covered in the PHP\DiscouragedPHPFunctions sniff.
If the error level & message needs changing, this can be done from the ruleset.

[jrfnl]

Alignment + comment style should be updated to reflect upstream changes ;-)

[jrfnl]

This sniff is now deprecated.

The WordPress.PHP.PHPDiscouragedFunctions sniff covers at least part of it.

[jrfnl]

I think this can be merged? I don't see any reason not to.

Had a quick look and sorry, no, this can't be merged as is. Code is very out of date compared to upstream.

[jrfnl]

• I will rebase this PR shortly & update for PHPCS 3.x
• Need input for what functions need to be sniffed for, what should be discouraged, what forbidden.

[jrfnl]

For history:

This PR was closed when we replaced the master/develop branches with the re-organized stand-alone repo.

It will not be re-opened for the following reasons:

1. This PR as it stands now would need to be split into several different ones anyway, think:
   • Add upstream WPCS sniffs to the ruleset.
   • Add sniff for PHP functions forbidden/discouraged for Themes.
   • Add sniff for WP functions forbidden/discouraged for Themes or, more likely, add to the existing PluginTerritory\ForbiddenFunctions sniff.
2. There is - at this moment - no clear list of which functions should be forbidden in the first place, so unless and until that becomes clearer, this PR would just be open for eternity.