Limiting The Visibility Of Posts In WordPress Via Usernames


Controlling who is able to view a post is a simple task once the system is established. Limiting access to certain users has several applications, such as enabling a design studio to distribute artwork to its various clients, or enabling a small school to arrange for homework to be posted online using a cheap and easy solution.


The easiest method to get this system working is to make the recipients of the information “subscribers” (since they need not be able to post) and the distributors of information “authors” (since they should only be able to edit their own posts). This system eliminates several headaches for the website owner by managing who has access to particular posts. The username would be used to identify who is allowed to view certain posts, since it is unique and, for the most part, constant.

The Basics

What Will You Need?

  • WordPress 3.1 or later
  • Members of various roles
  • The ability to modify your theme’s files
  • Basic knowledge of PHP and MySQL

What Is a Username?

In general, a username is a means by which to identify and verify a user. It is not the only way to identify a user, but remembering a username is easier for the person logging in than having to remember a random user ID. A username can be made unique to an individual, unlike a person’s name or email address (family members may share the same name, or even the same email address). This ease of use and uniqueness is why usernames are used on most websites that require people to sign up in order to access the website or certain of its features.

To WordPress, a username is means of identifying a user. Paired with a password, a username enables someone to access their profile and, depending on their permissions within WordPress, to access to the administrative pages of the website. A username can be used for many functions in the operation and management of a website, such as karma, prestige, user roles and expulsion.

A WordPress username is unique and impossible for the average user to change. Thus, the system is a potentially reliable means of identifying individuals. This reliability is important for a system in which a post must be visible to only a few people. The permissions of a post should not alter merely because someone has changed their name or email address.

Screenshot of a WordPress single user page1
The user page in a WordPress installation. Note that “Usernames cannot be changed.”

Setting Up The Back End

In order for an author to be able to set permissions for visibility, a method of selecting users must be set up on the post editing page. We could accomplish this by one of several methods, one of the easiest and most efficient of which is to create a meta box (or widget) in the post editing page that allows the author to add custom information, as required by a theme or plugin. This information enables us to tell the theme which members should have viewing rights to particular posts.

A Basic Custom Meta Box

Justin Tadlock’s article “How to Create Custom Post Meta Boxes in WordPress2” explains how to create meta boxes, and we’ll reuse that code here.

Let’s assume we’re dealing with a website for a music school named “Smashing Magazine’s Fancy Flautists.” We will use the name smashing_flautist_access in the code for the back end to distinguish it from other custom functions. Justin’s code is a great starting point for this project, but it needs a little customization for our purpose. Place the following code in your theme’s functions.php, and modify the various labels according to your project.

/* Fire our meta box setup function on the post editor screen. */
add_action( 'load-post.php', 'smashing_post_meta_boxes_setup' );
add_action( 'load-post-new.php', 'smashing_post_meta_boxes_setup' );

/* Meta box setup function. */
function smashing_post_meta_boxes_setup() {

   /* Add meta boxes on the 'add_meta_boxes' hook. */
   add_action( 'add_meta_boxes', 'smashing_add_post_meta_boxes' );

   /* Save post meta on the 'save_post' hook. */
   add_action( 'save_post', 'smashing_flautist_access_save_meta', 10, 2 );

/* Create one or more meta boxes to be displayed on the post editor screen. */
function smashing_add_post_meta_boxes() {

      'smashing-flautist-access',         // Unique ID
      esc_html__( 'Post Viewing Permission', 'smashing_flautist' ),     // Title
      'smashing_flautist_access_meta_box',      // Callback function
      'post',              // Admin page (or post type)
      'normal',               // Context
      'default'               // Priority

/* Display the post meta box. */
function smashing_flautist_access_meta_box( $object, $box ) { ?>

   <?php wp_nonce_field( basename( __FILE__ ), 'smashing_flautist_access_nonce' ); ?>

      <label for="smashing-flautist-access"><?php _e( "Enter the username of the subscriber that you want to view this content.", 'smashing_flautist' ); ?></label>
      <br />
      <input class="widefat" type="text" name="smashing-flautist-access" id="smashing-flautist-access" value="<?php echo esc_attr( get_post_meta( $object->ID, 'smashing_flautist_access', true ) ); ?>" size="30" />
<?php }

With Justin’s code, modified for this project, we should have a custom meta box that looks like this:

Screenshot of a basic meta box3
A basic meta box positioned below the post editing box.

Adding Ease to the Selection

This box can be used as is, and the author would simply input the members who they want to allow to view a post. This would work well if each author had very few usernames to remember; but if the author has long list of usernames to choose from, then a list of members would have to be displayed, and there would have to be a system that allows the authors to choose members from the list. Add the following code to the area just below the original box, just after the closing paragraph tag, to display a list of users with their names, along with radio buttons to grant one of the users access to the current post.

<table class="smashing-flautist-access">
<tr align="left">
<th>    </th>
<th>    </th>
global $post;
   $users = get_users('role=subscriber');
   foreach ($users as $user) {
         $user_info = get_userdata( $user->ID );
         if(get_post_meta( $object->ID, 'smashing_flautist_access', true ) == $user->user_login) $ifchecked = 'checked="checked" ';
         echo "<tr>";
         echo "<td>$user->user_login</td><td>    </td>";
         echo "<td align="center"><input type="radio" name="smashing-flautist-access" id="smashing-flautist-access" value="$user->user_login" " . $ifchecked ."/></td><td>    </td>";
         echo "<td>$user_info->last_name, $user_info->first_name</td><td>    </td>";
         echo "</tr>";

   } ?></table>

If everything goes well, you should end up with a box underneath the post editor that looks similar to the image below. The form containing the radio buttons gets a list of users that are listed as subscribers and makes the selection of the student with viewing permissions easy, all without the post’s author having to remember any usernames.

Screenshot of a meta box with user information4
A meta box that contains a method to select the particular name and information of each user.

Saving the List

Now that we have generated a list that makes it easy for the authors to pick which members they want to be able to view particular posts, we have to create a system to add the list to WordPress’ MySQL database so that we can retrieve it later. We also need a way to tell WordPress to update this list of usernames in case the author decides later to add or remove someone from a particular post’s list of authorized viewers. The code provided by Justin does excellent work; place his code below in your theme’s functions.php, just after the function that sets up the custom meta box.

/* Save post meta on the 'save_post' hook. */
add_action( 'save_post', 'smashing_flautist_access_save_meta', 10, 2 );

/* Save the meta box's post metadata. */
function smashing_flautist_access_save_meta( $post_id, $post ) {

   /* Make all $wpdb references within this function refer to this variable */
   global $wpdb;
   /* Verify the nonce before proceeding. */
   if ( !isset( $_POST['smashing_flautist_access_nonce'] ) || !wp_verify_nonce( $_POST['smashing_flautist_access_nonce'], basename( __FILE__ ) ) )
      return $post_id;

   /* Get the post type object. */
   $post_type = get_post_type_object( $post->post_type );

   /* Check if the current user has permission to edit the post. */
   if ( !current_user_can( $post_type->cap->edit_post, $post_id ) )
      return $post_id;

   /* Get the posted data and sanitize it for use as an HTML class. */
   $new_meta_value = ( isset( $_POST['smashing-flautist-access'] ) ? sanitize_html_class( $_POST['smashing-flautist-access'] ) : '' );

   /* Get the meta key. */
   $meta_key = 'smashing_flautist_access';

   /* Get the meta value of the custom field key. */
   $meta_value = get_post_meta( $post_id, $meta_key, true );

   /* If a new meta value was added and there was no previous value, add it. */
   if ( $new_meta_value && '' == $meta_value )
      add_post_meta( $post_id, $meta_key, $new_meta_value, true );
      $wpdb->query($wpdb->prepare("UPDATE $wpdb->posts SET post_status = 'private' WHERE ID = ".$post_id." AND post_type ='post'"));
   /* If the new meta value does not match the old value, update it. */
   elseif ( $new_meta_value && $new_meta_value != $meta_value )
      update_post_meta( $post_id, $meta_key, $new_meta_value );
      $wpdb->query($wpdb->prepare("UPDATE $wpdb->posts SET post_status = 'private' WHERE ID = ".$post_id." AND post_type ='post'"));
   /* If there is no new meta value but an old value exists, delete it. */
   elseif ( '' == $new_meta_value && $meta_value )
      delete_post_meta( $post_id, $meta_key, $meta_value );
      $wpdb->query($wpdb->prepare("UPDATE $wpdb->posts SET post_status = 'public' WHERE ID = ".$post_id." AND post_type ='post'"));

The three MySQL queries are in place to prevent unauthorized users from viewing protected posts and to hide the posts from the RSS feeds. The first query runs only when new data populates the previously empty custom field, while the second query runs only when the data in the custom field has changed. The third query runs only if the custom field is emptied, and it sets the post’s visibility back to “Public.” All three are protected from SQL injection attacks by using $wpdb->prepare() to validate the data entered into the username form field.

If you don’t like that WordPress precedes the post’s title with the word “Private,” then add the following code to your theme’s functions.php file. This custom function is called when your theme would display a post’s title; it finds any instance of the words “Protected” or “Private” at the beginning of the title and removes them. In the core of WordPress’ programming, the function get_the_title() adds those words if a post’s visibility is restricted and the person viewing is not an administrator. What the following code does is send a message to the action that get_the_title() hooks into, telling it to remove the terms “Protected: ” and “Private: ” from the title. So, you can set a post’s title to begin with either term, and the title will not be altered; this code only affects WordPress’ ability to add to your title.

function smashing_title_trim($title) {
   $title = attribute_escape($title);
   $needles = array(__('Protected: '),__('Private: '));
   $title = str_replace($needles,'',$title);
   return $title;

To allow users at the subscriber level to see private posts, you have to give them that capability. As it happens, some of the code we’ll be using later frees us from having to worry about users at the subscriber level seeing the posts of others.

$subRole = get_role( 'subscriber' );
$subRole->add_cap( 'read_private_posts' );

You can also grant users at the subscriber level permission to view private pages, in case you want a dedicated page of information that subscribers should know.

$subRole->add_cap( 'read_private_pages' );

Setting Up The Front End

Now that we have a way to add members to the list of people who can view a particular post, we have to modify our theme to use this data, and to actually control the visibility of each post based on this list. First, we need a way to get the username of the person who can view a post. Secondly, we would compare the username of the member with viewing permissions to the user who is currently logged in. Finally, we would make the theme display either the post in the loop or an error message (or perhaps nothing at all).

Place this code just after The Loop5 starts. It goes in single.php, category.php and index.php if you will be displaying posts on the home page.

/* Get the post's acceptable viewer. */
      $flautist_access = get_post_meta($post->ID, 'smashing_flautist_access', true );
/* Get the post's current viewer, if he or she is logged in. */
      if(is_user_logged_in()) {$current_flautist = $current_user->user_login;}
/* See if the acceptable viewer and the current viewer are the same */
      if($flautist_access == $current_flautist || current_user_can('author') || current_user_can('editor') || current_user_can('administrator'))
         {echo ''; ?>

Place this code just before the loop ends. Here is where you can show an error message telling the user that they may not view this post. Or you could leave this code as is to make it appear as though the current visitor is not missing anything.

<?php } else { echo ''; } ?>

This is what a hidden post looks like to the public or to a user who is not logged in. They would see what appears to be an error message and are redirected away from the post.

What the public sees when trying to view a protected post6
If a person is not logged in and tries to view a restricted post, they would get an error message.

What an unauthorized user sees when trying to view a protected post7
If a user is logged in but not allowed to view a restricted post, they would see either nothing or an error message specific to members.

What an authorized user sees when trying to view a protected post8
If a member is logged in and authorized to view a protected post, then they would see the post itself.


Being able to control who can view individual posts is a useful feature with a wide variety of applications. Third-party software can natively do this, but WordPress is widely supported and documented, which means that any security holes that might allow unauthorized users to view restricted posts would be shut in a future update. Plus, it allows you to run an actual blog next to posts with limited visibility. This system could be used by administrators to distribute personalized content, by professionals to send files to clients, or by bloggers to restrict the visibility of certain posts to certain members.

Enabling an author to control who can view their posts can help them tailor the blog’s content to the needs or tastes of certain users. Ultimately, you will have to factor in the purpose and content of your website when deciding whether to use this method. It’s not for everyone, but it suit the needs of owners of small websites who want to deliver certain content to certain people.




  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13

↑ Back to topShare on Twitter

Chris Ellison is a web developer living in the United States, and has been interested in WordPress since 2009. He owns a design studio, called Abbson Studios, where he is free to experiment with new ways of molding WordPress into whatever his clients need.

  1. 1

    Interesting idea. However, I would assume that limiting posts by a group of user names (perhaps instead of roles) would be more useful. So the radio inputs could be changed to checkboxes and some of the code modified.

    After all, If you have a page for only a single user – why not just email them what you have to say?

  2. 2

    I must admit, I’m surprised this isn’t part of the core WordPress functionality. I would have thought it would be basic functionality for any CMS. Be that as it may, this does seem a little bit primitive. Fine if you have a handful of users, but get up to a couple of hundred and it becomes almost unmanageable. Better to have groups of permissions, and assign users to those, I think.

    • 3

      The functionality is built into wordpress… not exactly this way, but you can set posts to “Private” or “Password Protected”, and I agree with david’s post above. If you were doing this for only one user, why not just password protect the post and send them the password? Alot less effort.

      Personally I’d change that code to use ROLES instead of USERS. it’s very easy in wordpress to create new roles and capabilities. And instead of just selecting the user, make it so you can select by role OR user.

      Also there is an awesome jQuery autocomplete plugin that would be great for this application it works the same way as twitter and facebook do, by typing @username and it will (using ajax) get a list of users matching the user name or user’s first/last name you type.

      • 4

        Thanks. I’ll look into it. I’ve never had to do a WordPress site that allows membership before, so I’ve not really gone into it before, but that does sound a good way to handle it.

  3. 5

    Great article, very useful! Thanks.

    I do have a related question though: an important problem with protected/private posts in WordPress, is that the files and attachments “belonging” to the post itself are NOT private. So say you have /some-hidden-post/ and a user/admin has uploaded a file or image inside that private post, that file/image is still publicly accessible, since it’s just a file in the upload directory /wp-content/uploads/etc
    I know this is not strictly the topic of this article, but I have seen quite a few clients getting in trouble because of this.

    So if anyone or the author of the article can say something about this that would be very helpful.

    • 6

      I would think that a more elegant solution than modifying the template files would be to hook elsewhere into the page/post display process. This would keep the modifications within the plugin (or functions.php file), with the option of pulling the error message from a single source, whether a template file via get_template_part(), a standard require/include, or even a dedicated post.

      There’s a call to current_user_can() during the post query. The result can be intercepted and modified through the “user_has_cap” filter. At very least, “the_content” filter can be used to do the same check and alter the output, though that would probably conflict with the private post status.

      • 7

        Jeff, is your answer a reply to my question? I fail to see the connection, unfortunately. Sorry to if my question was not clear! What I’m talking about is the media files being uploaded in WordPress by users. Those files can be uploaded from each post or page (or from within the Media library). So if you have a “private” page, and upload say a .pdf file on that page. Then a user would assume that that pdf file is also private. But it’s not. The file is publicly accessible by its direct URL. And this is something not many people realize. And something that is problematic, in my opinion. People create a private page, upload media to it and assume it’s private. While it’s not.

        Does this make sense?

        • 8

          Matthijs, my apologies. I was originally going to respond to your post, but decided to do a more general response instead. Though I had clicked on the Reply link next to your name, there wasn’t a clear indication that I was replying to you instead of the entire thread, nor how to “cancel” it and start over. A minor UX concern. :)

          What I was going to say about your post was that it was a very real concern. It’s a hard thing to tackle in a web framework designed to work on a wide variety of shared and dedicated hosting, which is why I don’t believe it’s in the core.

          With a dependency of mod_rewrite and Permalinks enabled, it should technically be possible to move protected attachments (or all of them) to a folder outside of the web root. Using some rewrite-fu (Rewrite API or mod_rewrite rules) a handler script should be able to do the security checks you speak of.

          There’s a scalability concern since content that used to be served statically would now interact with WordPress for each request. This is amplified for sites which use CDNs to offload this static content. If the implementation was designed to handle only protected attachments, I think this would be manageable.

          I don’t believe it’s an impossible task and solutions may very well be available in the plugin repository.

          I’m glad I could take the time to answer your question properly. Hope it helped!

          • 9

            Jeff, thanks for your new reply. Certainly helpful. I’ve read about some people trying to fix the issue with htaccess rewrite and channeling every request through a central script, but haven’t found a definitive solution yet. There are some plugins, but either they are very old or don’t look very good, or they are huge document management systems, giving me 99 features I don’t need for the 1 feature I’m looking for. I’ll probably have to write something myself and see how the performance implications are.

            Besides that, I think it’s important people are aware of this issue. I’ve had people (clients) using wordpress come to me (in panic) asking how suddenly sensitive information was found by search engines. They had put that information in uploaded pdf’s on so-called private pages.

          • 10

            I came up with this to solve that issue. As far as I tested, it’s working. Add the following to .htaccess:

            #only let logged users access pdf or doc files with ‘pvt’ in the filename
            RewriteCond %{HTTP_COOKIE} !^.*wordpress_logged_in_.*$ [NC]
            RewriteRule (.pvt).(pdf|doc)$ – [F]

            I don’t know if this is the best way, but it’s working for me. Thanks Matthijs for bringing this up.

        • 11

          This is good point. Let me know if you find some way to ‘protect’ direct URL (wp-content/uploads). Attacment page is easier to set private along with the private post. Or if I find a solid solution, I’ll let you know.

  4. 12

    Why not just use the Members plugin?

    • 13

      The point of this post is to show people how easy it is to do this yourself, instead of relying on plugins all the time.

      • 14

        I decided that members was a bit overkill for this problem. So I created a plugin that solves this on the site, Advanced Post Privacy.

  5. 15

    great and very useful article, thanks for sharing, I appreciate the hard work

  6. 16

    Once again clearly demonstrating how WordPress is not a CMS. This is super basic for any real CMS.
    Don’t get me wrong though, WordPress is great. It is the worlds most popular blogging platform for a reason!

    If you need to be doing this then it is time to move on to a more fully featured platform. There is a massive list with Joomla and Drupal at the top.

    In Drupal this is a simple permission callback. Very simple.

    • 17

      But Joomla and Drupal need much more knowledge from users to learn the system. Thats the beauty of WP, tell them posts are news and pages are pages and they can use WP. Not the case in Joomla or Drupal, they have to understand the site structure etc. I know it’s easy for a developer to use but users are idiots, it’s a fact. Make it as basic as possible (which WP is) and they might just get it (even then it’s a battle sometimes!)

  7. 18

    Loved this solution! It’s all in WordPress, no need to add a plugin. I was looking for this to make a bootcamp-like page for my clients. Very creative use of custom meta! Congrats!

  8. 19

    Awesome solution, I’ve been looking for this quite a while. Thank you for sharing this, I’ll definitely use this in many of my projects

  9. 20

    i created a plugin to designate certain post categories as ‘members-only’, and then to assign users to one or more of those categories.

    there are a few caveats, mainly with whether or not other instances of The Loop use the suppress_filters argument properly, but overall i found it to be a much simpler solution than assigning categories to roles, then users to those roles… it’s a direct correlation between your content and your users.

  10. 21

    @Chris: Thanks for the article. The solution is great! However, once you have checked one “visibility” radio button in the “Post Viewing Permisson”-box, there seems to be no way to reset the list of users with none selected. Is there a way to change that?

  11. 22

    Great article and really easy to achieve but still a question. Is it a easy fix to alternate this method so you can choose more then one user? If it is it will be exactly what i need. Hope someone can help me with this.

    Thanks again for this great explanation!

  12. 23

    Very useful post – saved me a bunch of time – but remember to add the code in the loop on the author.php and archive.php pages too!

  13. 24

    Hi! This looks like a great solution for my personal project. I have 2 questions:
    1. Is mandatory to publish the post as a “private” one? What if I publish it as “public”?
    2. I’m using WordPress 3.5 and I get the following error:
    Warning: Missing argument 2 for wpdb::prepare()
    Sorry, but I cannot fix it myself. I’m a PHP rookie.


  14. 25

    Currently this code adds the meta box into post only. What if I want to add this to posts and a custom post type? I’ve tried to change line 22 of the first part of the code:
    ‘post’, // Admin page (or post type)
    to this:
    ‘post’,’my-custom-post-type’, // Admin page (or post type)
    and to this:
    array(‘post’,’my-custom-post-type’), // Admin page (or post type)
    and neither seems to work.
    How can I achieve this?

    • 26

      Belen – did you find a solution to this?
      I’d like this to happen on a custom post type instead of the posts

      — sorry, just had another look – very easy

      ‘post’, // Admin page (or post type)

      Just change ‘post’ to ‘your_custom_post_name’

  15. 27

    Thanks for your great tutorial. I am looking for a way to restrict posts to individual users (or username) automatically, Meaning whoever (individual user) who creates the post is the ONLY person who can SEE and EDIT the post. I want to do this both on the back end and the front end. It would be similar to what you have shown, however as mentioned the post created by a user should be automatically restricted to him/herself (each username can see and edit their own posts only), and circumvent the need to make a selection.

  16. 28

    It looks awesome, although I get stuck on the 2nd stage as the radio box wont echo into the text field. Why is that?

    How would I assign multiple Editors to a post?

  17. 29

    Just a notice here if someone start restrict access on template level, as in this simple topic. This is only for children and family access fun solution. But it works and get the job done! Great turtorial! Thanks for sharing.

    My note here for readers is:

    Content is not properly restricted if an user can get the exerpts in widgets, listings, recent comments on that “hidden” post. WordPress can NOT HIDE its content very well as a CMS does. WordPress is ok to restrict the “address” to a content from working, but that is not TRUE restriction. The post shows up in the menues, droplists anyway and give an anoying “Sorry, cant find what you locking for, maybe search will help….”

    The only plugin so far (free) that can do this well is User Access Manager. But it comes with a pageload costs when the site grows. But with around 25 users and 100 pages you wont feel so much of a diffrent.

    Happy restrictions everyone!
    / Jonas Lundman, web project manager

    • 30

      What if i want to allow subscribers an option to select preferences in the backend in their profile and a custom page that shows the posts based on their preferemces (using tags or categories ) i am building an event based wordpress site to display current and upcoming events of my university and i want to give my users an option to see only those events they are interested in .. Is it possible ?

  18. 31

    That’s a great one ..

    In my blogs, all users can make a post, can I restrict the visibility to the admins and the member who made that post only? Please let me know if this is possible.

    My blog is sort of people asking me questions that I’m the only one who can answer. So, I don’t want other people and member to have access to it.


  19. 32

    Anyone have a solution for multiple checkboxes?

  20. 33

    For anyone interested, I’m working to try to get a solution for multiple checkboxes here:

    I will post final link when I have a solution. Any collaboration / contribution would be thoroughly appreciated.


    • 34

      Kamlesh Katolkar

      March 29, 2014 4:05 am

      I Think I done this point pleas go through following code:-

      /* Fire our meta box setup function on the post editor screen. */
      add_action( ‘load-post.php’, ‘smashing_post_meta_boxes_setup’ );
      add_action( ‘load-post-new.php’, ‘smashing_post_meta_boxes_setup’ );

      /* Meta box setup function. */
      function smashing_post_meta_boxes_setup() {

      /* Add meta boxes on the ‘add_meta_boxes’ hook. */
      add_action( ‘add_meta_boxes’, ‘smashing_add_post_meta_boxes’ );

      /* Save post meta on the ‘save_post’ hook. */
      add_action( ‘save_post’, ‘smashing_flautist_access_save_meta’, 10, 2 );

      /* Create one or more meta boxes to be displayed on the post editor screen. */
      function smashing_add_post_meta_boxes() {

      ‘smashing-flautist-access’, // Unique ID
      esc_html__( ‘Post Viewing Permission’, ‘smashing_flautist’ ), // Title
      ‘smashing_flautist_access_meta_box’, // Callback function
      ‘post’, // Admin page (or post type)
      ‘normal’, // Context
      ‘default’ // Priority

      /* Display the post meta box. */
      function smashing_flautist_access_meta_box( $object, $box ) { ?>

      <input class="widefat" type="text" name="smashing-flautist-access" id="smashing-flautist-access" value="ID, ‘smashing_flautist_access’, true ) ); ?>” size=”30″ />




      ID );
      if(in_array($user->ID,(get_post_meta( $object->ID, ‘smashing_flautist_access’, true )))) $ifchecked = ‘checked=”checked” ‘;
      echo “”;
      echo “$user->user_login “;
      //echo “user_login” ” . $ifchecked .”/> “;
      echo “ID” ” . $ifchecked .”/> “;
      echo “$user_info->last_name, $user_info->first_name “;
      echo “”;

      } ?>

      post_type );

      /* Check if the current user has permission to edit the post. */
      if ( !current_user_can( $post_type->cap->edit_post, $post_id ) )
      return $post_id;

      /* Get the posted data and sanitize it for use as an HTML class. */
      $new_meta_value = ( isset( $_POST['smashing-flautist-access'] ) ? sanitize_html_class( $_POST['smashing-flautist-access'] ) : ” );

      /* Get the meta key. */
      $meta_key = ‘smashing_flautist_access’;

      /* Get the meta value of the custom field key. */
      $meta_value = get_post_meta( $post_id, $meta_key, true );

      /* If a new meta value was added and there was no previous value, add it. */
      if ( $new_meta_value && ” == $meta_value )
      add_post_meta( $post_id, $meta_key, $new_meta_value, true );
      //$wpdb->query($wpdb->prepare(“UPDATE $wpdb->posts SET post_status = ‘private’ WHERE ID = “.$post_id.” AND post_type =’post’”));
      /* If the new meta value does not match the old value, update it. */
      elseif ( $new_meta_value && $new_meta_value != $meta_value )
      update_post_meta( $post_id, $meta_key, $new_meta_value );
      //$wpdb->query($wpdb->prepare(“UPDATE $wpdb->posts SET post_status = ‘private’ WHERE ID = “.$post_id.” AND post_type =’post’”));
      /* If there is no new meta value but an old value exists, delete it. */
      elseif ( ” == $new_meta_value && $meta_value )
      delete_post_meta( $post_id, $meta_key, $meta_value );
      //$wpdb->query($wpdb->prepare(“UPDATE $wpdb->posts SET post_status = ‘public’ WHERE ID = “.$post_id.” AND post_type =’post’”));

      I had modified it according to my need. If this will helps you lemme know:)
      and for front end I modified it as
      $flautist_access = get_post_meta($post->ID, ‘smashing_flautist_access’, true );

      /* Get the post’s current viewer, if he or she is logged in. */
      if(is_user_logged_in()) {$current_flautist = $current_user->ID;}
      /* See if the acceptable viewer and the current viewer are the same */
      //if($flautist_access == $current_flautist || current_user_can(‘author’) || current_user_can(‘editor’) || current_user_can(‘administrator’))
      if(in_array($current_flautist, $flautist_access)|| current_user_can(‘administrator’))
      {echo ”; ?>

      <?php previous_post_link( '%link', __( '← Previous’, ‘twentyeleven’ ) ); ?>
      <?php next_post_link( '%link', __( 'Next →’, ‘twentyeleven’ ) ); ?>



Leave a Comment

Yay! You've decided to leave a comment. That's fantastic! Please keep in mind that comments are moderated and rel="nofollow" is in use. So, please do not use a spammy keyword or a domain as your name, or else it will be deleted. Let's have a personal and meaningful conversation instead. Thanks for dropping by!

↑ Back to top