Paid Memberships Pro emails a membership invoice for all recurring or renewing membership subscriptions. This email is not sent after the initial membership checkout because all of the relevant invoice details are included in the Membership Confirmation email. If you’ve customized the Confirmation email and removed invoice details, you may want to send a separate invoice email using the recipe below.
Currency formatting varies from country to country. For example, the placement of a comma (“,”) or period (“.”) in a currency format can mean something completely different depending on what currency is being used. Our core plugin offers formatting for several built-in currencies, which you can specify on the Memberships > Payment Settings page, but what if your currency is not being properly represented?
This code recipe demonstrates how to use the pmpro_currencies filter to adjust the format to match your desired currency.
Do you offer three different payment options for the same membership access? This new code gist allows you to easily add a selection box to the checkout page.
The code example below shows you how to define level “groups”—levels that are related and should appear as payment plans on the membership checkout page.
Many development and staging sites want to restrict total access to the site’s folder on the webserver. One of the easiest ways to do this is by setting a UNIX password at the server level.
This advanced developer recipe shows you how to set up custom .htaccess rules to allow your Webhook or IPN data through this security measure. This will allow you to properly configure and test payment gateways in Paid Memberships Pro.
If your site has a UNIX password or is in Coming Soon/Maintenance Mode, your gateway will not be able to get to your site and send their data.
The recipe below will allow any of the listed IP addresses access to your website and will prompt everyone else to enter your secret UNIX username and password.
Note that this recipe specifically allows the IP addresses of the PayPal IPN Live Server and the Stripe Webhook. If you are using another gateway or using PayPal in Sandbox mode you will need a separate list of IP addresses. Please consult your payment gateway documentation to locate their active IP addresses.
This recipe will only work with sites restricted by a UNIX password. If you are using a Coming Soon plugin, you’ll need to take another approach to allow gateway access to your site (the easiest method is to disable the maintenance mode while running your tests). We’ll try to put together a similar recipe for popular plugins with this feature, or you can open topic in the members-only support forum for personal help.
Our Recurring Payment Email Reminder Add On allows you to notify members that their membership renewal payment is processing soon. This recipe shows you how to use the pmpro_upcoming_recurring_payment_reminder filter to modify when that notification is sent.
By default, the Recurring Payment Email Reminder Add On will send a notification 7 days prior to a member’s recurring payment date. In the example below, we are modifying that default to send the notification 14 days (or two weeks) prior to renewal. Annual plans may want to adjust this to 30 days prior (roughly 1 month) or another value that best fits the needs of your membership program.
In this post, we will cover a number of ways that you can control the allowed format and structure of usernames for new members.
If your site doesn’t have a need for public or frontend-facing usernames, you may want to simplify checkout by setting a user’s email address as their username. With the vast number of sites we are all members of, it has become extremely difficult to remember what username I created where. It’s much easier to remember your login credentials when using an email address as your login name.
During a default membership checkout, users are prompted to create a “Username” and enter their “Email Address”. This code recipe will take the information inserted in the Email Address field of the Membership Checkout page and use it as the member’s username.
To prevent any confusion, you will also want to hide the “Username” field using CSS (more on this below) or by using a Custom Page Template. If you do not hide this field and a member performs a checkout and inputs a username then the Code Recipe will still overwrite the username data and replace it with the member’s email address.
This code recipe will convert a member’s username to match your specific rules. In this example, we convert all characters to lowercase and replace any spaces found in the username with underscores. If a member inputs a username like “John Doe”, then this will be changed to “john_doe”.
One of our members recently had a support request related to the format of usernames. Their request was for appearance reasons, but there are other cases where you would like usernames to follow stricter guidelines. For example, if you are using a single sign on bridge to integrate your members with a third-party application, you may need to match the requirements of usernames for that external site.
This code can also be useful in cases where the member’s username appears in other features of your site, such as on a BuddyPress profile.
If you’re using widgets on your WordPress site and want to customize them for members and non-members, check out the recipes below. We’ll provide a way to filter an entire widget area for members-only, as well as a recipe to hide a specific widget instance based on the current user’s membership level.
The following recipe allows you to define dynamic sidebars (by sidebar ID) to hide or show based on the membership requirements of the active post ID. Any widgets placed in the filtered widget areas will not show if the current user does not have access to the post ID.
The following recipe allows you to hide specific widget instances (regardless of the widget area they are placed in) based on the current user’s membership level. This code recipe can be extended for several membership level checks based on your needs.
widgettype-NUM, for example text-2 or recent-comments-1.This code recipe will convert a member’s username to match your specific rules. In this example, we convert all characters to lowercase and replace any spaces found in the username with underscores. If a member inputs a username like “John Doe”, then this will be changed to “john_doe”.
One of our members recently had a support request related to the format of usernames. Their request was for appearance reasons, but there are other cases where you would like usernames to follow stricter guidelines. For example, if you are using a single sign on bridge to integrate your members with a third-party application, you may need to match the requirements of usernames for that external site.
This code can also be useful in cases where the member’s username appears in other features of your site, such as on a BuddyPress profile.
We also see many members using their email address as their username. To protect a user’s contact information, you may want to extend this recipe to convert the @ symbol so that a user’s email address isn’t displayed publicly.
Use the following code recipe to display a “Renew” link on the Membership Account page at your desired period before a member’s expiration date.
By default, when a member signs up for a membership level that has an expiration date, they will see a “Renew” link a certain number of days prior to their membership expiration date. When a member “Renews” their membership, the new period is automatically tacked on to the end of their existing membership level. The core plugin has built-in logic to determine when the “Renew” link appears based on the active member’s billing and expiration date settings.
If the member logs in to their membership account before this timeframe is triggered, they will instead see a “Change” link, allowing them to view current membership level offerings and change their membership level. This code recipe allows you to control exactly when the “Renew” link will appear for the member.
If you are new to PMPro, check out some of these other articles related to member renewals:
Let’s face it, dealing with refunds is an unavoidable part of your membership business. Some number of your refunds will be from legitimate users that realize they do not need or want your membership any more.
Some refunds, though, may be from abusive users who know that they can sign up, consume your membership product (whether that’s support, premium content or guides, downloads and more), then cancel and request a refund right away. If you are seeing this become a widespread problem, check out the code recipes below.
This post includes three different recipes based on how you want to approach the restriction on a new checkout. In each case, the user will see a notice if they try to purchase membership that can be adjusted for your needs. The default message reads: Please contact us about your account to complete checkout..
If you are new to PMPro, check out some of these other articles related to member refunds: