Kevin's Blog

Over the course of today and yesterday, I went through a pretty amazing journey.

A few years ago, I created a custom Drupal 7 module to generate a block of news headlines that renders in the "featured top" section of a Drupal content page.  When I ported this and other modules over to Drupal 8, I figured out the necessities and got the code working, but I'd left a large chunk of the module in Drupal 7 style or worse.  For example, I was collecting the data for these headlines through direct database queries, which even in Drupal 7 was frowned upon, but figuring out how to pull data from Paragraphs entities the right way had always proved too elusive.  On top of that, my output was generated directly within the block class's build() method, as I'd simply not had time to untangle the inner workings of Twig templates and render arrays.  I knew these techniques were not going to be terribly forward compatible, but they were purposeful quick and dirty kludges to get my sites working.

Sooner or later, it's going to happen.  You'll apply a module update or do some other under-the-hood task and the next thing you know, your Drupal 8 site is no longer responding (often called whitescreening).  While whitescreening is a good security practice (as opposed to the site spewing error messages to the browser that might reveal sensitive details), it's a royal pain when you just want your site to work and you have no idea what's wrong or where to start with fixing it.

What follows are some tips and advice that might get you back in action again without (completely) losing your sanity.

Backup, Backup, Backup (and Restore)

I'll go ahead and get this one out of the way, even though it may be too late at this point to be of any help.  In the future, always have an automatic backup generation plan in place.  The typical advice is to always make a backup before doing anything dangerous to your site, like applying patches and updates, but it's often when you don't think your action could be very dangerous that it ends up frying the whole site.

For some reason, the new internal page caching system has been the hardest thing for me to wrap my head around in Drupal 8, and dealing with it properly has eluded me for the better part of two years.  I think part of the problem is a lack of clear, understandable documentation about how it all works, so here's my attempt to sort it all out:

A Whole Host of Caching Tools

One of the more confusing parts to Drupal 8 is that there are now several ways to control caching, but the names of these components are not terribly intuitive and documentation is still kind of sparse.

External Caching Controls

Drupal 8 has an external cache control, on the Development -> Performance page, named confusingly "Page cache maximum age" (in Drupal 7, it was called "Expiration of cached pages", and the visible description included the phrase "external cache").  Contrary to what you might think, all this control does is to set an HTTP header that systems like Varnish can read and use to decide how long to cache that page.  The setting has absolutely no effect on the internal page cache.

Introduction

Recently, I released a framework that I call a Web Theming Infrastructure, and I think it's worth dissecting and exploring here given the potential that I see in it.  But first, I have to explain how I got to this point.

For more than a decade, web theming at Georgia Tech has been the domain of Institute Communications, and they have handled both specifications and implementation.  Unfortunately, they've never been funded to act as a true central web development unit, so they have struggled to manage the implementation side of the equation.  I would imagine that Georgia Tech is not alone in facing this kind of problem, but like most universities, we have been applying early 2000's techniques to a rather complex problem that needs a more sophisticated approach.

A little over a year ago, I wrote about the usability of the Migrate tool in Drupal 8.1.  We're now up to Drupal 8.3, and while Migrate has improved a little bit, it's still officially an experimental module, and still has some notable gaps.  This doesn't mean that you can't successfully use it, but you do have to understand what you're getting from it and prepare yourself to bridge those gaps by hand.

The instructions I gave in my previous post are still valid, so I won't waste space repeating them here.  Instead, I want to start by explaining how the Migrate tool works, so that you can better understand its limitations.