Port Drupal vB to Drupal 7

SUN can you tell us what would be the best way to move forward? Are you able to devote time if we provide funding?

I believe integration with D6 and VB4 is the first priority. I say this because VB3 is getting older by the day and the new mobile version for VB4 is crucial in my opinion. Opinions?

Described as a giant beast and a black hole. http://drupal.org/node/691736#comment-3921986

However a D7 version of VBdrupal is also needed and it would be nice to hear input on any plans moving forward and if funding is required.

I'm also willing to chip in for funding and help in any way I can. D6 + VB4 is critical, D7 is definitely needed.

Subscribing

Hey,
Small update: We have a working port of Vbulletin 3.6 to Drupal 7, it still needs a security audit and best practices run through and we will be doing that in coming few days. We needed VB 3.6 to work with 7 so thats the path we took, I will be interested to see if we can do vb 4 with 6 and maybe even 7 given there is funding.

@Sun if you are listening, what would be the best way to share the port?

Any progress on this and has anyone been able to contact @sun?

Sun is currently advertising for a co-maintainer on the project page.
Anyone up for that?

Sorry - I've clarified the current maintenance status of this project on the project page: http://drupal.org/project/drupalvb

@edb showed interest recently, so hopefully you'll see some nice follow-ups and patches from him on this issue very soon.

Hey guys,

Sorry its been like a month, real life ended up catching up with me!

Here is the patch that ports over DrupalVB to D7. I haven't managed to do thorough testing, but everything seems to be working OK. The most notable omission at the moment is I had to force the language ID to be 1 ("en") for all users. This will be fixed soon. Also, I have not updated any comments so they could be misleading. Overall, the code is working - but needs a good cleanup.

I thought it would be good to submit the patch here to show progress (and maybe get our own branch on the repo!).

oink! :) ok, that's a "true" work-in-progress patch ;)

How about this: If you stay within the 7.x-2.x-edb branch, I'd grant you commit/write access to the repo? :)

It sure is :)

Yep that sounds great Sun, I'm going to start the clean up work tonight!

I've got a few commits ready to go that fix up some of the major issues with the patch above. I see my branch, but I can't seem to write to it yet, any ideas what could be wrong?

This patch should be applied against the 7.x-2.x-edb branch.
It fixes the major issues with the previous patch and tidies up the code a bit. Still a lot of work to do, but we are getting there :)

Yep that's where it is, but unfortunately the latest code isn't committed there as I don't have access to it. Attached is the latest version of the module for D7.

What version of VB are you using? I will try and replicate the issue you are having.
Can you double check you correctly set up the VB variables as specified in the README.txt too.

Thanks for the extra info, I will take a look now

Using a fresh installation of 7.14 and VB 4.1.10 I cannot replicate the issue you are having :(

What version of Drupal and what other modules do you have installed?

EDIT: Also, what system was the user originally created on, VB or Drupal?

I found that I could replicate your issue when I had a user logged in on Drupal, but not logged in on Vbulletin and then tried to log in using VBulletin.

Try the updated module attached! (also fixed some permissions issues with this one)

I'd like to post patches against the lastest drupal 7 version of this module. The latest commit to git is: http://drupalcode.org/project/drupalvb.git/commit/dd9a23e, but it seems like #1106950-25: Port Drupal vB to Drupal 7 is more up to date? Please advise.

Yes the module in #25 is far more mature, I would advise patching against that. I will contact Sun again and see if he can help us out and push up the latest code to Git.

This is a patch against #25. Note that this patch hasn't been fully tested, I just fixed the bugs and issues that prevented the module from working in my particular usage case. Here's a summary of what's in the patch:

- default values for initial database connection is read from vB config file (tested with vB 3.8 only)
- add support for specifying a port# to the vb connection
- fixed bug and cleanup in database settings submit handler.
- initialize the user mapping table only when the table is empty, otherwise ignore
- change the admin menu path to admin/config/system/drupalvb
- fix bug typo bug in _drupalvb_init_user_map ($vb_user should be $vbuser)
- add multi-site support by allowing the config.php file to be located in the conf_path() directory (same location as settings.php file)
- add function to lookup vb userid based on drupal uid. Replaced multiple db_query's with this function
- fixed bug in drupalvb_user_logout - db_connect called without db_disconnect, replaced with drupalvb_db_is_valid instead

There are a few more things that I noticed in the module that can be done better. For example, the insert queries should be re-written to use the db_insert() query builder object. I can provide a patch for these secondary issues as well once the 7.x dev git branch is brought up to date with the recent changes.

I've committed @edb's patch from #25 to the 7.x-2.x-edb branch. @edb has write access to the git repo now.

Note that there are various coding style problems in the new code. Please read http://drupal.org/coding-standards and sub-pages.

Leaving #31 for @edb to review and incorporate.

Lastly, this change happened all over the place:

-  if (!drupalvb_db_is_valid()) {
-    drupal_goto('admin/settings/drupalvb/database');
-  }
+
+  //Check database is ok
+  drupalvb_db_connect();
+  drupalvb_db_disconnect();

I'm fairly sure that this is not correct. Switching the database connection back and forth should not happen all over the place. The purpose of drupalvb_db_is_valid() is to verify whether any vB connection has been setup already, and if so, whether it works. The new code continues with its regular execution even if there is no valid connection, which is wrong.

That said, I just committed @ttkaminski's patch, since the changes mostly make sense to me.

Additionally committed attached coding style fix-up patch. Existing D6 code was partially wrong already. Tried to limit the fixes to new code as much as possible.

Thanks @sun. I agree that the code

drupalvb_db_connect();
drupalvb_db_disconnect();

needs to be corrected. I was planning to make this fix in my previous patch, but then decided to keep the changes to a minimum. I'll make another pass on the code and fix any obvious issues that I feel need to be corrected. BTW, did you use a tool to fix up the code to meet the coding standards, or was it done manually?

I used the coder_format shell script, which I authored years ago to reformat any code for Drupal coding standards (note that some rules have changed since I posed that example; especially my comment on string concatenation is obsolete). The script still ships with the Coder module. However, usage of coder_format is semi-automated only. You still have to manually review all changes to correct any bogus changes. Ideally, you should write coding standards compliant code right from the start.

As clarified in the best practices for maintaining projects, coding style fixes should not be done within a module porting effort. That's why I tried hard to limit the changes/fixes to new code only.

Here's another patch. This one is against commit 40918211a2. Changes:

- remove drupalvb_db_connect and drupalvb_db_disconnect
- update drupalvb_db_is_valid to statically cache results
- remove drupalvb_get(), call drupalvb_get_options() and drupalvb_get_config() etc directly
- remove drupalvb_get_default_db_prefix(), not needed for drupal 7
- rewrote drupalvb_db_query to use Database::getConnection directly
- replace INSERT INTO with db_insert()
- some optimizations
- conform to coding standards
- update some LIMIT queries to use db_query_range instead
- update some drupal 6 style placeholder in queries with drupal 7 style ones
- fixed bug with call to theme_item_list. Should be theme('item_list')

One thing I noticed that should probably be addressed is at the top of drupalvb.module we have:

require_once drupal_get_path('module', 'drupalvb') . '/drupalvb.inc.php';
require_once drupal_get_path('module', 'drupalvb') . '/drupalvb.inc';

Yet, in various functions it includes the file(s) again.

module_load_include('inc', 'drupalvb');

Not a big deal, but something that needs to be eventually addressed.

Can someone please review and provide comments on my patch. Is it going in the right direction? If so, please merge into the 7.x branch.

Am I right in assuming the D7 port is only supporting vB4 integrations ?

Got a potential client that could chuck some cash towards getting this finished if anyone here has time.

I made a few more fixes to this module after testing it. It is currently deployed on a large site and working well for me. Attached is a patch against commit 40918211a2 on the 7.x-2.x-edb branch. It includes all the changes in #36 plus:

- updated db query functions
- when creating a new user, still attempt to update the mapping table, even if the user exists
- added support for current_pass, and updating other user accounts passwords
- remove validation from hook_user_presave and move it into a user_account_form_validate function
- fix drupalvb_login_validate to properly work with drupal7 authentication validation framework
- fix calls to watchdog. arguments were wrong.

It's still recommended to test these changes to make sure they work for your setup. FYI, I'm using VB 3.8, but it should also work with VB4. I'll probably have a chance to test it with VB4 in a few months, when I do an upgrade.

Fixed bug: Properly create userfield and usertextfield rows when new forum user created.

Looks great! Commited to edb branch with minor styling fixes.

Unless anyone has any objections I think we are at a stage where we can release a dev branch for public consumption.

Here's one more patch against the latest commit 9b5ab7b93.

Changes:
- use drupalvb_get_userid() as much as possible. Only when no mapping exists, attempt a lookup by username.

I think we are good to go with an official dev version.

Fixed in bug introduced in the previous patch. Patched against commit 9b5ab7b93.

Just thought I would provide some feedback. Our client Atari.com wants to use this ASAP to integrate their Forums and Atari.com.

I grabbed the drupalvb.zip from post #25, applied patches 33-43. Installed mod to our staging instance. Configured cookie domains on Drupal and VB, put in all the vB template replacement variables, etc... Here are the results of our test cases...

Test Case 1: When logging into Drupal, a user should also be logged in to VB.
Results: Success. Both systems indicate logged in state.

Test Case 2: When logging out of Drupal, a user should also be logged out of VB.
Results: Success. Both systems display a logged out state.

Test Case 3: When logging into VB, a user should also be logged in to Drupal.
Results: Success. Both systems indicate logged in state.

Test Case 4: When logging out of VB, a user should also be logged out of Drupal.
Results: Success. Both systems display a logged out state.

Test Case 5: When creating an account on Drupal, an account should also be created on VB and both systems should indicate a logged in state upon successful registration.
Results: Success. Accounts created on both systems. Both systems display a logged in state.

Test Case 6: When deleting an account in Drupal, the account should also be removed from VB.
Results: Success. Accounts removed from both systems.

Test Case 7: When blocking an account in Drupal, the account should also be blocked from VB.
Results: Success. Accounts blocked on both systems.

Test Case 8: When blocking an account in Drupal, the account should also be blocked from VB.
Results: Success. Accounts blocked on both systems.

More to come....

@mpaladino - great, thanks for the report (TC8 should read VB->Drupal instead of repeating the same as TC7, right?)

So, is it time for either a 7.x-dev release, or someone care to post a zip of a fully patched module so that even more testers can be tempted?

I've made a small bug fix since #43 related to users changing their passwords. Attached as a patch against git, and also including a fully pre-patched zip.

@Leeteq Actually... TC8 was a duplication on my part. Disregard. I would definitely post a dev release. We've got a few other clients who'd be interested in being test subjects as well, so we could get more QAT and UAT across multiple scenarios.

@ttkaminski I'm going to grab your latest patched version tomorrow and re-test. Additional test cases for tomorrow will include updating email, password, and username from the Drupal end to see if they sync to VB. I'll let you guys know how it goes.

@mpaladino Not sure if you are testing against vb3.8 or vb4. I can confirm it works fine with vb3.8. I've recently installed it with vb4, but it fails when inserting a user into the vb database because some of the columns introduced in vb4 do not have default values setup for them. You can either update your user table in vb so that each column has a default value, or wait until I put together a patch for this.

@ttkaminski Great point. Client is using vb 4.2. I can verify that when i created a new account on Drupal, a new record was written to the VB user table. See crappy Skitch of the written record in phpMyAdmin table here.

It looks like it's writing to the table. Not seeing any errors being thrown.

Thanks for all the feedback, testing and patches! I have committed the patch in #46. I have also merge the 7.x-2.x-edb into the 7.x-2.x branch. When d.o updates I will close this issue as fixed so we can start creating more specific issue threads relating to specific bugs as this thread is becoming a bit of a monster.

Hm. @edb: Did you intend to delete README.txt & some other files during that merge?

Some of the new code could also use a Coder module review and/or CS fixer to follow Drupal coding standards. I performed some basic corrections in attached patch.

@mpaladino - Ok, maybe it's some difference in they way vb4 was setup for me. I'll create a patch if other people complain about this issue.

Seems that the current 7.x-2.x branch is not updated or changes from edb branch has not been merged completely.
I'm getting this error
Warning: file_get_contents(sites/default/modules/drupalvb/README.txt)

Latest version from branch 7.x-2.x-edb works perfectly fine with VB 4.1.2,
Also note that i encountered and error with block_top_posters, the fix was easy
Replace the following line in drupalvb.module

$result = drupalvb_db_query_range("SELECT posts AS count, userid, username AS name FROM {user} ORDER BY posts DESC", array(), 0, $num_items, array());

with :

$result = drupalvb_db_query_range("SELECT posts AS count, userid, username AS name FROM {user} ORDER BY posts DESC", array(), $num_items, array(), array());

Also i wasn't able to use mysqli for database connection since drupabvb looks for includes/mysqli folder that doesn't exists.

I think it's ready for a beta release

Thanks everyone

@edb: Can you incorporate/commit #52 (ideally ensure coding style/standards via Coder module throughout all of the code) and verify the latest follow-ups? :)

Some useful db functions are also missing in drupalvb.inc, they can be use by other modules the rely on drupalvb to connect to vb :

/**
 * Insert into remote system database.
 *
 * @see db_insert()
 */
function drupalvb_db_insert($table, $options = array()) {
  drupalvb_db_is_valid();
  return Database::getConnection('default', 'drupalvb')->insert($table, $options);
}

/**
 * Update system database.
 *
 * @see db_insert()
 */
function drupalvb_db_update($table, $options = array()) {
    drupalvb_db_is_valid();
    return Database::getConnection('default', 'drupalvb')->update($table, $options);
}

/**
 * Delete from remote system database.
 *
 * @see db_delete()
 */
function drupalvb_db_delete($table, $options = array()) {
    drupalvb_db_is_valid();
    return Database::getConnection('default', 'drupalvb')->delete($table, $options);
}

Dear community!

First one - thanks All for this module!

I did finished VB4 and Drupal 7 integration process.

Why problem in this integration:

Problem 1 - different hashing algoritm - D7 - SHA512 - VB4 - MD5(MD5+Salt).
Solution 1 - change D7 to MD5 in this method - creating new file in D7/Includes directory and add to D7/default/setting.php this line:

$conf['password_inc'] = '/includes/md5passwd.inc';

Problem 2 - remote insert new user account to VB4 db (field adding error and different password hashing )
Solution 2 - change DrupalVB module file drupalvb.inc.php - replace all to file:
old -

$salt = '';
  for ($i = 0; $i < 3; $i++) {
    $salt .= chr(rand(32, 126));
  }

new -

 $salt = '';
    for ($i = 0; $i < 30; $i++) {
      $salt .= chr(rand(33, 126));
    }

and
old -

if (isset($edit['md5pass'])) {
    $passhash = md5($edit['md5pass'] . $salt);
  }
  else {
    $passhash = md5(md5($edit['pass']) . $salt);
  }

to new -

 if (isset($edit['md5pass'])) {
      $passhash = md5(($edit['md5pass']) . $salt);
    }
    else {
      $passhash = md5(($edit['pass']) . $salt);
    }

and new -

 $userid = drupalvb_db_insert("user")
    ->fields( array(
      "username" => drupalvb_htmlspecialchars($edit['name']),
      "usergroupid" => $usergroupid,
      "password" => $passhash,
      "passworddate" => $passdate,
      "usertitle" => $usertitle,
      "email" => $account->mail,
      "salt" => $salt,
      "languageid" => 5,
      "timezoneoffset" => $timezone,
      "joindate" => $joindate,
      "lastvisit" => time(),
      "lastactivity" => time(),
      "options" => $options,
      "fbuserid" => 0,
      "fbname" => 0,
      "fbaccesstoken" => 0
    ))->execute();

Edited and working for me module inserted.

Hi VictorGuzy, could you upload the password file you created please?

Thanks

I use module from post #25 with D7 and vbulletin 3.8.7. It works perfectly, but have one big trouble.

In drupal 7 "drupal_users" table i have thats id's:
uid - 5,6,9,10

When i use "Export Drupal users to vBulletin" i get in "vb_user":
userid - 5,6,7,8

Linked ids is broken. How i can fix it?

@Paldru; please dont hijack issues like this. Open new ones for your support or bug reports instead. This one is about porting to D7.

I have used this module with the latest checkout from the 7.x-2.x branch with vbulletin 3.8.2. This all works correctly with regards to user logins, registrations and deletions.

I haven't tried the user export/ import as we have had no need for this at present.

i have problem with password: in vbulletin 4 is not sync.

Am looking to update my current D6 site to D7, and was wondering is this actually working now?

Have tested it on a local set up, and while the users are getting copied across, I am unable to login with a few test users.

@sun; Can we have a status update from the perspective of the maintainers here, please?