Admin access to all the pages?

[cassel]

This seems like a pretty basic situation, but it has me stumped. I am logged in as and admin, and i can see all the pages that are accessible only to Free Registered members. That is perfect for adding content in that section. Now, i have some pages that are expected to be protected using Custom Capabilities so i had them set for Level 1 AND set the Custom Capability to "basic" (which will be the "category" for all the content in that custom package). However, despite being an admin, i cannot access that page, which i need to do to use the Visual Editor of Headway theme.

Is there anything i forgot to do to access it? I thought as an admin, i would be able to access anything at anytime.

[Cristián Lávaque]

That is correct, restrictions don't apply to the admin account.

Are you positive you were trying to access them from your admin account?

Could you please give more details of the problem?

[cassel]

I am logged in as Cassel (which is administrator, as i checked it).
I tried to access the page for unit 4 which has level 1 and "basic" restriction.
I was automatically redirected to the "oops" page, prompting me to register.
If i remove the "basic" custom capabilities, i CAN access the page.

Is there something i should do with the "Basic" custom capability in order to overide the restriction and view it as an admin? I didn't do anything except put it under the restriction level. I have not yet configure the paypal button and such. Not sure what else i can say to describe the situation.

[Cristián Lávaque]

OK, I've emailed Jason in case this is a bug. Let's wait for his input.

[Cristián Lávaque]

I can confirm I just reproduced this. The problem is with the custom capability, not the level. If the admin account doesn't have the ccap required by the page, then you are denied access. Jason may see this soon. In the meantime, add the custom capability to your profile and that fixes it.

[cassel]

Silly question but how do i add this ccap to my profile?

[cassel]

Nevermind, i found it. And it works that way too.
Thanks.

[Cristián Lávaque]

Cool.

[Jason Caldwell]

I can confirm I just reproduced this. The problem is with the custom capability, not the level. If the admin account doesn't have the ccap required by the page, then you are denied access. Jason may see this soon. In the meantime, add the custom capability to your profile and that fixes it.

Thanks guys. I'm investigating now.

[Cristián Lávaque]

Thanks!

[Jason Caldwell]

Investigation completed.
I was able to reproduce the issue described here.
This is the intended behavior.

In WordPress, there are two kinds of "Administrators".

1. On a standard WordPress installation,
there are "Administrator" Roles.

2. On a Multisite installation of WordPress, there are
"Administrator" Roles, and "Super Administrators" too.

On a standard WordPress installation, even "Administrator" Roles must satisfy any internal Capability ( and/or Custom Capability ) requirements. Administrators are not exempt from this, because there could potentially be more than one Administrator for a single standard installation of WordPress. Therefore, WordPress/s2Member disallowing access to an area of the site that requires a specific Capability, is correct, even for Administrators. If you require a certain Capability to access an area of your site, you need to make sure that your own Administrator account also has this Capability. This can be accomplished by editing your Profile in the Dashboard. s2Member provides a box to enter Custom Capabilities. There are also several Role/Capability editing plugins available, which allow further customization.

On a Multisite installation, "Super Administrators" have *all* Capabilities. In other words, nothing is ever off limits to a "Super Administrator". Unfortunately, a standard installation of WordPress does not have this feature yet. However, a standard installation of WordPress does assume that any Administrator with the permission to "delete_users", is a Super Administrator ( of sorts ). So the question is, should s2Member allow access to *anything*, if it's a standard installation Administrator that can "delete_users"? I'm leaning in that direction, but I'd like some feedback on this please.

[cassel]

Since i am only a single admin on a single site, i would lean the same way. If not, it might be an idea to specify that fact in the instructions so admins are not surprised by this, thinking it is a bug or something they did.

[Cristián Lávaque]

Rather than delete users, it makes more sense to base the decision off the capability to edit users. After all, if I can edit users including myself, I can give my profile the needed capabilities, and may as well just have them by default.

[Jason Caldwell]

I agree with you Cristián.
The ability to "edit_users" seems more logical to me too, although by default, WordPress does not allow direct editing of Capabilities, only of Roles.

This built-in Conditional would probably be good to use for this,
http://codex.wordpress.org/Function_Ref ... uper_admin
as it would help to future-proof the design.

But, upon inspecting the source code for this function, I find this:

Code: Select all

/**
 * Determine if user is a site admin.
 *
 * @since 3.0.0
 *
 * @param int $user_id (Optional) The ID of a user. Defaults to the current user.
 * @return bool True if the user is a site admin.
 */
function is_super_admin( $user_id = false ) {
    if ( $user_id )
        $user = new WP_User( $user_id );
    else
        $user = wp_get_current_user();

    if ( empty( $user->id ) )
        return false;

    if ( is_multisite() ) {
        $super_admins = get_super_admins();
        if ( is_array( $super_admins ) && in_array( $user->user_login, $super_admins ) )
            return true;
    } else {
        if ( $user->has_cap('delete_users') )
            return true;
    }

    return false;
} 

[Cristián Lávaque]

I see what you mean. What do you suggest then?

And were you thinking about using is_super_admin() in s2Member's code instead of is_admin? Maybe a new s2_admin()?

[Jason Caldwell]

We could modify s2Member's routine for Custom Capabilities on a standard installation of WordPress, so that Super Admins ( well, sort of ), on a standard WordPress installation are automatically excluded. I'm considering this.

However, since the WordPress core runs much deeper than just s2Member's protection routines, that type of change would actually be in conflict with the way other core functionality ( i.e. has_cap, current_user_can, user_can ) deals with permissions at a fundamental level.

I'm not sure if we should change this behavior at all. I think what needs to change, is the way WordPress itself tests for Capabilities. Ideally, a standard WordPress installation would employ the concept of Super Administrators too, making it possible to exclude Super Administrators from all Capability tests, even on a standard installation. But this is something the framework should do, not s2Member.

* I do realize though, we can't change the WordPress framework to meet our specific needs, so I'll continue to think about this and see if we can come up with an alternative. Either that, or perhaps we should start a TRAC ticket at WordPress.org to address this concern.