User capabilities should be used not roles nor deprecated capabilities #1364

grappler · 2018-05-31T16:34:41Z

This comes from WPTT/WPThemeReview#36 This was initially worked on for the theme review ruleset but we realised it would be better for WPCS.

I kept the first commit to give props where props are due.

WordPress/Tests/WP/UseCapabilitiesNotRolesUnitTest.inc

jrfnl

Looks good!

I've left a number of remarks inline. Most are just minor things, however there are two more pertinent issues which I'd like to ask you to consider:

As per the inline comments, the warning when the capability is a variable.
As this is now being pulled to WPCS, we need to consider plugins which add their own capabilities.
What about adding a public property to allow plugins to pass the capabilities they define to the sniff ? (default value would be an empty array).

jrfnl · 2018-06-03T02:59:33Z

WordPress/Sniffs/WP/UseCapabilitiesNotRolesSniff.php

+/**
+ * User capabilities should be used not roles.
+ *
+ * @link    https://make.wordpress.org/themes/handbook/review/required/#options-and-settings


This link tag can be removed as the sniff is now pulled to WPCS instead of TRTCS, so is no longer theme specific.

jrfnl · 2018-06-03T03:00:03Z

WordPress/Sniffs/WP/UseCapabilitiesNotRolesSniff.php

+	protected $group_name = 'caps_not_roles';
+
+	/**
+	 * List of functions that accept roles and capabilities as an agrument.


agrument => argument

jrfnl · 2018-06-03T03:01:34Z

WordPress/Sniffs/WP/UseCapabilitiesNotRolesSniff.php

+	 * List of functions that accept roles and capabilities as an agrument.
+	 *
+	 * The number represents the position in the function call
+	 * passed variables, here the capability is to be listed.


The number represents the position in the function call passed variables, here the capability is to be listed.

☝️ This sentence seems a bit wonky.

Did you mean: The number represents the parameter position in the function call, where the capability is supposed to be listed. ?

jrfnl · 2018-06-03T03:13:44Z

WordPress/Sniffs/WP/UseCapabilitiesNotRolesSniff.php

+	 *
+	 * @var array Function name with parameter position.
+	 */
+	protected $target_functions = array(


Even though it's disabled for new installs, there is also the add_links_page() function.

jrfnl · 2018-06-03T03:21:58Z

WordPress/Sniffs/WP/UseCapabilitiesNotRolesSniff.php

+
+		if ( isset( $this->core_roles[ $matched_parameter ] ) ) {
+			$this->phpcsFile->addError(
+				'Capabilities should be used instead of roles. Found "%s" in function "%s"',


I'd either add parentheses to the function name, as in Found "%s" in call to function "%s()" or would just leave the function name part away Found "%s". The line number and the parameter content should be clear enough.

jrfnl · 2018-06-03T03:28:24Z

WordPress/Sniffs/WP/UseCapabilitiesNotRolesSniff.php

+		'edit_posts'                  => true,
+		'delete_posts'                => true,
+		'read'                        => true,
+		'level_10'                    => true,


If I remember correctly, the use of "level_xx" capabilities was deprecated ages ago. Should these be put in a separate list and warned against when found ?

I have moved them to a separate list but I feel that the deprecation notice should be in a separate sniff.

I kept them in this sniff as they are still valid regardless if they are deprecated.

jrfnl · 2018-06-03T03:42:04Z

WordPress/Sniffs/WP/UseCapabilitiesNotRolesSniff.php

+			);
+		} else {
+			$this->phpcsFile->addWarning(
+				'"%s" is an unknown role or capability. Check the "%s()" function call to ensure it is a capability and not a role.',


Be aware that this will give a lot of false positives/unnecessary warnings as the $capability a plugin needs is often defined in a class property/(class) constant and passed to the function that way.

As I can imagine that this check is useful for the Theme Review Team, maybe have it disabled by default with the ability to enable it via a custom property ?

class My_Plugin { const CAPABILITY = 'manage_options'; public function do_something() { if ( current_user_can( self::CAPABILITY ) ) {} } }

jrfnl · 2018-06-03T03:45:35Z

WordPress/Tests/WP/UseCapabilitiesNotRolesUnitTest.inc

+  'parent_slug' ,
+  'page_title' ,
+  'menu_title' ,
+  $varible , // Warning.


$varible => $variable

jrfnl · 2018-06-03T03:49:43Z

WordPress/Sniffs/WP/UseCapabilitiesNotRolesSniff.php

+			return;
+		}
+
+		$matched_parameter = $this->strip_quotes( $parameters[ $position ]['raw'] );


This will only work when the $capability is passed as a single text string.

Note: If the warning is to be removed/disabled by default (see my other remark), this should be fine to leave as is.

The warning is now disabled by default.

jrfnl · 2018-06-03T03:51:02Z

WordPress/Sniffs/WP/UseCapabilitiesNotRolesSniff.php

+	 * The number represents the position in the function call
+	 * passed variables, here the capability is to be listed.
+	 * The list is sorted alphabetically.
+	 *


Maybe mention that these functions are defined in wp-admin/includes/plugin.php to make life easier for updating the list at a later point time.

jrfnl · 2018-06-03T04:01:31Z

Oh and another thing: the sniff should probably be added to a ruleset ;-) I'd suggest adding it to the Extra ruleset initially.

jrfnl

Hi @grappler, thanks for making those changes!

Based on the changed code, I think the code can be simplified and made slightly faster.
I'm also missing an error/warning for usage of the deprecated levels.

What about changing the logic to (note: pseudo-code/untested);

....
$matched_param = ...;
if ( isset( $this->core_capabilities[ $matched_parameter ] ) ) {
	return;
}

$this->customCapabilities = $this->merge_custom_array( $this->customCapabilities, array(), false );
if ( ! empty( $this->customCapabilities ) && in_array( $matched_parameter, $this->customCapabilities, true ) ) {
	return;
}

if ( isset( $this->core_roles[ $matched_parameter ] ) ) {
	$this->phpcsFile->addError(...);
	return;
}

if ( isset( $this->deprecated_capabilities[ $matched_parameter ] ) ) {
	$this->phpcsFile->addError('The "%s" capatibility has been deprecated since WP 3.0. Found: %s', ...);
	return;
}

if ( false === $this->checkOnlyKnownCaps ) ) {
	$this->phpcsFile->addWarning(...);
	return;
}

Notes:

The get_all_capabilities() method currently does not allow for changing the property inline which prevents this feature from being unit tested.
The proposed logic above would allow you to cut the get_all_capabilities() method out completely and to unit test the use of the $customCapabilities property.
As a side-effect, this will also get rid of the PHP 5.3 error about the use of array dereferencing not being available (yet) and will allow the build to pass.

Other than that:

My previous remark about the line nr for the error message still stands - I'm open to dropping it, but would like to see an argument not to make the change.

jrfnl · 2018-06-03T15:03:28Z

WordPress/Sniffs/WP/UseCapabilitiesNotRolesSniff.php

+	 *
+	 * @var boolean
+	 */
+	public $checkOnlyKnownCaps = true;


Please use $snake_case property names here and below.

FYI: the WPCS native CS check does not check for this as often upstream properties are used/overruled, but (new) WPCS native properties should be snake_case.

jrfnl · 2018-06-03T15:26:09Z

WordPress/Tests/WP/UseCapabilitiesNotRolesUnitTest.inc

+add_users_page( 'page_title', 'menu_title', 'administrator', 'menu_slug', 'function' );  // Error.
+add_management_page( 'page_title', 'menu_title', 'editor', 'menu_slug', 'function' );  // Error.
+add_options_page( 'page_title', 'menu_title', 'contributor', 'menu_slug', 'function' );  // Error.
+// @codingStandardsChangeSetting WordPress.WP.UseCapabilitiesNotRoles checkOnlyKnownCaps false


Please add a blank line above this to make it easier to see that a property is being changed and something else is now being tested.

Also: please reset the property at the end of the block of tests so additional unit tests which may be added later can expect the default properties to be in effect.

grappler

As I was replying to your comments I realised it was not working how it should be and ended up working on it before I could reply.

grappler · 2018-06-03T13:58:24Z

WordPress/Sniffs/WP/UseCapabilitiesNotRolesSniff.php

+			return;
+		}
+
+		$matched_parameter = $this->strip_quotes( $parameters[ $position ]['raw'] );


The warning is now disabled by default.

grappler · 2018-06-03T14:00:47Z

WordPress/Sniffs/WP/UseCapabilitiesNotRolesSniff.php

+		'edit_posts'                  => true,
+		'delete_posts'                => true,
+		'read'                        => true,
+		'level_10'                    => true,


I have moved them to a separate list but I feel that the deprecation notice should be in a separate sniff.

I kept them in this sniff as they are still valid regardless if they are deprecated.

grappler · 2018-06-03T20:08:30Z

WordPress/Sniffs/WP/UseCapabilitiesNotRolesSniff.php

+		if ( isset( $this->core_roles[ $matched_parameter ] ) ) {
+			$this->phpcsFile->addError(
+				'Capabilities should be used instead of roles. Found "%s" in function "%s"',
+				$stackPtr,


I thought the notice was being shown in the correct line as I had a similar example in the unit test. As I was double checking to reply here I realised it was not the case. It has been fixed now.

jrfnl · 2018-06-03T21:05:13Z

@grappler Hmm.. weird, I can't seem to respond to "outdated" comments anymore... GH playing up.

I have moved them to a separate list but I feel that the deprecation notice should be in a separate sniff.

Could you explain why you think this should be a separate sniff ?

I kept them in this sniff as they are still valid regardless if they are deprecated.

If there is not going to be a warning for the deprecated levels, than having the separate list & doing the array_merge() is just overhead.

I thought the notice was being shown in the correct line as I had a similar example in the unit test. As I was double checking to reply here I realised it was not the case. It has been fixed now.

I understand why you added the extra logic to determine the line as the start may be on the previous line, however, in that case, why not just use $parameter['end'] ?

If you do think the extra logic has value, it will need to be changed to take comments and annotations into account, i.e. use Tokens::$emptyTokens not T_WHITESPACE.

Other than that, my previous remark about the get_all_capabilities() method preventing unit tests with the $custom_capabilities from working still stands, just as the fact that that functionality does need unit tests.

And the PHP 5.3 issue also still needs attention.

grappler · 2018-06-04T18:25:40Z

Could you explain why you think this should be a separate sniff ?

Sure, I feel that UseCapabilitiesNotRoles if different from deprecated roles. It would fit better into deprecated parameter values. Something that I have started working on last year and should finish and make a PR. The sniff should should do one task not two. By making two sniffs it would make it easier to disable one or the other. (I know you could disable it via the error code too.)

There is an core issue where user levels are still needed. https://core.trac.wordpress.org/ticket/16841 WordPress core still uses them so the deprecated notice would need to be disabled.

why not just use $parameter['end'] ?

Because it would fail on the following code 🤷‍♂️

    add_menu_page(
        __( 'Custom Menu Title', 'textdomain' )
        ,'custom menu'
        ,'manage_options'
        ,'myplugin/myplugin-admin.php'
        ,''
        ,plugins_url( 'myplugin/images/icon.png' )
        ,6
    );

I have removed the get_all_capabilities() method and added a unit test for the custom_capabilities but I could not get it to unset.

jrfnl

The sniff should should do one task not two.

I don't actually agree with you on that. That's what error codes are for. One focus area: yes, one task: no.
Prior art already in this repo, as well as upstream, demonstrates this quite easily: take for instance the WP.I18n sniff.

In both cases - using roles or levels -, people are using the WP capabilities incorrectly, so you are effectively checking the same thing in both cases.

Sure, I feel that UseCapabilitiesNotRoles if different from deprecated roles.

IMHO that is more a case of the sniff needing a better name than a reason for not including the check.

WordPress core still uses them so the deprecated notice would need to be disabled.

As it would be in the Extra ruleset, that's not an issue. All the same, as Core deprecated them in 2.0 AFAIK, I would think it might be time that they ought to be removed from core too, but that's a discussion for another time & place.

Anyway, especially as you've pulled the other sniff in which the deprecated check would be contained (presuming it is), this is not a merge-blocker for me.

Because it would fail on the following code

👍 , though there is no unit test to show this. Could you reformat one of the existing test lines to add a safeguard for this ?

I have removed the get_all_capabilities() method and added a unit test for the custom_capabilities but I could not get it to unset.

You can unset it by passing false. The handling of this is build into the merge_custom_array() method.
// @codingStandardsChangeSetting WordPress.WP.UseCapabilitiesNotRoles custom_capabilities false

jrfnl · 2018-06-04T20:53:33Z

WordPress/Sniffs/WP/UseCapabilitiesNotRolesSniff.php

+	 *
+	 * @since 1.0.0
+	 *
+	 * @var string


Property type should be array with a default of array() as plugins can add more than one capability.

This is not an issue for the unit tests as the merge_custom_array() method already has a tolerance build in for incorrectly passed array properties, i.e. when they are passed as a comma-delimited string.

jrfnl · 2018-06-04T20:55:10Z

WordPress/Sniffs/WP/UseCapabilitiesNotRolesSniff.php

+	 *
+	 * @var array All deprecated capabilities in core.
+	 */
+	protected $deprecated_capabilities = array(


If the deprecated check is not going to be included, there is no reason for this to be a separate array.

jrfnl · 2018-06-04T20:56:15Z

WordPress/Sniffs/WP/UseCapabilitiesNotRolesSniff.php

+		$next_not_whitespace = $this->phpcsFile->findNext(
+			Tokens::$emptyTokens,
+			$parameters[ $position ]['start'],
+			$parameters[ $position ]['end']+1,


+ needs whitespace on both sides.

jrfnl · 2018-06-04T21:03:09Z

WordPress/Tests/WP/UseCapabilitiesNotRolesUnitTest.inc

+
+// @codingStandardsChangeSetting WordPress.WP.UseCapabilitiesNotRoles custom_capabilities custom_cap
+if ( author_can( $post, 'custom_cap' ) ) { } // OK.
+if ( author_can( $post, 'read' ) ) { } // OK.


Maybe also add:

// @codingStandardsChangeSetting WordPress.WP.UseCapabilitiesNotRoles check_only_known_caps false if ( author_can( $post, 'unknown_custom_cap' ) ) { } // Warning. // @codingStandardsChangeSetting WordPress.WP.UseCapabilitiesNotRoles check_only_known_caps true

... to test that the warning is still thrown correctly even when custom capabilities have been registered.

A unit test with several custom caps would also not be a bad thing. Doesn't have to be a separate test, you could just change the settings line here (use a comma-delimited list without spaces) and test both custom caps.

grappler · 2018-06-05T10:55:47Z

OK, I will rename the sniff to WordPress.WP.Capabilities and add a deprecated notice.

With two of my Unit Test additions $matched_parameter as 'super_admin' // Error. and 'super_admin' /* Error */. I see two ways of getting around this. One to use regex somehow or the other to strip PHP comments out of the strings. What do you think?

jrfnl · 2018-06-05T11:12:01Z

With two of my Unit Test additions $matched_parameter as 'super_admin' // Error. and 'super_admin' /* Error */. I see two ways of getting around this. One to use regex somehow or the other to strip PHP comments out of the strings. What do you think?

That's why walking the parameter tokens instead of using raw to test for a match is generally the way to go.
If you do a for loop from start to end and disregard any empty tokens, concatenate all text string tokens and have a toggle for "unexpected tokens" (variables, constants), both this as well as silly things like: 'super' . '_admin' can be detected reliably.

grappler · 2018-06-05T18:34:42Z

That's why walking the parameter tokens instead of using raw to test for a match is generally the way to go.

It ended up being such an easy fix 😄

I think I have fixed all of the comments.

jrfnl · 2018-06-10T02:32:50Z

I've added a commit to this PR to allow the builds to pass. This PR identified a fixer conflict which is why the build was failing. The fixer conflict involved two upstream sniffs.

I've opened PR squizlabs/PHP_CodeSniffer#2056 to fix the fixer conflict.

For now, the unit test case file from this PR will be ignored for the fixer conflict check. Once the upstream PR has been merged, my commit should be reverted.

jrfnl

Hi @grappler,

Just reviewed again. The token walking is still not stable, see my remark inline and my earlier remark:

If you do a for loop from start to end and disregard any empty tokens, concatenate all text string tokens and have a toggle for "unexpected tokens" (variables, constants), both this as well as silly things like: 'super' . '_admin' can be detected reliably.

Regarding the unit tests, I'm missing the following:

A test that nothing happens when the expected parameter is not set.
A test that no warning is being thrown for an unknown capability when $check_only_known_caps is true (default).
Testing that the $custom_capabilities property works as expected when $check_only_known_caps is true (default). I.e. the current tests are within the check_only_known_caps false block, so only the combination is tested.

Also the unit tests on line 45 and 54 are testing the same thing.

jrfnl · 2018-06-10T02:55:46Z

WordPress/Sniffs/WP/CapabilitiesSniff.php

+/**
+ * Check that capabilities are used correctly.
+ *
+ * User capabilities should be used not roles. Deprecated capabilities.


Deprecated capabilities... what about them ?

Did you mean to say: User capabilities should be used not roles nor deprecated capabilities. ?

jrfnl · 2018-06-10T03:02:57Z

WordPress/Sniffs/WP/CapabilitiesSniff.php

+			true
+		);
+
+		$matched_parameter = $this->strip_quotes( $this->tokens[ $next_not_empty ]['content'] );


Token walking means doing a for() loop between the param start and end. You are now just checking the first token and not even checking that this is a text string token....

This will break on all of the following examples (silly code, but you get my point):

if ( author_can( $post, editor() ) ) { } // Should not error for using role. if ( author_can( $post, 'super' . '_admin' ) ) { } // Should give error for using role. // @codingStandardsChangeSetting WordPress.WP.Capabilities check_only_known_caps false if ( author_can( $post, editor() ) ) { } // Should give warning about unknown capability, not error for using role. if ( author_can( $post, install_plugins() ) ) { } // Should give warning about unknown capability. if ( author_can( $post, 'install_' . 'plugins' ) ) { } // OK. if ( author_can( $post, 'install_plugins' . $something ) ) { } // Should give warning about unknown capability. if ( author_can( $post, 'install_plugins' . '_for_theme' ) ) { } // Should give warning about unknown capability. // @codingStandardsChangeSetting WordPress.WP.Capabilities check_only_known_caps true

Would it make sense to have this code as a utility function? I think there are other classes that would profit from it.

// More extensive check to prevent people circumventing the sniff. $text = ''; $found_variable_token = false; for ( $i = $parameters[1]['start']; $i <= $parameters[1]['end']; $i++ ) { if ( isset( Tokens::$stringTokens[ $this->tokens[ $i ]['code'] ] ) === false ) { if ( T_VARIABLE === $this->tokens[ $i ]['code'] ) { $found_variable_token = true; } return; } $text .= $this->strip_quotes( $this->tokens[ $i ]['content'] ); } return $text;

Copied the code from WPTT/WPThemeReview#26

I was thinking about that, but I don't think there has been much need for it before now in WPCS.

All the same, I'd be happy for this to become a utility function, however, the "is there a variable ?" check in this code snippet would probably be a different question whenever used. Also in the above sample, it is presumed only single/double quoted strings are used, not heredoc/nowdoc, so some changes would be needed and I'd guess that the utility should in that case just retrieve a string of all text string tokens found between $start and $end, not do the "is there are variable" check ?

P.S.: looking at the code now, I'm still going to make one more change to the WPTRT sniff this came from ;-)

OH, I forgot that the code was checking for two things. When I mentioned the idea I was thinking about returning a string of all of the text string tokens.

jrfnl · 2018-06-10T03:06:21Z

WordPress/Sniffs/WP/CapabilitiesSniff.php

+		}
+
+		if ( isset( $this->deprecated_capabilities[ $matched_parameter ] ) ) {
+			$this->phpcsFile->addError(


[No action needed, just noting this down for the future]

As the capability is only deprecated, should this be an error or a warning ?

Based on the logic used in other sniffs which check for deprecations, it should be an error as the version in which the capability was deprecated is more than three WP releases previous to the current release.

However, that would mean that a check should be done against the $minimum_supported_version of WP and that the deprecation version should be added to the $deprecated_capabilities array as the value for each item.

As all currently deprecated capabilities were deprecated in WP 3.0.0, I'm happy to leave this as is for now. As soon as other capabilities would become deprecated, this would need to be adjusted though.

@grappler I saw you went ahead and made this change already anyway 💕

Two minor remarks about that:

The use of the Sniff::minimum_supported_version property still needs to be annotated in the class docblock with a @uses tag.

As, at this moment, there are no capabilities which are deprecated in the last three versions, this needs a dedicated set of unit tests like so:

add_options_page( 'page_title', 'menu_title', 'level_10', 'menu_slug', 'function' ); // Error. // @codingStandardsChangeSetting WordPress.WP.Capabilities minimum_supported_version 3.5 add_options_page( 'page_title', 'menu_title', 'level_10', 'menu_slug', 'function' ); // Error. // @codingStandardsChangeSetting WordPress.WP.Capabilities minimum_supported_version 2.8 add_options_page( 'page_title', 'menu_title', 'level_10', 'menu_slug', 'function' ); // Warning. // @codingStandardsChangeSetting WordPress.WP.Capabilities minimum_supported_version 4.6

jrfnl · 2018-06-10T03:14:17Z

WordPress/Sniffs/WP/CapabilitiesSniff.php

+
+		if ( isset( $this->deprecated_capabilities[ $matched_parameter ] ) ) {
+			$this->phpcsFile->addError(
+				'The capatibility "%s" found in function call "%s()" has been deprecated since WordPress version 3.0.',


capatibility -> capability

jrfnl · 2018-06-10T03:14:40Z

WordPress/Sniffs/WP/CapabilitiesSniff.php

+			$this->phpcsFile->addError(
+				'The capatibility "%s" found in function call "%s()" has been deprecated since WordPress version 3.0.',
+				$next_not_empty,
+				'DeprecatedCapability',


Not a blocker, but the error code could just be Deprecated as Capability is already in the sniff name, so the full error code would be WordPress.WP.Capability.Deprecated.

jrfnl · 2018-06-10T03:18:10Z

WordPress/Sniffs/WP/CapabilitiesSniff.php

+			$this->phpcsFile->addWarning(
+				'"%s" is an unknown role or capability. Check the "%s()" function call to ensure it is a capability and not a role.',
+				$next_not_empty,
+				'UnknownCapabilityFound',


Not a blocker, but the error code could just be Unknown as Capability is already in the sniff name, so the full error code would be WordPress.WP.Capability.Unknown.

- PHPCS 3.x compat: Namespace all things - Move to WP folder as it is a WP specific sniff Rename: UseCapabilitiesNotRoles to Capabilities - Update list of target functions based on WP knowledge and list of capabilities based on WP core unit tests - Add an option to check only for know capabailites - Allow defining custom capabilites - Seperate deprecated capabilites and add depreacted caps error - Add notice to the line the parameter is defined

grappler · 2018-06-10T06:31:37Z

Thank you for the review.

A test that nothing happens when the expected parameter is not set. ✅
A test that no warning is being thrown for an unknown capability when $check_only_known_caps is true (default). ✅
Testing that the $custom_capabilities property works as expected when $check_only_known_caps is true (default). I.e. the current tests are within the check_only_known_caps false block, so only the combination is tested.
[I am not sure this is testable. There never will be an error as the custom capability is not a role nor an unknown cap.]
Also the unit tests on line 45 and 54 are testing the same thing.
[I wanted to make sure the error was the same after changing the setting.]

…m the fixer conflict check [IMPORTANT]: This commit should be reverted once the fixer conflict has been fixed upstream. The build was failing because this test file fails to fix during the fixer conflict check. This is caused by a conflict between the `Generic.WhiteSpace.DisallowSpaceIndent`, `Generic.Functions.FunctionCallArgument` and the `PEAR.Functions.FunctionCall` sniffs. As these are all upstream, a fix needs to be pulled there. For now, excluding the `WP.Capabilities` unit test file from the fixer conflict check will fix the build.

jrfnl · 2018-06-20T02:49:21Z

Further on #1364 (comment) :

I've added a commit to this PR to allow the builds to pass. This PR identified a fixer conflict which is why the build was failing. The fixer conflict involved two upstream sniffs.

I've opened PR squizlabs/PHP_CodeSniffer#2056 to fix the fixer conflict.

For now, the unit test case file from this PR will be ignored for the fixer conflict check. Once the upstream PR has been merged, my commit should be reverted.

The upstream PR has been merged, so my earlier commit to ignore this sniff for the fixer check can now be reverted.

jrfnl · 2018-07-06T21:25:40Z

@grappler Just checking in: will you have time over the next few days to update the PR so it's ready for a final review ?

jrfnl · 2018-09-23T16:42:57Z

@grappler Any chance that this PR will get some final love anytime soon ? Would be great to be able to add it to WPCS!

jrfnl · 2019-10-07T12:49:02Z

@grappler Just wondering if you'll have a chance to finish this off in the near future.

If you haven't got time or lost interest, please let us know and we'll see if we can find someone to take over.

Add initial checks for user capabilities

dff6f09

grappler mentioned this pull request May 31, 2018

[New Sniff] Check that capabilities are used not roles WPTT/WPThemeReview#27

Open

2 tasks

GaryJones reviewed May 31, 2018

View reviewed changes

WordPress/Tests/WP/UseCapabilitiesNotRolesUnitTest.inc Outdated Show resolved Hide resolved

JDGrimes approved these changes May 31, 2018

View reviewed changes

jrfnl mentioned this pull request Jun 1, 2018

Use capabilities not roles WPTT/WPThemeReview#36

Closed

jrfnl requested changes Jun 3, 2018

View reviewed changes

jrfnl added Component: Extra Type: Enhancement labels Jun 3, 2018

jrfnl requested changes Jun 3, 2018

View reviewed changes

grappler commented Jun 3, 2018

View reviewed changes

jrfnl requested changes Jun 4, 2018

View reviewed changes

jrfnl added the Status: Review ready label Jun 5, 2018

jrfnl requested changes Jun 10, 2018

View reviewed changes

grappler added 2 commits June 10, 2018 07:57

Add version check for deprectaed paramaters

89550d4

grappler force-pushed the feature/36-use-capabilities-not-roles branch from 6eeacd6 to 89550d4 Compare June 10, 2018 06:25

grappler changed the title ~~Use capabilities not roles~~ User capabilities should be used not roles nor deprecated capabilities Jun 10, 2018

grappler mentioned this pull request Jun 10, 2018

Add rule to prevent deregistering scripts. WPTT/WPThemeReview#26

Merged

jrfnl mentioned this pull request Jun 25, 2018

Release 1.0.0 #1388

Closed

10 tasks

jrfnl added Status: Awaiting feedback and removed Status: Review ready labels Apr 1, 2019

dingo-d mentioned this pull request Nov 25, 2022

Add sniff that will check that capabilities are used correctly. #2112

Merged

jrfnl closed this in #2112 Dec 2, 2022

jrfnl added this to the 3.0.0 milestone Dec 2, 2022

jrfnl removed the Status: Awaiting feedback label Jul 4, 2023

User capabilities should be used not roles nor deprecated capabilities #1364

User capabilities should be used not roles nor deprecated capabilities #1364

Conversation

grappler commented May 31, 2018

jrfnl left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jrfnl Jun 3, 2018 • edited Loading

Choose a reason for hiding this comment

jrfnl commented Jun 3, 2018

jrfnl left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

grappler left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jrfnl commented Jun 3, 2018

grappler commented Jun 4, 2018

jrfnl left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

grappler commented Jun 5, 2018

jrfnl commented Jun 5, 2018

grappler commented Jun 5, 2018

jrfnl commented Jun 10, 2018

jrfnl left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

grappler Jun 10, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

grappler Jun 10, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

grappler commented Jun 10, 2018 • edited Loading

jrfnl commented Jun 20, 2018

jrfnl commented Jul 6, 2018

jrfnl commented Sep 23, 2018

jrfnl commented Oct 7, 2019

jrfnl left a comment •

edited

Loading

jrfnl Jun 3, 2018 •

edited

Loading

jrfnl left a comment •

edited

Loading

grappler Jun 10, 2018 •

edited

Loading

grappler Jun 10, 2018 •

edited

Loading

grappler commented Jun 10, 2018 •

edited

Loading