The plugin filters what is in WP’s
$content variable during The Loop based on whether or not the user is logged in. In its most basic form, if the user is logged in, it allows the content to be displayed. If the user is not logged in, it empties this value and replaces it with the login and registration form.
Back in 2005-2006 when the plugin originated, this was a very simple process. Today, not so much. Today we have custom post types, visual page builders, plugins that are really a full blown application such as WooCommerce or BuddyPress, and countless other possibilities.
The plugin has kept pace with these developments while remaining true to its original purpose and use; but the answer to “why isn’t the plugin blocking my content?” has become a far more complicated answer. I’m hoping this post lends some clarity to some of these possibilities.
Let me assure you the plugin is not broken. Thousands of users use the plugin quite effectively. It even runs on this site for all of the member-driven content, subscription processing, user expiration, and other things.
In other words, I not only trust my own business to it, it actually runs my business.
Let’s cover some of the common situations that occur.
Archives and The Read More Tag
Officially, blocking only directly occurs on single posts and pages. The plugin’s primary objective is to drive user conversion (registration). It does this by displaying excerpts of posts with the “read more” tag (or the plugin’s auto excerpt setting) as teaser content which then directs the user to the single post requiring the user to log in or register.
One important note is that if you have the plugin set to display excerpts but you have not defined an excerpt with the read more tag or auto excerpt setting, then your excerpt will consist of the entire post/page.
Note that the plugin’s setting for displaying excerpts is specific to singular posts/pages. It is not referring to what displays in archive templates such as monthly archives, category listings, and search results. The plugin does not natively block content on archive templates.
Suppose that you don’t want to display excerpts. Can archive templates be blocked at all? Not directly. But there are multiple ways to handle this.
First, if you want content to not display in these situations, set it to be “hidden” (see below). That will remove it from archives, menus, search, etcetera unless the user is logged in.
Another possibility is to redirect the user to a login page that will redirect them back to the content upon logging in. There is a discussion of how to use the plugin’s API to accomplish this here, or you can use the plugin’s Advanced Options extension.
Since you’ll find redirection a common theme among these possibilities, there is a larger discussion of it at the end of this article.
While the default restriction uses an excerpt as described above, the plugin also offers the ability to “hide” content. For individual posts/pages, you can set them as hidden instead of blocked. This will make the post non-existent for a non-logged in user.
This works well for situations where you want the content completely hidden. However, it may not be appropriate for all situations. If you use direct links to hidden content, such as buy now buttons, or links in other content, note that going to a hidden post will not exist so the link will result in a 404 not found page.
The plugin will handle removing hidden content from menus, but cannot do so if the link is somewhere in content. So if that’s a concern, then redirecting it as blocked content may be a better option.
Keep in mind, not every situation is the same, so use the settings that are most appropriate to your specific use case.
The addition of certain shortcodes can interfere with the way the plugin handles The Loop.
This most definitely is not intended to say that ALL shortcodes interfere with this, because that is not the case. But some shortcodes, depending on how they process and what they process can cause content to not be blocked. Also, if a shortcode is used to display post meta (custom data not in the main content area), that may be displayed. Because post meta are custom, the plugin does not (and cannot) make assumptions on what is and is not wanted for display.
Solving these kinds of situations can be tracking down those offending shortcodes an removing them, finding alternatives, or finding alternatives to blocking the content. This might include using the [wpmem_logged_in /] shortcode, which may solve the issue, or redirecting the user to a login page.
WooCommerce is a tremendous (and popular) plugin. However, it really is a full application that has a lot of its own processes that function outside of WP’s processes. Primarily, the main thing that happens with WC is that it does not use the WordPress Loop. It has its own Loop. It uses its own templates and template functions.
Because of this, the WP-Members filter on the_content does not effect WooCommerce’s page displays. This is because that content is not going through WP’s the_content filter.
Generally, any time you find a plugin that uses its own templates and template functions outside of WordPress, you will find that you have a situation that will require special attention in order to get WP-Members to handle the process.
Similar to WooCommerce, there are other plugins that also implement their own features outside of The Loop. Sometimes, they just use Custom Post Types and in that case, they can be addressed like any other post or page – the CPT just needs to be identified in the WP-Members settings (more on this below).
In other cases, the plugin may use post meta fields for containing and displaying its content. In this kind of case, the content is unknown to WP-Members so it isn’t blocked. This is content that is outside the main $content variable.
This kind of issue comes up with event calendar plugins and LMS (learning management system) plugins as they tend to store a lot of information in post meta. bbPress would be another example.
The simplest solution to these is to use the Advanced Options extension and redirect away from the content. That way the page cannot be accessed.
Custom Post Types
Custom Post Types are just that – custom. So not every use of a CPT will function the same way. This is why WP-Members does not automatically attempt to manage CPTs in your installation. (Personally, I hate it when a plugin makes an assumption about what it thinks I want – don’t you?)
In general, if a CPT operates similarly to a regular post or page, then blocking/unblocking should operate similarly as well. But compatibility in this area depends on the CPT in question.
WP-Members can be set to attempt to handle a given CPT as it would a post or a page by adding the CPT to the WP-Members options. This can be done in the Custom Post Types section below the main options in the Options tab. Once a CPT is added, it can be managed in the main options in addition to posts and pages.
If a CPT is not able to be blocked like a regular post or page, the second option is to redirect the user to the login (see “How to handle redirection” below).
The above list is not exhaustive. There are just too many possibilities to consider all of them. Keep in mind, this is a WordPress plugin – not a (fill in plugin or theme name) plugin. So if your issue is something on the order of, “why doesn’t it handle (my special plugin)” remember, your other plugin is not part of the core of WordPress. Now that doesn’t necessarily mean it’s not compatible; but it may not be instantly compatible out-of-the-box. There are so many possibilities that the answer to this is “it depends.”
My best advice when testing out is to keep things simple. If you introduce WP-Members to a complex WP setup with 40 plugins, 10 Custom Post Types, a visual builder, and a theme that tries to be an application with bells and whistles that should be plugins, well then it’s going to be difficult to determine incompatibilities.
However, if you begin with a basic setup it will be easier for you to learn how the plugin works and it will be easier to work with additional plugins and themes.
That’s certainly not to say that it can’t be compatible with complex installs. It is very adaptable and extensible because of it’s framework of filters, actions, and API functions.
If you want the easiest path to handle complex installs, I highly recommend the Advanced Options Extension. This extension was designed to offer a number of options that could be enabled very easily. All of its options are as simple as checking a box. Also, a premium support subscription (or the Pro Bundle) are excellent options to help you make the most of your WP-Members installation. There are lot’s of articles and tutorials for support subscribers that address various common (and some not-so-common) customizations.
How to handle redirection
I’ve mentioned in several places that redirection can be a good solution to content blocking. It’s easy to set up as well.
You can handle this in a couple of different ways. Redirecting to the login page can be customized into your process by using the
wpmem_redirect_to_login() API function. Of course it would generally have to be hooked to an action to process. I recommend using
template_redirect as this happens early enough that you can still safely redirect the user, but late enough that the post information should be loaded so you can find out what page you are on. See the documentation on this API function to learn what it does and to see some examples on how to use it.
A very simple solution that also provides you quite a number of additional settings is the Advanced Options extension. For redirecting away from blocked content, it has several options. You can set it to redirect all content to the login page, just blocked content, or just selected content.