A love-hate relationship with drupal 8
Let me just start by saying that Drupal 7, probably was, and will be, my favourite CMS of all time, but since Drupal 7 will be end-of-life in November 2021 I as a developer is forced to consider drupal 8 as a viable CMS… Now that’s out of the way, let’s move on.
At first sight, Drupal 8 looks like a big chunk of code, with a lot of features you’re most likely never going to use. A freshly squeezed Drupal 8.6 packages weights just above 60MB… Jesus Christ, luckily disk space isn’t an issue in a modern world.
The more I use Drupal 8, and the more websites i build with it, the more dumbfounded I become by the sheer complexity of Drupal 8, and how it manages to over-complicate simple tasks such as changing the page title.
It’s understandable to keep a somewhat decent level of compatibility and consistency between thirdparty modules, made by thousands of developers around the globe, the core has to set strict standards and dictate how things should be done, and not allow too much wobbling around. That’s not a bad thing.
But I mean, I really shouldn’t have to create a new module, creating yet another config file, initializing another controller just to change the page title? in drupal 7 I could just call drupal_set_title(); and go on my merry way.
Don’t get me wrong, i’m a huge fan of a controller based structure, (or MVC for that matter) and Drupal 8 is even based upon the Symfony 3 framework, which allows me to chain functions, while also explaining what the method calls are doing, basically without having to write comments.
<?php \Drupal::currentUser()->isAuthenticated(); ?>
This is over-simplifying things a lot of course, database queries, for instance can be even longer and span across multiple lines.
Drupal 8 doesn’t allow you to customize your site.
I… hate.. Twig..! For the uninitiated twig is a templating engine that at the heart, abstracts away your need for writing PHP code in any template file.
Being developed by the same team as behind Symfony, I guess it makes sense to choose twig, over anything else
But, what using twig really does to you, is it limits your customization abilities even further, twig is just another (unnecessary) layer which serves no purpose that couldn’t be ommitted.
Barely allowing PHP in your theme, forces you to write all you logic in controllers, which in tunr belongs to controllers.
In reality you can only do the most basic things to in your template files, such as conditionals, loops and variables.
But didn’t you just say that controllers are a good thing, when dealing with thirdparty developers?
Yes.. but a key difference to notice is, twig operates at the theme level, not the module level, which there should only be one developer for, the site owner.
This leads you to installing numerous thirdparty contrib modules or rolling 1, 2, or even 3 custom modules..
Instead the team lead, or whoever may be in charge, should educate/train developers to use the best practices instead of introducing layers that just adds extra load to the server?
There’s a word for that… Bureaucracy.
It is clear that Drupal is targeting enterprise website and organizations, but don’t forget people are writing the code.
Let’s talk maintenance.
It is readily apparent that Drupal 8 cannot be upgraded by hand because of the giant black hole known as the /vendor directory where core keeps thirdparty libraries/components, and where thirdparty modules also install yet more libraries/components, all of which must be tracked by various .json files in order to be fully recognized by the system.
Depending on how you’ve installed your Drupal 8, it is possible to update your installation (core + modules) by a simple command.
This makes it a breeze to update a non-complex drupal 8 site, possibly even faster than WordPress does it. Definetily more verbose than anything I’ve ever seen
I’m not a huge fan of composer as a package manager though, but that’s a story for another day.
This is granted that only a “mere” 512MB of ram is allocated to PHP and does not yield the following gibberish error:
php composer.phar require "drupal/core ~8.2"
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 32 bytes)
in ./website.net/composer.phar/src/Composer/DependencyResolver/RuleWatchGraph.php on line 52
A word on updates.
You don’t have to use composer to update your site, it is still possible to update drupal the ol’ fashioned way of deleting the core/ and vendor/ directories and clone an updated copy from the repository
With Drupal 8, the process of updating the platform has changed, which is a huge benefit to clients, developers and Drupal itself.
Historically, upgrading to a new version of Drupal (like Drupal 6 to Drupal 7), required an entire rebuild. It is time consuming and it is expensive.
Starting with Drupal 8, that process changes. Upgrading from D7 to D8 still necessitates a new website though, but after that, you won’t need to rebuild when a new version Drupal comes out. So when Drupal 9 is released, you don’t have to start from scratch all over again.
Debugging…
Unless you have a local copy of your Drupal 8 site and an xdebug extension configured on your server, you’re in for a tough ride. (Sense the complexity again?)
Remember back in the school days when we used to create websites that would crash your neighbours browser
What if I told you debugging Drupal 8 can crash your browser too.
In literally any other CMS/Framework I’ve worked with I can “just do” something similar to
<?php var_dump($form); ?>
<?php print_r($view); ?>
Doing such things in Drupal 8 outputs anywhere between 10-100MB of raw text for your browser to parse. So if you’re not running a really tough CPU you better pull up that task manager fast.
One working solution i found for this was
<?php
function dump($var, $depth = 5) {
Doctrine\Common\Util\Debug::dump($var, $depth);
}
I’ll just start another custom module, and dump this function there, and i’m ready to debug again.
But still, that is a significant amount of characters for something as simple as debugging a variable. not to mention it limits the depth of arrays.
The conclusion.
TL;DR I like the structure of Drupal 8 and, for the most part, how everything has it’s place, nothing is left to chance.
But why does Drupal 8 have to make everything overly-complicated? when some things could be made much simpler.
Over time, it is difficult to imagine that the Drupal8 adoption rate is going to be very high, when the system is difficult to maintain, requires command line interface utilities to maintain, and which is essentially a huge black box when something is wrong with its .json configuration file (“assemblies”).
If Drupal wants to keep Drupal an exclusive club for developers – all Drupal has to do is continue the status quo, and it will scare the faint-hearted away.