Registration Bug, Unsure of The Fix

[boxingscene]

I've experienced this issue, on and off, for years.

I would estimate it happens to a handful of users out of every 30 registrations.

When users attempt to register they get the following error during the final step.

Fatal error: Existing data passed is not an array
Called set_existing in [path]/register.php on line 421
in [path]/includes/class_dm.php on line 235

From what I can tell, the user gets added to the database, but he never receives the email to confirm his email and we never get the email to advise of their registration.

I'm on Vbulletin 3.8x.

From what I found, this issue was even happening on VB 4.X. It appears to affect sites that use a slave/master combo.

VB staff solved this bug, in the following thread, but for 4.X.

http://tracker.vbulletin.com/browse/VBIV-10812

It's an issue when the functions.php does a call to the slave and that error comes (if I understand it right) because the info for the new user is not there yet on the slave.

Unsure of how to apply the fix to 3.X.

[Paul M]

The fix (as applied to vB4) requires two files to be edited.

Its a shame you didnt raise this a week ago, I could have fitted it into 3.8.11, too late now.

A simpler fix is the one listed in the Jira you linked to.
That fix does, however, mean you would always read userinfo from the master, somewhat defeating the purpose of a slave.

[boxingscene]

Originally Posted by Paul M

The fix (as applied to vB4) requires two files to be edited.

Its a shame you didnt raise this a week ago, I could have fitted it into 3.8.11, too late now.

A simpler fix is the one listed in the Jira you linked to.
That fix does, however, mean you would always read userinfo from the master, somewhat defeating the purpose of a slave.

We also use a caching server as well.

How damaging would that fix be in terms of server load on the master? does threads/posts still get read from the slave?

--------------- Added [DATE]1494610398[/DATE] at [TIME]1494610398[/TIME] ---------------

Is there way to code it to where it would only query the master when the current script is the registration page, but uses the slave query for everything else. That way it should have no significant impact on the server.

--------------- Added [DATE]1494622018[/DATE] at [TIME]1494622018[/TIME] ---------------

Originally Posted by Paul M

The fix (as applied to vB4) requires two files to be edited.

Its a shame you didnt raise this a week ago, I could have fitted it into 3.8.11, too late now.

A simpler fix is the one listed in the Jira you linked to.
That fix does, however, mean you would always read userinfo from the master, somewhat defeating the purpose of a slave.

What this be sufficient?

if(THIS_SCRIPT == 'register'){
$user = $vbulletin->db->query_first($query);
}else{
$user = $vbulletin->db->query_first_slave($query);
}

[Paul M]

Originally Posted by boxingscene

Is there way to code it to where it would only query the master when the current script is the registration page, but uses the slave query for everything else. That way it should have no significant impact on the server.

Thats precisely what the actual fix does.


I dont know if your code would work, I suggest you just test it on your test site.

(you have a test site, right ?)

[boxingscene]

Originally Posted by Paul M

Thats precisely what the actual fix does.


I dont know if your code would work, I suggest you just test it on your test site.

(you have a test site, right ?)

No test site, I usually set up a test site when it comes to the manipulating the database - since it's close to 30 gigs and I always do backups.

But I had a VB coder with experience do the coding to patch the functions.php file with a workaround (which is where I got that piece of code from).

I uploaded the patched functions.php file and in the last hour there appears to be no errors (at least additional errors to what I'm experiencing).

Several registrations and none of them have received that error, but too early to tell if the problem is solved as it doesn't always happen.