Patch Level 3 caused a bug
 

I need some help.

I applied patch level 3 line by line to my vb installation 3.8.7.
I made the changes on all the files that were included in the patch download, making sure that the changes were ported to my installation.

Now $vbulletin->userinfo is undefined in the fetch_userinfo function when using the fetch_userinfo_query hook. This function itself checks for the $vbulletin->userinfo['userid'], so this is not a desired behavior at all.

I cannot undo the changes, because 1) I trusted you guys to not screw the code up and 2) when I download vb 3.8.7, I get the patched versions of the files. So from the files that you offer, the error cannot be undone anymore.
I will now proceed to undo the patch using a backup.

This error was introduced with patch level 3 and needs to be fixed.

You should be reporting this at www.vbulletin.com not .org the guys here have nothing to do with the development or bug correction of the product!

I've read there have been a lot of problems with this new Patch even on vB 4

Anyone else had problems?

I am reporting this here, because it is the forum that offers help and assistance. On vbulletin.com, the only support that I will get is being told to reset the whole forum, remove all plugins and reinstall everything. No thank you - I've been told that one too many times.

I was unable to fix the problem. Maybe it was not the plugin afterall - I cannot tell. What I know is that it worked recently.

Actually, when doing a backtrace in functions.php > fetchuserinfo(), I see that fetch_userinfo is called from VB_Session in init.php.
$vbulletin->userinfo is only defined a couple of lines later in init.php.
$vbulletin->userinfo is undefined in the fetch_userinfo_query hook.

The backtrace in functions.php > fetchuserinfo() goes like this:
In words:
fetch_userinfo() is called in the vB_Session class in class_core.php. VB_Session is called in init.php, before $vbulletin->userinfo is defined. The "global" statement in fetch_userinfo() will fail. $vbulletin->userinfo is null.

Can somebody confirm that $vbulletin->userinfo is undefined in their fetch_userinfo_query hook?

I think there was some confusion because you posted "I trusted you guys to not screw the code up" and we're not the guys.



fetch_userinfo() is a member function of the session class, so it shoudn't be the same as the fetch_userinfo() that's in includes/functions.php. If you got that trace from a trace call at the fetch_userinfo_query hook, [S]then something's very wrong[/S]. ETA: no, I take that back - there is a member function but I don't think it's the one that should be called....but it does look like the other fetch_userinfo() needs the userinfo array to exist already, as you mentioned in the first post.

Something is amiss with my installation indeed. I looked at other plugins that hook into the fetch_userinfo_query hook and they use $vbulletin->userinfo['userid'] as well.

You are probably right. I will add the trace to the plugin instead of the function.

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

The result is the same.

I added this code to the fetch_userinfo_query hook in the plugin where $vbulletin->userinfo is null:

Note: if you add this code, you will have to globally disable plugins to remove the code again.

fetch_userinfo is called from vB_Session which traces back to init.php. At this point in time, $vbulletin->userinfo is not defined yet, as mentioned in the post above.

Actually I think I was wrong. To call a member function it would have to use $this->fetch_userinfo, and the parameters are wrong, so it is calling the one in functions.php. I think you're right that the first time it's called $vbulletin->userinfo isn't set even though it's used at the start of that function. It could be that the "is not an array" error message doesn't appear because messages are turned off.

I don't know what your plugin does, but maybe you could use hook fetch_userinfo and check $user instead of $vbulletin->userinfo.

The fetch_userinfo function itself checks for $vbulletin->userinfo. So something is broken in the original code already.
I can work around it, but I know other plugins check for $vbulletin->userinfo as well.
What bugs me is that it used to work a few days ago.
And since $vbulletin->userinfo is not available and I have no way to check if a user is logged in in that hook, it is not a good idea to just leave it like this.

Something's broken and there seems to be a flaw in the vb code. I checked a freshly downloaded code (patch level 3), and it follows the same logic.

init.php calls vb_session. vb_session calls fetch_userinfo, and $vbulletin->userinfo is not defined in this function.
Now let's assume that this call to fetch_userinfo() is not the call that loads this plugin. This would mean that the hook is executed twice. That would be extremely inefficient.

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

For example, the vbulletin blog product uses $vbulletin->userinfo['permissions'] in the fetch_userinfo_query hook.

Yeah, if that's true then it's a bug as far as I can tell (but I don't have the blog product).

Edit: just to be clear, as mentioned below I've been looking at the source code for vb3.8.7PL2 without the latest patch, so if this is a bug it existed prior to the latest patch. Also, I diffed the PL2 files with the patch files and none of the changes affect those areas of the code.

So should I not apply the Patches then?

I've been looking at the source code for vb3.8.7 PL2, so I don't see any evidence that any of this was caused by the latest patch.

Sorry, I forgot to say I use vB 4

I haven't really seen any issues with the latest security patch. I don't watch everything on vbulletin.com, but I only saw a couple of mentions of problems over there - one was vb3 (which I think was probably squishi), and the other was someone who I think installed the wrong patch. In any case it only involves overwriting over some files, so if it did cause problems you would only need to upload the original files again.