[admin]

Thanks for the detailed testing.

Worth clearing up first: our plugin never returns a 404. Core protection replaces the post content with the protection message, and the Full Page Protection addon replaces the page output or redirects. Neither sets a 404 status anywhere. So the “page doesn’t seem to exist” result means WordPress is resolving that request as not-found before our access check runs, which is why switching addons changed nothing.

The quickest way to confirm this: deactivate Simple Membership and both addons entirely, log in as that member’s WordPress user, and visit /events/ and one event. If you still get the 404, our plugin is not involved.

Two other things to check while you are there:

1) The anonymous test may have been served from LiteSpeed’s cache rather than PHP. Retest anonymously with ?nocache=1 on the end of the URL, or with LiteSpeed Cache deactivated. If it 404s then too, the behavior is the same for all non-admin visitors.

2) Confirm the event’s Visibility is Public, not Private. Private posts show fine for admins but 404 for subscriber level users, which matches what you are seeing.

Let me know how the deactivation test goes and we will take it from there.

[admin]

Hi, Instead of the Custom Post Protection addon, please try the following full page protection one. Does it work better with this tribe events post type?
https://simple-membership-plugin.com/full-page-protection-addon-simple-membership/

[admin]

Private browsing on cellular rules out browser caching, but not server side or CDN caching, so let’s narrow it down properly.

First, what that message actually means. The registration form only outputs “Free membership is disabled on this site” when PHP receives no member_id and code values in the request (and no level is specified in the shortcode). If PHP had received those two values but they did not match a member record, you would instead see “This unique registration link is invalid. Could not find a match for the given member ID and the security code.” If the account had already been completed, you would see “This unique registration link has already been used.”

So the fact that the parameters are visible in the address bar while you get the free membership message tells us the HTML being returned was not generated for that specific request.

Two quick tests:

Test 1: use a deliberately wrong code.
https://yoursite.com/membership-join/membership-registration/?member_id=36&code=wrongcode123

If you get the “This unique registration link is invalid” message, PHP is receiving the parameters. The problem is then with the member record or the reg code, not caching.
If you still get “Free membership is disabled”, PHP is not seeing the parameters at all, which means a cached or proxied copy of the page is being served.

Test 2: add a random parameter to a valid link.
…?member_id=36&code=REAL_CODE&nocache=987654

If it suddenly works, a cache layer is keying on the base URL and ignoring the query string.

If the tests point to caching: caching is not only caching plugins. Please check for:

Host level page caching (SiteGround, WP Engine, Kinsta, Cloudways/Varnish, LiteSpeed server cache, NGINX FastCGI cache). This is enabled by default on many hosts and is independent of any plugin.
CDN or proxy caching, particularly Cloudflare with “Cache Everything” or APO enabled.
Open the registration page in your browser’s dev tools, Network tab, and look at the response headers for the document request. Values like cf-cache-status: HIT, x-cache: HIT, age: or x-litespeed-cache: hit confirm a cached copy is being served.

Note that “my page edits show up instantly” does not rule this out, because saving a page automatically purges that one page in most host level caches, while the registration page keeps serving its cached copy to visitors.

If the parameters are reaching PHP (Test 1 shows the “invalid link” message): go to Simple Membership > Members, confirm the record for member ID 36 still exists and has an empty username (an incomplete profile), and confirm the code in the email matches the reg code on that record. You can resend the registration completion email from that same menu.

One more thing worth verifying. In your log the generated signup link is on /membership-registration, but the link you pasted is /membership-join/membership-registration/. Go to Simple Membership > Settings > Pages tab and make sure Registration Page URL is the exact permalink of the page that contains the [swpm_registration_form] shortcode. If it does not match, the request goes through a redirect first, and some redirect rules or plugins drop the query string. You can view the currently configured URLs under Simple Membership > Tools > System Info.

[admin]

Hi, this looks like the same caching issue you ran into before. See the previous thread here:

https://simple-membership-plugin.com/forums/topic/user-registration-after-payment/

With caching enabled, the page isn’t rendered dynamically. Instead of showing the registration form for that member, you’re seeing a static cached version of the page, which is why it displays “Free membership is disabled.”

This is a known caching-related issue and is explained in more detail here:
https://simple-membership-plugin.com/understanding-the-impact-of-caching-on-membership-sites/

To fix it, you’ll need to exclude caching on pages that require dynamic content (such as the registration page). Otherwise, this will keep happening.

[admin]

Please check this documentation to see if this is helpful:
https://simple-membership-plugin.com/creating-member-logout-link/

[admin]

It has been a couple of weeks, so I’ll mark this topic as resolved. If you still need assistance, please reply here.

[admin]

Thanks for the log, it’s helpful. Everything on the plugin side worked: member record 18 was created, the unique link was generated, and the return URL was set to the paid registration link.

The “Free membership is disabled” message only appears when the registration page loads without the member_id and code values in the URL. So the link is correct, but those parameters aren’t reaching the page. That’s a site-level issue, not a plugin setting, and no addon is required.

First, edit your registration page and confirm the content is just [swpm_registration_form] with no extra attributes such as a hardcoded level value, and that Settings > General Settings > “Registration Page URL” points to that page. This documentation covers how the required pages should be set up and how to recreate them if needed:
https://simple-membership-plugin.com/recreating-required-pages-simple-membership-plugin/

Then test this: open the exact link from the log in a private browsing window and check the address bar after it loads. If the parameters have disappeared, something is stripping them. Common causes are page caching or a CDN, a server redirect that drops the query string (http→https, www, trailing slash), or a security plugin filtering query args. Exclude the registration page from caching and review your redirect rules.

https://simple-membership-plugin.com/membership-registration-process-overview/
https://simple-membership-plugin.com/understanding-the-impact-of-caching-on-membership-sites/

You can regenerate the link from the plugin’s Tools menu to retest without paying again:
https://simple-membership-plugin.com/regenerate-and-resend-the-unique-registration-completion-link/

Also note your log records the user IP as a private address (10.0.0.1). The auto-redirect feature matches the pending member record by IP address, so if your site is behind a proxy or CDN and the plugin isn’t seeing the real visitor IP, it will fall back to the Thank You page. That likely explains the behaviour on your other buttons.

For the third button, edit and re-save it so the PayPal plan is recreated, then retest. If it still errors, post the browser console output and the log entries from that attempt.

[admin]

You can create as many free membership levels as needed. Each level simply needs to be configured according to your site’s requirements.

The following documentation explains the available options for offering free memberships:

https://simple-membership-plugin.com/offering-multiple-free-memberships-site/

https://simple-membership-plugin.com/offer-customers-free-membership/

[admin]

Did you import any users into this site, or were they created directly through the Simple Membership plugin? During an import, invisible whitespace or other hidden characters in a field value can sometimes cause this type of mismatch.

As a test, delete the affected user (from WP users interface) and also from the SWPM interface. Then manually add the member through the Simple Membership admin interface:
https://simple-membership-plugin.com/manually-adding-members-site/

[admin]

That error is actually the clue here. It means the member account exists in SWPM but has no matching WP User record, so the forced WP login fails.

Please try what the message suggests: take the username value from the error (ariolodin@gmail.com) and search for it in the WP Users menu (Users → All Users). Do you see a WP User entry for that username? If not, that missing WP user is the cause, let us know and we’ll advise on restoring it.

[admin]

To add to the above, if your goal is just to visually style that message (colors, spacing, font size, etc.) rather than wrap it in your full page template, CSS will handle it.

You can inspect the message with your browser’s developer tools to find its wrapper class, then target that class in your theme’s Custom CSS (or a custom CSS plugin so the tweak survives updates). Our CSS tweaks page has examples of this approach:
https://simple-membership-plugin.com/miscellaneous-css-tweaks-simple-membership-plugin/

For more precise control, use the free Simple Membership Custom Messages addon. It lets you replace the default notice with your own text and HTML markup — so you can wrap the message in a div with your own class or id, then target that with CSS to style it exactly how you like:
https://simple-membership-plugin.com/simple-membership-custom-messages-addon/

[admin]

Thanks for the update, and thanks for reporting back that it was the firewall’s bad query string / XSS rules causing the 403. That’s a useful detail, because it’s very likely relevant to the PayPal issue too.

Your PayPal log shows exactly where the flow stops

A complete PayPal subscription checkout produces this sequence in the debug log:

1. swpm_pp_create_subscription ajax request received for createSubscription… ✔ you have this
2. PayPal Subscription ID: I-XXXXXXXX ✔ you have this
3. Webhook event type: BILLING.SUBSCRIPTION.CREATED ✔ you have this
4. Webhook event type: BILLING.SUBSCRIPTION.ACTIVATED ✔ you have this
5. OnApprove ajax request received for createSubscription… ✘ missing

Step 5 is the one that matters. The onApprove step is a browser-side callback: once PayPal approves the subscription, the button’s JavaScript sends one final AJAX request from the customer’s browser back to your site’s admin-ajax.php. That request is what creates the payment/member record, sends the registration email, and returns the URL the customer should be redirected to.

Your log has no OnApprove entry at all, which matches your symptoms precisely: PayPal takes the payment (hence the PayPal emails and the ACTIVATED webhook), but the popup never hands control back to your page — so no registration email and no redirect. The webhooks alone do not create the member account; the onApprove request does.

Most likely cause

Since your firewall was already returning 403s on this site, the first thing to rule out is whether it’s still blocking that second AJAX request. The onApprove request POSTs a JSON payload (subscription details, PayPal URLs, etc.) to admin-ajax.php — exactly the kind of thing that “bad query string” and XSS filter rules tend to trip on. The first AJAX call (create subscription) is a much smaller payload, which would explain why that one gets through and this one doesn’t.
To confirm, please do this:

– Open your Join page in a browser where you are not logged in as admin.
– Open Developer Tools → Network tab (tick “Preserve log”), and also open the Console tab.
– Complete a test payment.
– Look for a POST to admin-ajax.php with action=swpm_onapprove_process_subscription. Tell us whether it appears at all — and if it does, what status code and response body it returns.
– Note any red errors in the Console.

That one check tells us whether the request is being blocked (firewall/WAF), is failing (server error), or is never sent, which would point to a JavaScript conflict instead.
https://simple-membership-plugin.com/forums/topic/test-for-plugin-and-theme-conflict-before-posting-an-issue-or-a-bug/

[admin]

Thanks for the detailed log.

Your webhooks are working correctly

Looking at the log, the Stripe webhooks are being received, validated, and processed successfully (invoice.payment_succeeded). The line “Ignoring unused stripe webhook event. Webhook type: customer.subscription.created” is normal, expected behavior — our plugin only acts on the events it needs and ignores the rest with a 200 response. It never returns a 403 for any webhook. So the 403 you’re seeing is not coming from our plugin’s webhook handling.

The 403 is a server-level block

“The server sent back an error: 403 Forbidden” is a response from your server (or a security/firewall layer in front of it), not from our plugin. Since you’ve already ruled out the SWPM Full Page Protection addon and ModSecurity, the next step is to identify exactly which request is being blocked:

Open your browser’s Developer Tools → Network tab, then run the payment test again. Find the request returning 403 and note its URL. That tells us what’s being blocked (e.g. admin-ajax.php, a REST API endpoint, or the return/registration page).
Check for any other security layer: Cloudflare or another CDN/WAF, Wordfence or a similar security plugin, or host-level firewall rules beyond ModSecurity. Any of these can return a 403 on a specific URL or query string.

Regarding XML-RPC

No, our plugin does not require XML-RPC to create registration pages or to process Stripe payments. You can leave it disabled; it’s unrelated to this issue.

Worth double-checking your setup

While you investigate the 403, it’s also worth confirming your Stripe button and webhooks were configured per our documentation:

Stripe subscription button: https://simple-membership-plugin.com/sca-compliant-stripe-subscription-button/
Creating the webhook: https://simple-membership-plugin.com/create-a-webhook-in-your-stripe-account/
Webhook signing secret (recommended): https://simple-membership-plugin.com/configuring-the-stripe-webhook-signing-secret/

Once you’ve identified the blocked request from the Network tab, reset the log file, run another test, and share both the 403 request URL and the new log data. That will pinpoint the source.

[admin]

Good to hear that you got it sorted out. Thank you for sharing your solution.

[admin]

Hi hapo, Since switching the export format didn’t fix it, the issue is most likely one of these:

Hidden BOM character in the file — Excel/Numbers on Mac often adds an invisible “byte order mark” at the very start of the file even when you export as plain CSV. This gets prepended to your first column header, so it’s technically not user_name anymore even though it looks correct. Fix: Open the CSV in a plain text editor (TextEdit in “Plain Text” mode, or VS Code/Sublime) instead of Excel/Numbers, and check the very first characters of the file.
Wrong delimiter, depending on your Mac’s regional settings, “Comma Separated” exports can still use a semicolon (;) instead of a comma. Open the file in a text editor and confirm the header row actually uses commas: user_name,email,password,…
Extra/renamed header cell — double-check there’s no trailing space, hidden character, or renamed cell (e.g., Username instead of user_name) in that first column header. The column name must match exactly, case-sensitive.

Quickest way to isolate it: Download the plugin’s official sample CSV template from Simple Membership > Import Members, and only replace the data rows — don’t retype or rebuild the header row. If that imports fine, the header row in your original file is the problem.

[Author]

Posts