fetch_userinfo_query

Andy R · April 5th, 2010, 08:21 AM

This is a problem that has been plaguing us for quite a long time. We have been having an issue with vbgallery 2.4.3 and up with the following code in the fetch_userinfo_query hook:

Code:

Content visible to verified customers only.

The problem arises during registration/login for a new user. If the ppgal_user data has not yet been populated, which happens during a new registration, then it can cause errors, especially with other products because false is returned. Also, $vbulletin->userinfo['userid'] can become blank (not 0, but '').

The main issue here is that the ppgal_user data is inserted at register_addmember_complete hook, yet this code is executed before that in vb:

Code:

Content visible to verified customers only.

This function executes this code:

Code:

Content visible to verified customers only.

Also, so may other plugins (like some of ours) execute this and the new joins and selects are causing the query to return no result.

I fixed this on our sites with the following edit to that code:

Code:

Content visible to verified customers only.

There could also be other instances where this may cause issues, but after quite some time debugging, this is what we have found so far.

Chuck S · April 5th, 2010, 10:18 AM

without the exact error its hard to say but I beleive we are looking at the wrong plugin code.

The number if people are still having issues are hacks which conflict with our code. Any bugs where indeed fixed in 2.5

http://www.photopost.com/forum/1252595-post65.html

Also READ POST 74 if you continue to have issues as the big issue with hack conflicts is the GPC userid thing which is hacks conflicting with the code and hense part of our code is never executed.

Andy R · April 5th, 2010, 05:30 PM

Did you read what I posted? This is NOT FIXED in 2.5! Try doing a fetch_userinfo() during the registration process before the register_addmember_complete hook. It returns false (not 0). This is BROKEN. It has nothing to do with GPC, because the userid is being assigned during registration, not inputted.

The scenario I am referring to is when a user registers and is being sent the new reg email and is automatically logged in. During the call to process_new_login() there are other hooks where products can plug into. Thanks to your code, they cannot use fetch_userinfo() until after register_addmember_complete because it returns false.

Anyway, the culprit is in includes/vbgallery/fetch_userinfo_query.php.

Chuck S · April 5th, 2010, 05:47 PM

Please read my post. This was indeed fixed and we tested thoroughly. The only thing we could narrow down is hack interference because we could never duplicate this on a clean vb vbgallery setup hense post 74 is a mere suggestion for those users still having an issue.

Basically the issue of hack interference comes in the $vbulletin->GPC['userid'] variable being messed with.

Doing as instructed in post 74 should assist you because removing that conditional allow that code you need to run to run regardless of whether the variable is present or not.

Andy R · April 5th, 2010, 06:19 PM

The thing is, I am not referring to $vbulletin->GPC['userid'], I am referring to: $vbulletin->userinfo['userid'].

Open functions_login.php and go to function process_new_login and note this code:

Code:

Content visible to verified customers only.

This is BUILT IN vb code.. Now, go to the next hook in that same function called login_process and consider a hack with the following code:

Code:

Content visible to verified customers only.

$vbulletin->userinfo['userid'] is false instead of 0 or greater because of your plugin code. At least this is the case when a user first registers. Most of the time this will not happen because you have already populated the ppgal_user information but during registration, fetch_userinfo is assuming that info is there and when it is not (it is after process_new_login() completes), no result could possibly be returned.

Chuck S · April 5th, 2010, 06:31 PM

Andy I do not believe what your talking about has anything to with what I am referring to. I can really only comment on our code. vbulletin code is not our code. We have tested vb 3.x with vbgallery 2.5 on a clean install NO HACKS and there are no issues at all. There are numerous posts on this issue.

In fact the only issue with vbgallery and the registration issue was a typo in the query line in the code noted in post 65.

Now looking into other peoples sites running code mods I noted as a side note in post 74 that users using hacks I was able to rectify there issue by removing the conditional so that query in our hook runs all the time meaning when someone registers they are always added to the gallery table.

Our plugin hook has nothing to do with the variable you are noting. Basically the query scans the users table and makes sure there is a gallery entry for the user in the gallery users table.

Andy R · April 5th, 2010, 07:59 PM

Quote:

In fact the only issue with vbgallery and the registration issue was a typo in the query line in the code noted in post 65.

No, in fact, here is another one!

I am talking about your code:

Code:

Content visible to verified customers only.

Quote:

Our plugin hook has nothing to do with the variable you are noting. Basically the query scans the users table and makes sure there is a gallery entry for the user in the gallery users table.

Yes, and THERE IS NO ENTRY at the point in time I am referring to!!! This breaks the variable I am referring to! Your code has NOT added the entry until "register_addmember_complete" hook:

Code:

Content visible to verified customers only.

Unfortunately the above code is inserted AFTER process_new_login() is executed after a NEW registration. VBULLETIN will populate $vbulletin->userinfo during a NEW REGISTRATION in that function. Your CODE breaks fetch_userinfo so $vbulletin->userinfo is FALSE!

This causes problems to ANY product that hooks into process_new_login. That is YOUR fault, coders should not have to write code to compensate for your errors. You are for all intents and purposes breaking that function during certain scenarios.

I have attached a flow chart to illustrate the issue because I am running out of ways to explain this.

Chuck S · April 5th, 2010, 08:53 PM

What I am saying is this we write our application to integrate with vbulletin. Our application performs flawlessly with vbulletin.

Your issue as I have said a few times here is with the use of code hacks or mods for vbulletin. We can not find or duplicate any issues with our code and vbulletin.

It is not our responsibility to fix issues that arise from the use of code outside that of vbulletin and ours.

I see your flow chart. However there is no issue with registrations or anything with vbulletin and vbgallery when testing our applications together. I have already done this.

If you get errors only after adding hacks then the real fault here is the hack not our code. Do you understand where we are coming from here. if there was a real problem with our code we should be able to duplicate issues with our code interacting with a clean vbulletin/vbgallery install. Simply done we can not.

Andy R · April 6th, 2010, 04:57 AM

You are breaking a vbulletin function chuck, not any other mod. Do you understand where WE are coming from?

I can duplicate the issue for you right here and now. Run your vbgallery with the plugin that I have attached that only contains this code:

Code:

Content visible to verified customers only.

Run that and register a new user with your vbgallery and note the mysql error, then run it with vbgallery disabled.

If you continue to want to play ignorant on it, be my guest, it will be YOUR time your wasting when people ask you about the error in the future.

Oh and by the way, your application has never and never will run flawlessly with Vbulletin. I fix more errors in this code just to get it to run right than any other application I have ever seen.

When your application breaks the function of Vbulletin, then yes, it is your responsibility. But be stubborn, I could care less as I have wasted enough time here, good day.

Chuck S · April 6th, 2010, 08:54 AM

Andy I can appreciate what your saying but can you understand what I am saying here. I can pass along what your saying but this still does not get past the main issue I have been stating all along.

1. You will never encounter any issue you describe in a default vbulletin / vbgallery setup with no hacks. everything works as it should.

This can not be replicated in any manner we have tried over and over again. Only when users start using vb hacks do issues come up and from any company whether its us or vb the concensus is always its the hack authors responsibility.

Your code is merely a conditional so its no big deal to add it provided it is disected enough to see your change wont do anything.

My personal thought is that your patch is merely that a patch and things go back down to what I have been stating all along with the hack interfering with the plugin I noted where the user is added. If that plugin is run then you never see an issue even with hacks installed. Now with certain hacks installed that plugin is not ran and thats when you have an issue. That has been the sum of multiple people looking into this in the past.

Andy R · April 8th, 2010, 08:50 AM

Chuck, NOBODY runs a forum with no vbhacks installed. VBGALLERY IS A VBHACK!

This mere conditional keeps your code from breaking things, so I believe it is rather important.

I showed you how to replicate it, but obviously you haven't read what I wrote so there is no need to bother here anymore. A 2 minute look into code would have saved you all this time.

Chuck S · April 8th, 2010, 09:42 AM

Andy I said I would pass it along because all that is is a conditional which should not break our code but we would need to test it out thoroughly.

vbGallery is not a hack it is a full featured gallery product. I beleive it runs fine with any other major product like vbcms etc which has been designed totally based around core vb code. The only way you encounter this issue is with hacks from vbulletin.org which vb doesnt even support.

For something to really be classifieds as a true bug in our code you need to replicate the issue with a clean vb/vbgallery setup because we cant guarantee compatiblity with the tons of hacks out there only vbulletin. That is the one and only point I have repeatedly brought up here to make you understand.

Andy R · April 9th, 2010, 09:48 AM

Chuck, it isn't a compatibility issue. When your product breaks vb functions, it is an error, plain and simple.

Vbgallery is as much of a hack as any other product on vb.org. VB does not support vbgallery either.

Chuck S · April 9th, 2010, 10:14 AM

Everyone has there opinion. Of course vbulletins not going to support vbGallery its not there product. We don't provide support for vbulletin either.

Andy I really do not know how to explain this any other way but if we where breaking something in vbulletin would we not be able to see this evident when vbgallery and vbulletin where the only things installed sure we would. Simply issue is you can not replicate any errors given my scenerio its only when you use hacks to vb.

This issue is really closed because I already said I would pass this along for consideration

Andy R · December 21st, 2010, 06:52 AM

We are getting requests to our sites from your users asking US how we fixed this as they are experiencing the issue too. Not knowing their license status, I am going to post what we are currently doing here ONLY. Another member here shared this with us and we have been using it with success.

Replace the Userinfo Merge plugin with this code:

Code:

Content visible to verified customers only.

Then add this code to the BEGINNING of the Global Complete plugin:

Code:

Content visible to verified customers only.

This problem is still occurring with the latest version. We just installed it on another site and it immediately started breaking stuff. This fixed it.

klaush · January 3rd, 2011, 04:51 AM

Thanks a lot for this fix! We where about to uninstall vbgallery because of this issue.

Quote:

Originally Posted by Andy R

This problem is still occurring with the latest version. We just installed it on another site and it immediately started breaking stuff. This fixed it.