Restrict Content Pro Custom Renew - WordPress Plugin

How to Configure Restrict Content Pro Custom Renew for Membership Levels

This guide to Restrict Content Pro Custom Renew will help you understand the difference between a global renewal rule and a per-level override, prepare your membership levels for launch, configure predictable behavior for different offerings, and test it without putting active members at risk. We’ll walk through the process, from choosing a renewal policy to testing registration, checking membership status, and troubleshooting cases where a level’s rule does not appear on the public-facing site.

Custom Renew does not create a new payment system or replace the core behavior of Restrict Content Pro. This add-on gives each membership level its own renewal setting. That lets site owners keep a global rule for most levels while requiring automatic renewal for a specific level or disabling it for another. This control is especially useful when a site offers ongoing access, one-time access for a limited term, and a trial program at the same time, since they may not all need to work the same way.

One important distinction is clear from the outset: the add-on controls the automatic renewal rule for each membership level. It does not fix payment processor errors, cancel subscriptions that have already been created by an external provider, or replace a reminder email. A good setup therefore depends on more than a single dropdown. It requires a consistent plan for what you promise users, which global rule is enabled in Restrict Content Pro, which levels have an override, what the registration form shows, and what a test member sees.

What the Add-on Controls and Why It Takes More Than a Checkbox

On a membership site, the word "renewal" is often used to mean several different things. For an administrator, it may mean recurring charges through a supported payment method. For a member, it may mean not having to return to the registration form before access expires. For a content editor, it may mean confidence that access to a restricted section will not end unexpectedly. Restrict Content Pro Custom Renew works at a narrower, but important, level: it determines whether a membership level follows the global setting, must renew automatically, or must not renew automatically.

The add-on documentation describes three options. Default follows the setting in Restrict > Settings > General. Auto Renew requires automatic renewal for the selected level, even when the global setting disables it or lets visitors choose. Do Not Auto Renew does the opposite: the selected level should not renew automatically, even when automatic renewal is required globally or visitors are given a choice. This ability for a level to override the global setting is what sets the add-on apart from a site-wide setting.

Imagine an educational platform with three offerings. The "Monthly Club" is designed for ongoing participation, so automatic renewal makes sense. "Conference Recording Access" is available for a limited time and should not look like an ongoing subscription. The "Trial Month" could follow the site's global policy until the owner decides which option is clearest on the form. If every level uses only the global setting, one of the offerings may send the wrong signal: users might see automatic renewal where they expect one-time access, or a recurring product might require them to return and register again manually.

It helps to separate the business rule from the technical check. The business rule can be stated plainly: "This level always renews automatically," "This level requires manual renewal," or "This level follows the site's policy." The technical check answers a different question: which option appears in the admin form, what choice a test user sees, and what happens at the end of the term. Do not start by randomly selecting Auto Renew. First, record the purpose of each level in a working site document or at least in the level description. That helps prevent a mismatch between what the plan name says and how renewals work.

Think of the Three Options as a Rule Hierarchy

Default does not mean "not configured." It is a deliberate choice to pass the decision to the global setting. This works well when most levels should behave alike. For example, a site with several access options for the same club can change the global policy once without editing every level. But inheritance is useful only when you are comfortable with the behavior changing after an update to the global setting. If a level has a separate promise in its description, ads, or emails, setting an explicit option is safer.

Auto Renew is not for cases where recurring charges are always better. Use it when a particular level should renew automatically regardless of a more permissive global policy. This makes sense when a site offers a primary club membership alongside one-time products. Members on the primary level will not get a choice that conflicts with the access model, and one-time levels will not inherit a rule meant for something else.

Do Not Auto Renew is just as useful. It helps separate access with a set end date from an ongoing commitment. However, do not treat this option as a ban on future purchases. If the site's standard configuration allows it, a member can return and register for access again through the usual process. The point is that automatic renewal will not be imposed on one level just because another level needs it.

Practical rule: If you cannot explain in one sentence why a particular level renews automatically or manually, hold off on launching it until the offer is clear. A technical setting cannot fix an unclear promise to visitors.

What Custom Renew Should Not Do in Your Setup

Do not attribute features to the add-on that belong to the Restrict Content Pro core plugin or the payment method. It does not configure prices, membership terms, tax rules, emails, restricted page content, or payment details. These settings still affect the member experience, so check them alongside the renewal rule, but change them in their appropriate sections. If a test user does not receive an email, Custom Renew is not the first place to look. If they cannot open a protected page, first check their access and the content restriction rule. If a transaction fails with the payment provider, check the logs and payment status rather than only the level dropdown.

Also, do not assume that changing a setting will silently convert all existing member arrangements retroactively. The add-on documentation describes a level configuration, not a bulk migration of existing subscriptions. On a live site, first test the change on a staging copy or a new test level. Then separately review which current members have payment histories and whether you need to contact them. Never test a new policy on the only active level used by real members.

Who Benefits from Per-Level Renewal Rules, and Who Can Keep It Simple

The add-on is especially useful for site owners whose levels differ in more than name and price: they also have different lifecycles. Examples include a club with ongoing membership and a separate seasonal pass, a resource library with both a subscription and a one-time program, an association with annual membership and a short-term guest level, or a restricted catalog with recurring support and a temporary package. In each case, a per-level setting makes the access plan a clear, observable rule rather than a hope that visitors will read the fine print on the form.

An administrator who manages a single level and treats every registration the same way will often need only the global Restrict Content Pro setting. Custom Renew is not necessary just because it is available. Unneeded overrides make future maintenance harder: a few months later, it may be unclear why a level does not follow the global policy. With one level or several identical levels, keep the setup simple and document the global setting.

The plugin also does not provide complex sequences of different payment periods within a single level, flexible payment schedules, or custom rules for individual members. If you need that kind of setup, first check whether the core system and payment method support it, then consider a different way to structure your levels. A Restrict Content Pro level should remain an understandable product offering. Custom Renew helps manage behavior across levels; it is not meant to turn one level into a collection of conflicting exceptions.

Before Installing: Define the Access Policy and Set Boundaries for Testing

A common organizational mistake with renewals is installing the add-on first and then trying to guess what the existing levels are supposed to mean. A brief inventory is much more reliable. List each active level, its access term, purpose, payment method, current global rule, and intended behavior. You do not need financial details. A few columns are enough: "level name," "recurring or time-limited access," "Custom Renew setting," and "what a test user should see." This map gives administrators and editors a shared reference when they write the text around the registration form.

Check that the core Restrict Content Pro plugin is active and that you can access its Restrict admin sections. Custom Renew is designed to work as an add-on to the core membership system. If the main menu does not appear, fix the core plugin issue before looking for the add-on field. Also make sure the site has membership levels you can edit. Custom Renew's setting appears when editing a level, so an empty system with no levels gives you nothing to test.

Choose a safe testing environment as well. For a live site, use a staging copy, a test subdomain, or a new test level that is hidden from visitors. In that environment, you can change the global setting, create a test member, and compare forms without affecting existing member expectations. If you do not have a staging copy, create a temporary level with a clear internal label and do not publish a link to it. After testing, remove or disable the test level according to your internal process. The goal is to see the rule in action, not to make a real sale.

Align the Level Description with Emails

Three things should match for each level: the name of the offering, its renewal rule, and the text users read before registering. If a level is called "One-Time Access to Materials" but the form sets it to renew automatically, that is more than a marketing inconsistency. The mismatch can increase support requests and make disputes harder to resolve. Conversely, a recurring club that requires visitors to return to the form each time may lose members because the process is unclear, not because of the content.

Review plan descriptions, the text above or below the form shortcode, post-registration messages, and standard emails about access ending soon. Restrict Content Pro lets you add your own content around the page where the shortcode appears, so you can explain the terms where users make their decision. Do not use technical options like Default or Do Not Auto Renew in visitor-facing copy. What matters to them is simple: access renews automatically, or they will need to register again.

Check the Global Rule and Level Setting Together

The core product documentation describes three global automatic renewal options under Restrict > Settings > General: always enable it, never enable it, or let visitors choose. When visitors can choose, the registration form displays an additional checkbox, and the administrator can decide whether it is checked by default. This is the baseline behavior to compare against the per-level override. If you do not check both, you may mistake the expected result of an inherited global setting for an add-on issue.

Create a small test matrix. With the global setting set to let visitors choose, leave one test level on Default, set another to Auto Renew, and set a third to Do Not Auto Renew. Then open the registration form for each level separately and note the differences. This quickly confirms both that the field is available in the admin and how its priority works. Do not try to keep every combination in your head, especially if the site has many levels.

The matrix does not replace legal terms or promise a universal setup for every payment method. It makes the admin decision easy to verify: open a level, see the assigned option, and compare it with what should appear on the page. For teams with several people, this table reduces the risk that a designer changes the copy, a marketer creates a new level, and the technical administrator never hears about the new override.

Backups and Conflict Checks

Before working on a live site, save an available standard backup and record the current global setting and the levels you plan to change. This is not about treating a routine configuration as a crisis; it gives you a quick way to undo a change. If the form behaves unexpectedly, you can restore the previous setting, clear the relevant cache, and retest with a test level. Do not edit plugin files or add unverified code snippets for this task: the documented level setting is the primary mechanism.

Conflicts are more likely to appear where the form, caching, and other membership features meet than inside Custom Renew itself. For example, visitors may be served an outdated registration page that still shows the previous choice. Plugins that override the registration form, switch levels through a link, or change how fields appear can also affect what you see. After making a change, use a logged-out browser window and, if available, a separate browser profile. This helps distinguish an admin session or cached page from the path a new visitor sees.

Installing the Add-on and Running the First Check

Install the add-on using WordPress's standard process for an archive you have already obtained: in the admin area, open Plugins > Add New > Upload Plugin, select the ZIP archive, complete the installation, and click Activate. The installation itself is straightforward, but it is not the end of the task. Custom Renew does not need to add a large, separate settings page after activation. Its setting should appear when editing an individual level under Restrict > Membership Levels > Edit.

Do not start changing every level as soon as you activate the add-on. Open one test level and scroll down to the bottom of its form, where the renewal option should appear. If it is there, the add-on is connected to the right screen. If it is missing, note the exact circumstances: whether the add-on is active, whether you are editing a membership level, whether you have administrator access, and whether the interface is hiding additional fields. Do not create arbitrary settings while searching for a "main Custom Renew page"; the add-on is intentionally configured one level at a time.

Choose an option on the test level, save it using the form's usual button, and reopen the edit screen. Reopening matters because it confirms the setting was saved, not just selected. Then find the registration page for that level or create a safe test path using your site's standard registration method. If the form looks as expected, compare it with the other test levels. If the behavior is unexpected, do not draw a conclusion from one visit. First check the global setting, then the level setting, then the cache, and only then move on to troubleshooting.

First check summary: After activation, you should see an additional renewal option on the level edit screen, be able to save it, and explain why the level inherits the global rule or overrides it. The public-facing experience is the next thing to check.

Detailed Configuration: From the Global Policy to a Per-Level Override

After the first check, follow a consistent order. First, choose the global policy under Restrict > Settings > General. This is the baseline for all levels set to Default. Then edit each level that should behave differently and choose Auto Renew or Do Not Auto Renew. This order makes the intent clear: the global setting defines the site-wide rule, while the level setting records the few meaningful exceptions.

Do not start by assigning Auto Renew to every level. First, that duplicates the global policy and makes future changes harder. It also becomes difficult to tell an important override from a value that was saved by accident. Leave Default wherever a level should follow the global setting. Use the explicit options for offerings that need different behavior regardless of the policy for most new members.

Step 1: Choose a Global Setting Based on the Policy You Want

Go to Restrict > Settings > General and find the automatic renewal setting. The core documentation describes three options. With automatic renewal always enabled, it is the default for levels without an override. With automatic renewal disabled, users must return to the registration form after their access ends. When visitors can choose, the form displays a corresponding checkbox, and a separate setting determines its default state.

Do not reduce the choice to an assumption about which option is "best." Recurring access may make sense for a club but not a one-time program. Letting visitors choose offers flexibility, but the form needs especially clear copy. A manual renewal approach reduces the risk of unexpected renewal, but requires a clear reminder and a way to return to registration. Choose the option that fits most levels, not the one that is ideal for a single exception. That is what Custom Renew is for.

Step 2: Configure Each Level on Its Edit Screen

Open Restrict > Membership Levels, select the level, and click Edit. After you activate the add-on, the renewal option is available near the bottom of the screen. Leave Default selected for a level that should inherit the global policy. Choose Auto Renew for a level that requires recurring renewal. Choose Do Not Auto Renew for a level with a fixed term or one that requires users to return and register again. Save the level, and avoid changing its name, term, or other settings at the same time if you are testing renewal behavior alone.

Making changes separately is practical. If you update the description, price, term, form, and renewal option all at once, it is hard to pinpoint why something looks wrong. On a live site, change one thing, document it, and then test. If the behavior does not match the plan, you can restore a single setting instead of sorting through several simultaneous changes.

When to Choose Default

Choose this option for levels that belong to the main product line. For example, a site may offer three recurring membership levels with different amounts of content, but all should use the global visitor choice. This setting creates no hidden override and preserves flexibility: if you change the baseline policy, these levels will follow it. It is useful to note for the team that Default was chosen intentionally, rather than left in place by accident.

When to Choose Auto Renew

This option makes sense when a level must always renew automatically, even if the global setting is "never" or "let visitors choose." One example is the main club membership, where continuity is part of the offer. Before saving, make sure the copy near the form does not promise otherwise. Then test this level against a global setting that would normally conflict with it. That contrast confirms the override is working rather than the level simply inheriting the global setting.

When to Choose Do Not Auto Renew

Use this option to exempt a level from the recurring policy. A time-limited collection of resources, a seasonal membership, or a package that requires users to register again intentionally are good examples. Choose the option, save the level, and check its form while the global setting requires automatic renewal. If the page still appears to promise automatic renewal, check caching, the page copy, or another add-on rather than guessing at the level setting.

Step 3: Document the Setting for Your Team

Custom Renew has few fields, but that does not mean the setup needs no documentation. An internal note next to the level or in a working document should answer four questions: why the level exists, which option is selected, which global policy it overrides, and how to test the behavior. This is especially helpful when a team member changes, the registration page design is updated, or a new level with a similar name is added.

For larger sites, use an internal note rather than overloading the public name. The public title should explain the offering to members. An internal note can use a short description such as "recurring, automatic renewal required" or "fixed access term, no automatic renewal." You do not need technical links or code for this. The goal is for the next administrator to understand the decision without reading the change history.

How to Check the Registration Form Without Confusing It with Another Setting

The setup is complete only after you check the public-facing site. Open the test level's registration form in a clean browser session. First, confirm the level name, then compare the renewal option with what you expect. A level set to Default should reflect the global policy. A level with one of the explicit settings should behave differently from the global setting where intended.

You do not need to make a real charge. Just confirm that the form and the rest of the user journey are consistent with the selected policy. If the core product and payment method provide a safe test mode, use it according to your site's procedures. Do not share test credentials with visitors or make real payments just to capture a screenshot. What matters is comparing the configuration with the expected behavior, not the number of transactions processed.

Open the same pages as a new visitor and as a logged-in test member if your setup handles those states differently. Then clear or bypass the page cache if your site uses one. The order is simple: the admin page confirms that the setting was saved, and the public form confirms what users see. Together, these checks show whether the setup is ready.

Verify the behavior: For each override, record the global setting, the level setting, the expected option on the form, and what appears in a clean session. This is the quickest way to spot a regression after a theme, cache, or add-on change.

Practical Example: Club Membership Alongside a Fixed-Term Program

Consider a use case where Custom Renew proves useful without adding artificial complexity. A site offers a monthly private club and a separate program with access for a limited term. The owner wants to keep the global setting at "let visitors choose" because some secondary levels should offer that choice. But the club must always renew automatically, while the program must never do so. Without the add-on, the administrator would have to give up the flexible global setting or look for workarounds in the form copy.

Set the Goal and Prepare the Test

The goal is to make three different outcomes predictable. The "Club" level always renews automatically. The "Program" level never renews automatically. The "Guest Access" level inherits the global visitor choice. Before you begin, create or set aside test versions of these levels, record the expected behavior, and confirm that each registration page leads to the right level. You can use placeholder content on protected pages, but make sure it is easy to distinguish from a public page.

In the global settings, choose the option that lets visitors decide whether to renew automatically. This is not a recommendation for every site; it is a deliberate contrast for testing. Then edit "Club" and select Auto Renew. Select Do Not Auto Renew for "Program." Leave "Guest Access" on Default. Save each level separately, then reopen it to make sure the changes were saved.

Test in Three Passes

1. Check the guest level. It should reflect the global visitor choice. This control confirms that the baseline setting appears on the form at all.
2. Check the club level. It should follow Auto Renew, even though the global setting lets visitors choose. If it looks the same as the guest level, first check the saved option and the cache.
3. Check the program. Its registration path should not require automatic renewal, even though other levels use it. Compare this with the description of time-limited access on the page.

Run each test in a clean browser session or with a separate test account. Otherwise, saved form data, a logged-in session, or caching can make the comparison unreliable. Do not stop after checking one level that works: the point of the add-on is to have different levels behave differently under the same global setting. If two levels behave alike, that is not necessarily an error, but you should be able to explain it based on their selected options.

What Users Should See and What Administrators Should Record

Users do not need to know that the site uses Custom Renew. They need to see a clear explanation of the access they are choosing. For a recurring club, that means a clear statement that the offer renews regularly. For a fixed-term program, the form should not promise the opposite. For a guest level, it should offer a choice if that is what the owner intends. The fewer technical terms in the public-facing copy, the easier it is for users to understand what access they are choosing.

Administrators should record different details: the global setting, the specific level setting, the date of the internal check, the page that was tested without publishing its address in user-facing copy, the cache state, and the outcome. This record is useful after a form redesign or when a new add-on is installed. It distinguishes "Custom Renew saved the right option" from "visitors see the correct page."

Check Access After Registration: The Form Is Only Part of the Experience

The registration form confirms the user's choice, but it does not replace an access check. After a safe test registration, confirm that the test member can see the protected materials assigned to their level. Then open the same page while logged out and with another test level. The goal is not to retest all of Restrict Content Pro, but to make sure the renewal policy has not been confused with content restrictions. These features affect the same user experience, but they are configured separately.

Check the message shown to visitors who lack access. The core system can display a message in place of restricted content, and that message should point people toward a clear next step. It should not make the page look like a technical error. For levels without automatic renewal, it can be helpful to explain that access is time-limited and that users can register again through the site's usual process. Do not promise a renewal date or method unless your configuration supports it.

A Simple Editorial Practice: Keep One Source of Truth for Renewal Terms

Do not repeat renewal rules in different page sections without coordination. Approve a short description for each type of level and use it in the plan description, form, and emails as appropriate. No code is needed. For example, the editor can approve wording that explains the recurring nature of club access and separate wording that describes the term and manual renewal process for a limited program. Before publishing, compare the copy with the level setting. If the wording changes, decide whether the admin setting also needs to change rather than simply polishing the page text.

This is safer than writing custom PHP automation. The documented way to use Custom Renew is through the level setting, so it makes sense to maintain the user-facing promise through editorial review and regular checks. If you later need a more complex form change, test it on a staging copy and do not edit WordPress core, Restrict Content Pro, or add-on files.

Use case summary: Custom Renew is useful when one global rule works for most levels, but specific levels need clear overrides. The test is successful when the difference appears in the settings, the user journey, and access to the materials.

Changing the Policy on a Live Site Without Surprising Members

Once a site is accepting registrations, a renewal setting is not just a technical choice; it also affects what members expect. A rule that works for a new level may be too abrupt for existing members. Custom Renew gives you useful per-level control, but do not assume that changing an option will automatically explain the new policy to people or safely rewrite existing payment arrangements. Plan the change as a small, separate rollout.

First, define what the change affects: a new level, future registrations for an existing level, or current members. For a new level, test before publishing it. For future registrations, check the page copy, cache, and registration flow. For current members, do not assume how the new setting will affect subscriptions created in the past. Test on a staging copy, review the state of test records, and prepare a support message if members have different historical terms.

A Safe Change Process

1. Record the current global setting and the affected levels in an internal note.
2. Agree on clear user-facing wording for the new policy and review the surrounding copy on the registration page.
3. Test the change first on a staging copy or a new hidden level.
4. Test the form in a clean session, then check access for a test member.
5. Only then change the live level and run a brief public-facing check again.

Each step has a purpose. The process separates planning from configuration, configuration from the form display, and the form display from access to restricted content. If something does not match expectations, you know which part to investigate. If you change everything in one browser session and immediately check while logged in as an administrator, you may miss the fact that a new visitor sees a completely different page.

Caching, Themes, and Form Add-ons

Caching can be especially tricky with registration forms. An administrator saves a level, opens the page, sees the old interface, and concludes that the add-on is broken. In reality, the browser, a caching plugin, or a proxy may be serving a saved page. After a change, use a private window, clear only the cache layer supported by your infrastructure, and compare the page while logged out. Do not disable security or performance features at random or across the entire site without a reason.

Pay attention to the theme and page builder if they change the registration template or display the form in a separate block. Custom Renew controls the level's policy, but the form's presentation can hide or move related fields. During testing, check the standard form template and return to the standard registration path if it is available. If the standard path works but the customized template does not, the issue is with how the form is displayed, not the Auto Renew or Do Not Auto Renew setting.

What to Check After Updates

After updating WordPress, the core membership system, the theme, a caching solution, or a payment add-on, run a brief regression test. You do not need to register through every possible level. Choose one level set to Default, one set to Auto Renew, and one set to Do Not Auto Renew. Compare them with the global setting and open a protected page using a test account. This covers the add-on's core behavior and can reveal common form display conflicts.

Record successful checks as well as failures: which version of the form template you tested, which level you used, what appeared on the form, and which settings were saved. You do not need to publish version numbers or internal addresses in the article, but they are useful in the team's log. Then, when a member contacts support, the team does not have to start the investigation from scratch or ask the person to register again without knowing why.

When to Restructure Membership Levels Instead of Adding Overrides

Custom Renew works well when overrides are few and easy to explain. If every new offering requires several workarounds, pause and reconsider how the levels are structured. One level may combine two different products: recurring membership and a fixed-term package. Or the names may obscure the difference between access to materials and a recurring service. In that case, another renewal option will not address the underlying issue. It will make the catalog harder for both the team and visitors to understand.

There are clear signs that the levels need restructuring. The same level is expected to offer a choice, require automatic renewal for some members, and disable it for others. Editors cannot explain the access term in one sentence. Support keeps having to clarify why two similar names lead to different outcomes. The test matrix no longer fits in a reasonable table. These are not signs that the add-on is inadequate; they suggest that a level is no longer a clear unit of an offering.

Instead of editing core files or writing custom rules, create separate levels with clear purposes and configure Custom Renew for each one. This is easier to test, explain, and undo. Before showing a new level to visitors, test registration and access. This approach may require updating the page copy, but it reduces the risk of unexpected behavior while a user is deciding what access to choose.

What to Record Before Contacting Support

If renewal works on a test level but not on a live one, gather specific observations before changing settings back. Record the option under Restrict > Settings > General, the saved value for the level, the page where the problem occurs, whether it happens while logged out, and whether it goes away when caching is bypassed on a staging copy. If a real transaction was involved, separate its outcome from what the form displayed. This turns a vague "it doesn't work" report into a reproducible case.

Restrict Content Pro's built-in debugging mode can log important actions and updates when enabled under Restrict > Settings > Misc. The Debugging tab then appears under Restrict > Tools. Use it briefly, only for troubleshooting, and follow your site's data-handling policies. Do not publish logs publicly or leave data collection enabled longer than necessary. Use the log to confirm the sequence of events, not to expose member information.

Safe rollback: If a change produces an unexpected outcome, restore the recorded value for the affected level, clear the relevant cache, and check the form again in a clean session. Do not change the global setting, a dozen levels, and the form template all at once.

When Restrict Content Pro Custom Renew Is a Good Fit

The add-on makes sense when a site already uses Restrict Content Pro and its levels have different, but simple and explainable, renewal policies. It provides precise control without custom edits to plugin files: the global setting remains the default, and overrides have a clear place on the level edit screen. It works best when the administrator tests levels with different settings, the editor keeps the form copy in sync, and the team maintains a short record of its decisions.

If all offerings work the same way, keep the global setup simple. If there are exceptions and you can explain each one in a sentence, Custom Renew helps you configure and check them on the public-facing site. Once you have prepared a test environment, compared the rules, and checked the form in a clean browser session, you can download the latest version of Restrict Content Pro Custom Renew and repeat the same steps for your own levels without unnecessary experiments on active members.

Restrict Content Pro Custom Renew Setup Video

This video supplements the guide: a video about the product. Watch it after the initial setup to compare the interface and sequence of steps.