I maintain a huge Drupal-based e-commerce site. Not huge in terms of customers; it’s a family business. But we have more than 8000 products in over 2500 categories. With the D7 EOL deadline approaching, I faced a difficult task.

What’s more, Drupal is now built on Symfony which is object-oriented. I would have to learn OOP just to keep using Drupal. Migrating the data would be a ball-ache. I’d have to re-build the commerce_node_checkout module myself, as well as a module to calculate the cost of drive belts based on their length, and a module to calculate shipping costs.

As what Dries might call an ‘ambitious site builder’, I had a lot in front of me:

• Figure out this ‘Composer’ nonsense
• Learn Twig
• Learn OOP
• Learn how to use the Migrate module

And I was not the only one in this position. The statistics speak for themselves.

Should I have stuck with the D7 architecture and used Backdrop? It certainly would have been quicker. However there’s another side of the story that is also told quite clearly by a couple of graphs. While overall usage has been steadily declining since 2014:

… the number of sites in the internet’s upper echelons has increased:

Source: https://trends.builtwith.com/

Clearly building a site with Drupal has gotten harder. There have been recent strategic initiatives to combat this, which appear to be steps in the right direction. These include:

• Automatic Updates: about time 👏
• Experience Builder: yet another way of arranging content on the page.
• Project Browser: browse and install modules and themes through the site’s admin pages.
• Recipes: it’s install profiles again.

All of these are welcome but I feel they miss the core problem. Drupal was never a platform for novices. It has always been aimed at those who are willing to put in some time and get their hands dirty. The problem was that the time required to learn how to use it increased dramatically, because for solo web designers (remember those?) it also meant learning a new set of tools.

Time is precious

Throughout the D7 golden era, I hosted the website within Aegir running on a Linode VPS. Aegir makes it very easy to spin up a Drupal website, and to make and restore backups. Aegir creates the Apache vhosts file and the Drupal settings.php file from templates, and does a lot of other things that would have otherwise been very tedious. In the time before Docker or Composer were popular (or at least, before they were commonly mentioned on drupal.org), this workflow was very much preferable to manually creating virtual hosts entries and databases. It saved me a great deal of time.

But with D8 came Composer, and the community had to like it or lump it. I hated it. It seemed to needlessly complicate something that used to be so simple. Why would I write a config file to script the installation of Drupal if I was only going to install it once? The implementation of Composer-based installation in Aegir rendered multi-site installs unusable, which I also disliked. What to do?

For the time being, ignore it. The contrib module ecosystem had been utterly decimated and was far from ready, anyway. I had no new sites to build, and store.lathes.co.uk worked fine on D7. So it was for several years.

Tooling

But then I had to collaborate on a Drupal website and in doing so discovered Lando. In fact, after about nine years of occasionally working with Drupal alongside my day job, I discovered the benefits of local development for the first time. I knew it was possible but until then only saw it as a waste of time; back when the best tools on offer were WAMP / XAMPP that was not unfounded. I was quite happy developing on my production server, thanks. But at some point during those nine years, the use of Docker via DDEV or Lando had become the norm, and I was totally ignorant of it.

I believe I was not alone in my ignorance, and that this is another factor in Drupal’s decline. Among developers working on Drupal core, or on any large project, I expect the GitOps workflow is taken for granted and has been for some time. But for self-taught web designers who’ve spent years tinkering with PHP (using print_f to debug) and are tasked with upgrading a site from D7 to D8+, installing Composer is a very annoying foothill at the base of the mountain they are about to scale.

If in the early days of Drupal 8, the Drupal maintainers had been more proactive in bringing site builders up to their level in terms of tooling (rather than simply passing down the edict that Composer must be used), I believe Drupal would have retained more of its user base. Moreover there would now be a larger pool of developers working on contributed modules; The module ecosystem was a key factor in the success of Drupal 7, and took a catastrophic hit with the move to Drupal 8.

Recovery

There is now a fairly detailed guide to local development on drupal.org and the download instructions for the recently released Drupal CMS specifically mention DDEV, but I suspect it is too late. The contributed module ecosystem took a long time to recover, and in that time the number of sites using Drupal has declined consistently. Even if both initiatives are successful, there are difficulties facing the core demographic of Drupal users that haven’t been addressed. The Twig Tweak and Form Dazzle modules should not be necessary - the functionality they provide should be in core.

In my opinion, the future of Drupal hinges not on its accessibility to novice users, but to amateur developers. Drupal is not (and hopefully never will be) a competitor to Wix, or Squarespace. We don’t need drag ‘n drop; we just need a canonical source of documentation that is written with the intended goal of teaching site builders how to fish.