CSCGal & Keith's gorgeous vBulletin Hack

Good-looking work by CSCGal & Keith — breaks like this are exactly why a careful deployment workflow is worth the five minutes it takes to set up. @robbio’s rush to upgrade is a common trigger: install hacks on a clone, not on the live board. Below is a compact, practical checklist that captures the usual pitfalls and safe rollback steps.

Full backups first. Dump the database and archive all vBulletin files (including attachments/, images/ and includes/config.php), then store the archives offsite. Example commands:

mysqldump -u root -p vbulletin_db > vbulletin-db-prehack.sql
tar -czf vbulletin-files-prehack.tar.gz /path/to/vbulletin/

Create a staging clone that matches the production PHP/MySQL environment, update includes/config.php to point at the staging DB, and disable outgoing mail/cron tasks so the clone cannot send mail. Apply the hack only on staging. Track every change with diff/patch or Git so the exact file changes are documented:

diff -ru ../clean_vb ../staging_vb > cscgal-hack.diff
patch -p0 < cscgal-hack.diff

# or using git
cd /path/to/staging_vb
git init
git add -A
git commit -m "pre-hack snapshot"

When installing, avoid wholesale template/file overwrites. Merge template edits in AdminCP where possible and clear vBulletin caches / rebuild styles/datastore after changes. Test the full critical path on staging: login, posting, attachments, private messages, search, moderation tools, and user permissions. Check PHP/webserver error logs for fatal errors. If rollback is needed, restore with:

mysql -u root -p vbulletin_db < vbulletin-db-prehack.sql
tar -xzf vbulletin-files-prehack.tar.gz -C /

Since this thread has active contributors, consult the replies here for any version-specific notes or updated install instructions before touching a live board. Tracking patches in Git and keeping a repeatable staging workflow makes both applying and undoing hacks predictable and safe.