S2 Button code suddenly not working with PayPal

I don’t know either, I hope he’s ok. Sometimes people struggle with personal problems and get overwhelmed, I guess?

I did the best I could, including a couple of donations towards the project.

I didn’t have enough time to invest learning PHP, but I considered it, that would be helpful one way or another, maybe sometime in the future.

Meanwhile I am just using “dumb” buttons created by PayPal, then I manually update each profile and upgrade each user. Can’t use PayPal for new subscribers that are registering, they must use Stripe or register as free users and upgrade later.

That’s the advantage of having a very tiny micro website, I guess? I’d have moved on or learned how to fix it if I had enough flow, but as it’s not the case I just do things manually. :grimacing:

Thankfully PayPal still works for me, but I think it’s because I pay the monthly PayPal fee and I only sell one-time memberships.

BUT… if PayPal suddenly stops working, I’m gone. While I hate the thought of having to learn a new plugin and migrate my members, I need to earn money, and there is no indication that s2Member will ever be upgraded.

no, I have no affilation with them except using their services for invoices. Actually if you know any other service that does this reliably for cheaper (OSS is all I need) I’m very interested, as their services are really not cheap (and as I used it until 1.5 months behind s2 IPN, and only if s2 successfully handled the IPN it would be forwarded - I on one hand had to write quite a few invoices manually, on the other hand would very easily see all the s2 malfunctions as no invoice (I queried it with a database vs paypal/stripe transaction lists) meant s2 had bugged something up beforehand. So that way I noticed all those signup_vars problems - it was always signup_vars never any other error - and clavaque hasn’t ever found the error for most of those problems if I forwarded him all the logs - signup_vars is the huge dirty blackbox of s2member.

For me my own paypal button still works as usual - just without encryption. But the problem is that 1 out of ever 200-300 payments ends up in s2member signup_vars nirvana. Meanin customer pays, and either cannot create an account or doesn’t receive the notifcation emails from s2 (or some other bug like can register but will see a huge error notice).

The problem is not using another plugin, the problem is another plugin correctly handling your old customers on recurring payments. It should be much better now as IPN is phased out and plugins can integrate directly into paypal via API - but not sure which membership plugin makes use of that already. But if it’s possible to create invoices, cancel invoices and get all the relevant data via API (for Stripe that’s possible since the start, for paypal I think since 2 years or so) than it makes it much easier. The IPN and forwarding it for other services or websites/domains or similar is just too limited.

The big question is - what is absolutely in need of modernization in s2, and how much will it cost to have a good developer change it? I guess maybe 10.000€ for 1. and 2.
In my eyes s2member needs to be changed

  1. to never look at signup_vars anymore, and only on the fields that are actually visible in the profile.

  2. Move paypal from IPN to API.

  3. optional - make it possible to use wocommerce or similar as a frontend for s2member. Keep s2member only for content protection. I think this is much more difficult so would be many many more hours to code.

It will be a lot cheaper if we do 1&2. via a group spending effort than even 1/3 of s2 users moving away to another platform and migrating.

So we pay someone to upgrade s2Member, and then what? Give the upgraded version we all paid for to @clavaque? Pretty sure we can’t just modify s2Member and distribute it ourselves.

I think this is something Cristian needs to do. It’s his plugin. If he wants to continue to sell it, he needs to invest in it.

1 Like

We cannot modify s2member pro, but s2member we can modify and either Christian gives the okay and takes over the modified version - or we use another name. Besides the name it’s okay to resuse s2member (non pro) and distribute it in a modified version.
I don’t see a better way. And both points - stopping all that signup_vars messing around and moving paypal to API are absolutely essential. Especially as a lot of follow up problems are caused by the signup_vars mess (e.g - if you create a new user by hand and mess it up, especially by inserting domain into the wrong field).

I’m willing to chop in 1000€ if both those points are solved. 2000€ should we need to spend over 20.000€ for a programmer to solve this mess.

Would be nice to hear from @clavaque on this issue. If he’s working on this, tell us. And if he’s not, tell us.

1 Like

We can find a much cheaper programmer than that if a student or someone in our community does it. Or maybe someone on Fiverr. It would be important to know what @clavaque is struggling with so we can perhaps focus on that.

I don’t think it’s that easy. I guess it’s 1-2 weeks to move to api, and 1-2 days to program out all the references to signup vars (some are used also on PayPal, but only for initial payment not recurring unlike stripe). And we really want that code well documented - the very good but expensive dev I paid for implementing a vat moss solution in 2015 (based on some now defunct vat service) was complaining badly about the mess of the PayPal code and lack of proper documentation.

But yeah GoFundMe or similar to get the amount together and then hire a dev via a platform is fine.

I think clavaque right now tried to just go for the new ipn version which still leaves loads of mess. A clean modern solution based on API is what we want. So that it’s future proof and easy to adapt on future changes.

At the same time an update to the horrible pro form with a way to define which fields are shown/optional and mandatory would be another possible thing. But that’s not too important. If it goes via API and allows third party checkouts or PayPal generated forms/buttons we don’t really need an improved pro form. Also proform is inside s2member pro so that would cut out s2 member pro .

1 Like

I’m not sure enough money would be raised to upgrade s2Member when there are other plugins in active development.

This entire thread has mostly been a discussion among the same four people, and I doubt even half of those four people would be willing or able to contribute enough.

1 Like

Maybe @clavaque needs to release a newer version of the plugin with a new higher price and give a discount to current s2member pro users.

That might give him more motivation. But I am unsure if that’s the main issue as he’s not interacting in the forum for a while, I guess perhaps he needs time to deal with a personal matter or something unrelated.

Let’s wait a few days to see what he says.

s2Member has been on life support for years. @clavaque is great at general customer support issues but s2Member needs more than that.

1 Like

I believe we’ll figure something out, but it might take us time. Even if it means spending a few months to learn php so we can code something ourselves. Maybe release add ons that integrate with s2member to fix what it can’t do.

It’s been a very long time since I last looked into it but I did not like the pricing model of the other plugins as I think they mostly required a monthly fee or a percentage of the revenue. I don’t want a plugin that holds me hostage, that’s why I like s2member. We make our purchase and even if it glitches here and there, we can keep things running “for free” even if it means doing lots of things manually. I see it as an amateur solution that helps small websites.

I think most people who wanted to purchase this plugin already did it and perhaps there’s not new interest as the plugin is clearly abandoned for a while (not entirely, but mostly).

New potential customers for s2member just move on to other solutions when searching for a membership plugin because they visit the forum and they see it’s outdated.

I think that we can somehow try to bring it back to life. It might require a lot of work, patience, time and perhaps even resources. The code is open, so anybody with enough knowledge could have come in and helped, but this never happened either. I don’t know any php, sadly, or I’d have done it a long time ago, at least on minor issues like s2member’s terrible (lack of) routines around failed payments, demotions and reupgrades upon late payments, for example.

@openmtbmap mentions issues surrounding stripe’s variables that’s another item that needs to be fixed that sounds a bit easier for someone with php knowledge, as I assume it would only require some code modifications to use the fields we can see (sub and customer fields) instead of using the hidden array. Or, at least, show the hidden array on the user profile, even if on a raw format, so we can easily edit it when necessary.

The signup vars are way too complicated to replicate. So if something goes wrong on registration with stripe you can never get the subscription recognized anymore. It needs to look at email and subscription ID and over.
I guess the reason for the signup vars was that it was supposed to be possible with future changes to have several subscriptions per customer but that’s better implemented differently.

Yeah for someone with PHP knowledge I guess it really can’t be more than 1-2 days of work and the main part will be digging and finding the places where it’s used - needs changing of quite a few files in small bits. The problem is that the code isn’t very clean and copied together a bit.

Oh yeah there was one programmer doing plugin’s for s2member and adaptions, but I once paid him for doing a vat solution and he didn’t even get anywhere to have a useful solution.
The person that back then did it for me could figure a better solution within 5 minutes and then took a couple of days of work to code it. The main part for him was understanding how s2member and PayPal ipn work.

I have noticed this issue today. I have seen that paypal configuration has “suddenly” activated the “sand box” mode by himself. I have restored it to “NO” and it works again.

Sometimes to solve a problem you have to come at it from the opposite direction.

Rather than hoping someone here can solve this, what about going to a Paypal forum and see if someone who knows Paypal wants to look at the current code and fix it. They don’t have to know much about S2Member, just how to make the link to Paypal work properly.

Anyway, my 2 cents worth. Many decades ago I would have looked into the code. Now I am a coffee farmer and can only tell you how coffee keeps programmers awake. :slight_smile:

1 Like

PayPal hasn’t been any help in the past, none of their support channels. So you can forget about it.

If Christian isn’t fixing it, forking s2 is the best solution. Create a new modern implementation of PayPal and Modern pro forms or compatibility with Shopping carts, PayPal created forms and so on is the best and only solution.

Also it’s not about fixing code but a complete new implementation of PayPal. Nothing to rewrite there, needs to be done from scratch. That’s why dropping s2 pro forms would be easiest. Actually just using s2 ipn to create users after using a third party checkout would be the easiest.
However for stripe needs to remove that stupid signup vars mess else it’s not possible to create users with subscription payments into s2 (except if the new solution also handles deactivations)

I am just using PayPal “dumb” buttons (PayPal’s generated code, NOT s2Member buttons) for now and processing things manually. It’s just a small extra task in comparison with everything I have to do because the plugin was never good to manage payments (and their lack) in the first place, anyways.