Plug-in on the vBulletin side

I have to disagree here and say this is unnecessary and not the correct way to write module for Drupal. The goal is no core changes whatsoever, and there are other ways to fix this issue in your actual module than breaking potential upgrades.

You need to look into hook_user or hook_form_alter instead. Drupal vB right now copies changes over to vBulletin using hook_user, and you can add to/modify that process to make it play nice on the vBulletin side. Or, you can use hook_form_alter to remove fields from the account edit screen on the Drupal side. You should never advise someone to make core changes. If you need some more hook pointers, I'm happy to help!

Not to worry mate, the change in the file does not actually delete or add anything, I simply added permissions to the edit button so that only admins can see it. Since the admins know not to change their password in Drupal but to do it in vB instead, it works perfect.

Besides, I think I'll just change the template to not display it instead ;) I haven't decided if I want to add the functionality for the profile edit to update vBulletin too, but if I do I'll just add it to the module. Seems like just extra non-sense to me, I'd rather have one central spot for changing my user profile instead of having my members confused as to which profile to change.

Another possibility is simply linking that edit button to their edit profile in vBulletin.

Yeah, I like the idea of linking the edit link to their vBulletin account.

I'd say just make it optional in the admin configuration... and keep thinking of good ways to alter the menu item instead of making site admins change user.module.

heh, just found this by accident: http://drupal.org/project/userprotect

Might be perfect :)

I realize I am late to the game, but as a current/former vBDrupal user there are a few comments I want to make.

1) COMMENTS: I think the comments system should remain on the Drupal side. It's awkward for a user who wants to comment on a node to all-of-a-sudden be redirected to a vBulletin forum.

2) PROFILE: One of the great things about Drupal is its ability to provide a simple user registration/profile experience. When one registers on vBulletin, or modifies their profile, there are so many fields and options that it can appear overwhelming. This is not to say that users shouldn't be able to modify/customize their vBulletin profile, but making the default profile feature is undesirable to me.

Many of us here are vBulletin veterans, and we have a good grip on what's involved. But there are a lot of users out there who prefer simpler experiences. Users more apt to join a community if it is easy and straightforward. Rerouting them back and forth, and throwing a bunch of different, complex looking interfaces at them, will undoubtedly deter at least some users from continuing the registration process.

I think it would be easiest on the user to restrict profile edits and views to Drupal, while allowing the user to jump into the vBulletin forums and make posts. Essentially, I wish that Drupal's forums had the "flat forum" appearance without having to hack the hell out of templates and css files. I much prefer to use vBulletin forums. But all the extraneous stuff that goes on in vBulletin (outside of simple thread creation and replies)... I could do without.

My ideal: "REGISTER at Drupal, LOGIN at Drupal, COMMENT at Drupal, VISIT our vBulletin forums and make posts. And here are some BLOCKS on the Drupal pages to let you know what's going on in the forums."

Again, I realize I am late to the discussion and that much of the intial development has already been done. I just want to provide my users with a consistent, easy, non-intrusive experience.

I appreciate al the work you folks are doing to provide Drupal-vBulletin integration, and I hope it will satisfy my needs. And like others, if I'm impressed and choose to go your route, I'll have no problems tossing a few duckets to you both.

Are there any updates regarding the Plug-In? (I know, your last post was just some days ago, but I'm looking forward to this promising Plug-In)

1) COMMENTS: I think the comments system should remain on the Drupal side. It's awkward for a user who wants to comment on a node to all-of-a-sudden be redirected to a vBulletin forum.

That's not a problem at all! vBulletin plugins are grouped together to make a "product." My plugin will actually be called a product in vBulletin when you install it, and if you browse out of the product manager and into the plugin manager you will see about 8 plugins listed for the product. When I finish the luxury features such as the comment system, if you would like to use it you simply install the single plugin rather then the whole product which installs many plugins at once. I like to do it this way so that those who only want the basics don't have to add the extras unless they want.

I haven't began development on the comment system yet, but I plan to keep the comments within Drupal, but they will be mirrored in a vBulletin forum since it's the only way to do it without modifications. You will have the choice to make the forum visible or not visible, so as an end-user there would be no way of knowing the comments are actually going into a vBulletin forum :)

2) PROFILE: One of the great things about Drupal is its ability to provide a simple user registration/profile experience. When one registers on vBulletin, or modifies their profile, there are so many fields and options that it can appear overwhelming. This is not to say that users shouldn't be able to modify/customize their vBulletin profile, but making the default profile feature is undesirable to me.

Many of us here are vBulletin veterans, and we have a good grip on what's involved. But there are a lot of users out there who prefer simpler experiences. Users more apt to join a community if it is easy and straightforward. Rerouting them back and forth, and throwing a bunch of different, complex looking interfaces at them, will undoubtedly deter at least some users from continuing the registration process.

I think it would be easiest on the user to restrict profile edits and views to Drupal, while allowing the user to jump into the vBulletin forums and make posts. Essentially, I wish that Drupal's forums had the "flat forum" appearance without having to hack the hell out of templates and css files. I much prefer to use vBulletin forums. But all the extraneous stuff that goes on in vBulletin (outside of simple thread creation and replies)... I could do without.

My ideal: "REGISTER at Drupal, LOGIN at Drupal, COMMENT at Drupal, VISIT our vBulletin forums and make posts. And here are some BLOCKS on the Drupal pages to let you know what's going on in the forums."

Thanks for the input, I'll put this up on the whiteboard.

Are there any updates regarding the Plug-In? (I know, your last post was just some days ago, but I'm looking forward to this promising Plug-In)

Yes mate! I ran into some issues with sub domains where the proper cookies were not being set, but I pulled another all-nighter on friday and got it taken care of.

I'm working on getting it out to you guys asap! I promise! Here is a quick shot of what's to come :-)

http://www.theoverclocked.com/drupaltin

I don't like to release anything unless I know the big bugs are worked out. I'm fairly certain I've fixed them now!

ETA: Two more days so I can write up some documentation so you know how to install ;-)

2) PROFILE: One of the great things about Drupal is its ability to provide a simple user registration/profile experience. When one registers on vBulletin, or modifies their profile, there are so many fields and options that it can appear overwhelming. This is not to say that users shouldn't be able to modify/customize their vBulletin profile, but making the default profile feature is undesirable to me.

Good point, but on the other hand the user could be confused if he has two different "UCPs" to manage. If it isn't much work to sync the user profile with vb by editing it in Drupal then the possibility of choosing between both options (only vb or vb+Drupal profile management) are better of course. But I don't see the Drupal+vb management as a "must have" feature for Version One of this plugin.

I ran into some issues with sub domains where the proper cookies were not being set, but I pulled another all-nighter on friday and got it taken care of.

Do you use parent Cookie Domain (.domain.com)? For me it worked that way with e.g. Gallery+Drupal or pmForum+Coppermine.

Do you use parent Cookie Domain (.domain.com)? For me it worked that way with e.g. Gallery+Drupal or pmForum+Coppermine.

Oh yeah of course. It didn't help at all though. The cookie was being set from the subdomain for the main domain thus browser security would kick in and the cookie wouldn't work. It worked in some browser (namely IE) but not in FF or Opera.

It's good to go now though!

Drupaltin has been released!

Get your copy now at http://www.TheOverclocked.com/Drupaltin

Hope you guys like it!!!!

-Jordan

This is great!

I've tested this on a vB 3.6 installation with 7500+ users and a fresh Drupal 5.1 installation. All vB users were imported to Drupal, and with the required changes to Drupal were able to log in to either site and use their cookie to move between either site. Logging out of one site logs you out of both sites.

One hitch with installing the vB product XML file, however. The includes/drupaltin_config.php file wasn't uploaded automatically via the admincp, so the installation failed (and an error message flashed by in admincp). I resolved this by uploading the includes file and the .xml file directly to the vBulletin directory and installing as a local product xml file. Perhaps this was documented and I glossed over it in my haste.

Updating the cookie path was required as my Drupal and vB sites were in different subdomains.

I do note, however, that activating the Drupal vB module at the same time as the Drupaltin module results in a function name conflict and Drupal fails to load.

There seems to be overlap in the functionality and goals of the Drupaltin and Drupal vB modules. This is not criticism on the achievements by both! I get that Drupaltin is in alpha, which to me means "did whatever was necessary to get it to work".

Albeit that they concentrate on different directions of user data sync, at first glance it appears that the modules use different methods of achieving the shared cookie state and different database access routines. My belief is that most of the nuts-and-bolts can be re-used by both if a standard is agreed upon and implemented.

So my question to both Drupal vB and Drupaltin is.. what are the plans, if any, to increase interoperability between these two Drupal modules?

I see the promise of a shared code base providing full-mesh vB <-> Drupal syncing of user profile and group/role data, provision of blocks for recent forum posts, user private messages, etc, etc. I also consider these modules more supportable than what I've seen of vbDrupal.

Again, great work, folks. I look forward to seeing this develop and possibly contributing to its success as possible.

This is great!

I've tested this on a vB 3.6 installation with 7500+ users and a fresh Drupal 5.1 installation. All vB users were imported to Drupal, and with the required changes to Drupal were able to log in to either site and use their cookie to move between either site. Logging out of one site logs you out of both sites.

One hitch with installing the vB product XML file, however. The includes/drupaltin_config.php file wasn't uploaded automatically via the admincp, so the installation failed (and an error message flashed by in admincp). I resolved this by uploading the includes file and the .xml file directly to the vBulletin directory and installing as a local product xml file. Perhaps this was documented and I glossed over it in my haste.

Updating the cookie path was required as my Drupal and vB sites were in different subdomains.

I do note, however, that activating the Drupal vB module at the same time as the Drupaltin module results in a function name conflict and Drupal fails to load.

There seems to be overlap in the functionality and goals of the Drupaltin and Drupal vB modules. This is not criticism on the achievements by both! I get that Drupaltin is in alpha, which to me means "did whatever was necessary to get it to work".

Albeit that they concentrate on different directions of user data sync, at first glance it appears that the modules use different methods of achieving the shared cookie state and different database access routines. My belief is that most of the nuts-and-bolts can be re-used by both if a standard is agreed upon and implemented.

So my question to both Drupal vB and Drupaltin is.. what are the plans, if any, to increase interoperability between these two Drupal modules?

I see the promise of a shared code base providing full-mesh vB <-> Drupal syncing of user profile and group/role data, provision of blocks for recent forum posts, user private messages, etc, etc. I also consider these modules more supportable than what I've seen of vbDrupal.

Again, great work, folks. I look forward to seeing this develop and possibly contributing to its success as possible.

Thank you very much for the input. Posts like this is what drives me to work harder on the script :)

The config file does need to be uploaded with an ftp client prior to running the installer. Another user mentioned the instructions were somewhat confusing in that section, but he edited the instructions on the web site. You can find the installation instructions at http://www.theoverclocked.com/drupaltin/install. If you are a registered member you can edit handbook pages and contribute new pages as well. Honestly I'm the only developer working on this product so far, so every little bit of help from you guys makes a huge difference. The instructions page I made it quickly before the release just so you guys had something to go off of.

Thanks for noting about the conflict between Drupal vB and Drupaltin, much appreciated.

As for future plans on Drupal vB and Drupaltin, I can really only speak for Drupaltin since the Drupal vB future is totally up to rszrama. I have talked to rszrama and he was happy about my proposal to add almost all of Drupal vB into Drupaltin. In theory, Drupaltin will soon be Drupal vB and more ;) While developing Drupaltin I decided to start from scratch and code everything as if Drupal vB didn't even exist. Since I did that I am now able to look at the pros and cons of each product does things and the final product will be the best of both worlds. By forcing myself to learn everything needed to create Drupaltin, I had no choice but to extensively investigate each and every corner of the required functions for Drupal vB and Drupaltin to work. This means I can find new and better ways of doing things :) You can see some future plans or request new features/fixes here: http://forums.theoverclocked.com/showthread.php?t=1952

The vbDrupal in my mind is basically dead. I used it before using Drupal which was right around the time 5.0 came out. I kept an eye out over at their site and realized that the developers don't much give a shit about anything. The concept of vbDrupal seemed pretty good until I realized that they were trying to reinvent the wheel which is why it takes so long for them to release new versions. I did not like at all that some Drupal modules and perhaps even some vBulletin plugins would not work with it.

Hence the birth of Drupaltin :-)

_{btw, sorry for the slow(er) replies, I've been trying to develop the script, goto school, and work 30 hours a week so my time is extremely limited :(}

For Bug reports etc. use this forum, please: http://forums.theoverclocked.com/forumdisplay.php?f=156

awesome thanks guys. I plan on playing around with it this weekend.

quick question. I have several different elements to my site: local guide, social network type section, race reviews, etc. I was thinking of using this module to break the site by subdomain and use vbulletin and drupaltin as the core registration database. so have local.site.com, race.site.com, groups.site.com all on separate drupal install/DB and use drupaltin to hook all into vB. You think this would work? having a few druapls installs on subdomains pointing back to one vbulletin install?

I' rather have multiple installs of Drupal with a couple key modules for each, then one install and a dozen modules. i think it'll keep the site faster and upgrading modules will be easier and not wreak havic on other elements.

any thoughts would be appreciated. thanks.

awesome thanks guys. I plan on playing around with it this weekend.

quick question. I have several different elements to my site: local guide, social network type section, race reviews, etc. I was thinking of using this module to break the site by subdomain and use vbulletin and drupaltin as the core registration database. so have local.site.com, race.site.com, groups.site.com all on separate drupal install/DB and use drupaltin to hook all into vB. You think this would work? having a few druapls installs on subdomains pointing back to one vbulletin install?

I' rather have multiple installs of Drupal with a couple key modules for each, then one install and a dozen modules. i think it'll keep the site faster and upgrading modules will be easier and not wreak havic on other elements.

any thoughts would be appreciated. thanks.

I would highly suggest you wait for 5.x-2.0 ;)

It shall be perfect for that use :)

For those on 4.7, are we limited to the Drupal vB module or are there plans for a Drupaltin 4.7 release? A lot of us have modules and such on our Drupal sites that are not currently in 5.0 release (and may even be a while until they get there) so a migration to 5.0 isn't possible at this point (but planned!).

Having 2 projects with the same scope is also kind of confusing at this point, but better to have more people working on the issues of forums and Drupal!

@JStarcher: Thanks for sharing your code. I'm currently cleaning up Drupalvb and will probably integrate some ideas from Drupaltin, though not sure yet, which ones. Unfortunately, access to your SVN repo is currently broken. So if you have better code somewhere in HEAD, I'd be glad to review (a tgz would be sufficient). Thanks!

Marking this issue fixed (queue clean-up).