Content Permissions

The Content Permissions feature lets you choose which roles can view a post or page.

For any public post type (posts, pages, etc.), you’ll find the Content Permissions settings on the post editing screen:

  • Block editor: open the Content Permissions (Members) panel in the editor’s settings sidebar (the Post or Page tab). Changes in this panel save automatically, so you don’t need to click Update for them to take effect.
  • Classic editor: use the Content Permissions meta box below the editor. Your changes save when you click Update or Publish.

Content Permissions meta box

Select the roles that can view the content of the post/page. If no roles are selected, anyone can view the content. The post author, users that can edit the post, and any users of roles with the restrict_content capability can always view the post, regardless of their role.

Members only: to show a page to anyone who’s logged in, whatever their role, tick every role.

A visitor needs any one of the ticked roles. Roles aren’t ranked, so ticking “Editor” doesn’t also let Administrators in; tick each role you want.

You can add a custom error message for individual posts. Otherwise, the error message will default to whatever you have set under the plugin settings.

The feature is on by default. You can turn it off under Members → Settings → Content Permissions.

What visitors without access see

  • The page itself still opens. Members replaces the post content with your error message; the URL doesn’t redirect.
  • The excerpt is replaced with the error message too.
  • Comments are hidden, and so is the comment form.
  • In your RSS feed, protected posts show the error message instead of their content.

Child pages inherit protection. If a page has no roles ticked but its parent page does, the parent’s roles apply to it too.

Put a login form in the error message

The error message runs shortcodes, so you can put the [members_login_form] shortcode in it. Visitors who aren’t logged in get a login form right where the content would be, and come back to the same page after logging in. Add it to a single post’s Error Message, or to the default message in Members → Settings.

Big important note: This feature only blocks the post content (that’s what you write in the post editor), post excerpt, and post comments. It does not block anything else.

What Content Permissions doesn’t protect

Because it works on the post content, Content Permissions does not hide:

  • The title, featured image, menus, search results, or sitemaps. Visitors can see that the post exists. To also hide protected posts from search results and archives, see Hide protected posts from search and archives.
  • Uploaded files. Images, PDFs, and other files in your Media Library open for anyone who has the direct link. To protect files, use MemberPress Downloads.
  • Custom fields shown by your theme or a plugin outside the post content.
  • The blog’s “Posts page” (the page set under Settings → Reading). Use Private Site, or protect the posts themselves.
  • Content from page builders that don’t use the post content. See below.
  • WooCommerce products beyond their description. See below.

There’s also no rule for a whole category, tag, or post type. Content Permissions is set post by post. To protect new posts automatically, see Protecting new posts by default. To protect whole categories, tags, or post types, MemberPress Rules do that, and cover new content as you publish it.

Page builders and themes

Members protects content through WordPress’ the_content filter. Builders and themes that use it work as expected. Others need a setting, or aren’t supported:

  • Bricks: supported. Pages and posts built with Bricks, including posts that use a Bricks template, are an exception to the note above: visitors who can’t view the page see your error message in place of the whole page body, not only the post content. Your Bricks header and footer still show.
  • Breakdance: turn on Breakdance → Settings → Advanced → Apply the_content Filter, then Members can protect Breakdance pages.
  • Elementor and other builders: content built in the builder may not pass through the_content, so Members may not be able to protect it. Test a protected page while logged out before relying on it.
  • The error message shows more than once: your theme runs the_content in more than one place (for example, in a sidebar or footer). Ask the theme author, or try another theme to confirm.

WooCommerce products

The Content Permissions box appears on products, but WooCommerce shows the price, short description, and Add to cart button outside the post content, so only the product description is hidden. To hide restricted products from your shop and category pages, add this snippet (for example with the free WPCode plugin):

add_filter( 'woocommerce_product_is_visible', function( $visible, $product_id ) {
    return $visible && members_can_current_user_view_post( $product_id );
}, 95, 2 );

The WooCommerce integration add-on doesn’t restrict products; it only adds WooCommerce’s capabilities to the role editor.

Translations (WPML)

Each translation is its own post, so restrictions don’t carry over automatically. Either tick the roles on each translation, or tell WPML to copy the _members_access_role custom field to translations in its custom field translation settings.

The REST API

Hide Protected Posts from WP REST API (under Members → Settings → Content Permissions) is on by default. It keeps protected posts out of the WordPress REST API for anyone who can’t view them, so their content can’t be read from /wp-json/ and they don’t show up in lists of posts there.

Some features load posts through the REST API: event calendars, some blocks, and apps. If one of these shows nothing to logged-out visitors, test by turning the setting off. If that fixes it, the protected posts were being hidden as intended. Turn the setting back on and leave those posts unprotected, or ask the feature’s author about it.

This is separate from Private Site’s Require authentication for access to the REST API option, which blocks the whole REST API for logged-out visitors. See Private Site.

Caching

If a page cache serves the same copy of a page to everyone, a visitor may see a cached version meant for someone else, like an error message after they’ve logged in. Make sure your caching plugin or host doesn’t cache pages for logged-in users, and exclude protected pages from caching if your cache can’t tell visitors apart.

Protecting new posts by default

If you’d like new posts to start out restricted, see Protecting new posts by default in Snippets.

Need more than roles?

Content Permissions is great for keeping content to logged-in users or certain roles. When you want to charge for access, protect whole categories or post types, drip content over time, or protect files, see Members and MemberPress. It covers how the two work together and how to move your protection over to MemberPress.