[TroyWolf]

It would be unfortunate if this page was not simply a “page” we can edit like any other. Hopefully we’ll get an official response here. 🙂

[TroyWolf]

I’m sorry, you made that clear, but I read it too quickly. 🙁

When you go to “Pages” in your controlpanel, do you see a page titled “Thank You”? Just edit it like any other page.

[TroyWolf]

I’m not an expert–a relatively new user myself, but try Admin Controlpanel:

WP Membership > Settings > Email Settings (tab)

[TroyWolf]

This reminds me of a thought I’ve had that might be useful. How about a Simple Membership “Protect Content Widget” that could be used in the Widgets section. It would be very simple and would have basically 2 options.

1. Require Login / Require NOT logged in
2. The content to protect.

The content to protect could be any bit of HTML or short code, etc. So for example, if you have a plugin that offers a short code to show some bit of content and you only want members to see that content, you would use the SWM Protect Content widget then put your short code into it.

Any reason this idea would not work? (I’m not a widget or WordPress expert.)

[TroyWolf]

My guess is that you will have to get your hands a little “dirty” with a PHP code tweak. The hardest part can be simply figuring out which PHP file is responsible for outputting that AVADA filter component/widget. Once you do, you can wrap it with a bit of code like this:

<?php if(SwpmMemberUtils::is_member_logged_in()) { ?>
    //AVADA filter output code here...
<?php } ?>

Here are some good snippets–which is where I stole the example above:
https://simple-membership-plugin.com/simple-membership-miscellaneous-php-tweaks/

[TroyWolf]

A little update — turns out I was right about SM update reverting my changes. After an SM plugin update, my changes to loggedin.php were gone. Very easy to fix, but just FYI for folks.

[TroyWolf]

As mbrsolution points out, we don’t know exactly what you are looking for, but one way to indicate to the user whether they are logged in or not is to use this shortcode in a “text” sidebar widget:

[swpm_login_form]

It shows the login form when not logged in AND it shows some member info when you are logged in.

For my taste, it showed too much info. I edited the PHP file that drives it to only show the user’s name and the logout link. I also made the name a link to the profile page. The file I edited is:
/wp-content/plugins/simple-membership/views/loggedin.php

[TroyWolf]

I am reporting that I have this same issue. I copied system to a sandbox (copied database, wordpress directory, and modified wp_options to change the site URL)

One by one I deactivated all my plugins. Each time I checked to see if my admin toolbar showed up. The very last plugin I had activated was “Simple WordPress Membership”. When I deactivated it, my admin toolbar showed up.

I re-activated Simple WordPress Membership, and my toolbar again went away when viewing the public site.

Note that in my profile, the entire time I had “Show toolbar when viewing site” checked (on).

THEN…I looked closer at my SWM settings and noticed these 2 options:

Hide Adminbar
Show Adminbar to Admin

I had the first checked and the second not checked. SO DUH! This overrides individual user profile settings for showing the toolbar.

I changed my config to check BOTH of those options, and now when I’m logged in as an admin, I see my toolbar.

@LaMpiR, is there any chance your issue is as simple as this?

[TroyWolf]

Some good points by @jscmal.

Even though a member signs up with an auto-renewing PayPal subscription, I still want the user to see their expiration date as 1 year out. That is what they have paid for so far. (Or 3 months for @jscmal’s site)

When the auto-renew happens, then yes, the expiration date should get bumped out a year.

Even more important to me, and as @jscmal points out, if a member cancels their subscription in PayPal, their membership should still be good until the expiration date. Cancelling a PayPal subscription is not the same thing as cancelling a membership in my website–and since there is no refund, the member should continue to enjoy the membership period they paid for. I think I’ve seen other support threads about this situation–that currently SM will cancel the membership if the subscription is cancelled. Is this correct?

Thanks!

[TroyWolf]

Usually for a subscription type payment you set the membership level setting to “No Expiry”. So as long as the payment keeps coming, the member’s account will be active. If the payment stops, the account gets blocked.

I am glad I read this. Like others, I have my expiry set to 1 year. My members pay via subscription that should auto-renew every year. I assumed this was the correct way to set it up–so it will expire if the payment fails for whatever reason.

Instead, you are saying we should set our memberships to No Expiry and trust that the system will block the account if the annual renewal payment fails. Correct?

[TroyWolf]

Excellent. I assume you addressed last_accessed_from_ip at the same time. I found this value was not always stored–same issue as last_accessed.

Thanks!

[TroyWolf]

Hmmm, I did my best to interpret his somewhat cryptic post!

What you describe–adding PayPal links (or buttons) in a table, wouldn’t you just log into your PayPal account, create the button or link, then copy the code it gives you and paste into your WordPress page? Simple Membership wouldn’t play any part in it.

[TroyWolf]

@simatecve, If you want a standard link instead of a button, I just tested this solution and it works. Use the SM form shortcode like you normally would, then add a bit of CSS to hide the button that is part of the form. Then create a link that will submit the form when clicked.

Here is one way to do it. This is what you’d put in any page where you want the “join” link. Of course your ID will be different–so don’t copy this verbatim–use your own SM form shortcode.

[swpm_payment_button id=643 button_text="Join Now"]
<style>
.swpm-subscription-button-submit { display: none !important; }
</style>
<a href="#" onclick="document.forms[0].submit()">Click here to join</a>

Notice the forms[0] part above. This will submit the first form on the page (hidden or not). If you have other forms on the page ahead of this one, you may need to change this to forms[1] or [2]–you get the idea.

Alternatively you could use a selector to find the submit button using the classname, then click() it. Here is a jquery option:

<a href="#" onclick="jQuery('.swpm-subscription-button-submit')[0].click()">Click here to join</a>

Of course you’ll need to use the raw text editor for the page to add this snippet instead of the Visual editor.

[TroyWolf]

@ravisojitra,

The original post from @admin is excellent. Unfortunately, there are always more hoops being added into the mix if you want to send mail from your server. You have to worry about things like reverse DNS, SPX records, authorized MX records for your domain, etc. Sometimes your hosting platform restricts your ability to send SMTP directly from your server. Sometimes your server/droplet/ec2 instance/whatever doesn’t come with an SMTP service installed–leaving you to install and configure an SMTP service.

I’m going to share the secret I’ve discovered that has eliminated all my mail sending challenges.

First, like @admin shared, install an SMTP sending plugin. He suggested easy-wp-smtp:
https://wordpress.org/plugins/easy-wp-smtp/

I’m sure any SMTP plugin will do.

This adds SMTP options to the WordPress Settings menu item.

And here is the secret sauce. Simply use the Mailgun service from Rackspace as your SMTP server. It is free to create an account and free to send mail up to 10,000 messages per month. Most folks are going to fall WAY under that limit. If you need to send more than 10,000 messages per month, well maybe it’s worthwhile to pony up the low fees.

Mailgun’s SMTP is extremely fast, reliable, and the best part, you can log into your Mailgun Dashboard and look at your sending logs. If there is a problem sending the message, it’s right there in the log. You can look at stats that show you how many messages have failed, etc.

You do need to follow the Mailgun instructions very closely to configure your DNS to allow Mailgun mail servers to have authority to send mail on your behalf. The instructions they provide are very clear. In fact, if you want to use your own SMTP, these instructions might help you understand the bits you need to configure to get your own mail sending working.

I use Mailgun SMTP for all my WordPress and phpBB systems. If you are a developer, you can actually send mail using the Mailgun API instead of standard SMTP. It’s lightning fast and you get feedback on the success of your sending.

[TroyWolf]

Thanks. I understand now. As I look closer at the “Show Member Info” plugin, I now notice that it does not include last_accessed as one of the available fields. (last_accessed_from_ip, but not last_accessed time)

So perhaps it’s known by the developers that this columns is not to be trusted.

HOWEVER, last_accessed time was stored for one of my members! I’d think it either works or is doesn’t!

ALSO NOTE — I now see a similar problem pattern with last_accessed_from_ip. Only 3 of my 8 members have a last_accessed_from_ip set. At least 2 of these that are missing the value I KNOW have logged in to the system.

I hope some others are willing to check their table to see if they see similar issue.

mysql> select user_name, last_accessed, last_accessed_from_ip from wp_swpm_members_tbl;

[Author]

Posts