Regular readers of my site no doubt noticed that my site was offline for a little while a few days ago (today, by the timestamp, because Bolt doesn't let me postdate articles, only postdate when they go live) because I was upgrading the software to the latest stable version. It went remarkably smoothly this time, modulo the fact that I had to manually erase the disk cache so the upgrade process could finish and not error out. Deleting the cache alone took nearly an hour, and in the process I discovered something I wish I'd known about when I first started using Bolt.
So, here's what I'm on about...
Bolt uses a templating system called Twig internally to take data from the back-end database (like the internal post ID, intro block, and body of a post) and turn it into the HTML your web browser can display. As you might expect, this tends to be computationally intensive, so Bolt writes the generated HTML to disk in a cache directory and keeps track of where and how old the files are, so when other people request the same resource (like my H-Card (what's an H-Card?)) it can send the user the pre-generated HTML rather than re-generating it. This results in a faster user experience than you'd otherwise have (fun fact: If you're logged into Bolt you don't see your cached pages because then you wouldn't be able to see your edits). Ideally, caches get periodically cleared out so that they don't grow too large and so stale files don't get served. I thought that Bolt had a cron function which did just that. It does. That cron function, however, isn't like the one PivotX (the CMS I used to use before it went out of support) - it doesn't run on its own, it's a process that runs on the back-end in the server's cron table. What I had to do was add the following to the cronjobs I already have stacked up on Dreamhost's server:
# Don't e-mail me every time it runs. MAILTO="" #Every hour, run the Bolt cronjob. 0 */1 * * * /usr/local/bin/php-7.0 /path/to/drwho.virtadpt.net/app/nut cron
By doing this, I've hopefully turned on the "delete the oldest files from the disk cache" feature of Bolt, which should also be nicer to the admins at Dreamhost. It'll also make future software upgrades much less hairy.
Once I'd gotten the upgrade to finish I logged into Bolt to see a couple of notifications from the Bolt software. One of them was that I had to change a couple of internal configuration options because I'd done a fairly major upgrade (v3.2.x to v3.4.x). This wasn't a big deal. The other was that my system logging tables were over 13,000 lines and would I like to truncate them?
System logging tables?
As it turns out, Bolt has two database tables (bolt.bolt_log_changes and bolt.bolt_log_system) where it tracks events, such as interim saves of posts, notifications of plugin updates, and error messages. These two tables are supposed to be truncated periodically by the Bolt cronjob, but because I wasn't running it on the web server, that wasn't happening. So, by adding the above cronjob I think I've sped things up even more, at least on the back-end of things. Things certainly seem more snappy as I write this article. I'm pretty sure I've also made the database backups smaller in the long run, which is a net win. Time will tell if I did it right.