Colophon

For those interested in such matters, the tale of how such an unlikely tool as Tolkienists came to be is endlessly fascinating, and much (largely apocryphal) has been written about it elsewhere. This is not that tale. What follows will in fact be of interest not so much to anthropologists as to archæologists — not so much to keepers of lore as to software engineers and data architects. You have been warned; continue at your peril.

History

In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move.

— Douglas Adams, The Restaurant at the End of the Universe (though earlier it was part of the original radio series)

Skipping ahead a bit.… When Tolkienists’ architect/visionary/engineer/data-entry clerk/​code monkey Erik Mueller-Harder made his first website (then called a web site) in 1993, there were only a few thousand of them in the world, and they required little more than some HTML text files (called text files) and a text editor with which to edit them (in Erik’s case, this was called BBEdit). Move forward 28 years, and today’s websites are now sent to browsers as HTML text files, and Erik uses BBEdit to edit them.

On the face of it, then, nothing at all has changed; but such a — quite literally — superficial reading of history would be very misleading. Some of the earliest challenges the nearly prehistoric web developers of 1993 faced included web browsers that didn’t display what the HTML writers wanted them to display, images that would be presented in the wrong sizes or aspect ratios, typography that wouldn’t … typograph.…

To set web developers’ minds at ease (and often to line their own pockets in the meanwhile), wily entrepreneurs created companies to create products that would solve all these problems and more — Adobe Dreamweaver (née Macromedia Dreamweaver), Adobe Flash (previously Macromedia Flash, previously FutureSplash, originally SmartSketch), Adobe FrameMaker (née Frame Technologies FrameMaker), Adobe Fonts (previously Small Batch’s Typekit), and WordPress (not yet known as Adobe WordPress) came to the rescue.

On the whole, things are much more complicated now, even as they’ve become more predictable and more simple. It’s now possible to center text on a web page, for example. And (unless you’ve disabled web fonts in your web browser), you’re reading this paragraph set in the lovely typeface that I chose for it — Christian Thalmann​’s Cormorant — instead of Microsoft’s sorry reinterpretation of the incredibly useful and flexible (but not so useful or flexible as all that) Helvetica.

But it’s no longer possible — or at least, it’s no longer advisable — to just whip out a few pages of HTML code and call it a site. That doesn’t scale well, and (to be brutally honest) it never did. So journey with us, if you’re interested, and visit some of the technologies used for creating and running Tolkienists!

ProcessWire

There are two distinct methods for construction a website. Tim Berners-Lee’s original concept of creating one document (HTML file) per page on the site is simplicity itself, and tends to produce a svelt site whose pages load in the browser really really quickly.

A later approach is to store lots of pieces of boilerplate templates together with most of the site’s actual content in a database, and have the web server pull out the bits and pieces and construct web pages (still HTML) on the fly when a visitor asks to load a page from the site. This approach is much more complicated and (in most cases) quite a lot slower.

So why would a website developer choose to use the comparatively unwieldy second choice?

1. It’s easier to update. Let’s say you had a site and your mailing address appeared at the bottom of every page. With the first approach, if you ever moved, you’d have to update every page on your site; with the second, you can quickly make the change in just one place.

2. It’s more flexible. If you have a site where you sell ham and eggs, but you also decide you’re going to sell spam, you’d again need to update every page in the page-by-page approach to let users navigate to the spam section of your site; again, this would be a simple change in a database-driven system.

Just these two principles explain why the vast majority of sites of any size are constructed using tools broadly described as CMSs (“content management systems”). You may not be familiar with Drupal or Joomla, but WordPress drives more than 40% of all web sites. I’m waving my hands a bit here with definitions, since people disagree about whether WordPress is technically a CMS (it grew up as a blogging and ​“website generator”) — but however you define it, WordPress is far more akin to CMSs than to a ​“flat-file” system.

Tolkienists is built using a CMS called ProcessWire. I suspect it’s not a coincidence that ProcessWire’s name looks a bit like WordPress, inverted, for it’s really like the un-WordPress. WordPress, honestly, is a good choice for a simple blog. An entire industry has arisen, though, to support organizations that are trying to fit large complicated round web sites into WordPress-shaped square holes.

ProcessWire was designed and written from the ground up as a flexible, lean CMS that supports the creation of exactly the website you want to create, while staying out of the developer’s and designer’s way. As both the designer and the developer of Tolkienists, I doubly appreciate this approach.

[Here’s an outline of sections yet to come…]

• PHP, MariaDB, Apache
• Cloudways & Vultr
• Noun Project, Solarized
• Cloudflare
• Amsterdam & New York: A tale of two cities
• gratitude to early, enthusiastic Tolkienists supporters
• roadmap