Upgrading XenForo from 1.1.4 to 1.4.5
The TShock for Terraria forums have been running XenForo, an excellent forum installation that mixes modern discussion with things like AJAX and a refreshed design. XenForo is great, but I had no idea how things would go upgrading from 1.1.4 to 1.4.5 – four years worth of upgrades, in one go. The task was daunting, to say the least.
Performing the upgrade #
Upgrading turned out to be dead simple. I renewed our license for a year of support, downloaded the latest upgrade package, and uploaded it. The upgrade looked to be performing well, but at the end it hit four database errors because [bd] Forum Watch conflicted with a newly added XenForo feature. This caused the upgrade to fail.
Fixing the upgrade #
The solution to this broken upgrade was to login to the admin panel, disable, and then uninstall the Forum Watch add-on. After doing this, I went back to the upgrade url and hit “rebuild master data.” From there, the upgrade rebuilt the database, and everything worked out well.
Switching out plugins #
When I started using XenForo for TShock, I used several plugins. Here’s the fate of what ended up breaking, being unsupported, or removed for other reasons during the upgrade:
- (Previously mentioned) Forum Watch - Removed; Broken, and superseded with built-in support for watching forums.
- XenPorta - Removed; 8WayRun unsupported the free version of their portal. Replaced by Extra Portal.
- XenUtilities - Removed; 8WayRun unsupported this addon. StopForumSpam integration was added to XenForo so this change was actually quite welcome.
Not mentioned: Addons that didn’t break, including Mass Delete Spam Users, Kotomi, and TaigaChat. All of these were kept.
HTTPS #
Following the upgrade, I set out to implement site-wide HTTPS using CloudFlare (and owning no certificate myself). In CloudFlare, I turned on Flexible SSL. Then, in the XF ACP, I turned on the Image Proxy. This is found under Options -> Messages.
Because XenForo relies on PHP to tell it if the web server is serving things over HTTPS, I also added a hack to index.php and admin.php above the XenForo autoloader to force the server to treat TLS as always enabled. This guarantees that XenForo will generate links and resources over HTTPS, rather than HTTP. This avoids problems with HTTPS sessions being dropped, as well as mixed content warnings (as a result of the image proxy).
$_SERVER['HTTPS'] = 'on';
The resulting modification in place in index.php and admin.php:
<?php
$startTime = microtime(true);
$fileDir = dirname(__FILE__);
$_SERVER['HTTPS'] = 'on';
require($fileDir . '/library/XenForo/Autoloader.php');
// Rest of file omitted
?>
Finally, I used the word censor as a clever way to rewrite all existing links in posts to the secure version of the site.
Some other minor tweaks were required to fully avoid mixed-content warnings, such as making sure templates, emoji, and embedded media are all served over HTTPS.
XenForo Resource Manager #
I bought and enabled XenForo Resource Manager to serve plugin downloads for TShock. The only real configuration required here was the addition of Resource Manager Thread Reassign to enable linking the new plugin resources with their old discussion thread counterparts.
XenAPI #
To enable a somewhat useful API for getting forum data (such as resources, for the sake of checking for plugin updates), I modified and installed XenAPI. The modifications were primarily to make getting resources public. This is the “actions” table:
private $actions = array(
'authenticate' => 'public',
'createalert' => 'api_key',
'createconversation' => 'authenticated',
'createconversationreply' => 'authenticated',
'createpost' => 'authenticated',
'createprofilepost' => 'authenticated',
'createprofilepostcomment' => 'authenticated',
'createthread' => 'authenticated',
'deletepost' => 'authenticated',
'deleteuser' => 'authenticated',
'downgradeuser' => 'api_key',
'editpost' => 'authenticated',
'editthread' => 'authenticated',
'edituser' => 'api_key',
'getactions' => 'public',
'getaddon' => 'administrator',
'getaddons' => 'administrator',
'getalerts' => 'private',
'getavatar' => 'public',
'getconversation' => 'private',
'getconversations' => 'private',
'getgroup' => 'public',
'getnode' => 'public',
'getnodes' => 'public',
'getpost' => 'public',
'getposts' => 'public',
'getprofilepost' => 'authenticated',
'getprofileposts' => 'authenticated',
'getresource' => 'public',
'getresources' => 'public',
'getresourcecategories' => 'public',
'getstats' => 'public',
'getthread' => 'public',
'getthreads' => 'public',
'getuser' => 'authenticated',
'getusers' => 'public',
'getuserupgrade' => 'api_key',
'getuserupgrades' => 'api_key',
'login' => 'public',
'register' => 'api_key',
'search' => 'public',
'upgradeuser' => 'api_key'
);
Because the website is behind CloudFlare, I manually added a page rule to turn detection of bots off. This permits actual API use from normally invalid browsers and scrapers (like WebClient).
Conclusion #
All said and done, the upgrade to XenForo 1.4.5 from 1.1.4 went fairly well, considering that it was roughly four years of version history being applied. The upgrade process would have worked without fail the first time if I had removed the forum watching addon first, but other than that anomaly, it could not have went better. The most disappointing part in the upgrade process was finding out that XenPorta was discontinued in favor of a paid module. While I have nothing against it, there’s something really disheartening about it being discontinued, rather than an upgrade path being possible, or even a reduced version being offered. Overall, however, this proved to be a minor obstacle. For the two hours of work, the payoff was definitely worth the effort in dealing with these speed bumps.