Comments/Questions-
NCWW has really suffered over the past few years whenever new vBulletin versions have been installed . It just seems like it is becoming a lot of work for volunteers- my hat is off to you! I don't know anything about programming or vBulletin, but have a few questions/comments-
1. Are these problems caused because NCWW uses an extremely customized (with NCWW or third party software?) version of vBulletin- photo hosting, classifieds, etc., etc. and these mods are not often not compatible with, supported by, or in sync with vBulletin?
2. Is there any reason we need to "upgrade" each time vBulletin issues a new version? Couldn't we skip one or more versions to lessen the frequency of problems? Kinda like going from Windows 98 to Win XP, bypassing Win 2000 and Win ME or going from Win XP to Win 7, bypassing Vista?
3. Would it be helpful to have a mirror site on the server so that upgrades can be beta checked before being installed in the main site and going live on the web?
All fair questions and I'd be happy to answer them one-by-one.
1) vBulletin itself is stock for our site (we don't make physical alterations to the vBulletin code base or upgrades would be a massive impediment to progress). However, many of the features everyone enjoys are either plugin code we've hacked together to extend vBulletin (which, being fairly simple are pretty stable) or third-party plugin applications (much of the major enhancements) which are a good deal more complex and because they interact with vB more so are much more vulnerable to changes in vB's code base.
The issue with third-party plugin compatibility is further aggravated by the fact that vBulletin, while very dependent upon a third-party developer community, has never actively supported third-party development with any sort of documentation as to which functionality a developer can count on to be stable versus which functions and procedures are considered "internal" to vBulletin and, thus, subject to change without notice. This means that vBulletin's developers tend to consider *all* code "internal" and subject to unannounced changes. Add onto this the fact that PHP, which is what vBulletin and many other major web applications is written in, is undergoing its own period of upheaval with long-standing functionality being actively deprecated and removed from one version to the next... and developers like vBulletin trying to stay ahead of the deprecation curve and you have two driving issues adding to this confusion.
But it also does not help that vBulletin seems to refuse to adhere by the usual rules of major and minor release versions, namely that minor release versions, by convention, *should* only be bug, security, or browser-compatibility fixes, not wholesale code changes (i.e. "minor" is supposed to equate to "minor" fixes). If they would follow this convention then it would be much more practical for site admins to anticipate possible fallout in advance and act accordingly.
Additionally on the third-party plugin front, some of the plugins we've become somewhat dependent upon are no longer supported by their authors and have no direct or suitable replacements at this time. As a result this code falls to us to resolve whenever problems crop up (Classifieds is a big headache in this regard as it is also poorly coded... and there haven't been many alternatives for Classifieds for vBulletin 4.x, much less vB 5.x...). Any developer will tell you that trying to maintain and debug someone else's work is a major pain in the butt. Even more so in the case of Classifieds where much of its code is thousands of lines of nested conditionals rather than "functional" in design (by which I mean lots of endless "IF..ELSE..THEN" statements versus the use of manageable code blocks we call functions). As a result, to fix an issue in repeatedly reused code blocks can mean applying the same fix 20-40 times versus fixing a singular function had it been written in a traditional functional style.
2) We have actually skipped a couple of minor releases for that very reason. We don't generally update until one of two conditions comes to be: 1) there is a security bulletin and upgrading is the necessary choice to resolve the security risk and 2) we have fallen a couple of minor versions behind and don't want to fall so far behind that catching up is anywhere near as painful as what Steve and myself (by which I mean Steve much more than myself) experienced in January 2011 where the site was down for nearly 2 weeks while we tried to catch up after something like 12-18 months with no significant upgrades to the site... and several security compromises as a result (which was why Steve came back on board to help catch up). This most recent update was the result of both 1 and 2 concurrently, though I did wait several weeks after the release of 4.2.2 in the hopes that most of the fallout would be contained since developers will have had a few weeks to sort things out by now.
You can fall behind a little bit and their will be some modest pain to deal with... some features down for a few days (maybe more) but an otherwise largely functional site. Or you can fall way behind and accept the security risks and deal with an upgrade so painful that the site literally has to be taken down for weeks to catch up afterwards. It's really a balancing act.
3) We do occasionally create mirrors of the site for beta testing, but it is a very inconvenient and time consuming thing to do (it literally takes days do duplicate the site and make all the necessary tweaks). It is almost impossible to keep such a site properly synchronized with this site since this site undergoes regular tweaks, changes and minor updates on a practically weekly basis (most of which nobody will ever notice).
Due to how difficult it is to maintain such a mirror we really only resort to this if we have good reason to expect catastrophe (e.g. if we were about to upgrade to vBulletin 5.x!). This upgrade was more painful than one would have expected for a jump from 4.2.0p4 to 4.2.2... Creating the mirror and doing everything twice can be exhausting for the admins because it turns hours of work into many days, but even when done there is still the downtime and period of time where the main site gets impacted just because the updates themselves can only be performed at human speed... and sometimes we just have to get some sleep!
There are always better ways to do things, but at the end of the day we are all volunteers sharing out interest in woodworking with one another. Unlike tablesaws, a few moments of glitches, or even mistakes, won't cost anyone an appendage so we do accept some risks in exchange for greatly minimizing our day-to-day workloads.
I hope this answers some of your questions and helps everyone better understand what we've been up to.
PS - All said, there is the chance that I may yet have to roll us back one minor version if that's the only way to resolve a couple of issues. But ultimately it is best for us to try and move ahead and put this little bit of pain behind us so that we don't have to revisit the exact same issues in the next update (thus leaving even more work until next time). It's always preferable to handle things in manageable bites over time rather than putting off too much of the work only to be done all at once.
