vbDrupal 5

[elmuerte]

First some administrative things.

I've converted the vbdrupal project from using CVS to SVN, this means you will have to checkout the things from SVN and ofcourse use an SVN client.
The reason for this change is that the Drupal team moved some files around in Drupal 5 and CVS doesn't properly support moving of files.

The current development version of vbDrupal resides in:
https://svn.sourceforge.net/svnroot/vbdrupal/trunk/vbdrupal-ng
The trunk will be used for the latest development branch, e.g. the main branch
Major released will need to be branched off the main branch. So vbDrupal 4.7 development will be done in the following location:
https://svn.sourceforge.net/svnroot/vbdrupal/branches/vbdrupal-4.7
(note that the trunk is still vbdrupal 4.7, it doesn't contain any Drupal 5 stuff yet)

So:
vbDrupal 4.6 = EOL
vbDrupal 4.7 = stable
vbDrupal 5.0 = in development

Also gman (a.k.a. gregman on sf.net) has been added as developer to the project. (and more will follow?)
I will still do maintenance for 4.7 and maybe some minor development.
For 5 I will mostlikely do some management and a bit of development here and there (e.g. I hope others pick up some dev work).


-----

Ok, so now about vbDrupal 5. There are a couple of things that must be done and there are a couple of things that requires some brain activity.

1) First of all we will need to make the same adjustments to the directory layout as done Drupal 5. And we need to come up with a userfriendly way to make sure people upgrading from 4.7 to 5.0 will also have their 'old' stuff cleaned up.
2) Also we need to add module .info for the vbDrupal modules, not really a major thing.
3) We also need to upgrade our modules to be 5.0 compatible, afaik this isn't a big deal as it was between 4.6 and 4.7.

Now the bigger things.

4) We need to figure out what has changed between drupal 4.7 and 5.0 that affects how vbDrupal works. An probably find out where we can improve the way vbDrupal works (maybe they added stuff we can abuse so we don't have to touch a lot of core files).

5a) We may need to improve or change the installation procedure. The vBulletin product XML is nice in one way (e.g. saves us creating an installer). But I don't have a lot of trust in that system (e.g. when installation fails the user is left with a broken environment). So maybe we could adjust the installer that comes with Drupal 5 and do everything from there. The installer ofcourse should also import the templates and other vBulletin stuff. But we could simply hook into the normal product installation of vBulletin for that. But it'll happen behind people's back. It's just that the creation of tables and importing of data is done through the Drupal installer. This would also mean that we need to change the update script to "import" update vBulletin stuff. So for a .1 or .2 release people would only have to execute the update.php script after they have copied the files.
5b) Alternatively we should clean up the product XML to kick of directly with Drupal 5 so that people don't have to perform the whole "import XML, visit update.php" just to install it.

6) testing


well,... that's about everything that come with for now.

[Gman]

Since we are starting a new part of the project, I thought I would bring something up again. I know that the footprint of the vbDrupal changes was greatly reduced from 4.6 to 4.7, and I hope we can keep the footprint to be small with 5.0.

But I have always thought that a whole distribution for vbdrupal seems like a lot for drupal users. Drupal users might think that more or most of the distro is different and incompatible with normal drupal modules/operations.

It makes sense to have a whole distro for vBulletin users, so they don't need to venture somewhere else to get the whole drupal package, but drupal users moving over to vbdrupal (like I first did), don't know the changes to the core/modules and might balk when they see a whole new distribution.

Maybe if the affected files, and the general extent to the changes, are clearly outlined (am I volunteering??), then this might matter less.

Or we have to distro's, one for vbulletin upgrades to vbdrupal, and another for new users, or drupal to vbdrupal conversions.

Just opening up the thought session as this is the time to do it.

Maybe we should take a poll on how many people start with vbulletin and how many are coming from drupal.

[elmuerte]

What do you mean? You want to create a package with just the changed files?

well.. we might be able to create a conversion package

[Gman]

Yes, a conversion package, that only has the updated folders/files along with the conversion scripts, if any.

I understand that most people come from vbulletin, so the other installer was fine, but for drupal people, a conversion/update package (instead of a whole new 'drupal' package) would be less intimidating.

Just trying to make vbdrupal more palatable and less intimidating to drupal users.

[Gman]

One reason for packaging a smaller 'For drupal user's' distro, that only includes the updated file, is that 5.0 will have recipe possibilities, preconfigured installations that ship and install extra modules/settings. If we have a 'Changes only package', then it can be dropped into one of these recipe installs, over-writing the needed files, but leaving the rest of the recipe distribution intact, instantly make a 'recipe install' into a 'vbdrupal recipe install'.

[bugsbunny]

http://drupal.org/node/100203

beta 2 now released!

[bugsbunny]

http://drupal.org/drupal-5.0-rc1

drupal 5 rc-1 released!

how is vbdrupal coming?

[Gman]

Yep, I just saw that too. Downloaded the RC, though I have not much time to fiddle with it. Now that it is in RC, the strings, variables and APIs should be mostly stable, with bug fixes being the only concern. So I guess now is the time to really see what needs to be updated.

I just was given a new web dev job, specifically as a Drupal site developer for a small company. So I will be in Drupal for a living now :). But I am also crazy busy wrapping up my last job and trying to impress the new folks.

Elmuerte hopes to give direction to the next group of vbdrupal devs (which I hope I am not the only one :eek: ), so maybe we will all have a fun peak at the code over the holiday break and then see where we can go from there.

[Tom-E]

I'm not the most experienced of programmers, but I think I'd be able to handle reasonable tasks.

Winter break is coming up, and I'd be willing to code during it!

Let me know!
Tommy

[elmuerte]

I just wrapped up some very busy weeks so I have more time for other things (like vbdrupal development).

[Tom-E]

Number 2 on the list:

adding .info's

Just checkout the attachment, hopefully everything is as it should be.
Cheers

[Roi Danton]

I'm wondering if you have looked on drupal vb (http://drupal.org/node/58779).

Though it isn't ported to Drupal v5 it's a good approach to the Drupal - vBulletin issue. I think for most people it is important to sync user data/session and the possibility to upgrade to the newest version of Drupal in time. The modules of vbDrupal and commenting using vB in Drupal are nice though, but they aren't essential for a Drupal-vB site. At least not so important like the assurance of being able to update Drupal as fast as a new version is released.

So maybe it's more wise to let vbDrupal 4.7 like it is and just using modules as bridge between Drupal 5 & vbulletin instead of modifying vbDrupal 4.7 core files to match Drupal 5 ...

... most files in /include/ differ from Drupal 5 to vBDrupal 4.7. It would be much work to upgrade vBDrupal and this has to be redone on every major update of Drupal.

So I think it is wiser to concentrate on a module for Drupal which manages the user sync. I don't know the vBulletin API (http://members.vbulletin.com/api/), but it has to been possible, e.g. it works well between gallery 2 and Drupal (all the include files needed are part of the module).
If that has accomplished the headache caused by changed Drupal core files, installation routines etc. would never appear again. Not to speak from the compatibility with other Drupal modules.

Additionally more people would use such a module than now using vbDrupal b/c the fear of using a module is much lesser than using a fork which maybe isn't supported say in two/three years.

[Caerydd]

Yes, but where does it leave us who have been following vbDrupal? Database syncing sounds more...risky than running directly off the vBulletin database >>

[Roi Danton]

Database syncing sounds more...risky than running directly off the vBulletin database >>It isn't. Drupal vb compares the User Name of vB & Drupal to manage Login/Edit/Logout Actions. Drupal has it's own users in its tables and vB as well. So the full functionality of both software packages is guaranteed.
Of course Drupal vb isn't capable of what vbDrupal is (interaction of both software packages) but this interaction vbDrupal offers should be possible with a module, too, like the gallery 2 module proofs: http://drupal.org/project/gallery

I don't think that creating such a module means more work than creating an own fork.

[Caerydd]

It may not, but the idea of transferring over drupal vb, after building a fairly extensive system on vbDrupal, gives me the creeps at the amount of work.

[elmuerte]

Yes we know about drupal vb, it has already been discussed on the forum.
The way vBulletin is set up makes it impossible to use create a module that includes the same functionality as vbDrupal currently offers.
So a drupal module would only be able to directly modify/access the vBulletin tables.

The number of changed files between the stock Drupal and vbDrupal is actually quite minimal:

includes/bootstrap.inc (a few minor changes, mainly to redirect bootstrapping)
includes/common.inc (a few minor changes)
includes/file.inc (because of a function name collision)
modules/user.module (major changes)
modules/system.module (a few minor changes)
modules/node.module (only change is to change of the initial site text)


the reason why there are so many differences between vbDrupal 4.7.5.0 and Drupal 5.0 is that there are a lot of differences between Drupal 4.7.5 and Drupal 5.0

[Roi Danton]

Hm, that's doesn't seem to be more work than a module. But so it would be easier to build vbDrupal 5 on Drupal 5 and not on vbDrupal 4.7.5 IMHO? Is there a documentation on the exact changes that are done between Drupal 4.7.5 and vbDrupal 4.7.5? (okay, I could compare the files, but a doc would be a little nicer ;) )

[elmuerte]

nope, no docs yet. But I have started documenting the changes for vbDrupal 5.0

[Gman]

Well, Drupal 5.0 is out, http://drupal.org/drupal-5.0. I really do need to make time to do some stuff for elmuerte. Real life should be reaching a normal flux very soon.

[elmuerte]

You can see the changes I made to Drupal 5.0 to convert it into vbDrupal here (http://vbdrupal.svn.sourceforge.net/viewvc/*checkout*/vbdrupal/trunk/vbdrupal-ng/DevelopmentDocument.html). It will be updated everytime I make changes.
The current state of the code is: not working
I need to adjust the system module and the user module before I can see what changes are required for the vbDrupal specific modules. After that we can start working on the new things for vbDrupal (e.g. proper installer, improved update system (without the vbulletin plugin step), and "stock"-patch). And ofcourse the bug hunting stuff.

[elmuerte]

88

still a lot to do

[Gman]

For the 'Proper Installer', I believe the profile aspect of Drupal 5 may help tremendously. With it you, Drupal is bootstrapped and you are allowed to install any module you want and write to the database. Most people will use it to offer a Drupal distribution (like a blogger one with the blogger modules pre-activated).

But we could also use it to write to the database, thus creating and altering any tables that we need to from inside the drupal installer.

Since the Drupal and vB databases are together, we can use them to install all the vB plugins that are needed directly, thus skipping the plugin aspect that vbDrupal 4.7 depended on.

I have been writing a few of these fpr my job, so I am becoming familiar with them. Hopefully this will help get the 'installer'/'upgrade' path going more quickly.

[elmuerte]

the profiles thing is an partial sollution, vbdrupal doesn;t need a database configuration but it does need the vBulletin location, so that part has to be changed.

[Gman]

I was thinking more of the database entries that are needed from the product.xml file for the installation of the vB hooks and plugins. This will help vbDrupal seem more of its own product instead of something installed into vB. Since I am coming from a Drupal perspective, that is better. Just my opinion though.

[Tom-E]

Is there any information on what still needs to be done for Vb 5?