Keep this example in mind, when you write capability checks or add custom capabilities to a system. They have differently named roles with equally "high" capabilities, but for completely different parts. Most developers will not have access to billing details and neither will the accountant have access to deployment settings or security credentials. Think about the accountant whose email address you enter in some SaaS backend to receive the invoice. Note: Do not think about roles in a hierarchical manner. Yes, you can use a role name as well, which will work in WordPress, but it's a concept that will bring along a hard to track down bug when a role name changes. That's easier to maintain, in case a role name changes. Just look at what the most restrictive access is and search for a matching capability. You can find a list of built in roles and capabilities here. Capabilities: As role names can change and as roles are just groups of capabilities, it's best to check against a capability, not a role name.
#WORDPRESS USER ROLES PASSWORD#
Custom login, logout, register, password reset logic might breaks this.
Keep in mind that should only work with defaults (see comments in code). OR current_user_can( 'CAPABILITY_NAME_HERE' )Īdd_action( 'admin_init', 'wpse66093_no_admin_access', 100 ) $redirect = isset( $_SERVER ) ? $_SERVER : home_url( '/' ) Ĭurrent_user_can( 'CAPABILITY_NAME_HERE' ) & isset( $GLOBALS ) AND 'wp-login.php' = $GLOBALS Especially if you have custom login/logout/reset password/etc rules and routes set up. This might need one or two more checks. Do not run if the user is logged in and trying to log out * Plugin Name: (#66093) »kaiser« Deny Admin-UI access for certain roles */ It then redirects to the site the request came from. It's basically just a user capability check, followed by a redirect in an exit call.
0 kommentar(er)
