The aim of this article is not to poke holes, or say ‘vBulletin sucks’, but to provide constructive criticism of a successful product, proving that vBulletin is not always the best choice. In places the article compares vBulletin to Drupal, this is the platform The Webmaster Forums will be switching to and represents many of the things vBulletin should—in our humble opinion—aspire to.
Note: vBulletin™ is a registered trademark of vBulletin Solutions. aPaddedCell, the Webmaster Forums are not affiliated with them nor do we speak for them in any way.
- Too Many Features!
A good forum (or CMS for that matter) is like software Lego, written in a modular way so that code is re-used and only required functionality is included in the site, meaning the code is quicker at generating pages. While vBulletin has added the ability to create add-on modules, the software is still based upon a monolithic code base instead of a sensible set of core functionality, an API to extend it, and set of optional modules.Too many features generally leads to bloated code, a confusing interface, a large number of poorly implemented features instead of a few complete ones, and more bugs or security flaws. The Admin Control Panel is indicative of the too many features problem: it’s messy, over-complicated, with far too many options lumped under vBulletin Options. Compare vBulletin admin interface to Drupal’s administration interface:
Notice how the vBulletin interface lacks organisation and appears cluttered. Drupal puts options under generic categories whilst allowing modules to include their own menu items, administrators can remove the verbose option descriptions or even view options organised by module. The Drupal interface is the result of carefully planning a set of core functionality, keeping extensibility in mind. The vBulletin interface is the result of cramming as many features as possible into one piece of software, number of features is the main objective.Below is a suggested list of functionality that could be removed from the vBulletin core package and turned into installable add-on modules (in no particular order):
- Signatures
- User Profiles
- Avatars (and profile pictures)
- Private Messages
- Subscriptions
- Buddy/ignore Lists
- Post attachments
- Calendar
- Event Reminders
- Announcement
- Polls
- Send Email to users
- Infractions
- User Ranks
- User Reputations
- User Titles
- Paid Subscriptions
- Smilies
- BBCode
- Statistics
- Podcasts
Without these the vBulletin interface could be made lean, mean, streamlined and fast. Why slow sites down, confuse users, increase HTML/back-end code bloat with unneeded features? Administrators will enable/disable this functionality by clicking a check box (modules could also be enabled by default so existing users are not given a nasty surprise), but only the modules needed by the site are enabled. Additionally if people dislike, or wish to extend, something they can write their own custom module to replace the one provided by vBulletin, then share it with the rest of the community.Also worth mentioning here is vBulletin’s layout, for example: table based layouts make modular design difficult, a template that begins and ends with a div having a unique id attribute is better encapsulated than a table row. An encapsulated div assumes nothing about other templates, a table row (or even cell) introduces dependencies upon other templates having tables too, this makes it difficult to switch functionality on and off.Note: tables are not evil, when filled with tabular data (such as a forum listing) they are great tools, fulfilling their semantic purpose. Tables are not meant for layout however, as they are not generic containers.
2. Bloated Code Output
The code of any vBulletin page is weighed down by a circa 1990s layout; tables nestle inside other tables, whilst in-line JavaScript peeks from behind drop-down menus. The HTML that comes from vBulletin is bloated, difficult to comprehend and overdue a complete overhaul. This can be demonstrated by comparing the same forum thread in both Drupal and vBulletin, three are compared to ensure the result is not a fluke:
The tests were carried out using vBulletin version 3.6.2 (not the very latest but not far off), with the default vBulletin theme and Drupal 5.2 with its default Garland theme. The pages tested are available for download, these are available under a Creative Commons license (please see the LICENSE file included in the attachment).
It could be argued that bandwidth is not that important, but when paying the bandwidth bill for a site with some volume of visitors, every kilobyte per page counts. On average (taken from the figures above) a Drupal thread is 40KB smaller than its vBulletin equivalent, a site with 500,000 page views per month—using Drupal—can expect bandwidth savings of 19GB. That’s nearly 14 million tables (vBulletin has around 0.69 tables per kilobyte of code) and hopefully some money off their bandwidth bill.
3. Constantly Changing Templates
Every time a new vBulletin is released, be it a bug fix or large version change some templates are nearly always broken. The reason for this is that vBulletin does not adhere to MVC principles. MVC means Model-View-Controller, simply put: database code is kept together, code for business rules and logic is kept together, the display layer code is kept together (i.e. the templates) and none of them are mixed.Since vBulletin has template authoring capabilities built into the application it would seem to more-or-less follow these principles (it’s worth noting that zealously adhering to these principles generally leads to over-engineering). Unfortunately this is not the case, after every upgrade vBulletin informs the administrator that there are: ‘Out-of-Date Custom Templates Found!
’aPaddedCell (this site) has been through two Drupal upgrades (5.0 to 5.1 then 5.2) without needing to edit templates once, so this is not impossible to fix. Much of the problem is code in the view—the templates—that should be in the controller (the logic and business rules). Examples of code which do not belong in the templates are:
From SHOWTHREAD <script type="text/javascript" src="clientscript/vbulletin_post_loader.js?v=$vboptions[simpleversion]"></ script>
A template author will never need to change this and it does not affect the layout of the page, this belongs in the header, preferably as part of a $scripts variable. If necessary, this could go in the headinclude template, however this (and most of the code in headinclude) doesn’t really belong in a template at all.
From postbit <if condition="$show['infractionlink']"> <a href="infraction.php?$session[sessionurl]do=report&p=$post[postid]" rel="nofollow"> <img class="inlineimg" src="$stylevar[imgdir_button]/infraction.gif" alt="<phrase 1="$post[username]">$vbphrase[add_infraction_for_x]</phrase>" border="0" /></a> </if>
Spotting the problem with this is not so easy. It’s that when the infraction feature was added all vBulletin templates were broken, this is avoidable if the controller part of the application were to build an array of links that the view could iterate through (or even create the HTML as a simple list, optionally overwritten by another template). When this feature was added, it would have been added to the array, no need to update templates.
From footer <script type="text/javascript"> <!-- // Main vBulletin Javascript Initialization vBulletin_init(); //--> </script>
All JavaScript belongs in external files, there are occasional exceptions to this rule but this is not one of them. vBulletin_init() should be attached to the document’s onload event by the addEventHandler (or eventCallBack for IE) function. Even using the onLoad HTML attribute is preferable to this, which is esoteric and superfluous for theme authors, also including this on every page increases bloat, as shown above.If this code is ever served with the correct Mime type of application/xhtml+xml the function will never be called, browsers will ignore everything in the HTML comments ( <!– –> ).Removing these snippets and other code that doesn’t belong from the view means easier template authoring, less template maintenance and more logically ordered back-end code.
4. Other Gripes
Following are problems that make the software a bad choice for The Webmaster Forums in particular. They are not problems with vBulletin but areas where our priorities and those of Jelsoft are at-odds.
- Licensing
This is a personal reason for wanting to move The Webmaster Forums to different software, Free software allows us to:
- Not worry about licensing;
- Have the freedom to change code in the software package, then give it back to the community;
- Have the freedom to change code in the software package and distribute as we wish;
- Not worry that the software is owned by a single company who could go bust, be bought-out by another company with no interest in developing the product, or a competitor who buys the company in order to kill it;This is a personal preference, many forum owners are perturbed by such things.
- Templates Stored in the Database
Templates stored in files are preferable, as in Drupal for example, because many editors (like Vim) can edit files directly via FTP, SFTP or SSH.The database will have to be queried for each template in terms of performance a flat file is better suited to this job (since no complicated seeking or joining datasets is required).
- Security Issuesv
Bulletin releases often due to security updates. This is just based on our experience and may be indicative of quick action on the part of the vBulletin devs, however each security update tends to break a large number of the templates which must then be corrected manually.A large number of bugs may be caused by vBulletin’s lack of adherence to MVC principles or the lack of a consistent API, other software fares better in these respects.
- SEO
vBulletin lacks optimization for search engines. As this is a heavily debated topic, that seems to have no clear answers, this article will only briefly note that vBulletin appears to have SEO problems. Certainly The Webmaster Forums does not seem to do as well from search results as it should do, it also appears that to be successful with search engines a site must use a third party plug-in named vBSEO. The success of this product indicates that there is an issue.The Webmaster Forums will be tested on Drupal, if it is successful then there are changes to vBulletin that could make it easier for search engines to index sites using it.
Conclusion
The points in this article do not stand alone, these issues are related. When the objective of the software is to include as many features as possible other areas suffer, code becomes bloated and difficult to manage, this manifests itself in the templates. The code downloaded to the browser is bloated and full of cruft, whilst much of what is in the templates doesn’t belong there at all.
vBulletin is too restrictive for our needs, we developed standards compliant templates, but were stopped by new releases which broke our custom templates. Radical changes to vBulletin styles are not possible (probably why no-one has achieved Kier’s style challenge yet) and the developers appear uninterested in supporting standards.
Overall there are plenty of site owners for whom vBulletin will work perfectly well, many people do not care about tables for layout, limited usage licenses, buying an SEO plug-in, or features they’re never going to use. Many are excited by having features available out of the box. For these people vBulletin could not be any better, but for the rest of us the alternatives are improving all the time. Drupal may not be the best forum software available, but as it’s Free software we can get our hands dirty, fix the problems and contribute back to the community. The answer is, ‘It soon will be.’
The second part of this series will deal with how to switch from vBulletin to Drupal. From a conversion tool, to matching functionality and theme authoring.
The second part of this article is finally up!
