If you're concerned about performance, you should definitely upgrade to the current Role Scoper version (rc9.9311). I added some considerable performance enhancements starting with rc9. In fact, your question led me to revisit the analysis today and eliminate (via cache) 40 queries from the Post/Page edit form.

Role Scoper adds the following server overhead in my most recent trials:

with persistent cache enabled (default):

• front end: 3.1 MB memory, 5-12 queries
• front end, "no front end admin" option: 2.5 MB memory, 5-12 queries
• admin (Administrator): 2.4 - 3.1 MB, 4-6 queries
• admin (non-Administr): 2.9 - 3.6 MB, 10-18 queries

without persistent cache enabled:

• front end: 20-25 queries
• admin (Administrator): 17-40 queries
• admin (non-Administr): 23-60 queries

Number of users should not have a dramatic effect on performance, though I have not done any stress testing. I would appreciate future feedback from you or others on that topic.

also, a couple of months ago you provided me with a patch for rc8.9108:

admin_rs.php
–
// optional hack to prevent roles / restrictions menu for non-Administrators (may be implemented as an option in future versions)
if ( empty($current_user->blog_roles['wp_administrator']) )
    return;
// end optional hack

filters-admin-ui_rs.php
–
// optional hack to prevent role assignment boxes for non-Editors (may be implemented as an option in future versions)
global $current_user;
if ( empty($current_user->blog_roles['rs_post_editor']) ) {
    remove_action('do_meta_boxes', array(&$this, 'act_tweak_metaboxes') );
    return;
}
// end optional hack

has this hack been incorporated into the latest release (rc9.9311)?

one more thing.

do comments in php work thus:

// = comment this line

/* and */ = comment multiple lines

if so, the second part of the above hack (contained within the filters-admin-ui_rs.php file) was bracketed with the /* and */ characters within my filters-admin-ui_rs.php file.  interestingly, i didn't notice any role assignment boxes displayed when i was logged in as an Editor with this hack commented out.  is that because the first part of the hack over-rides the second part?  or am i not understanding how this hack works?

Kevin said:

besonen said:

what's the recommended rc8.9108 to rc9.9311 upgrade proceedure?

---

Until I put Role Scoper into the WP Plugins directory (soon), these are the available upgrade procedures:

• Upload the new role-scoper_???.zip to your plugins folder; use your web control panel file manager to extract it. This is the preferred method because RS is never deactivated and the file updates happen near-instantly

so the preferred upgrade proceedure might look like:

 - upload the new plugin to a "role-scoper-new" directory

 - rename the existing plugin directory "role-scoper-old"

 - rename the new plugin directory "role-scoper"

doing the above *without* deactivating the existing Role Scoper plugin–which won't cause any problems??

i've never upgraded a plugin without first deactivating the old version–and Role Scoper seems pretty complex–but i suppose that doesn't matter because whenever wordpress needs the Role Scoper code it is reloaded from the Role Scoper files every time?

Yes, it's a port of the WordPress 2.3 cache, which stored internal results such as categories and pages as files in the wp-content/cache folder. I have adapted it to store user-specific categories, category roles, general roles, pages, groups, etc. Restrictions are also cached there.

Kevin said:

besonen said:

prevent roles / restrictions menu for non-Administrators

---

This is now handled as a Role Scoper Option. On the Realm tab, Access Types section: deselect "editing and administering content".

prevent role assignment boxes for non-Editors

---

This is also handled as a Role Scoper Option. On the Advanced tab, Hidden Editing Elements section: select "Role administration requires a blog-wide Editor role"

Maybe an existing configuration of either of these options would answer your above question regarding non-appearance of role assignment boxes despite the commented-out hack code.

so the hack that still exists in admin_rs.php is just a vestigial code bit–completely superseded by the new options that you coded?