Note: this was originally published in 2014, and as a result the code samples may not be compatible with newer versions of MemberMouse. Please test appropriately before use in production!
On a recent membership site we built, we had a few specific criteria for how members would be able to access content:
- New content is published every week on the same day of the week
- Each week, all members get access to the same new piece of content (as opposed to a drip schedule)
- Members should only be able to access content that has been published since they signed up (as opposed to all old content)
Member Mouse has support built in for protecting content on a drip schedule. With that setup, what content a member sees each week (or day, or month, etc.) depends on how long they’ve been a member. For instance, they might immediately get access to post 1 when they join, then post 2 a week later, post 3 a week after that, etc.
One benefit of a drip setup is that if you only have a set amount of content that you’ll ever publish, once you prepare it all, you’re done. The downside to that approach is that once a someone has been a member long enough to access all of the content, there’s no reason for them to continue paying. As a result, the lifetime value of a member is capped. Another drawback is that because each member isn’t seeing the same new content each week, you can’t discuss that specific piece of content when promoting the site (for instance “this week, members get XYZ – join now!”).
With all that in mind, this site needed some customizations to make the content protection work as desired. We can use Member Mouse’s built in content protection settings and grant access on day 0, but that’s not enough.
With that in place, when a new member joins, they’d be able to access all previously published content, which isn’t what was needed for this site. To prevent that, I simply ran a quick check to compare a member’s “days as member” value in Member Mouse to the number of days a piece of content had been published, and if it had published more than seven days prior to a member joining (well, not really – more on that in a minute), the member is redirected to an error page. Here’s the code to do that:
Remember how I mentioned that I’m not really comparing to a member’s join date above? Take a look at the “days as member” calculation. I’m not actually checking the member’s join date. Instead, I’m referencing the Member Mouse “days as member” number. The important difference there is that once a member joins, that join date can never be changed (at least not from within the Member Mouse UI). By contrast, the “days as member” number can be manually changed later on:
Why does that matter? Well, the truth is, it probably doesn’t. However, I believe it’s always good to design a solution with edge cases in mind. Perhaps someone will join the site at some point, then want to pay extra to be given access to all old content. It doesn’t take any extra work to write the code in such a way that that kind of scenario is easily accommodated, and it’s one less issue that might crop up in the future.
Actually, all of the above is really just extra protection. The way we set up the site, a member shouldn’t ever actually see a link to a piece of content they aren’t allowed to access. To ensure that this is the case, we alter the query on the meal plan (the custom post type we’re protecting) archive page with the following code:
Here, we again check for the “days as member” value, then add seven days, and get only content published after that date. Why the seven days in both of these functions? Because content is published weekly (on Fridays, in this case), and we want to avoid a situation where someone signs up and has nothing available to them. This way, as long as content is published every week, a new member will immediately have access to a piece of content.
Additionally, on that meal plan archive view, we filter the message that’s displayed if no posts are found and replace it with our own message. If the user is logged in, then we apologize (because they should be able to see something), and request that they contact us. If they’re not logged in, we tell them, and provide a login form (helpfully provided by Member Mouse) in case they’re already members but just happen to not be logged in.
We also encourage them to view the plans available if they’re not a member yet, and link to the relevant page on the site. Non-members shouldn’t ever get to that page, but again, we’re trying to anticipate the edge cases and design for them, rather than ignore them. I’m sure our client would rather a visitor be encouraged to browse membership options if they happen to land on that page, rather than being rudely turned away!
Got any questions about Member Mouse customization? I’d love to help out if I can. Also, if you see any issues with the code I shared, please let me know!