Today I spend some time on the update process. The installation was already working (good enough). Previously, for the alpha release, I worked on the installation system a lot. Today I decided to test the system with previous releases of vbDrupal.

I've picked three releases to test:

• The first stable vbDrupal 4.7 release: 4.7.3.0
• The new year's release: 4.7.4.4
• The latest release: 4.7.6.4

There is not a significant difference between the first stable4.7 release and all releases after that. I have been using the Drupal update system ever since the first stable release. So theoretical every release after 4.7.3.0 should have the same issues (if any).

Well, that assumption appeared to be false. My vBulletin (3.6.7) install was using utf8 and mysqli. And I forgot that the 4.7.3.1 release was broken for mysqli. So I ended up with a couple of missing tables. Not a major problem, I simply added those tables to the database dumps I made for testing.

So, starting with proper database dumps of those versions I started testing the update system. And soon enough I found some bad code and some debug code I should have removed in the first place. With a few minor adjustments the update process appeared to work as it should. Updating from 4.7 to 5 was just as easy as it was in a normal Drupal.

There is however a very important note. For this test I started with a clean vbDrupal 4.7 installation just to create the database structure. After successful installations of the chosen versions I deleted all vbDrupal 4.7 files and copied the current vbDrupal 5 files. After which I started the update process. This works well when you don't have any 3rd party themes or modules installed. If you do have those installed you will probably have to mess around with some files and new versions of those modules (before running the update).
Starting with Drupal 5 all stock modules have been moved to separate directories for each module. So simply coping the new files will result in duplicate module files that are incompatible. You'll have to manually clean that stuff.

I've also been messing around with Siege and XDebug profiling.
Siege is an http regression testing and benchmarking utility. It was designed to let web developers measure the performance of their code under duress, to see how it will stand up to load on the internet.
Using that I have been able to make some performance adjustments. And test the performance different between a vBulletin running in utf8 or in an other character set.
When vBulletin is not using utf8 as character encoding vbDrupal will need to perform on the fly conversion. Which of course has a performance hit. Anyway, I have been able to improve the performance at various places.
I did not use a proper set up for the benchmarking, so the exact numbers are not very useful or trustworthy. But the performance hit when not using utf8 for vBulletin is over 50% when using vbDrupal 5. In the current vbDrupal 4.7 this is a bit lower because it doesn't have the same performance improvements I made to vbDrupal 5, but it is still a significant difference.
For vbDrupal 5 I will try to improve the performance even more, vbDrupal 4.7 will not be changed.

In case you are wondering about the conversion of vBulletin to utf8. Somebody is working on a vBulletin add-on that will automate the conversion: vCharset.
However, the current beta release of vCharset is not compatible with vbDrupal. It will screw up your vbDrupal content during the conversion. But it is being worked on. I will post a new item when a version is released that is compatible with vBulletin.

Anyway, the first beta of vbDrupal 5 is getting close. The only thing left on my TODO list for this release is to restore the user role editing. It currently does not include assigning vBulletin usergroups.