Integration with vBulletin - Complete Wordpress/Vbulletin Bridge - Share Users And Postings

DOES NOT WORK FOR Vbulletin 4.x

This version probably no longer works for Wordpress 3.x. I have started developing this product over and have released the NEW version here:

http://www.lampwrights.com/showthread.php?t=41

This mod bridges your Vbulletin users over to Wordpress. You can also use Vbulletin as your comment engine instead of the spammy one built into Wordpress. You can display the comments inline in your post. You need not use the comment feature, if your only interested in sharing users.

You can map your Vbulletin Usergroups to Wordpress Usergroups and those users will then be recognized as registered Wordpress users.

For example, user "Joe" registers at your forum and logs in. Joe then clicks on your Wordpress page. Joe is instantly added to the Wordpress user base with the permissions you set for his usergroup. In otherwords, if a user comes over belonging to the "Registered User" group, you can select that he is placed in the Wordpress "Subscriber" usergroup.

If you change a users group from vbulletin, it will automatically change in Wordpress.

Requirements:

• DOES NOT and WILL NEVER support Wordpress MU.
• Wordpress and Vbulletin scripts must reside on the same physical server.
• Wordpress and Vbulletin must use the same domain name.
• Stable Wordpress Version greater than or equal to 2.5.
• If your WP login name is the same as your VB username, this user will NOT be ported! If this was the case, you could lose your WP admin rights if there was an error, or if you deactivated the plugin.
• DOES work for Vbulletin 3.7.

Limitations:

• Please don't ask if it works for any BETA versions of Vbulletin. I do not know and will not convert this to the latest version of VB (whatever it is at the time you are reading this) until the version is released as non-beta.
• If you delete a user, you must do so in both Wordpress and Vbulletin.
• If you are using XMLRPC to post with applications such as Windows Live Writer, you must change the password of the author in the WORDPRESS admin cp, after the user is ported over from VB. If you are not integrating users, then you do not have to.
• Chances are, this will not work when VB and Wordpress are located in different sub domains. I.E. forum.yoursite.com - blog.yoursite.com. Cookie issue.
• I did the best I could in determining your forums file path with the script. There may be certain script setups that cannot find the file path properly, in which case you may get errors that the script cannot find or open /config.php. If this is the case, please HARDCODE your ABSOLUTE path to the forum in vbridge.php.
  
  To do this find:
  
  

   ## If you are having path problems, uncomment this next variable and define the path
  ## NO TRAILING SLASH!
  # $vwd = '/some/path/to/your/forum';

  And uncomment the last line, and change the path to your forums path:
  
  

   ## If you are having path problems, uncomment this next variable and define the path
  ## NO TRAILING SLASH!
  $vwd = '/some/path/to/your/forum';

Common Mistakes When Installing:

• Using two different host names causes problems. If your forum URL contains www.yourdomain.com, then your wordpress blog URL MUST contain the www. part of www.yourdomain.com also. This goes for any other host name. Browsers are finnecky when it comes to cookies (as they should be).
• Editors generally EDIT, not write. In Wordpress, editors don't show up in the post author drop down. This has nothing to do with this plugin, that is Wordpress code.
• Make sure you DO NOT create a subdirectory for this plugin in the wp-content/plugins directory. Just upload it directly there.
• If the admin username in Vbulletin is the same as the one in Wordpress (i.e. Admin), that user will NOT be able to login to the WP dashboard.
• If you do not map users before you turn auto-integrate on, the plugin has no idea whether your allowed into the dashboard.
• If you all of a sudden can't login to the dashboard, see the above two common mistakes.
• FOLLOW the directions and make a test post first. Being in a rush and not testing will most likely turn out bad for you.
• When you create a test user in VB to test mapping users, the test user MUST have an email address. If a VB users email address is blank, they will not map.

UPDATES:

01/03/2007 - Fixed the unlock_tables() issue on some setups.

01/03/2007 - Fixed a bug in the script that if you used a MySQL database prefix, integration would not work. Please see this post for more information! Special thanks to axisoverdrive for giving me access to his server and letting me troubleshoot the issue!

01/05/2007 - Fixed issue where if a user saved (not published) and published later, the post would not be added to the forum.

01/05/2007 - When a post is edited, it will also be edited in the forum.

01/08/2007 - Modified slightly so when posts are edited, so are the titles (if edited).

02/07/2007 - Major modifications to new version (now 2.05). The list follows:

• Reworked the code so it uses the $vbulletin object throughout the code especially during the bridging process.
• Users are bridged whether they checked the "Remember Me" box or not.
• Removed a couple of SQL calls that became redundant.
• Addressed a bug where if a user logged out of the dashboard, it only logged them out of VB.
• Added Inline Comments capability. Comments posted to the forum (using VB for comments) will now appear at the bottom of a WP Post when viewing the post.
• Author user names can now be linked to their VB profile page if desired.
• Added option to turn off posting to forum. All this really does is remove the "Select Forum To Post To" option when writing a post. (There you go AxisOverdrive )
• The $vbulletin object should now be available in all templates and most plugins.
• Fixed a bug where deactivating any plugin would semi deactivate this plugin.
• With the reduction in SQL calls, and the removal of now unnecessary variables, speed and memory use should be improved.
• PLEASE READ THE UPGRADE INSTRUCTIONS IF UPGRADING!

07/17/2007

• Fixed problem where upload iframe was a bit mangled.
• Fixed problem where users had to refresh the dashboard once after logging in.
• Fixed problem that arose from Wordpress 2.2.1 upgrade that would not allow activation.
• Fixed logout issue where users would still be logged into Wordpress.
• When a Wordpress post is deleted, so is the thread it created.
• Added option to allow thread posted from Wordpress article to be truncated, with a linkback to the article.
• Fixed issue when user re-activates plugin, and vb_threadid column already exists. Now checks for column first.
• Removed a stray VB_Init() call.
• Forums that do not allow threads will not be selectable in the drop down menu when writing a post.
• Forums are listed out in a parent/child nested pattern.
• (Note: 367 downloads of version 2.05)

11/29/07 - 3.00

• Added TABLE_PREFIX throughout the script instead of the get_option('vbb_VBPRX') call. get_option('vbb_VBPRX') is now deprecated.
• Addressed path issues by establishing $vwd first. If for some reason there are path issues on an install, the path only needs to be manually changed once, at the beginning of the script.
• Removed call to admin_db.php which seems to no longer be necessary.
• Changed all queries to the VB database to be handled by the $vbulletin object. This should facilitate multiple database configurations.
• Added limited XMLRPC support.
• Had to include a basic copy of the functions_wysiwyg.php file (functions_wysiwyg2.php) with a minor change in the sanitize_url function (now sanitize_vburl) as it conflicts with a new WP function of the same name. Otherwise, this is identical to the VB release. This was necessary to keep formatting somewhat uniform between the two.
• Removed unnecessary globals.
• Changed the global.php call so it always loads. $vbulletin should be available throughout the code (via global in functions).
• Edited some code around wysiwyg functions of VB, and conversions to vbcode.
• Added "Turn Plugin On" option.
• Fixed an issue with the forum list on the "Write Post" page. Default forum was not being auto selected in some cases.
• Modified from BETA so that the new functions_wysiwyg2.php file is loaded using the WP ABSPATH constant. Requires the plugin to stay in the plugins directory.
• Fix an error message when a post was deleted in VB, then edited in WP.

12/10/07 - 3.01

• Fixed two <? tags that should have been <?php (pointed out by Amenadiel)

03/31/08 - 3.02

• Fixed media-upload clash for new version of Wordpress (2.5).
• Added fix that will now delete threads in VB when the post is deleted in WP and not using Ajax delete.
• Added code to insert a default email address if VB users email address is blank upon bridging.

04/20/08

• Fixed a bug in user roles for the new version 2.5.1 of Wordpress.

05/08/2008

• Fixed issue where CSS was munging scrolling text box when selecting a forum during a post
• Fixed an issue where content encoding was getting screwey between WP and VP creating a lot of unintended characters (only on PHP installs where utf8_decode() exists (most)).

05/08/2008

• Fixed issue where post count of a user did not change

Sites Using This Plug-In:

• http://www.jeffsrecipes.com
• http://www.worldwidecreations.com
• http://www.xboxcircle.com
• http://www.detailuniversity.com
• http://www.daggersden.net/
• http://www.talkbronx.com/
• http://www.czeta.it

(PM me if you want to add your site here)

Special Thanks:

axisoverdrive - Debugging Help, Kyraal - Paypal Donation, Kalina - Paypal Donation, Wildcard27 - Paypal Donation, Shri - Paypal Donation, pspcrazy - Paypal Donation, Tomahoochi - Paypal Donation.

If you use this plug-in, and find it useful, please support us by nominating us for Mod Of The Month (MOTM) in the top right corner of this thread, or feel free to donate.

[j4ck455]

Originally Posted by Jafo232

Wordpress and Vbulletin must share the same database.

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?

[Jafo232]

Originally Posted by thebluelizard

I'm confused here. How is anyone getting this working in it's current form? I'm running WP 2.0 and it wasn't working. I looked through the code and found these lines:

I actually don't know how that's even working for anyone, because the links to activate the plugin are in the format ?action=activate. So, there's no activate GET variable as far as I can tell. I change those lines to this and it's working fine for me:

Maybe it requires register_globals on? In which case, that's a no-no, as it encourages insecure programming practices. Just want to make sure everything's secure for everyone

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:

wp_redirect('plugins.php?activate=true');
	} else if ('deactivate' == $_GET['action']) {
		check_admin_referer('deactivate-plugin_' . $_GET['plugin']);
		$current = get_settings('active_plugins');
		array_splice($current, array_search( $_GET['plugin'], $current), 1 ); // Array-fu!
		update_option('active_plugins', $current);
		do_action('deactivate_' . trim( $_GET['plugin'] ));
		wp_redirect('plugins.php?deactivate=true');

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.

[Jafo232]

Originally Posted by j4ck455

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?

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

[Jafo232]

Originally Posted by axisoverdrive

Hey Jafo,

Does this plugin jive with the new Wordpress 2.1?

Thanks!

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.

[axisoverdrive]

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?)

[thebluelizard]

Originally Posted by Jafo232

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.

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:

[j4ck455]

Originally Posted by Jafo232

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

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.

[dtdesign]

Originally Posted by Jafo232

The users must login via Vbulletin. When those users then go to the wordpress page, they should be logged in under the same username as they have in VB.

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 ?

[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.

[Jafo232]

Originally Posted by j4ck455

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.

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.