The latest version of PMPro includes an update sponsored by Chris Lema. You can now add a “delay” parameter to the membership shortcode to have content appear a certain number of days after a member’s membership starts. Use a shortcode like this:

[membership level=”1″ delay=”6″]This content will show up 6 days later. (Memberships start on day 0.)[/membership]

Development Changelog for Paid Memberships Pro Release Updates

Even better, the new version of PMPro has code to support a “sister plugin” we’re developing for drip feed content. PMPro Series. We plan to get it into the WordPress repository soon to fully support it. But in the meantime, you can grab that code on GitHub right now.

Here’s a few screen shots showing the PMPro series plugin in use. They show a series being edited, what it looks like on the frontend, and what it looks like for users without access.

PMPro Series being edited
PMPro series plugin on the frontend
PMPro series plugin for users without access on frontend

Once things solidify a bit and we get this in the WP repo, I’ll make some videos to show the step by step to setup serial content using PMPro.

Here are the other updates and fixes included in these updates. Of note are fixes to the queries used to send the expiring soon emails.


  • Fixes in the new pmpro_getMemberStartdate and pmpro_getMemberDays functions.
  • Fixes to SQL queries for the expiration and trial ending crons.
  • Added a pmpro_required_user_fields filter similar to the pmpro_required_billing_fields filter.
  • Added a function pmpro_setMessage($message, $type) that sets $pmpro_msg and $pmpro_msgt globals if they aren’t set already.
  • Added a function pmpro_getClassForField($field) that will return a string including “pmpro_error” or “pmpro_required” if applicable. You can filter the classes added to the fields via the pmpro_field_classes filter.
  • Showing * on required fields via javascript on the checkout page.
  • Updated checkout page to highlight in red fields that are related to the error message shown.
  • Added headers property to the PMProEmail object. You can add headers (e.g. to add a cc or bcc) to PMPro emails using the pmpro_email_headers filter.
  • Updated Stripe library to version 1.7.10. Updated PMPro to take advantage of new “interval_count” parameter in subscriptions, so you can now have subscriptions setup for “every 2 months”, etc.
  • Fix to pmpro_checkout_start_date_keep_startdate filter added in 1.5.5
  • Added “Start Date” and “End Date” to emails sent to admins when a membership is cancelled.
  • Now checks for CSS files in a paid-memberships-pro subfolder of your active theme and uses those admin.css, frontend.css, and print.css files instead if they exist. (Going to move email and page template checks to that subfolder in the future as well.)


  • Updated pmpro_check_site_url_for_https function to cache the siteurl to limit DB queries.
  • Added includes/filters.php to store hacks/filters/actions that were originally developed outside of the PMPro core and brought in later… or just things that are cleaner/easier to impement via hooks and filters.
  • Added a “delay” property to the membership shortcode. E.g. will show that content if a member has had level 1 for at least 7 days.
  • If a member checks out for the same level again (extending their membership), the startdate added to pmpro_memberships_users will be their old startdate.
  • If a member checks out for the same level again, the remaining days on their existing membership will be added to their new enddate. So e.g. if a user starts an annual membership in April 2013, then checks out again (extends) their membership in February 2014, their new enddate will be April 2015 instead of February 2015. (NOTE: if you were doing this through the custom code here – – you should remove your custom code.)
  • Fixed bug where you couldn’t remove all required membership levels from a page/post. (Thanks, lisaleague)
  • Updated the button CSS included in paid-memberships-pro/css/frontend.css. I added a pmpro_ prefix to these classes so they don’t conflict with other .btn CSS rules. I also changed the rules a bit to show the buttons more consistently. If you relied on the old CSS rules, you may need to tweak your theme to get things looking right.
Was this article helpful?