Only show your own posts in admin (hiding others’ posts from contributors)

I’ve written some themes and plugins that make extensive use of WordPress custom post types. These are coupled with new roles that lie somewhere between contributor and editor. The member can publish some post types, submit others for review. It has raised the problem that I do not want these members to see other members’ posts. The reasons for this are twofold. Firstly the admin screen will get busy, there will be too much noise, this will usually be too complex for them to handle. Secondly I don’t want them looking at other member’s unpublished posts.

The answer is to filter the global $query object, restricting the member to their own posts. This can either be white or black labelled depending on how you wish to go.

/**
 * This restricts posts in wp-admin for Subscribers
 *  and Contributors to their own posts only.
 * However, none of the admin-table-filters hookable into,
 *  so you'll need some CSS too.
 */
add_filter('pre_get_posts', 'tcb_admin_show_only_authors_posts');
function tcb_admin_show_only_authors_posts($query) {
  global $current_user;
  $post_type          = $query->get('post_type');
  $allowed_post_types = array();
  if ( in_array($post_type, $allowed_post_types) ) return $query;

  $restricted_roles = array('subscriber', 'contributor');
  get_currentuserinfo();
  $user_roles = $current_user->roles;
  $role       = reset($user_roles);
  if( $query->is_admin && in_array($role, $restricted_roles) ){
    global $user_ID;
    $query->set('author', $user_ID);
  }
  return $query;
}

The filter only works for the actual editable content. The (useful) menu across the top allowing people to select mine or published uses some separate SQL, and there are no hooks in the code. So these must be hidden using CSS.

This should get you started:

#editor-toolbar,
#misc-publishing-actions,
#slugdiv,
.subsubsub,
.search-box,
.author-other,
.tablenav,
#contextual-help-link-wrap,
#media-upload-header{
 display: none;
}

Remove gravity forms capabilities

The Gravity Forms plugin adds capabilities at the same level as roles (as opposed to adding capabilities to roles). This means that your users (subscribers, contributors e.t.c) may end up with access to your forms in the back end. This is because the plugin checks for that capability, rather than examine the user’s role’s capabilities.

I wrote a filter to check for and strip away this capability on authentication:

/**
 * Removes the capablity, added by Gravity Forms, from all
 *  non administrators when they log in
 *
 * This hook removes that access on login. To trigger it,
 *  the member must log out first, then back in.
 */
add_action('wp_authenticate', 'tcbarrett_authentication');
function tcbarrett_authentication($username){
  remove_gravityform_caps_from_non_admin($username);
}
function remove_gravityform_caps_from_non_admin($username){
  global $wpdb;
  $user_id = username_exists($username);
  if(!$user_id) return;

  $userinfo = get_userdatabylogin($username);
  $property = $wpdb->prefix."capabilities";
  $caps     = $userinfo->$property;
  if( $caps['administrator'] ) return;
  if( $caps['gform_full_access'] ){
    $member = new WP_User($user_id);
    $member->remove_cap("gform_full_access");
  }
}

Welcome

Welcome to my little blog. I have watched http://www.tcbarrett.com for years (decades even) wondering if I should join in with what so many millions of other people have already done. Should I start putting my ramblings on the internet for all to see?

Well, I’ve done it. And now I feel I have taken on a responsibility, like buying a house, a pet or even getting married and having children. Surely these first steps have an implicit promise of quality content, that I am obliged to provide to you my reader. Luckily, for me, I’ve managed to no longer feel such an obligation. So expect some real drivel!