- This topic has 14 replies, 2 voices, and was last updated 12 years, 5 months ago by
.
-
Posts
-
WP eStore v 6.8.7
WP eMembers v7.9.8.5
[http://howtothinksideways.com]
Our system has been working fine for a while, but then my client turned on the require email verification for free signups because of too many spam signups. She used method 1 on the directions of just checking the box.
Customer support has been flooded with messages of it not working.
I tried myself, and this is what happened.
1) On the registration page, I have a box for First Name, Last Name, and email.
2) Click register and get “Please check your email and follow the link to complete the registration.” message
3) Get an email with a link to the same page but with a blank member id and a code
4) Click link
5) End up on the registration page again, but it’s still got the verify email address form rather than the full one.
I turned on the debugging for eMember, but nothing was recorded, so I have no logging to indicate what went wrong. Oh, and I tried twice and the confirmation code did change. I also tried in both Iron and Chrome.
Few things can go wrong when you change the entire registration flow.
1) Load fresh copies of both the plugins first:
https://support.tipsandtricks-hq.com/forums/topic/re-install-or-load-a-fresh-build-of-the-plugins
2) Share the link that you are clicking on (refer to your step 4). This will allow me to investigate that link
3) Did you try enabling eMember’s reCAPTCHA feature before doing this whole email verification option? In most cases the Google reCAPTCHA verification can stop spam bot signups for free registration.
4) Dis is for free membership signups correct?
Yes this is for free signups, and my client has had issues with people having trouble with the captcha. I’ll try the re-install tomorrow.
And here are two of the links I got (tried to make test accounts twice).
[http://howtothinksideways.com/join-us/registration/?member_id=&code=7d9882e624d10726a2010006f29c1c18]
[http://howtothinksideways.com/join-us/registration/?member_id=&code=5a56e5f34f6b66fec3a350735c76de82]
I’m guessing it was supposed to create an account and include the member id in the URL. However, I checked the database, and it didn’t have any records in the members table for either of these.
Yep, it is missing the member ID value which is the causing this. It is possible that the client didn’t upgrade the plugin correctly using our upgrade instruction so the database columns got out of sync. The re-install should adjust everything automatically:
Well, since I did the latest upgrades and did follow the instructions to disable before loading the files in, it should have, but hiccups happen. I’ll request a new version now.
Okay, I solved it through putting some more catches in the code, ones I’d recommend you add as well because none of the steps (reinstalling, upgrading eStore, etc. worked).
The problem was this:
The members table had a unique index on the username, which means that only one person could have an “account verification in progress” at any one time. The first spammer to fill out that form blocked everyone afterwards.
I don’t know whether the unique index was something that was added in one of the upgrades, something I did to improve database performance since so many queries use the username, or something my host added to speed up our queries and reduce our impact on the database resources.
What I do know is that the reinstall did not check for conflicting indexes. Nor did the application provide that information at any point.
The catches I put in place are as follows:
1) In the email registration verification function, I checked to see if the member_id was greater than 0. If not, I sent myself an email with the key fields for troubleshooting.
2) In the db_access file, I added a catch for the $wpdb->last_error if true to send that to the admin and add the error message to the debug log.
The second change is what allowed me to figure out what the problem was, but the first allowed me to change the output from “everything is fine” to “there was a problem and we’re working on it” so any problems in the future will not be compounded by the end user and admin thinking it should be fine.
There must be a number of other factors involved which is causing this behavior on your site. Because, you can have multiple concurrent user verification in progress without any issue (we already tested that behavior). Its fine that you made some custom tweak on your site to handle this but it is not necessary in the core eMember as it already works.
Well, the only thing necessary to fix it was changing that index from UNIQUE, so that was the cause. The other registrations would not have been affected, only one that puts multiple entries with non-unique usernames, in this case a blank.
The tweaks I recommended were merely catches for if there is a problem with the insert caused by database issues. It would allow you to give more specific advice than to reinstall, which since the reinstall did not change or remove the index, had no effect despite the suggestion that it would repair any database issues. However, it is your call, obviously. My code only triggers on a failure, so it has no effect on normal running but will assist in tracing and resolving problems faster. I’m willing to share the specific code if you’d find it useful, though it sounds like you’ve already decided against any failure catches.
I am not sure what you mean by “index from UNIQUE”. Can you please tell me where it is? Which file and which line?
A table index on the database, not in a file.
A UNIQUE index requires only one instance of the entry at any one point. But you can index a field for faster searching without making it unique. The indexes improve query response time either way. So I took off the unique requirement for an index on the username field in the database using phpmyadmin, leaving the field indexed.
Does that clarify?
The eMember’s member DB table doesn’t have any column marked as “UNIQUE” so I am not sure where that is coming from.
Well, I said that I, or my host, may have added the index to improve database performance. But since it’s a dead stop for a couple of your options, and hosting companies do sometimes attempt to help in this fashion, it’s worthwhile including a debug message containing the reason an insert has failed. This specific instance wasn’t a bug so much as a misunderstood feature (usernames must be unique, but you’re not using it in that fashion because you allow blank usernames), but because you have mention of database table issues as one of your reasons for reinstall, I’m suggesting pushing the wpdb->last_error into the debug log to help troubleshoot the source of the issue.
Personally, I’d also suggest putting the unique code in as a temporary username rather than having blank usernames allowed by the database, but that’s a design issue rather than a support issue.
- You must be logged in to reply to this topic.