Using MemberPress to Get that Magazine Feeling
Posted on November 6, 2017
Our customers come up with the best ways to use software sometimes. I recently had to have my eyes opened to the fact that just because we are in a digital age doesn’t mean we have to abandon all the old tools available to us.
Let’s say you want to do a magazine style site where monthly content is given to subscribers. A standard way of implementing this with membership software is to charge for a monthly subscription which gives you access to everything, Then if you cancel, you lose access to the site. In one respect this model gives people the incentive to remain a customer but in another sense, it’s not exactly fair.
- If a customer paid for a subscription and received 3 “issues” why wouldn’t they retain access to that over time?
- Another thing to think about is that if you are expecting your customers to pay monthly, you have to keep the prices low enough such that they don’t notice it on the bill. This is how Time gets away with it at just $2.50/mo. That’s low enough to just pay forever without worrying about it and having access to (quick google search) 93 years worth of back-issues.
- If you want to charge a higher subscription rate you have to offer a little more and one of those things can be the fact that they get to retain access to issues they were subscribed.
So… how to implement this? Without code there really isn’t a way to accomplish this. The reality is it completely breaks the concept of a membership site to allow people access to premium content after they are no longer a member.
MemberPress developers to the rescue.
MemberPress recently implemented a rule which allows for this exact scenario. At its simplest form it states, “Even though you have access to this resource, I’m going to deny you anyway.” The way we correct this is to simply not protect the magazine issues and instead write a little snippet of code which asks, “This issue was published on March 9th, does the user attempting to access this issue have a transaction for March 9th?”
With the chunk of code below we check and make sure they have a transaction covering the time period they’re trying to access. If they do, we allow them to see what they’ve already purchased.
We love taking awesome products like MemberPress and tweaking them to provide the exact functionality our clients desire. If you have a WordPress or MemberPress customization project, please get in touch:
add_filter('mepr-last-chance-to-block-content', 'deny_selective_access_9s');
function deny_selective_access_9s($deny,$current_post,$uri) {
//short circuit if it's not even a magazine issue post type
if($current_post->post_type != 'magazine-issue')
return $deny;
//if there isn't even a user block access. We don't want to do a lot of
//work looking up transactions if they aren't even logged in
$user = new MeprUser(get_current_user_ID());
if(!$user->ID)
return true;
//add a custom where to get transactions by user by date
add_filter('mepr_transaction_get_complete_by_user_id_custom_where', 'deny_selective_access_where_9s');
$num = get_all_complete_by_user_id( $user->ID,
'', //order by
'', //limit
true, //count only
true, //include expired
false, //include confirmations
true //include custom where
)
//do not leave this filter lying around to confuse other parts of the memberpress software
remove_filter('mepr_transaction_get_complete_by_user_id_custom_where', 'deny_selective_access_where_9s');
if(!$num)
$deny = true;
return $deny;
}
function deny_selective_access_where_9s($where,$user_id){
global $post,$wpdb;
$where .= $wpdb->prepare(
'AND %s > t.created_at AND %s < t.expires_at ', $post->post_date,
$post->post_date
);
return $where
}
