That Email Address is already in use

#1

I’ve been having problems on another issue (not returning to success page)

…/stripe-multiple-trial-installments/5606

…and while trying to test that issue another issue has popped up… and I think blocking me from that issue.

(Note this is S2member Pro using Stripe)

No matter what I do, and whatever bogus email address I use I get:

That Email Address is already in use. Please try again.

???

All plugins have been deactivated… except s2member
New pages and have been created with a new Stripe Proform
All users (exempt admin) have been deleted
All test customers in Stripe have been deleted
Stripe is in test mode
Tested in Firefox, Chrome, and Safari on Mac
Tested in Firefox and Chrome on Windows.
(All same behavior)

After submitting the form it returns to that same proform page with that above message…

That user has now been added (new) to the users
That user has now been added to Stripe as a customer.

So behind the hood the payment is “working” but I get this “Error” and I’m hoping this is what might be blocking the redirect to the success page… Which is the critical step I need to get working…

Any ideas !!! (Please… I’m stuck here)

#2

Any MU plugins active? Also can be from the theme…

#3

Hi,

Thanks for the feedback… No there are no MU plugins active, in fact in this test there were NO plugins active. Using the Divi Theme from Elegant Themes. I have not found this issue connect to that theme in my searches…

I did not see this issue right away, it was only as I was trying to “fix” the original issue (not redirection to the success url) that this issue showed up.

In my research I found there was a “loopback” issue related to that so I’m in the process of tracking that down.

I’ll post those results…

#4

Ok…

I tried the loopback fix… no joy.

Also my allow_url_fopen is on at the php.ini level.

Next I tested it on the default theme. (twenty-sixteen I believe) and ALL PLUGINS deactivated except s2member…

Still getting the same issue

That email Address is already in use…

What else can I check???

#5

Did it runs well without s2M? Sorry about stupid question, you maybe try already, but just in case…

#6

Sorry, but I don’t quite understand that question. It is the s2member proform that is returning that error. So if s2m is not active then I can’t test it…

Did you mean something else…???

#7

Sorry, that was the winner in “The stupidest question” competition… Seems I was too sleepy :-/

#8

Wow. What searches? I’ve been using s2Member+Divi+Stripe for a while now and never experienced this. Or it was so long ago I wrote some custom code and forgot it. If you share the links you’re referring to and it jogs my memory I’ll look to see if I wrote a fix.

Also, long shot here, but where are you hosting? And any errors from the console can be helpful.

I tried to open the site linked from the other thread, but it didn’t appear to be up anymore.

#9

Hi Ric,

Thanks for responding… Glad to hear you are using that same combination, so there is some hope that the theme is not the issue.

If you read the thread…

…/t/stripe-multiple-trial-installments/5606/7

…you can get some background on how I got to this point. Basically, it seems that in trying to get those solutions working, I seem to have mucked up things to a point that it is throwing this bogus error (it is adding the new user and processing the payment).

Hosting…

I do my own hosting so I have complete control of that… You reminded me of the php logs… (use to be a Java programmer so I’m so use to seeing a console that I forget about the log files…) I did a search that file for this test domain and don’t see any errors that might relate to this… Good idea though…thanks…

Here is that link to my test site on this…

http://test.peer-pods.com/proform-test/

Everything is strip down to a basic install plus s2member. Any WAGs (wild ass guesses) would be appreciated.

#10

I was mostly thinking it might have been a hosting issue like the Trellis/Bedrock issue I posted (and solved) here:

But if you’re doing your own hosting and are not doing anything crazy with changing WP default directories, etc. and are using Apache then I don’t have any other “WAGs.”

BUT I just put through a test transaction using Safari and it worked. Go figure.

Capto_Capture 2019-02-23_09-22-12_PM.jpg711×477 41.5 KB

#11

Wow!!

I see your entry…

How did you do that…???

I just did a new test also in Safari, using several bogus emails and users that I have NEVER used before and I still get that “email is already in use” message. I just did 4 in a row, each with a different emai, different user name…etc… all got that message

But, they also all got entered as new users in Wpress AND Stripe.

Now I’m really in the Twilight Zone… Aaaarrrrggggg…

(Anyway, thanks for trying and thanks for getting back on that…)

#12

Just wanted to wrap up this topic so that is someone sees this later they don’t feel it is a total dead end…

It was Wordfence that was causing the problem.

What is interesting is two things: 1) When I originally started this part of the project, the basic proform was working fine and Wordfence was active, it appeared to suddenly stop working one day. My assumption is that I did an update of that plugin and that introduced the issue. 2) that it does not have to be active. Its very existence causes the problem. I searched for that type of issue, (i.e. deactivated plugins causing compatibility problems) and did not find anything…

It was my assumption, clearly wrong in this case, that deactivating it brought it out of play. Well, in the case of Wordfence, not so!

It was suggested by Cristian in another thread on a related issue that it is the MU plugin that Wordfence was probably installing that is the cause of it interfering even though not active. I have NOT confirmed this yet, but it is a possibility.

What I did find though, concerns me long term, as far as stability of the basic s2member subscription process. What I mean is that any 404 or other failed resource would/could trigger a re-firing of the “init” functions on that page. It seems that the dependency of using the “init” to fire the checkout code is risky (and not something that is easy to discover) and is not something even you suspected (which leads me to suspect that this technique is not common knowledge??). It appears that Wordfence does something, possibly in the MU plugin that triggers this re-call of the page because it is clear from my research that this is exactly what was happening.

Here is the link I found that matches the data I collected… (Though note, that in tracking the network traffic, the browser did not detect any 404 errors, therefore it may be something Wordfence is doing locally on the server. The effect appears to be the same regardless.)

I hope this helps someone else that encounters this issue/mystery…

1 Like