Forum Replies Created
-
Posts
-
The Show Member Info shortcode is designed to show a message when nobody is logged in. To hide those fields completely from visitors, you can try the following:
Wrap them in the section protection shortcode from our free Partial Protection addon.
Install and activate the addon:
https://simple-membership-plugin.com/apply-partial-section-protection/Wrap your member info shortcodes like this:
[swpm_protected visible_to="logged_in_users_only" do_not_show_protected_msg="1"] Email: [swpm_show_member_info column="email"] Account Status: [swpm_show_member_info column="account_state"] Expiry Date: [swpm_show_member_info column="expiry_date"] Membership Level: [swpm_show_member_info column="membership_level_name"] [/swpm_protected]With this, visitors who are not logged in won’t see anything in that area: no labels, no message, and no empty space. Once a member logs in, the information appears.
As before, please type or paste the shortcode in a Shortcode block (or the Text tab of the classic editor) so the quotes stay straight.
This is most likely a copy-and-paste formatting issue. When shortcodes are copied from the forum, the straight double quotes (“) often get converted into curly quotes (” or “). The shortcode then can’t recognise the field name, so it outputs nothing when you are logged in.
Please delete the existing shortcodes and type them again manually using straight quotes. For example:
[swpm_show_member_info column="email"] [swpm_show_member_info column="account_state"] [swpm_show_member_info column="expiry_date"] [swpm_show_member_info column="membership_level_name"]If you use the block editor, add them inside a Shortcode block. If you use the classic editor, paste them while in the Text tab, not the Visual tab. This keeps the quotes from being reformatted.
The addon documentation also has a tip about this:
https://simple-membership-plugin.com/simple-membership-addon-show-member-info/#tip-for-copying-and-pasting-the-shortcodeIf it still shows empty after that, please let me know the following:
1) Whether the logged-in account is an actual member account (not just a WordPress admin user without a member record).
2) Whether you use any caching plugin. If you do, try excluding that page from caching.
https://simple-membership-plugin.com/understanding-the-impact-of-caching-on-membership-sites/The [swpm_show_expiry_date] shortcode doesn’t currently have an option to change the date that way. It shows the expiry date in the format set under Settings -> General -> Date Format, but it can’t move it to the previous day or add a time.
We’ve added two new filter hooks to this shortcode, and they will be included in the next release of the plugin (v4.8.4). Once you’ve updated, you can add the following code to show the expiry date as the previous day at 11:59pm:
add_filter( 'swpm_show_expiry_date_value', function( $expiry_date, $expiry_timestamp ) { if ( $expiry_timestamp == PHP_INT_MAX ) { return $expiry_date; // No expiry. } return date_i18n( 'F j, Y', $expiry_timestamp - DAY_IN_SECONDS ) . ' at 11:59pm'; }, 10, 2 );You can add it using a plugin like Code Snippets, or in your child theme’s functions.php file. For example, an expiry date of September 6, 2026 will then show as “September 5, 2026 at 11:59pm”.
Please note this code will only work after you update to the new version v4.8.4. I am aiming to release this version within the next few days.
If you want to show individual details of the logged-in member (instead of the combined block shown by the login form), you can use the Show Member Info addon. It gives you a shortcode that outputs one field at a time, for example:
[swpm_show_member_info column=”email”]
[swpm_show_member_info column=”account_state”]
[swpm_show_member_info column=”expiry_date”]
[swpm_show_member_info column=”membership_level_name”]You can place each one anywhere on a page. The full list of supported fields is on the addon page:
https://simple-membership-plugin.com/simple-membership-addon-show-member-info/For the expiry date only, the core plugin also has this shortcode:
[swpm_show_expiry_date]
If you need the data in custom PHP code instead, you can use:
if ( SwpmMemberUtils::is_member_logged_in() ) { $member_id = SwpmMemberUtils::get_logged_in_members_id(); $email = SwpmMemberUtils::get_member_field_by_id( $member_id, 'email' ); }If I’ve misunderstood what you’re trying to do, please give a little more detail on where you want this information to appear or be used.
Why no email is sent when the account is created at checkout
When the account is created on the WooCommerce checkout page, WooCommerce creates it as a WordPress user, not through our registration form. Our plugin then creates the matching member record automatically, using the “Enable Auto Create Member Accounts” option. That automatic step doesn’t send an email. The Simple Membership registration email only goes out when someone submits our registration form (the [swpm_registration_form] shortcode) or completes their registration through the completion link.
So in this setup, the welcome email at account creation comes from WooCommerce. Go to WooCommerce > Settings > Emails and make sure the New account email is enabled. Once payment is confirmed, the member then gets our upgrade email.
If you want the Simple Membership registration email instead, have users sign up with our registration form before they go to checkout.
Password reset tag
There’s a {password_reset_link} tag, but it only works in the password reset email, because that’s the only time a reset key is generated. In any other email it will be empty.
In the upgrade email, just add your password reset page URL as plain text. For example:
Forgot your password? Reset it here: https://yourdomain.com/membership-login/password-reset/You can copy the exact URL from the Password Reset Page URL field in WP Membership > Settings > General Settings.
Hi Carlos,
Short answer first: there’s no change in 4.8.3 that touches wp-admin session or cookie validation, so rolling back to 4.8.2 probably won’t help you. Your isolation result is still real though, and I can point you at the exact code in the plugin that’s capable of producing reauth=1, plus why one of your own troubleshooting steps may have made it worse.
On 4.8.3
I went through the full 4.8.2 to 4.8.3 diff before replying. The changes are Stripe/PayPal IPN handling and payment button ID validation, annual fixed-date expiry calculation, some new opt-in subscription renewal email settings, the login event auto-prune window, and moving the auto-login-after-registration handler out of init. None of it calls into WordPress’s auth cookie or session APIs. You read the changelog correctly. We also have no other reports of this from Hostinger or LiteSpeed users.
How the plugin can still cause it
There are three code paths in Simple Membership that call wp_destroy_current_session() and wp_clear_auth_cookie(). They all run on init or wp_loaded, which fire before auth_redirect() in wp-admin. So if one of them triggers, WordPress’s session token check fails milliseconds later in the same request, and you get bounced to wp-login.php?…&reauth=1. That’s exactly your symptom, and it’s why deactivating the plugin makes wp-admin stable.
The most likely of the three is our cookie integrity check. Our auth cookie’s HMAC is derived from your AUTH_KEY and AUTH_SALT values. You mentioned regenerating the salts in wp-config.php as one of your fix attempts, and that invalidates every Simple Membership cookie already sitting in a browser. Our code reacts to a failed check by clearing the WordPress session too. If the stale cookie then doesn’t get removed cleanly (which happens when COOKIE_DOMAIN or COOKIEPATH don’t match whatever originally set it, www vs non-www being the usual culprit), it keeps re-triggering on every request. It’s possible the salt regeneration turned an intermittent problem into a permanent one.
One thing I’d gently push back on: “the public site works” doesn’t actually clear the cookie layer. reauth=1 means auth_redirect() rejected the wordpress_[hash] / wordpress_sec_[hash] cookie, and that one is scoped to /wp-admin. The logged_in cookie at path / can be completely valid at the same time, which is why your front end behaves normally. That also means object caching of the session_tokens user meta isn’t fully ruled out by the tests you ran, even though I agree you’ve been thorough with LiteSpeed.
What would settle this
#1) Clear all cookies for guiacepa.com in your test browser, both www and non-www. This is necessary after a salt change regardless, and it might be the whole fix.
#2) Turn on our auth debug log: WP Membership, Settings, Advanced Settings, “Enable Debug”. Reactivate the plugin, reproduce the logout, then check the wp-content/plugins/simple-membership/log-auth-*.txt. If it shows Validate() function – Bad hash or Active login limit feature – login session token expired at the time of the logout, that narrows it to one specific branch.
#3) Log the WordPress side too. Drop this into wp-content/mu-plugins/auth-debug.php, reproduce, and send the matching lines from your PHP error log:
<?php add_action('auth_cookie_bad_hash', function($c){ error_log('SWPM-DBG bad_hash '.print_r($c,true)); }); add_action('auth_cookie_bad_session_token', function($c){ error_log('SWPM-DBG bad_session_token '.print_r($c,true)); }); add_action('auth_cookie_expired', function($c){ error_log('SWPM-DBG expired '.print_r($c,true)); }); add_action('clear_auth_cookie', function(){ error_log('SWPM-DBG clear_auth_cookie '.wp_debug_backtrace_summary()); });bad_session_token means something destroyed the session. bad_hash points at salts or a cookie scope mismatch. And the clear_auth_cookie backtrace will name the function responsible outright, so if it’s our code, our file will be right there in the trace.
#4) Check three settings under Advanced Settings and tell me whether each is on or off: “Force WP User Synchronization”, “Enable Active Login Limit”, and “Disable Access to WP Dashboard”. All three interact with session handling.
#5) Is your admin WordPress account also a member record? Check for the same username or the same email address under WP Membership, Members. If it is, that links the two session systems together and makes the paths above reachable for your admin user.
#6) Delete and reinstall Simple Membership 4.8.3 from scratch, rather than updating in place. Those 19 HTTP 500s bracketing the 21:39 update, plus Hostinger flagging the site as Inaccessible, look a lot like an interrupted or partially written update. A clean reinstall costs you nothing and rules it out. Your settings and member data live in the database, so nothing is lost.
#7) If you still have them, the PHP error log lines from 21:24 to 21:53 UTC on 2026-09-17 would be a very useful thing you could share with us.
If you’d rather keep the plugin deactivated while we work through this, that’s fine. Do steps 1 and 6 first, and just send the logs from step 2 or 3 if you can reproduce it once. With either log, I can tell you definitively whether this is our code or something in the environment, and if it’s ours, it goes into the next release.
Glad the account-first setup is working.
The empty password is expected. The plugin never stores passwords in readable form. When a user sets a password, it’s encrypted (hashed) right away.
#1) When the user completes registration via the link, the plugin sends the email at the moment the user submits the form. The password they just typed is still available, so the {password} tag gets filled in.
#2) When an existing member upgrades after payment, the account and password were created earlier. By the time the payment email goes out, the plugin only has the encrypted version, so there’s nothing it can put in the {password} tag.
There’s no safe way to show the password in that email. We recommend editing that email template (WP Membership -> Settings -> Email Settings) as follows:
Remove the {password} tag.
Remind the user to log in with the username and password they chose when they created their account.
Include the {login_link} tag, plus a link to your password reset page in case they forgot it.These users only just created their account at checkout, so they’ll normally know their password already.
Email settings documentation:
https://simple-membership-plugin.com/simple-membership-documentation/Glad the account-first setup is working.
The empty password is expected. The plugin never stores passwords in readable form. When a user sets a password, it’s encrypted (hashed) right away.
#1) When the user completes registration via the link, the plugin sends the email at the moment the user submits the form. The password they just typed is still available, so the {password} tag gets filled in.
#2) When an existing member upgrades after payment, the account and password were created earlier. By the time the payment email goes out, the plugin only has the encrypted version, so there’s nothing it can put in the {password} tag.
There’s no safe way to show the password in that email. We recommend editing that email template (WP Membership -> Settings -> Email Settings) as follows:
Remove the {password} tag.
Remind the user to log in with the username and password they chose when they created their account.
Include the {login_link} tag, plus a link to your password reset page in case they forgot it.These users only just created their account at checkout, so they’ll normally know their password already.
Email settings documentation:
https://simple-membership-plugin.com/simple-membership-documentation/The “page not found” error means the registration completion link is pointing to a page that doesn’t exist on your site. The plugin builds that link from the Registration Page URL value in the plugin settings. If the registration page was renamed, moved, deleted, or had its slug changed, and that setting wasn’t updated to match, every completion link will lead to a 404.
This also explains why the new link you generated from the Tools menu failed too. It’s built from the same setting.
Please do the following:
- Go to WP Membership -> Settings -> General Settings and find the Registration Page URL field.
- Copy that URL and open it in a browser. If it shows “page not found”, that’s the cause.
- Update the field with the correct URL of the page that contains the [swpm_registration_form] shortcode, then save.
- Check the other required page URLs in the same section (login, profile, password reset) while you’re there.
This guide explains how the required pages work and how to recreate them if needed:
https://simple-membership-plugin.com/recreating-required-pages-simple-membership-plugin/For customers who have already paid: the links they received by email contain the old, broken URL, so they won’t work even after the fix. Once the setting is corrected, go to WP Membership > Tools, generate a fresh registration completion link for each incomplete account, and send it to them.
To prevent this in the future: you can use a setup where users create their account first and then make the payment. That way nobody ever ends up in a state where they’ve paid but can’t finish setting up their account:
https://simple-membership-plugin.com/allowing-members-create-account-prior-completing-membership-payment/The account expiry value is stored and calculated as a date only, so there is no time value attached to it that the plugin can display. The date is formatted using your WordPress date format setting (Settings > General), which is why adding a time to that format would only ever show 12:00 am.
That said, what you want to display is accurate. Internally the membership is treated as expired from the start of the expiry date, so an expiry of September 28, 2026 means the member’s access ends at the end of September 27. If you want the account page to say it that way, you can override the template that renders it.
Copy the plugin’s views/loggedin.php file to your theme in the following location:
/wp-content/themes/your-child-theme/simple-membership/loggedin.phpThen in your copy, replace the line that outputs $auth->get_expire_date(); with something like this:
$member_id = SwpmMemberUtils::get_logged_in_members_id(); $expiry_ts = SwpmMemberUtils::get_expiry_date_timestamp_by_user_id( $member_id ); if ( $expiry_ts == PHP_INT_MAX ) { echo __( 'No Expiry', 'simple-membership' ); } else { echo date_i18n( 'F j, Y', $expiry_ts - DAY_IN_SECONDS ) . ', 11:59 pm'; }Adjust the date format string to suit. The template override is upgrade safe, so your customization will survive plugin updates. Note that this only changes the member account page. The expiry date shown in the admin member records and in email merge tags will still use the standard date.
Template customization documentation:
https://simple-membership-plugin.com/how-to-override-simple-membership-plugin-templates-in-your-theme/Good progress. The wp_set_current_user(0) line explains the logout problem, so that part is sorted.
The remaining -1 is a nonce failure, not a plugin bug. A -1 with a 403 from admin-ajax.php is WordPress’s response when nonce verification fails. If the action itself were missing you would get 0 instead.
WordPress nonces are tied to the current user ID and the current session token, not just the action name. So a nonce created while logged out (user ID 0) will fail once it is verified as a logged-in user, and a nonce created before a logout will fail after logging back in, because logout destroys the WordPress session token and the new login creates a different one.
Most likely cause: the nonce is going out inside a JS file or markup that is being cached in a different login state. Even without a caching plugin, JS minify/combine/optimise features (Autoptimize, LiteSpeed, SiteGround Optimizer, Jetpack Boost, Perfmatters, theme optimisers, CDN asset combining) will bake a stale nonce into a cached file. Turn all JS optimisation off and retest.
To confirm, log get_current_user_id() and wp_get_session_token() both where you create the nonce and at the start of your AJAX handler, then compare. Also check that your AJAX URL is built with admin_url(‘admin-ajax.php’) so the host and scheme match the page, otherwise the auth cookie is not sent and the request is evaluated as logged out.
Finally, a nonce is CSRF protection, not authentication. Keep the SwpmMemberUtils::is_member_logged_in() check for deciding what data to return, and register both wp_ajax_ and wp_ajax_nopriv_ handlers for your action.
The custom archive code is outside what we can support here, but this should be enough to track it down.
First, some context on that cookie.
swpm_sessionis not the login cookie. The plugin assigns every visitor a random session ID, and that ID is used only as a key for short-lived front-end status messages (registration errors, profile update confirmations, password reset notices). It expires when the browser closes and holds no member data.It is also only issued once per visit, not on every page. The Set-Cookie header goes out on the first request, and after that the cookie is simply present in each request. So what is slowing you down is the CDN treating any request that carries a cookie as uncacheable, rather than the plugin re-issuing it each time.
The cookie you actually want the cache to react to is
swpm_in_use(andwp_swpm_in_use). We set that one only when a member logs in, specifically so caching layers can bypass the cache for logged-in members while still serving cached pages to everyone else. Full cookie list here:
https://simple-membership-plugin.com/cookies-used-by-simple-membership-plugin/What I would recommend:
- Ask their support to ignore swpm_session in the StackCDN caching decision, and to bypass cache only when swpm_in_use, wp_swpm_in_use or wordpress_logged_in_* is present. This is the proper fix and it applies site-wide. StackCache itself has no cookie exclusion field, so this has to be done at the CDN/edge level.
- In StackCache > Cache Exclusion, exclude your membership pages: the login page, the join/registration page, the thank you page, and any member-only pages. Those should never be served from cache.
- Leave everything else cached as normal.
On “Remove All Cookies From My Homepage”: it only affects the homepage, so it will not solve the problem across the rest of your site. It is safe if your homepage is plain public content with no membership elements. Do not enable it if your homepage contains the login form or login widget, the registration form, or protected content, because stripping cookies from that response also strips the login cookies and the login will silently fail.
I would also leave “Remove PHP Session Cookies From All Pages” alone. That targets PHPSESSID, not our cookie, and it can break other plugins.
More background on caching and membership sites:
https://simple-membership-plugin.com/understanding-the-impact-of-caching-on-membership-sites/That message is shown on a browser or device that was logged out after the same account logged in elsewhere. The text is translatable, so you can change it using this technique:
https://simple-membership-plugin.com/customize-text-and-messages-using-the-translation-file/
