I have written before of my love affair with Drupal 7 and, separately, of my anxiety about Drupal 8. Drupal 7’s abandon-ship, event-horizon end-of-life looms on November 2021 and, although this is long enough away to do something about for a single website, I decided earlier this year to crack on and address this matter. Here is what I learnt.
As a freelance web designer I need to give sound advice to my own clients who have a Drupal 7 website. Should they stay (with Drupal and make the leap to 8) or should they go-go? I calculated that the best way for me to gain experience sufficient to answer that question would be to work on my own website which, although modest at just over 280 nodes with perhaps 11 different content types, is more complex than most of the client sites I have built in Drupal 7. Nail a re-build in D8 of my own website and everyone could theoretically be kept on board, was my thinking.
Attempts to migrate Drupal 7 to Drupal 8
Drupal 8 comes with its own suit of migration modules which are designed to take a D7 site and upgrade it into a D8 site. These require you to prepare a separate D8 site ready to accept D7 content, rather than enabling you to perform an in-place upgrade on the same site. The guidance seemed authoritative. Much work is - rightly - required to install and enable as many of the equivalent D8 modules as you think would be required to achieve the same the D7 functionality. The migration process is supposed to create all the required content types and fields as part of the process. Detailed configuration of the D8 site cannot take place until the content migration has been completed. You can choose between using Drush or running the migration in the browser. I chose the latter with the Minimal installation profile option.
The first attempt populated the error log with an impossible number of errors, most of which were related to experimental modules that came as part of the D8 install. I uninstalled any modules which were alpha, beta, release-candidate or dev versions, then ran the migration again but into a new site. The results were more hopeful. Content was invisible until each node’s text filter was specified. There were no blocks and no views. Menus were successfully migrated. I therefore created a third D8 instance and ran the migration once more, this time specifying the Standard installation profile. This looked even better. There were no error messages. Whereas 65 modules were not going to be upgraded, 42 would be. There were again no custom blocks and no custom views brought over from the D7 site, nor basics like the site slogan or default front page.
So why didn’t this do the trick? The process created a slew of “migrate_map” and “migrate_messages” tables in the underlying database and this ballooned the dB size. I would probably have been able to drop these tables - presumably after having disabled the migration modules - but my anxieties had been let out. What else was I going to encounter that the migration had done - and would it not be altogether better for me to build everything from scratch? This was akin to the “which is better” question: to upgrade, for example, Windows 7 to Windows 10 or to nuke the former and install the latter from scratch? Given that I had always done the latter - always, whatever the version of Windows - why should I now operate differently with Drupal? (The comparison between Drupal and Windows version upgrades is illustrative only. You should get my drift.) I therefore decided to build the site in D8 from scratch. I consider this a matter of sound practice as it enables you to get your hands dirty, and so better able to fix things further down the line. Besides, if all the migration had done was what I could do by manually copying and pasting content, a bit of time saved was not worth living with uncertainty. It was very helpful have the process build content types using D8 equivalents, but maybe I should have been doing that for familiarisation. If all the blocks and Views configuration was still needed to be done, why not start completely afresh?
A from-scratch Drupal 8 rebuild
So that’s exactly what I did. I set out to replicate the existing D7 site in D8 on my local WAMP stack and, to begin with, it was surprisingly easy. Well, that’s to say it required much preparation in learning key D8 concepts (configuration management, Composer and Twig, the PHP template engine).
This back-to-school stage wasn’t anywhere as easy as installing a D8 instance and replicating in it what already existing in the D7 version. I believed that I had done due diligence and was equipped to proceed. In the main, that was true. The establishment of the D8 version went more or less well. The usual problem-identification followed by the search for ways through or round each of these was satisfyingly familiar. The Drupal community, whether in version 7 or version 8, is a diverse and fundamentally supportive one and there is an extraordinary volume of good material available on the Drupal site and elsewhere. As is said again and again, whatever your Drupal problem, someone somewhere will have encountered it before you - and posted a fix or a work-around. The Drupal IP Geolocation Views & Maps module does not have a D8 version, and progress with an alternative approach, as in the Geofield Map module, looked good but at the time lacked mature documentation. Composer was apparently an absolute requirement which meant that all discussion about it being possible to roll and maintain a D8 site without Composer could absolutely not apply in my case. This became an issue that I re-visited repeatedly. If I understand it correctly, one can install D8 without Composer, but you cannot maintain or upgrade a D8 site without it. More on this later.
The path to getting a D8 version of the site up and running was therefore surprisingly easy once the back-to-school work had been completed. The Token Filter module proved to be a life-saver as this enabled references to inline images to be tokenised: src=“https://www.rob-tomlinson.com/sites/default/files/filename.jpg” instead of src=“sites/default/files/filename.jpg”. Learner’s cramp appeared when puzzling over the D8 Block Layout page. Was I the only one who failed to see the Place block button when looking for the listing of a desired custom block? And D8 Views didn’t (as of 8.6.15) output .active classes for menu links pointing to the current node or its parent. No doubt I could address that through a preprocess_menu hook in the template.
But no matter. I was working with a largely functional D8 version of something very familiar. Only conditional logic in Views and any ability to generate node-location maps in Views was absent. They would no doubt follow.
Attempting to upgrade Drupal 8.6.15 to Drupal 8.6.16
Pride comes before a fall and no doubt my contentment at upgrading individual modules and dependencies using Composer was bound to get the better of me. The fall came when I took the momentous decision to upgrade Drupal itself using Composer. I wanted to get from version 8.6.15 to version 8.6.16. A D7 minor version upgrade like that would normally take 10 or 15 minutes. If I could have accomplished that, I reckoned that I would be able to manage the complexities of Composer on a live site even if I needed to use a telnet utility like PuTTY to fire Composer commands up the tube with SSH on a shared hosting environment. (I wasn’t looking forward to the prospect of that, but reckoned that the gain of sticking with what was fast becoming a comfortable D8 experience would be well worth it.)
The fall did indeed come in the form of: The website encountered an unexpected error. Please try again later. That had been preceded by judicious use of composer update --dry-run and composer prohibits drupal/core:8.6.16 but, even so, the update of Drupal core fell over - and irretrievably. Various discussions out there indicate a spread of errors relating to updating from version 8.6.15, such as https://www.drupal.org/project/drupal/issues/3053631 and I avidly followed them all and tried everything out there. I worked on the composer.lock file, deleted the vendor folder, repeatedly restored a pre-upgrade dB and its associated file-base, and retraced my steps pretty vigilantly, multiple times over.
I had clearly not been alone in this and better heads than mine had no doubt found the solution to their particular problem. What was frustrating was that (a) not all error messages for this particular minor version upgrade were the same and (b) no single fix dealt with everyone’s problem. It seemed as if the underlying dependency stack was so capable of of accumulating internal errors that the Composer dependency manager that was designed to deal with this was fundamentally incapable of doing so. The moment you pass control of something so inherently complex to a black box system that requires its own team, a vector of significant potential weakness has been introduced. These things are fine when the pool of expertise online is sufficiently wide and deep for freelancers like me to be able to track down the required fix. When it isn’t - which I believe was/is the case with Drupal and Composer - then headway can only be made by those who have in-house specialists in that particular field. Drupal 8, in my opinion, is no longer something that one-man Drupal shops can work with.
I’m writing this several months after the upgrade attempt itself. The details now escape me and I’m not prepared to go back in and try to document every step of what happened. After a couple of days of it, I decided to throw in the towel. Yes, that was a ton of work down the drain, but I was not prepared to battle this degree of complexity on all of the sites I work on. This was a test case, a single site, and I had repeatedly failed its D8 minor version upgrade.
Farewell Drupal 8
I have now ceased my courtship with Drupal 8. Initially I had a heavy heart. I adore Drupal. Drupal 7 is spectacular. Over the years I have learned to accomplish practically anything in it. It has put food on my and my clients’ tables. But when I see dependency management software firing torrents of code at my code base, without my fully understanding what’s going on, then I know that the game has changed and my simpler needs will not be met by my sticking with Drupal. I leave it for the enterprise space to who will wrangle it with better polished heads and more resources. Much larger organisations where different specialists can deal with each of these components will no doubt thrive working with Drupal 8. I wish them luck. But small web shops and one man bands cannot easily cope with this degree of complexity.
Hello Backdrop CMS
I have now answered the question I asked here a couple of years ago. My loyalty to Drupal has been stretched to breaking point and I have jumped ship and am committing to Backdrop CMS. It’s a fork of Drupal 7, containing Views in core, under the expert guidance of Nate Haug/Lampton and Jen Lampton and there are plans to NOT take it in the direction of Drupal 8 with all the dependencies that caused my headaches. At the time of writing, I have re-built the local version of this site with Backdrop and it’s as familiar as Drupal 7 with plenty of lovely improvements. It has been in the wild since 2015 and has already enjoyed 13 minor version upgrades. I have already used it to build a site for a client and both of us are perfectly happy with its functionality and robustness. Upgrading to Backdrop version 2, when it eventually comes out, is promised to be easier than moving to version 1 from Drupal 7. Their road map is clear. Sounds good.
A Backdrop wish list
This remains more or less the same as my Drupal 8 wish-list started out as being in that I’d like to see:
- The ability to apply conditional logic in building a View, for example by having a style applied to a menu item if the node it points to has a field with a value of x but not y.
- The ability to build Leaflet-based maps using Views so that multiple nodes can be plotted on a (preferably non-Google) map and then given interactive potential to link throughout the site. If adjacent text menus of the same data can pop up location bubbles over the map as the text menu items are hovered, oh dream.
When I have found a satisfactory way of accomplishing this I shall take down my live Drupal 7 site and replace it with the Backdrop CMS version. I have until November 2021.
Footnote
[Update: following my two wish-list points above, conditional logic in Views became available in July 2020 courtesy of the Views Conditional module, and the ability to build Leaflet-based maps of Views node geolocations in Backdrop became available in June 2021 courtesy of the Leaflet module. Get building your content management websites in Backdrop and celebrate!