[wp-hackers] current_user_can() and roles ?
Dion Hulse (dd32)
wordpress at dd32.id.au
Wed Jan 6 21:46:29 UTC 2010
Theres 2 approaches that can be taken here.
The caps like that could become meta_caps, Ie. you called
current_user_can('switch_themes', 'widgets'); which could be different
from current_user_can('switch_themes', 'themes');
But that requires Core changes.
The better option is to have all these functionalities on their own
capability. For example, I think the Core upgrade is using the Plugin
upgrade cap. They should be on different capabilities in my opinion.
Might be worth a trac ticket to add extra caps for all these, so that the
functionality can be disabled/controlled properly on a per-admin-feature
On Thu, 07 Jan 2010 08:42:18 +1100, Moya, Eddie <emoya at tribune.com> wrote:
> Since there is a conversation going on about roles and capabilities, I
> like to pose another question. What options do we have for granulizing
> the capabilities?
> For example, I needed to create a new role that would be able to edit
> widgets, but not themes. Both use the capability "switch themes". Its
> possible to change the admin menu item capabilities through the global
> and $submenu arrays. However, this doesn't change the capabilities on the
> pages themselves, which leaves significant security holes.
> Due to time constraints on the project, the solution ended up being that
> begrudgingly edited the files themselves to change those hardcoded
> Is there any clean solution to this? The only partial comes where there
> get variables (such as 'import') we can retrieve to distinguish a page,
> a part of a page, from another, at which point we can trigger a check
> against our custom capability. Is there any real solution to this, or
> are we
> stuck editing the otherwise hardcoded caps?
> On 1/6/10 3:23 PM, "Dion Hulse (dd32)" <wordpress at dd32.id.au> wrote:
>> Also, Please do not use the level_* capabilities.
>> They're been deprecated since 2.0 and really need to go away (3.0
>> intrduces a warning that they're deprecated too).
>> Rely on the string caps instead, for example, 'manage_options' is a
>> good choice most of the time, only admins have that, and that suits 90%
>> On Thu, 07 Jan 2010 07:14:27 +1100, Stephen Rider
>> <wp-hackers at striderweb.com> wrote:
>>> On Jan 6, 2010, at 1:33 PM, Frank Bueltge wrote:
>>>> The admin give other users a rolle, not rights and in my plugin it os:
>>>> the admin select the role and i will check only for this. Maybe i must
>>>> add a new capabilitie to the role, the select the admin. And then i
>>>> can check for the new object. A also then it is possiblt to add this
>>>> object to a new role "superman".
>>> Generally I have found that an existing capability is "close enough" to
>>> the ability I want to add. If your plugin is doing something truly
>>> unique, though, you may think about actually adding a new capability.
>>> If you do that, don't forget to assign that Capability to one or more
>>> Roles so somebody can actually do the thing! ;-)
>>> (I'm actually going to have to do this soon with a plugin that I don't
>>> even want *admins* to have direct access to. I believe I'm going to
>>> up creating a new capability and new "super admin" role....)
>>> wp-hackers mailing list
>>> wp-hackers at lists.automattic.com
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
Dion Hulse / dd32
e: contact at dd32.id.au
msn: msn at d32.id.au
More information about the wp-hackers