Migrating a Drupal Site to JAMStack with Eleventy

Some time ago I set out to rebuild a Drupal site on the JAMStack. I had two primary motivations. First, I needed to do something with the site because it was four major versions behind on Drupal and at least two major versions behind on PHP. Upgrading PHP would require an upgrade to Drupal and the audio plugin the site used for MP3 files was no longer supported in the current Drupal version. I could have updated the plugin for the newer PHP version but PHP is not my strong suit and I would rather work with the JAMStack. I’d heard about the JAMStack and read about it and it resonated with me. Since I was working with the JAMStack at work I wanted to deepen my knowledge of it and this seemed like great project for it.

The site that I was migrating is a church web site that is updated at least once weekly and sometimes more often. It contains a collection of sermon audios with outlines as body content and binary attachments, as well as blogs and a few standard pages. Each week at least one new sermon would be posted and blogs would be added periodically by the pastor.

The Drupal audio plugin provided some nice features including reading the MP3 metadata and creating pages to view audios by title, album, artist, year, as well as random audio block (which displayed a link to a random audio entry on each page view) and a latest audio block (which displayed a list of the latest X audio entries where X could be configured). Since Drupal is a server-rendered web application, these “pages” would be generated on the fly by querying the database: first to generate the list of links and second to generate the full-page content. Since I would be moving the site to the JAMStack this would not be possible in the same way.

I wanted as much of the site as possible to be pre-rendered and served statically from a commodity web server without any backend application server, including the ability to serve the site from an AWS S3 bucket. I wanted a purely serverless architecture. I am an application developer and in that role I have never enjoyed patching or updating operating sytems or application server runtimes. I’ve been in the IT space for over two decades and I can and have done that type of work, but when dealing with a simple web site that is a lot of extra overhead that I’d prefer to do without. I wanted to update this site architecture once and have it last another twenty or more years. I realize, of course, that such a statement is a bit of a pipe dream in the tech space since things change so quickly, but at least with the JAMStack and serverless I could hopefully minimize the necessary change. That’s the goal. I guess in twenty years I’ll be able to let you know how well that went.

Things to Consider

These are some of the considerations I had in migrating the Drupal site to the JAMStack.

Content

The site has over 500 sermons with audio files and a couple hundred blogs.

Stripping away the web application backend from the site presents some challenges. In the first place, the Drupal site has a single PHP file that ends up rendering all of the pages on the fly based on the URI requested. It looks up the URI in the database and assembles the content on the fly based on the content type and the configuration of the page (e.g. which blocks to display, what layout to use, etc.). The Drupal site allows the administrator to choose a different theme and apply it to the whole site in a single click. This is a nice feature, but not important for this site. What is important is the ability for me as the webmaster to be able to change the design as needed without having to manually touch all of the pages.

Throwback to the old days

Back in the day when I got started creating web sites the cool tech for maintaining a consistent layout and design was Server Side Includes (SSI). Using SSI you could maintain, for example, a header and footer and side menu each in a single file and then include them with a one-liner on every page of your site. This works by dynamically including the contents of the referenced file in the place of the include statement, so that when the page is rendered the contents of the referenced file would be part of the markup. This obviously requires a server (hence the Server in Server-Side Includes), something that the target architecture will not have.

Enter Static Site Generation (SSG), a process whereby web sites are generated at build time (also called pre-rendering). Wait a minute, what is build time? In the case of a Drupal site there is no such concept, at least not in the normal process of running a Drupal site. If you’re a developer that actually works on Drupal itself, there is a build time when each release is cut, but most people who run Drupal sites don’t have to deal with that. Build time can be roughly equated to publish time in the context of a Drupal site. We’ll deal more with this later, but for now suffice it to say that in static site generation the output is fully rendered markup* (i.e. the content is mixed with the layout and design as if it had been hard-coded). (* Technically speaking the markup may not be fully rendered - it could be enhanced by runtime Javascript, but that’s a detail to take up later.)

The Publish Process

When content is published to a Drupal site, it becomes … [Note: As I mentioned on the home page, the content is not finished. I hope to finish it at some point.]