I've decided to use the blog feature of Drupal to do some more regular status updates about the vbDrupal developments. You know, the normal blog like reporting and ranting about stuff I've done, are going to do and the things I've thought about. So here's the first development update on vbDrupal 5.

Not so long ago I released the first alpha release of vbDrupal 5. This alpha release contains only the bare minimum to have a vbDrupal 5 system running. The main goal was to make sure that an installed version of vbDrupal 5 would operate without problems. An important side goal was to try to move even more code out of the stock Drupal code.

The original vbDrupal 4.6 contained a lot of changes to various parts of Drupal, this made maintenance quite troublesome. With vbDrupal 4.7 I tried to make as much use of the Drupal module system and moved various other code outside the core files so that the core files only had a few line or changes additions. Hower a couple of stock Drupal modules were still modified a lot, most notably the user module. I didn't do much research in how to properly alter the behavior of the user module to fit our requirements, but it all worked out quite well. For vbDrupal 5 I wanted to make it even better. So I started from scratch for the user module which resulted in the vbUser module that contains all vbDrupal specific user module code. In some cases I could simply alter the behavior through Drupal's hook system. In other cases I had to forward a method in the user module to the vbuser module. This should make merging new code from Drupal much easier. Or so I hope. In the end the current alpha release contains about 18 changes to the stock Drupal code (in total). However, this will probably increase because the install/update system also needs to be adjusted in a couple of places.

The items on the TODO list for the first beta release are to change the update and install routine. Since Drupal 5 there's a nice graphical installation, before that people had to manually edit the config file and create the database structure. For vbDrupal people only had to adjust a single line in the configuration file and import the vBulletin product.xml. This last step is something I didn't like a lot, for a couple of reasons:

1. Install code is quite annoying to write. I can't really use a normal text editor like I normally use for PHP programming, I have to edit the install code in the browser. And the interface isn't really great
2. A bug in the install code can cause a lot of problems. If the install code in the products.xml contains a bug that results in a PHP error the installation will be very broken. Because of this I had to create an additional script to undo the faulty initial installation and create a page where people could create a dummy product.xml so they could upgrade.
3. It's a single run installation. Everything in the install code is done in a single webserver request. This is not always a big problem unless you have to do things that take a lot of time. In vbDrupal 4.7 we restored the Drupal user table and thus we needed to copy all vBulletin user records to the Drupal table during installation. With a lot of records this often resulted in problems.

With the exception of the installation code the while vBulletin product.xml stuff is great to be used for vBulletin plugin installation. But it's not very well suited for vbDrupal, specially not because Drupal now has a nice graphical installation process.
An other annoyance factor (to me at least) was the requirement to import the product.xml and run the update.php script everytime a vbDrupal update was installed. It would have been much nicer if this could all be done in a single step. So that's why I set the goal to change the vbDrupal installation and update procedures.

I didn't want to lose the functionality of the vBulletin product.xml because it makes things so much easier for the developer. The product.xml contain the vBulletin templates, admincp settings, vBulletin plugin code and various other vBulletin information that can be added through the admincp. With a simple step all this stuff can be exported to the product.xml file. Manually extracting that information and inserting it into an install script is just plain annoying and error prone. There was just a major downside, vBulletin didn't have an API to import a product.xml into vBulletin from an other PHP script. So I was forced to write my own code and this is what I've done in the past couple of days. Well... almost anyway, not everything from the product.xml is imported, just the stuff that vbDrupal is using so far. And ofcourse there are some restrictions to the functionality, I couldn't use the install code at all. But that's not really an issue because I wanted to use the Drupal method for installation anyway. So right now I'm able to import the product.xml directly from within Drupal. All I have to do is move the previous install code to the Drupal system.

Ofcourse this sounds easier than it actually is/was. Since vBulletin actually uses an incremental installation routine for the vBulletin addons the install code was also incremental since the first vbDrupal release. The Drupal system works a bit differently, there's a different install and update path. At installation it assumes it will be installed to the most recent update. Porting the old code from the vBulletin product.xml to the Drupal system isn't much of a problem. However, making sure it is all executed in the proper order is. Right now I'm pretty sure that and installation from any stable vbDrupal 4.7 release to vbDrupal 5 will go without "much" problem (ofcourse I haven't tried it yet). But upgrading from a pre-vbDrupal 4.7 might become a bit more tricky. Maybe I have to split that up into two steps, where the user first has to update to a 4.7 system (using a vBulletin product.xml) and then the normal Drupal update stuff. Ofcourse I could also label the vbDrupal 4.6 to vbDrupal 5 upgrade path as not possible (e.g. first update to the latest vbDrupal 4.7 before upgrading that to vbDrupal 5). But that still leaves a few open issues, because as far as I can see the Drupal installation system is also a single instance system, and that will ofcourse will make syncing users during the installation a bit more difficult.

Anyway... that's still stuff that is in front of me and something you might read about in the next update.