[The Assurer]

@helenware
In your own words, please describe the issue you are experiencing.

• This reply was modified 5 months, 2 weeks ago by The Assurer.

[The Assurer]

The granularity is on whole calendar days only, and expiration take place at the end of the last day; because it is run as a system wide batch job.

[The Assurer]

Please describe what exactly is going on, that is prompting your inquiry.

[The Assurer]

In the Simple Membership plugin, the login form/page is intentionally kept simple so it can adapt to any WordPress theme. That means customization is usually done using pages, shortcodes, CSS, or small code tweaks, rather than a built-in “template editor”.

Let me walk you through the main ways you can customize the login page:

✅ 1. Create Your Own Custom Login Page (Recommended)

The plugin doesn’t force you to use a fixed login page—you can create your own.

Steps:
Go to Pages → Add New
Create a page (e.g. “Member Login”)
Add this shortcode:
[swpm_login_form]
Publish the page
Use this page in your menu or redirect users to it

👉 This gives you full control over:

Page layout (using your theme or page builder)
Adding text, images, branding, etc.
🎨 2. Customize the Design (CSS Styling)

The plugin uses minimal styling and inherits your theme styles.

So if you want to change how the login form looks (colors, spacing, etc.), you can use CSS.

🔧 3. Customize Login Redirect Behavior

You can control where users go after login.

Go to:
WP Admin → WP Membership → Settings → General Settings

Look for:

“After Login Redirect URL”

👉 Example:

Redirect to dashboard page
Redirect to members-only content

[The Assurer]

What you’re describing actually lines up with two known limitations + a likely server-side issue with the Simple Membership plugin—so you’re not doing anything wrong.

✅ 1. Important: “Protect Category” does NOT update posts individually
This is the key misunderstanding:
👉 The “Protect Category” feature does NOT write/update the membership level into each post.

It applies dynamic protection at runtime
The posts themselves will still show no membership level selected in the editor
So what you’re seeing here is expected behavior, not a failure.

👉 In other words:

✔ Category protection = works globally
❌ It does NOT modify the post meta (no bulk assignment)

⚠️ 2. Page/Post Protect tab not loading (critical error)
This part is NOT normal and is the real issue.

Based on your description:
Only first page loads once
Then crashes / critical error
You have ~3000 posts

👉 This strongly suggests:
A server/resource or conflict issue

From experience with this plugin, the most common causes are:

🔹 (A) Memory / execution limits (very likely with 3000 posts)
The bulk interface tries to load a lot of data → crashes

🔹 (B) Plugin or theme conflict
JavaScript or PHP error breaking the UI

🔹 (C) Hosting-level caching (SiteGround uses aggressive caching)
This can break admin AJAX requests

🔧 3. Recommended troubleshooting steps (in order)
Step 1 — Check error logs (VERY important)

Ask SiteGround for your error_log or check:
Site Tools → Statistics → Error Log
This will tell you exactly what is crashing.

Step 2 — Increase PHP limits
Ask SiteGround or set:
memory_limit = 512M
max_execution_time = 300
With 3000 posts, this is often required.

Step 3 — Do a conflict test
Switch to a default theme (like Twenty Twenty-Three)
Disable all plugins except:
Simple Membership

Then try:
👉 WP Admin → WP Membership → Page/Post Protection

If it works → it’s a conflict.

You can also try:
https://simple-membership-plugin.com/forums/topic/test-for-plugin-and-theme-conflict-before-posting-an-issue-or-a-bug/
Step 4 — Disable caching (important for SiteGround)

SiteGround uses:
Dynamic Cache
Memcached

You should:
Disable caching temporarily
Or exclude admin pages

[The Assurer]

Just to confirm, if I buy and install that plugin. It is a one time payment right?

This is a one-time payment (includes 1 year of support and updates).

Then once installed, can I keep my “join membership” page as well, or should I use woocommerce only to add membership?

Yes — absolutely.
You do not need to switch membership payments to WooCommerce.

Your Case 1 (WooCommerce purchase → membership later)
Your understanding is correct.

Your Case 2 (Membership first → WooCommerce purchase later)
Also correct.

Your preferred structure is actually ideal
What you described is exactly what many sites do:

WooCommerce → physical goods
Simple Membership → memberships

You do not need to sell memberships through WooCommerce.

[The Assurer]

Great — it sounds like you’ve already understood the system quite well 👍 Once the logic of WP Users vs Membership records becomes clear, everything starts to make sense.

Let’s answer your two questions clearly.

1️⃣ If WooCommerce creates a user, will it automatically appear in Simple Membership?

No — not automatically by default.

Simple Membership stores members in its own table, separate from the standard WordPress users table. So when WooCommerce creates a user account, that user does not automatically become a Simple Membership member.

That’s why you previously had to use the import tool.

You already used the correct tool for that:

👉 https://simple-membership-plugin.com/import-existing-wordpress-users-simple-membership-plugin/

This is usually needed when users already existed before installing the membership plugin.

2️⃣ Is there a way to automatically create membership records for WooCommerce users?

Yes — and this is the recommended solution if you are using WooCommerce heavily.

Use the official WooCommerce integration addon

👉 https://simple-membership-plugin.com/woocommerce-simple-membership-plugin-integration/

About the password issue you saw

This happens sometimes when importing users.

The reason is:

Simple Membership does not store the password itself — WordPress does.

So when importing users, the plugin sometimes requires a password reset or first login to sync properly.

This is normal and usually only happens once during migration.

[The Assurer]

This actually helps a lot. What you are seeing is expected behavior with the Simple Membership plugin when a WordPress user already exists (like from LearnDash).

In the standard paid registration flow, Simple Membership assumes the user does NOT already have a WordPress account.

However, WordPress does not allow two accounts with the same email or username. So if the person already has a WordPress account (for example from LearnDash), the registration form cannot create another one. This results in the error you are seeing.

That’s why the system gets stuck and you need to activate the account manually.

If the user is already logged into their existing account when they purchase, the plugin normally applies the payment to that account automatically (effectively upgrading it).

But if they are not logged in, the plugin assumes they are a new user, which triggers the registration link workflow.

Require users to be logged in before buying

Since your students already have accounts from LearnDash, the cleanest solution is:

Ask users to log in first.

Then purchase the membership.

[The Assurer]

Thank you for the detailed explanation—that helps a lot 👍

What you are seeing is almost certainly caused by the theme’s global input reset, not by the Simple Membership plugin itself. The plugin intentionally applies minimal CSS so that forms inherit styling from the active theme. This is mentioned in our support notes as well: the plugin generally lets the theme control styling, which sometimes leads to conflicts when a theme aggressively resets form inputs.

In your case, the Kentha theme rule like this is likely the culprit:

input {
-webkit-appearance: none;
-webkit-backface-visibility: hidden;
}

When appearance: none is applied to input[type=”checkbox”], the browser removes the native checkbox UI, which is why the label still works but the checkbox itself becomes invisible.++

Recommended CSS Fix

Try explicitly restoring the default appearance only for the login form checkboxes generated by the [swpm_login_form] shortcode.

/* Fix invisible checkboxes in SWPM login form */
.swpm-login-form input[type=”checkbox”] {
-webkit-appearance: checkbox !important;
appearance: checkbox !important;
-webkit-backface-visibility: visible !important;
backface-visibility: visible !important;
opacity: 1 !important;
visibility: visible !important;
width: auto !important;
height: auto !important;
}

You can also try a slightly broader selector if the theme overrides deeper:

.swpm-login-form .swpm-remember-me input[type=”checkbox”],
.swpm-login-form .swpm-show-password input[type=”checkbox”] {
-webkit-appearance: checkbox !important;
appearance: checkbox !important;
}

[The Assurer]

A syntax error usually means something wass mistyped.

If you want to check for conflicts, please see:
https://simple-membership-plugin.com/forums/topic/test-for-plugin-and-theme-conflict-before-posting-an-issue-or-a-bug/

[The Assurer]

Hi Ron — thanks for the detailed info, that helps a lot.

You’re getting:

400 ERR
“Error: Invalid webhook data received.”
Event type: invoice.payment_succeeded
Debug log: can’t retrieve subscription cpt record!

This tells us two important things:

Stripe successfully processed payment

Your server rejected the webhook payload

Your code then failed to find the matching subscription CPT record

Since one subscription updated correctly today, this is very likely a data-matching issue, not a Stripe outage or global configuration problem.

What’s Actually Failing

Your system is receiving the event:

invoice.payment_succeeded

But when your webhook handler runs, it tries to:

Extract the subscription ID from the event

Find the corresponding subscription CPT (custom post type) record

Update it

And it fails here:
can’t retrieve subscription cpt record!

So the core issue is:

The Stripe subscription ID in the webhook does not match a subscription record in your database.

Why This Happens (Most Common Causes)
1️⃣ Subscription ID Not Stored Correctly

The Stripe subscription ID (e.g., sub_…) may:

Not be saved in post meta

Be saved under a different key

Be saved incorrectly

Have been deleted or overwritten

Two failing subscriptions suggests those specific records have bad/missing metadata.

2️⃣ Webhook Signature Validation Failing

Your message says:

“Invalid webhook data received.”

That error is commonly thrown when:

The webhook signature check fails

The raw body is modified before verification

The endpoint secret is wrong

The wrong mode (live vs test) is used

However…

Since one subscription worked today, your webhook secret is probably correct.

[The Assurer]

(Recommended): Add It to Your Theme’s functions.php
Steps:

Go to your WordPress Dashboard

Navigate to:
Appearance → Theme File Editor

Open the file:

functions.php

Scroll to the bottom

Paste the custom code there

Click Update File

That’s it.

⚠️ Note:
If you change themes later, you will lose this code.

[The Assurer]

Yes, this is possible — but not with the default behavior out of the box.
What you are currently seeing:
Details:

Array
(
[phone] => nnnnn nnnnnn
[member_id] => nn
)

means that the email is printing the raw $fields array, and only the fields that were processed in that particular hook are being included (not a full profile snapshot).

Why This Happens

When a member updates their profile, the plugin triggers a notification using the updated fields array. That array typically only contains:

The fields that were submitted
Or sometimes only a subset of processed fields
It does not automatically fetch all profile fields from the database.
So by default, the email only shows what was passed to that function — not the full member record.

Recommended Solution – Modify the Email to Pull Full Member Data

Instead of printing the $fields array directly, you can fetch the full member record from the database using the member ID and include all fields in the email.

Here is an example approach:

add_action(‘swpm_member_profile_updated’, ‘my_custom_profile_update_email’, 10, 2);
function my_custom_profile_update_email($member_id, $fields) {

global $wpdb;
$table_name = $wpdb->prefix . “swpm_members_tbl”;

// Get full member record
$member = $wpdb->get_row(
$wpdb->prepare(“SELECT * FROM $table_name WHERE member_id = %d”, $member_id),
ARRAY_A
);

if (!$member) {
return;
}

$body = “Member profile updated.\n\nFull Details:\n\n”;

foreach ($member as $key => $value) {
$body .= $key . ” => ” . $value . “\n”;
}

wp_mail(
get_option(‘admin_email’),
‘Member Profile Updated’,
$body
);
}

This will send the complete member record instead of just the edited fields.

[The Assurer]

The “Deliver to billing address” option at the bottom of the PayPal Debit or Credit Card form is part of PayPal’s hosted checkout page — not something generated or controlled by the Simple Membership plugin.

When you use a PayPal button created via Simple Membership, the plugin simply redirects the user to PayPal. The entire card form (including: “Pay with Debit or Credit Card” Address fields “Deliver to billing address” checkbox) is rendered directly by PayPal on their servers.

Can it be removed?
Unfortunately, no — this cannot be removed or modified from within the Simple Membership plugin. PayPal controls the layout, the form fields, rhe wording, the checkbox behavior.

We don’t have an API option or setting in the plugin that allows removal of that checkbox.

[The Assurer]

Since Stripe renewal notification emails are working correctly, that tells us a few important things:
✅ Your WordPress email sending is working.
✅ The Simple Membership plugin email system is functioning.
✅ Your server can send renewal emails properly.

So this issue is almost certainly related specifically to the PayPal subscription renewal notification process.
Let’s go through this step-by-step.

1️⃣ Confirm PayPal IPN (Not Just Webhook)
For PayPal subscription renewals, the plugin relies on PayPal IPN (Instant Payment Notification) — not webhooks.
Even if other PayPal emails are arriving, renewal processing depends on IPN correctly sending the subscr_payment event back to your site.
Please check:
PayPal Account → Settings → Website Payments → Instant Payment Notifications
Make sure:
IPN is enabled
The IPN URL is set to:
https://yoursite.com/?swpm_process_ipn=1
(Replace yoursite.com with your actual domain.)

2️⃣ Enable Debug Logging (Very Important)
This will tell us whether PayPal is even notifying your site.
Please follow this guide:
👉 https://simple-membership-plugin.com/enable-debug-logging/
Then:
Wait for a renewal payment to occur.
Check the debug log file.
Look for:
IPN received
subscr_payment
Any errors related to PayPal
If nothing appears in the log during renewal, then PayPal is not notifying your site.

3️⃣ Check the Subscription Type
Important question:
Are you using a PayPal subscription button created via the Simple Membership plugin?
Or was the subscription created directly inside PayPal?
The plugin must create the subscription button so it can track the subscription reference properly.
If the subscription was created manually in PayPal, renewal emails will not be triggered by the plugin.

4️⃣ Confirm the Email Settings
Go to:
WP Admin → WP Membership → Settings → Email Settings

Check:
Is “Send Notification to Member on Account Renewal” enabled?
Is the renewal email template configured properly?
Since Stripe works, this is likely correct — but good to double check.

4️⃣ Confirm the Email Settings
Go to:
WP Admin → WP Membership → Settings → Email Settings
Check:
Is “Send Notification to Member on Account Renewal” enabled?
Is the renewal email template configured properly?
Since Stripe works, this is likely correct — but good to double check.

5️⃣ Common Cause: PayPal Renewal Not Linked to Member Record
Sometimes renewals fail to send emails because:
The subscription reference is missing
The member record cannot be matched
The renewal becomes an “orphaned” subscription
If you see messages like:
Could not find member record for this subscription
Then this guide will help:
https://simple-membership-plugin.com/subscription-payment-troubleshooting-orphaned-subscription-management/

[Author]

Posts