vb.org Archive

vb.org Archive (https://vborg.vbsupport.ru/index.php)
-   Forum and Server Management (https://vborg.vbsupport.ru/forumdisplay.php?f=232)
-   -   Registration Bug, Unsure of The Fix (https://vborg.vbsupport.ru/showthread.php?t=325069)

boxingscene 05-12-2017 04:49 AM

Registration Bug, Unsure of The Fix
 
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 05-12-2017 10:18 AM

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 05-12-2017 02:42 PM

Quote:

Originally Posted by Paul M (Post 2586421)
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] ---------------

Quote:

Originally Posted by Paul M (Post 2586421)
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 05-12-2017 07:23 PM

Quote:

Originally Posted by boxingscene (Post 2586436)
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 05-12-2017 07:31 PM

Quote:

Originally Posted by Paul M (Post 2586450)
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.


All times are GMT. The time now is 12:29 AM.

Powered by vBulletin® Version 3.8.12 by vBS
Copyright ©2000 - 2025, vBulletin Solutions Inc.

X vBulletin 3.8.12 by vBS Debug Information
  • Page Generation 0.01039 seconds
  • Memory Usage 1,729KB
  • Queries Executed 10 (?)
More Information
Template Usage:
  • (1)ad_footer_end
  • (1)ad_footer_start
  • (1)ad_header_end
  • (1)ad_header_logo
  • (1)ad_navbar_below
  • (4)bbcode_quote_printable
  • (1)footer
  • (1)gobutton
  • (1)header
  • (1)headinclude
  • (6)option
  • (1)post_thanks_navbar_search
  • (1)printthread
  • (5)printthreadbit
  • (1)spacer_close
  • (1)spacer_open 

Phrase Groups Available:
  • global
  • postbit
  • showthread
Included Files:
  • ./printthread.php
  • ./global.php
  • ./includes/init.php
  • ./includes/class_core.php
  • ./includes/config.php
  • ./includes/functions.php
  • ./includes/class_hook.php
  • ./includes/modsystem_functions.php
  • ./includes/class_bbcode_alt.php
  • ./includes/class_bbcode.php
  • ./includes/functions_bigthree.php 

Hooks Called:
  • init_startup
  • init_startup_session_setup_start
  • init_startup_session_setup_complete
  • cache_permissions
  • fetch_threadinfo_query
  • fetch_threadinfo
  • fetch_foruminfo
  • style_fetch
  • cache_templates
  • global_start
  • parse_templates
  • global_setup_complete
  • printthread_start
  • bbcode_fetch_tags
  • bbcode_create
  • bbcode_parse_start
  • bbcode_parse_complete_precache
  • bbcode_parse_complete
  • printthread_post
  • printthread_complete