The answer to the following question has probably been covered somewhere in this thread before - if so please link me to the relevant post(s):

What is the technical reason for Wordpress and vBulletin needing to share the same [MySQL] database, and is there any possibility of separating the two to use separate databases?

If it had anything to do with register_globals then there would be no need in using the $_GET array, you could just use $action, or $deactivate.

If you open the plugins.php file you will note:

You will note the wp_redirect call where it sets activate and deactivate. The reason why you do not compare the action, is because it has not been thoroughly checked to make sure it is an admin calling the action amongst other things. It is a security checkpoint.

Nobody has reported any problems activating the plug-in. You should note however, that there are issues with the plugin page in wordpress because it uses AJAX and the developers did not take into account all the possible cache settings browsers/ISP's may be using. You can google: wordpress plugin page AJAX, to see more about this.

I have been considering this myself. The reason why I stated this caveat is that PHP 4.x by default would only allow an instance of a script to make one database connection. See the following Google search to see what I mean:

http://www.google.com/search?hl=en&l...22&btnG=Search

However, from what I understand, PHP 5.x has addressed this issue. I may be able to rewrite the code to take that into consideration, but honestly, it is so easy for them to share the same database, that using two connections would just be a waste of resources. If you are vaguely familiar with phpMyAdmin or other such MySQL applications (navicat, etc) you can easily merge databases.

There are many pages on the net that show how to merge databases, and here is one:

http://www.everymanhosting.com/forum...d122ddc0190861

I just finished testing this on a 2.1 platform. Appears to be running smoothly. You should be fine, but as always, backup all your mysql data and files before you upgrade just in case there is something I didn't catch.

Yep, I also got it to work on Wordpress 2.1 earlier this afternoon.

Thanks!

(BTW, hate to be a pain, but i was never able to get the disable "post to a forum" option to work. Any ideas?)

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.

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.

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.

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:

Jafo232, thanks for the reply :).

I need to clarify my reasons for wanting|needing a separation of d/bs between WP & vB: it basically boils down to 2 factors - security & server load balancing.

The hosting company we're using for our vB 3.6.4 forum is quite restrictive and a recent request to upgrade from PHP4 to PHP5.2.0 resulted in PHP 5.0.4 being installed & running under CGI in Apache [was not CGI under PHP4], also register_globals is enabled under PHP 5.0.4 [CGI], I have a feeling things are going to go pear-shaped very soon :(. From a security POV I would prefer to have 2 separate MySQL d/bs for WP & vB respectively, although it probably won't make a huge difference, it might limit some damage.

ITO load-balancing, the option of being able to run a separate MySQL server [b] for WP and other stuff, and keep the PHP for WP & vB running on the same server [a] that vB has its d/b on.

Howdy,

I've got a question on this, I'm thinking of using Wordpress as my CMS for the site, as I'm fed up of my site looking like every other forum based site. So does this preclude me from using wordpress as the front end as users will have to have logged into VBulletin firstly ?

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.


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.

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.

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. :)

Not sure I agree with everything you stated here, but regardless, it is possible to use two databases I suppose, but you would have to edit the code a bit. Basically, you will have to use the vbulletin database object for any and all calls to the vb data. Probably not that difficult to do, I just personally have no need to create such code.