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

Check for deprecated parameters #826

Merged
merged 1 commit into from
Jul 19, 2017

Conversation

grappler
Copy link
Member

Solves part of #576

I got the list of deprecated parameters by looking where _deprecated_argument() was being used.

This is the first of three sniffs. The other two that will follow are

  • WordPress.WP.DeprecatedParameterValues e.g. bloginfo( 'url' ); where the value url is deprecated
  • WordPress.WP.DeprecatedParameterArgValues e.g. For wp_dropdown_categories( $args ) $args['type'] cannot be links.

There will be an notice if the parameter value is not what is used by default. The default value is important as in some cases the deprecated parameter maybe in the middle. e.g. load_plugin_textdomain()

If a dynamic parameter is used then there will be still an error. The values for the deprecated functions are normally empty strings, bool or null. It is best to write them as is then using a function or variable.

I have again included a property to define the minimum supported WordPress version. Perhaps for future discussion: Would it make more sense to define the minimum supported WordPress version in the Sniff.php instead so it would only need to defined once instead for every deprecated sniff.

There maybe a better way to add the ordinal suffix. I have not added support for 11th, 12th or 13th as that many parameters would be an edge case.

@jrfnl
Copy link
Member

jrfnl commented Jan 28, 2017

Would it make more sense to define the minimum supported WordPress version in the Sniff.php instead so it would only need to defined once instead for every deprecated sniff.

That would make no difference as properties have to be defined per sniff and cannot be defined for all sniffs in a standard in one go via a ruleset. The only difference it would make is that that property would then be available to be set for all sniffs, while only a few use it, so I think it could lead to confusion.

IMHO it would be best to keep the property in the sniff class which actually uses it, but use the same name for the property everywhere. In the wiki page for properties (#614), these would then all be grouped together and intuitive to use.
We could also consider allowing that particular property to also be set from the command-line, similar to what was implemented for the I18n sniff and allow the command line value to be valid for all sniffs which use the property.

Copy link
Member

@jrfnl jrfnl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great addition! Looks useful.
Aside from the remarks below, please have a look at the code style issues causing the travis build to fail.

*/

/**
* Check for usage of deprecated parameters in WP functions and provide alternative based on the parameter passed.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

provide => suggest

*
* This sniff will throw an error when usage of deprecated parameters is
* detected if the parameter was deprecated before the minimum supported
* WP version; a warning otherwise.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This first line seems more like a "long description" for the sniff itself, so might be better placed in the class doc.
Possibly the second line too.

* By default, it is set to presume that a project will support the current
* WP version and up to three releases before.
* This variable allows changing the minimum supported WP version used by
* this sniff by setting a property in a custom phpcs.xml ruleset.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A ruleset does not need to be named phpcs.xml

*
* @since 0.11.0
*
* @var string WordPress versions.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

versions => version

'get_last_updated' => array(
1 => array(
'value' => '',
'version' => '0.0',
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

version 0.0 ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The parameter was already deprecated when it was merged into core. https://developer.wordpress.org/reference/functions/get_last_updated/

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In that case, I suggest setting it to the version nr in which it was merged into core or to MU as may be the case.
Goes for the other function(s) with version 0.0 as well.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Turns out xfn_check() was deprecated in version 2.5. The version in core was incorrect. https://core.trac.wordpress.org/ticket/39737

@@ -0,0 +1,53 @@
<?php

// all will give an ERROR.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comments should start with a capital.

public function process_parameters( $stackPtr, $group_name, $matched_content, $parameters ) {
foreach ( $this->target_functions[ $matched_content ] as $position => $paramerter_args ) {

if ( ! isset( $parameters[ $position ] ) ) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be an idea to add a $paramCount = count( $parameters ); before the loop and to add a if ( $position > $paramCount) { break; } above this line (or instead of this line) for efficiency.
After all, no need to continue looping through for parameters which aren't set anyway.

wp_new_user_notification( '', function_name() );


// all will give an WARNING.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dito

wp_title_rss( 'deprecated' );
unregister_setting( '', '', '', 'deprecated' );

// all will be OK.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dito

wp_title_rss( 'deprecated' );
unregister_setting( '', '', '', 'deprecated' );

// all will be OK.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe add some info on why these are ok ? Is it because they have the default value ? or because the params aren't deprecated ? or ... ?

@grappler grappler force-pushed the feature/576-deprecated-parameters branch 2 times, most recently from 0ca5c3b to 18cd5c3 Compare January 29, 2017 22:16
@grappler
Copy link
Member Author

Thank you @jrfnl for the review. The issues you mentioned should be fixed now.

$message .= ' Instead do not pass the parameter.';
}

if ( version_compare( $parameter_args['version'], $this->minimum_supported_version, '>=' ) ) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Depending on which PR gets merged first, this toggle can be replaced with the addMessage() helper function as introduced in PR #827

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI: the addMessage() utility function is now available as part of develop.

@grappler grappler force-pushed the feature/576-deprecated-parameters branch from 18cd5c3 to d602d0a Compare January 30, 2017 07:25
@jrfnl
Copy link
Member

jrfnl commented Jan 30, 2017

@grappler I'll try and have another look later this week. Quick question in the mean time: to which ruleset will this sniff be added ? And shouldn't that change be included with this PR ?

@grappler
Copy link
Member Author

We added the other deprecated sniffs just to Extra. I can add that to the PR.

@jrfnl
Copy link
Member

jrfnl commented Jan 30, 2017

I wouldn't be adverse to both this sniff as well as the one for WP.DeprecatedFunctions being added to Core as - obviously - core shouldn't be using methods and parameters which it has deprecated, but others might have a different opinion.

@grappler grappler force-pushed the feature/576-deprecated-parameters branch from d602d0a to 394b4b5 Compare February 1, 2017 15:17
@grappler
Copy link
Member Author

grappler commented Feb 1, 2017

I have used the new addMessage() utility function. I have added the sniff to the extra ruleset. Will do a separate PR to add it to the core ruleset. Started a discussion in #576

@grappler
Copy link
Member Author

grappler commented Feb 9, 2017

Does anyone else have any thoughts on this PR? Don't worry it is not as big as my last one.

Copy link
Contributor

@JDGrimes JDGrimes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 Looks great, just a couple small tweaks I'd suggest.

continue;
}

$is_dynamic_parameter = $this->phpcsFile->findNext( array( T_CONSTANT_ENCAPSED_STRING, T_ARRAY, T_FALSE, T_TRUE, T_NULL, T_LNUMBER, T_WHITESPACE ), $parameters[ $position ]['start'], ( $parameters[ $position ]['end'] + 1 ), true, null, true );
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This function call could really benefit from being multi-lined.


if ( $is_dynamic_parameter ) {
$this->phpcsFile->addWarning(
'The dynamic parameter [%s] at possition #%s of %s() could possible by deprecated.',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/possible by/possibly be/

Copy link
Member

@GaryJones GaryJones left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another couple of typos, but looks good otherwise.


if ( $is_dynamic_parameter ) {
$this->phpcsFile->addWarning(
'The dynamic parameter [%s] at possition #%s of %s() could possibly be deprecated.',
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo: position

continue;
}

$message = 'The parameter [%s] at possition #%s of %s() has been deprecated since WordPress version %s.';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo: position

@grappler grappler force-pushed the feature/576-deprecated-parameters branch 2 times, most recently from 70bd3a0 to 18dd89a Compare February 10, 2017 19:25
@JDGrimes
Copy link
Contributor

@jrfnl @GaryJones It looks like @grappler has fixed all of the issues you pointed out, would you like to take one more look and approve before merging?

@jrfnl
Copy link
Member

jrfnl commented Feb 26, 2017

@JDGrimes Yup, this one is high on my priority list, will get to it soon.

*
* @since 0.11.0
*
* @var array Multi-dimentional array with parameter details.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo here.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

* }
* }
*/
protected $target_functions = array(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we get these in alphabetical order of function name? Makes it easier to check in the future.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They are currently sorted in order of version deprecated. @jrfnl @JDGrimes What do you think?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm... I generally prefer things in alphabetical order. Like @GaryJones says it makes it easier to check if a function is already there (though of course you could also search). Having them in the order deprecated is a nice feature, but does it actually provide benefit for users/developers? Only things I can think of, is that as we add new functions to the sniff over time, we'll always be adding them at the end (which isn't necessarily any better/easier than adding them in alphabetical order, I guess). But I guess it does make it easier for somebody who is using the sniff to see which functions are going to be flagged based on what WordPress version they support. I can see the potential benefit of that, so I'm fine leaving the list like it is. But I don't have a strong opinion either way.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fine with the current order then (I hadn't spotted it was in WP version order), but at least add a comment before the array saying what the order is to clarify for future readers and contributors.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense, I have done that.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just adding my two pennies to this discussion:

In most cases, either alphabetical order or version order would be fine. In this particular case, I think alphabetical order has a clear advantage.

Consider the following example: function something has four parameters, parameter 2 gets deprecated in WP 4.0, parameter 4 in WP 4.8. As the function already has a previously deprecated parameter, it is located under the WP 4.0 section, but someone adding deprecations for WP 4.8 might easily miss that if they are adding the newly deprecated parameters. In that case, the latter function array will overrule the earlier and the WP 4.0 deprecation of parameter 2 will never be reported anymore.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think all things considered, we should probably just have this list be in alphabetical order. I don't really see a compelling case for putting it in order of version number, so for simplicity and consistency alphabetical order seems best.

@grappler grappler force-pushed the feature/576-deprecated-parameters branch 2 times, most recently from 1878050 to 002e7b4 Compare February 27, 2017 05:41
@grappler
Copy link
Member Author

Thank you @jrfnl for your review. I have updated most of the items. Once we have clarified the last few items and the new changes look good I will make another commit.

* 'version' => (int) The WordPress version when deprecated.
* )
* )
* );
*
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PHPCS throws a notice for a superfluous empty comment line at the end here.

@grappler
Copy link
Member Author

@jrfnl I have made a few more changes and add some replies to your comments.

Copy link
Member

@jrfnl jrfnl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm ok with merging it as it is now.

The whole "token walking" vs checking of the raw parameter value issue can be addressed if/when bugs reports about this come in.

@JDGrimes @GaryJones As the PR has changed quite a lot, do you still want to have another look or can this be merged ?

* Minimum WordPress version.
*
* This variable allows changing the minimum supported WP version used by
* this sniff by setting a property in a custom ruleset xml file.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

xml => XML

'version' => '2.7.0',
),
),
'get_delete_post_link' => array(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this list is meant to be in alphabetical order, then get_delete_post_link should come after get_category_parents.

'version' => '2.5.0',
),
),
'update_user_status' => array(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The order of these three update_* keys is not alphabetical.

@GaryJones
Copy link
Member

3 minor fixes if possible, but otherwise good to go.

@grappler grappler force-pushed the feature/576-deprecated-parameters branch from 4e230af to 2d1226c Compare July 18, 2017 07:41
@grappler
Copy link
Member Author

Thanks for spotting those. I have updated the PR.

'wp_get_http_headers' => array(
2 => array(
'value' => false,
'version' => '2.7',
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this value require being exactly 2.7 (as opposed to 2.7.0)? If so, maybe worth adding a comment so it's not accidentally "fixed" in the future?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not that I think so, it should be 2.7.0

*
* @var string WordPress version.
*/
public $minimum_supported_version = 4.5;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Each new WP release will require that this is updated, if the "last four major versions" gap is to be maintained.

Do we have other code that is based on a value of "$release - X"?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, all of the deprecated Sniffs work with the calculation.

Copy link
Member

@GaryJones GaryJones Jul 18, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if there's value in having a centralised $current_version, and then having the properties for the relevant Sniffs be calculated from there (not needed for this PR - just thinking aloud).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a centralised $current_version would a good idea.

@@ -0,0 +1,64 @@
<?php

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are these groups in order of release? i.e. functions with deprecated params in 4.9 can be added to the end of the relevant groups? If so, maybe add a comment here to remind future contributors.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes the idea would be for future functions to be added at the end.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, so just a commented needed here then please.

(I was tempted to suggest putting these functions in alphabetical order, but then remembered seeing discussion about the better order - a comment would help tell others what the logic is.)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have ordered the functions in the test in alphabetical order.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have ordered the functions in the test in alphabetical order.

That wasn't my intent here - future functions, unless they start with z, will not be at the end. The grouped nature means that new functions added in the first group will naturally means all of the error line numbers below need to be updated anyway though.

break;
}

// The list will need to updated if the default value is not supported.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comment should be moved down, right about the switch statement. It is confusing where it is.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@grappler Didn't you remove this condition earlier based on a previous comment I made ? It's superfluous. (And removing it would sort the comment out as well ;-) )

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I removed it. It slipped in again. Sorry.

@grappler grappler force-pushed the feature/576-deprecated-parameters branch 3 times, most recently from 27df536 to 32a17ac Compare July 19, 2017 22:22
@jrfnl
Copy link
Member

jrfnl commented Jul 19, 2017

@JDGrimes I think all concerns have been addressed. Would like to take another look or can I dismiss your earlier review ?

continue;
}

$message = 'The parameter "s%" at position #%s of %s() has been deprecated since WordPress version %s.';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s% should be %s

@grappler grappler force-pushed the feature/576-deprecated-parameters branch from 32a17ac to 532839e Compare July 19, 2017 22:54
@jrfnl jrfnl merged commit 8eddc26 into WordPress:develop Jul 19, 2017
@jrfnl
Copy link
Member

jrfnl commented Jul 19, 2017

🎉 🍾 🌮

@grappler grappler deleted the feature/576-deprecated-parameters branch July 20, 2017 06:40
@GaryJones
Copy link
Member

Well done and thank you @grappler :-)

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

Successfully merging this pull request may close these issues.

4 participants