Version of Paid Memberships Pro is out with a couple of bug fixes and minor enhancements.

Please update Paid Memberships Pro from the plugins page of your WordPress dashboard. You can also get the latest version of PMPro here or version specifically here.

The full list of updates is below.

  • BUG: Fixed bug when using the testing gateway.
  • BUG: Avoiding issues where is_user_logged in is not yet available for the pmpro_search_filter() function. (Thanks, d_enajetic)
  • ENHANCEMENT: Updated Italian translation. (Thanks again, Angelo)
  • ENHANCEMENT: You can now define(‘PMPRO_USE_SESSIONS’, false); in your wp-config.php to force PMPro to skip the call to session_start. Note that PayPal Express and some addons require sessions to function.

Comments (15)

ENHANCEMENT: You can now define(‘PMPRO_USE_SESSIONS’, false); in your wp-config.php to force PMPro to skip the call to session_start. Note that PayPal Express and some addons require sessions to function.

Can you explain this in greater detail? What are the potential impacts? We have a high volume news site with a hard paywall, and we have occasionally seen 503 errors under large traffic spikes. Our hosting provider has told us that the reason for the 503’s are the session_start calls overwhelming the server.

Session vars are only used by the PayPal Express and TwoCheckout gateways and possibly some of our addons. So if you aren’t using those gateways, you should be able to disable session vars. Should test first for sure though.

p.s. I’ve looked in the past into ways we could use something other than sessions or a kind of replacement for sessions (some plugins in the WP repo that try to do this). I stopped because it was always easier to enable sessions on the host. I wasn’t actually thinking about the performance impact of session vars. It might be worth looking into further for us.

After dealing with considerable performance issues on a site of mine, I ran a profiler that detected session_start as the culprit within PMPro. I found the line of code that uses the PMPRO_USE_SESSIONS global variable which led me to these release notes. Setting PMPRO_USE_SESSIONS to false has boosted my site performance substantially. Fortunately we’re not using PayPal Express. I would suggest a more prominent blog post on using this trick to boost performance.

You could search/grep the code for “$_SESSION”. FYI, we’re working on an update to lower the performance hit we cause through our session use. Basically, we’ll be starting only when we need it and closing it ASAP.

It seems like paypal express might be a bit broken now, whenever someone tries to signup it creates the profile, tries to get the initial payment, fails and cancels the profile.

There were some changed to how we integrate with PayPal Express to account for situations where users have taxes setup in PayPal. It shouldn’t have affected others. It is still working on our site and dev/testing sites. Have you created a forum thread somewhere where we can get more info about your setup (levels and info, other plugins/gists running) to test it out?

It might be worth queuing the debug emails in the ipnhandler as if there is a problem with the mail system it stops payments from working with little to go on (profile is created, then cancelled 3-30mins later with the initial payment failed)

I just started reviewing your plugin today. I’m getting all kinds of jQuery errors on the checkout page.

ReferenceError: jQuery is not defined
jQuery(document).ready(function() {
?level=1 (line 110, col 6)

ReferenceError: jQuery is not defined
} <link rel="icon" href="
?level=1 (line 178, col 1)

ReferenceError: jQuery is not defined
jQuery('#discount_code_button').click(function() {
?level=1 (line 199, col 3)

ReferenceError: jQuery is not defined
?level=1 (line 237, col 2)

ReferenceError: jQuery is not defined
jQuery("input[name=submit-checkout]").after('<input type="hidden" name="javascri…
?level=1 (line 283, col 1

Thanks Jason. I surmised that already. Autoptimize was causing the problem apparently.

Found another glitch in your plugin. I’m still testing and evaluating, so maybe it’s a setting I missed.

I noticed that Paid Membership Pro doesn’t stop a user from signing up to the same exact non-expiring monthly membership level. I created a membership level and then created a new user to test everything. After completing the sign-up process, I tried it again and it allowed me to sign that user up to the same level.

I doubt that’s a desired result.

The levels page will typically say “Your Level” with no link to check out for recurring membership levels. You are correct that PMPro doesn’t explicitly restrict an existing member from checking out for the same level. There are some use cases where users do need to check out for the same level to change payment options/etc.

It’s possible to restrict checkouts this way through custom code. We can help to craft that in the member forums. Perhaps we could make it an option that can be set by filter/etc.

Right…but if they haven’t signed into the site, they’d get the new user registration and checkout. I will come up with something. Maybe modify the plugin with an option to allow / prevent multiple sign-ups. They would need to cancel their existing membership first or allow the system to do it for them. In my case, I don’t want members accidentally being erroneously charged for something they already have (existing membership). I also don’t want to be bothered with having to credit those members for these kinds of mistakes.

Also, have you guys done anything with AWS S3 yet? I noticed some of your competitors offer this option.

What would cause a page that is set to require membership keep demanding an existing member with rights to login and never show the content. The user can get to all of the OOTB pages that come with Paid Membership Pro.

Is there an authentication shortcode that needs to be added to created pages???

Leave a Reply

Your email address will not be published. Required fields are marked *