[Jafo232]

Originally Posted by thebluelizard

Actually, this guy had the same issue: https://vborg.vbsupport.ru/showpost....89&postcount=9 We're running PHP 5, so I assume that's what's doing it. I'm afraid I don't see how that's a security checkpoint. Someone can just do ?activate=true in their URL just as easily as ?action=activate.

Huh? That post you are referring to has nothing to do with any issue you had. If anything, it is symptomatic of the AJAX issue. If someone just called ?deactivate=true it will not deactivate anything. The redirect is issued after the plugin is is deactivated. This has however brought to my attention a fact that a drop command could be called on the vb_threadid column on any deactivate. I will address this issue later today.

Originally Posted by thebluelizard

I was also having session issues because we have a login box in the upper corner on our theme. This submits to the vB login.php file so it can set up the appropriate session cookies there before shooting back to WP. I created a small vB plugin to redirect back to the WP install if that's where you were logging in from. So, there were some cookie domain and path issues because we have the scripts in /board/ and /WP/. The cookies are *supposed* to be setting with .domain.com and / for the domain and path respectively. But they weren't due to the $vbulletin global not being available inside of the vbsetcookie() function. This is because you were calling require_once('./includes/init.php'); inside of vb_Init(). Since it's inside of that function, things get messed up further down the call stack. I commented that out (along with the CWD stuff) and just put a require_once('./global.php'); to be done with it. Nothing vB does interferes with WP, so it's safe to do so. That fixed it getting the correct domain settings and such.

However, I noticed you weren't using the built-in vB session handler. I'm not sure why you'd want to do this, since the code is much more robust and production-tested. So, I took out the define at the top, and converted all the $vbuser stuff to $vbulletin->userinfo, and it runs perfectly now.

Actually, this is not the case in most installs. Most installations have wp files and vb files in different directories, so calling ./globals will get you a "no such file or directory" error (if you comment out the CWD stuff).

Also, if you require ./globals from inside a function, you are going to get init errors from VB under certain circumstances. This is why init was called instead inside the vb_Init function. I am assuming that since you have clicked uninstall on the plugin, you may have figured this out already.

Originally Posted by thebluelizard

The last issue was also with the login box. When you're logged in, it says your name and shows a log out button. However, you had to refresh the page at least once for this to show up, as the bridge code is setting a cookie, but not setting the current user for the current execution of the script. So, I just added a set_current_user($results->ID,$vbulletin->userinfo['username']); to vb_Init() after the setup_userdata() calls, and that fixed everything.

This may be an issue when the user is initially bridged (first time to wp from vb after the plugin is installed), but afterwords, it should be all set.

Originally Posted by thebluelizard

I'd also recommend you do some proper formatting on this code. It's a harder to work with when there isn't standard formatting throughout. The tab key is your friend :up:

I never agreed with what some call "proper formatting". I have been coding in this style since I started scripting. Spacing everything out with tabs has only confused me when writing/reading code. There are some times when I might use it when I want a particular block to stand out while I scan over code. This is just a personal preference of my own, like reading from left to right.