|
|
Thanks, Bruce. Just edited and updated my post!
|
|
|
Hi Hamid,
Users don’t need to create a PayPal account to pay with credit card (edit: unless you have a subscription-based model as Bruce points out below, then they would need a PayPal account).
PayPal Standard checkout presents the customer with an option to pay with PayPal or to enter a credit card (without needing a PayPal account).
It’s not the ideal solution (vs having forms on your own site), but it works.
Frank
-
This reply was modified 4 years, 1 month ago by
 Frank.
|
|
|
Makes sense. The only reason I said I would ignore it for now is because most of my content isn’t even accessible to not-logged-in members, and there’s really only one page that non-logged-in members would be accessing (for now). Once I add more public static content, I’ll definitely cache all that stuff.
|
|
|
Thanks a ton, Bruce. Very helpful advice.
I think in my case, it would simply be a matter of removing the account info widget (and relocating the info to a non-cached page), and removing the s2 conditional short codes (and figuring out a static way to accomplish what I used the short codes to accomplish).
|
|
|
OK, that’s what I figured. Sounds like I’m not going to bother with caching at all then for now.
I wouldn’t want to include /members/ because that includes the very content I want to cache – static content (for the most part) that all members should have access to.
Is it not normal then to setup caching for the content behind the login wall? Seems like I’m outside the norm with what I want to do. What about membership sites that have a ton of protected static content, and a ton of active visitors bouncing around between that content? Would caching make sense for them?
I guess I’m just trying to understand why caching is turned off by default for logged in users, among other things.
|
|
|
Hi Bruce,
Thanks!
Yea, perhaps I’ll just remove that login/account info widget from the sidebar and make a separate page for account info then (and just exclude that page from caching as you suggest).
I would just add that page I want to exclude to the No-Cache URI Patterns Box in Quick Cache, correct?
http://www.examplesite.com/members/account-info -> put in /members/account-info in the No-Cache URI Patterns box?
Also, what if I use s2 conditional short codes throughout some of the logged-in content? Will caching mess that up as well? For example, I use s2 conditional short codes to display certain messages to certain levels of members, while hiding that message from other levels of members.
Thanks a bunch,
Frank
|
|
|
Thanks, Bruce.
Bummer, I do have a sidebar that shows the user’s name, and a link to modify their profile.
|
|
|
Forgive my ignorance on this, but my thinking is that if a membership website (with lots of content) has a bunch of members who are logged in all at once, then caching would be useful for increasing performance (and decreasing the load on the server/database).
I just installed Quick Cache, so if you could provide recommended settings to get protected content cached (but still protected), it would be much appreciated!
Thanks again,
Frank
|
|
|
Hi Bruce,
That sounds about right.
Will I be able to cache protected areas of the site with Quick Cache though?
Thanks!
Frank
-
This reply was modified 4 years, 1 month ago by Frank.
|
|
|
Can you guys please send an email notification to existing customers once Stripe integration / the new version of S2Member comes out? I started the PCI compliance process for using PayPal Pro, but do not want to be involved with that process at all if Stripe is an option.
|
|
|
So, it “works” but it’s going to be super confusing to users. The pro form loads, says “we accept paypal” above the payment options, and everything (visa, mc, etc.) is grayed out except for paypal. In other words, it will make people think they need a paypal account to checkout. When in reality, they can enter their cc on the next page via paypal.
|
|
|
Christian,
It’s for any payment processing where financial details pass through your servers. If you use PayPal Pro + Pro Forms, if I’m not mistaken, credit card details make their way through your site’s servers on their way to PayPal’s for processing.
But regardless, I just checked the Pro Forms section of s2member and noticed that Pro Forms can be integrated with PayPal express checkout.
And you’re exactly right there with that last tip. Thanks for pointing that out! I’m going to try this, as it might be a good interim solution!
Thanks,
Frank
|
|
|
Hi Christian,
If I understand you correctly, that’s pretty much what I initially set out to do. I think that only works with PayPal Pro though. I’m assuming the OP wants a solution that uses PayPal Standard.
The reason I started looking into the PayPal buttons via PayPal Standard instead of the Pro Forms route was because I found out that I would have to handle PCI compliance on my site (about $500 per year) if I went the PayPal Pro + Pro Forms route.
Thanks for the ideas!
Frank
|
|
|
Christian, I have s2member pro, but I’m not sure how the pro forms would help in this specific situation. Could you explain a little further? Thanks!!
Edit: I understand that it could help if you went the PayPal Pro route (because you could just use your own normal button to link to your pro form checkout page), but I don’t understand how it could help if you try to go the PayPal Standard button checkout route.
-
This reply was modified 4 years, 1 month ago by Frank.
|
|
|
I’m having the same issue here, and agree with Craig that it’s not ideal (for conversion rates and convenience to the user mainly) to send the user to another page just to click a pay button there.
|
Pre-Sale FAQs
Video Tutorials
Community Forum
Knowledge Base
News/Updates
s2 Codex / Docs
GPL v2 License
Contact A Human
About Us
Our Customers
Support Policy
Privacy Policy
Old Forums (READ-ONLY): The 
