[The Assurer]

You need to manually update the “Access Starts” date to the start of when the new subscription begins.

* When the user is assigned the new membership level, edit their member profile in wp-admin.

* Change the “Access Starts” date to the current date (or whatever date you want the new membership to begin).

* Ensure the membership level has the correct “Expire After” / “Duration” setting (e.g. 1 year) so that the expiry is computed from that start date.

* Save. The plugin should then compute the expiration date as (new “access starts”) + (membership duration).

[The Assurer]

No, it is not. The email addresses are checked against the WP User table.

[The Assurer]

Please restate or rephrase your question with example (if possible) so I can understand it better.

[The Assurer]

You have already tried customizing the Partial Protection Addon messages?
https://simple-membership-plugin.com/apply-partial-section-protection/

So… what you are asking for is to define these customized messages with some kind of global message variable?

[The Assurer]

About two weeks ago (same time the plugin shows an update)…

The plugin does not automatically update (unless you configure WordPress to do that). Please ensure that you are using a copy that was downloaded from the official site.
https://downloads.wordpress.org/plugin/simple-membership.zip

Also are you using any page caching plugins or server modules?
https://simple-membership-plugin.com/understanding-the-impact-of-caching-on-membership-sites/

[The Assurer]

By default, the Simple Membership login form uses a standard WordPress form submission. That’s why when a login attempt fails, the page refreshes and you only see the error message after the reload.

Unfortunately, the plugin does not currently support AJAX-based login submissions out of the box. That’s why when you put the login form inside a modal, failed login attempts force the modal to close, requiring users to reopen it.

Your best option is to open a paid support ticket.
https://simple-membership-plugin.com/paid-support-simple-membership-plugin/

[The Assurer]

Since you used the term 501(c) I’m assuming you are based in the US. Please contact Stripe directly to determine if there is a “magic switch” they have to turn on, or if there is other account related things that we have no control over.

I believe you can use WooCommerce (via the WooCommerce Integration Addon, a premium extension). You can set up a membership product with variable pricing (a donation-like option) in WooCommerce. That could mimic a donation flow. But these features—variable pricing and subscriptions—require paid WooCommerce extensions. However, you would still be subject to regular Stripe fees.

[The Assurer]

Unless you are an organization that is recognized by your country’s taxing authority as a charitable organization; Stripe does not support donations.
https://support.stripe.com/questions/requirements-for-accepting-tips-or-donations

[The Assurer]

Perhaps you are looking for a plugin like this?
https://wordpress.org/plugins/shortcode-variables/

[The Assurer]

To receive support for a premium addon, please open a Premium Addon Support ticket and a developer will contact you:
https://simple-membership-plugin.com/premium-addon-support/

[The Assurer]

Here’s what’s going on and why you’re seeing mixed results:

### Why Some Members Show as Active and Others Expired

1. **Expiry Date Handling (Time of Day Factor)**
The Simple Membership plugin checks expiry dates at the **server’s timezone**, not your local timezone.

* If your server is set to a different timezone (e.g., UTC instead of your local time), some members’ accounts may not be marked expired until later.
* This explains why on September 1st some still show as “Active.”

2. **Member-Specific Expiry Dates**
Even if you set the level to expire on 31/08/2025, members may have slightly different expiry dates depending on how they were registered or renewed (e.g., some might have an expiry of 2025-08-31 23:59:59, others 2025-08-30 or 2025-09-01). A quick check of their profile expiry date in **WP Admin → Simple Membership → Members** will confirm.

3. **Caching**
Sometimes cached pages display old status (especially around login). If you’re using a caching plugin or your host has aggressive server caching, one member might see “Expired” while another still sees “Active” until the cache clears.

—

### Why Expired Members Can’t Log In

You mentioned you have it set so expired members can still log in and pay. There are two relevant settings:

* Go to **WP Admin → Simple Membership → Settings → General Settings**

* ✅ Ensure “Allow Expired Members to Login” is enabled.
* Go to **WP Admin → Simple Membership → Settings → Advanced Settings**

* Check that “Disable Expired Members Login” is not enabled.

If both are correct but some still can’t log in, it’s usually:

* A **caching issue** (login redirect is cached), or
* A **conflict with another plugin** (security, redirection, or caching plugins often cause this).

—

### Immediate Steps You Can Take

1. **Verify expiry dates directly**: Check a couple of members who still show “Active” in **Members → Edit Member**. Confirm what expiry date is stored there.
2. **Check your server timezone**: In **WordPress → Settings → General → Timezone**, make sure it matches your local time.
3. **Clear cache**: If you use a caching plugin (WP Rocket, LiteSpeed, etc.), follow the compatibility guides here:

* [Understanding caching issues](https://simple-membership-plugin.com/understanding-the-impact-of-caching-on-membership-sites/)
* [WP Rocket guide](https://simple-membership-plugin.com/wp-rocket-cache-compatibility-for-simple-membership/)
4. **Test login**: Use a test expired member account and confirm you can log in and see the renewal option.

—

✅ By tomorrow, all accounts *should* show as expired, but if your server timezone is behind yours, there may still be a mismatch until the date rolls over fully.

[The Assurer]

Here’s the situation:

The Simple Membership plugin itself doesn’t have any built-in feature to automatically assign all existing protected content (like downloads from WP Download Manager Pro) to a new membership level. By default, you need to go into each protected post/file and assign the new level manually.

The integration with WP Download Manager Pro is essentially done via WordPress post-level protection (since downloads are stored as custom post types). That’s why the membership restrictions have to be applied per item.

Some versions of WP Download Manager allow bulk-editing of access settings. If you can bulk-edit and add the new membership level restriction to all downloads at once, that may solve the problem without touching code.
https://www.wpdownloadmanager.com/support/topic/bulk-change-downloads-page-template/

[The Assurer]

I see what you’re running into 👍 — this is a **known limitation when using social login plugins like Nextend or Super Socializer with Simple Membership (SMP)**.

Here’s why it happens:

* When someone registers via Nextend Social Login, WordPress creates the **WP user account**, but SMP doesn’t automatically know which **membership level** to assign unless the registration goes through SMP’s own process (via its registration form or API).
* That’s why in your **admin dashboard**, you see the user, but they don’t actually have working access on the front-end — the SMP side of things hasn’t been linked correctly.

### Possible Fixes

1. **Check Membership Level Assignment**

* After social registration, make sure the user has an SMP membership level assigned (via **WP Admin → Simple Membership → Members**).
* Sometimes the account exists but without an active level → so access is denied.

2. **Auto-Sync Custom Code (for developers)**

* Since SMP doesn’t have direct integration with Nextend or Super Socializer, you need to **hook into the social login process** and assign a membership level programmatically.
* Example: Using the user_register hook in WordPress, you can call SwpmMemberUtils::create_member_entry() to ensure the SMP record is created.

3. **Alternative Recommendation (Officially Supported)**

* The SMP team officially recommends using their **own registration system** or integrating with **WooCommerce** for complex login/registration needs (since WooCommerce → SMP sync is officially supported).
* Docs: [WooCommerce Integration](https://simple-membership-plugin.com/woocommerce-simple-membership-plugin-integration/)

4. **Debug Conflicts**

* Sometimes the social login plugin interferes with how SMP checks sessions. If caching or redirects are in play, you might see “access shown in admin but not working on site.”
* See caching doc: [Understanding Caching Issues](https://simple-membership-plugin.com/understanding-the-impact-of-caching-on-membership-sites/)

—

👉 Since you mentioned you’re **forced to use SMP (ThemeForest requirement)** and already bought Nextend, the practical path is to have one of your developers to add a **small code snippet** to bridge the two.

[The Assurer]

Thanks for sharing the error details. The message

Uncaught (in promise) TypeError: Cannot read properties of null (reading ‘setAttribute’)

suggests that the Stripe subscription button script is trying to find a form element but is not able to (it returns null). This usually happens after an update if:

1. The Stripe subscription shortcode/button HTML is being altered by your theme or a page builder (extra wrappers, missing IDs, or stripped attributes).
   → Please double-check the page in the WordPress editor to make sure only the shortcode is there and that no hidden pre or <div> tags are wrapping it.
2. Theme or plugin conflict is interfering with Stripe’s JavaScript.
   → The plugin team has seen this with some themes (e.g. Divi’s Defer jQuery option breaks the Stripe button). If you are using Divi, disable Defer jQuery under performance settings.
   → If not using Divi, the same issue may still happen if another optimization/caching plugin is deferring or combining scripts.
3. Cache/minification is preventing the Stripe script from attaching to the form.
   → Try excluding the Stripe-related scripts from minification/caching.
   → Or temporarily disable your cache/optimization plugin and test again.
4. Webhook or configuration mismatch is not usually the cause of a JavaScript error, but if you recently changed your setup, it’s still worth verifying that your Stripe webhook is correctly configured.

✅ What to try first:

• Inspect the HTML on the membership join page and see if the subscription form is present in the DOM. If it’s missing, your shortcode might be wrapped/stripped.
• Temporarily switch to a default theme (like Twenty Twenty-Five) with only Simple Membership active. If the button works there, then it’s a conflict with your theme or another plugin.
• If you are using Divi, disable Defer jQuery.

👉 Could you also share:
The shortcode you’re using for the Stripe subscription button.

[The Assurer]

Hi there! It looks like you’re running into a known limitation of how the free Custom Messages and Full Page Protection add-ons interact in the Simple Membership Plugin. Here’s what’s happening—and how you can address it.

What’s Going On

By design, when both the Custom Messages Addon and Full Page Protection Addon are active, both messages appear because the custom message replaces only parts of the output, but the full page protection’s default message still renders as well
Membership Plugin
WordPress.org

From a support thread:

“If you use the custom messages addon to override the standard protection message of the plugin then the login addon can’t add the extra parameter … You can’t get both.”
Membership Plugin

While that comment specifically referred to compatibility with the After Login Redirection add-on, the same principle applies here. Essentially, the replacement performed by the Custom Messages addon doesn’t fully suppress or replace the default output of the Full Page Protection addon, so you end up with both messages stacking.

What You Can Try
Option 1: Use Only One Addon

* Remove or deactivate one of the add-ons to avoid duplicate messaging. If you’re aiming for a customized, clean message experience, prioritize the Custom Messages Addon and deactivate Full Page Protection.

* Or, vice versa, rely solely on Full Page Protection’s default message and disable the custom one.

Option 2: Customize via CSS

If you’re comfortable with CSS, you can hide the default message by targeting its class or wrapping element. For example:

/* Example CSS: adjust class name as needed */
.swpm-fullpage-protection-msg {
display: none !important;
}

This will hide the message output by Full Page Protection and only show your custom one. Be sure to inspect the page (using browser dev tools) to identify the exact CSS class being used.

Option 3: Override Templates or Hooks (Advanced)

If you’re a developer or comfortable with code:

1. Look for filters or template files in the plugin or the Full Page Protection add-on that output the default message.
2. Override or remove that part using your theme’s functions.php (e.g., by removing action hooks or adjusting logic).
3. This approach gives you full control—though it’s more technical and requires familiarity with the plugin’s structure.

Recommendation
If your priority is to display only your custom message, the quickest route is either to deactivate Full Page Protection and rely entirely on the Custom Messages Addon—or to use CSS to hide the unwanted duplicate. For full control, diving into hooks or templates is the most flexible (though advanced) solution.

[Author]

Posts