Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New Abstract for restricting arguments in functions #745

Closed
grappler opened this issue Dec 25, 2016 · 2 comments
Closed

New Abstract for restricting arguments in functions #745

grappler opened this issue Dec 25, 2016 · 2 comments

Comments

@grappler
Copy link
Member

grappler commented Dec 25, 2016

I started working on something for theme sniffs but realized this would fit better ustream. WPTT/WPThemeReview#80

As we have an abstract to restrict function it would make sense to have one to restrict arguments.

A few examples for this would be

  • get_bloginfo( 'home' ) where home is deprecated
  • making sure the correct argument is used e.g. date_i18n( get_option( 'date_format' ) ) Sniff to discourage use of number_format() and date() in output #739
  • requiring that a function has a certain argument get_bloginfo( 'name', 'display' )
  • if a certain hook should not be used e.g add_filter( 'mime_types', '' ); as it is plugin territory
  • unneeded checking for backwards compatibility with function_exist( 'add_action' )

Related issues WPTT/WPThemeReview#93 WPTT/WPThemeReview#42 WPTT/WPThemeReview#27 WPTT/WPThemeReview#1 WPTT/WPThemeReview#96
#611

The current array is as below.

array( 
'get_bloginfo' => array(
	1 => array(
		'home' => array(
			'alt'     => 'home_url()',
			'version' => '2.2'
		),
		'siteurl' => array(
			'alt'     => 'home_url()',
			'version' => '2.2'
		),
	),
),
);

First we have the function name, the position of the argument, the argument it should match. Alt is the alternative function for the deprecated parameter and version is when it was deprecated.

What I unsure about is how I can differentiate when a argument should not be used and when a argument is required.

@jrfnl
Copy link
Member

jrfnl commented Dec 25, 2016

May I suggest having an abstract class and then three concrete class - one for deprecated arguments, one for required arguments, one for checking correct usage of an argument ? Keeps the different logic isolated in different sniffs.
Does that help or did you mean something else ?

@grappler
Copy link
Member Author

grappler commented Dec 25, 2016

Thank you @jrfnl Would such a structure make sense:

  • abstract class WordPress_AbstractArgsRestrictionsSniff implements PHP_CodeSniffer_Sniff
    • class WordPress_RestrictedArgsSniff extends WordPress_AbstractArgsRestrictionsSnifff
      • class WordPress_Sniffs_Theme_DeprecatedArgsSniff extends WordPress_RestrictedArgsSniff
    • class WordPress_RequiredArgsSniff extends WordPress_AbstractArgsRestrictionsSnifff
      • class WordPress_Sniffs_XSS_BloginfoArgsSniff extends WordPress_RequiredArgsSniff
    • class WordPress_ControlArgsSniff extends WordPress_AbstractArgsRestrictionsSnifff
      • class WordPress_Sniffs_WP_DateArgsSniff extends WordPress_ControlArgsSniff

The array for WordPress_RestrictedArgsSnif would be

'get_bloginfo' => array(
	2 => array(
		'home' => array(
			'alt'     => 'home_url()',
		),
		'siteurl' => array(
			'alt'     => 'home_url()',
			'version' => '2.2'
		),
	),
),

The array for WordPress_RequiredArgsSniff would be

'get_bloginfo' => array(
	2 => array(
		'display' => true,
	),
),

The array for WordPress_ControlArgsSniff would be

'apply_filters' => array(
	1 => 'widget_title',
	2 => true,
	3 => true,
	4 => true,
),

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants