Former Code Enigma director, Steve Cowie, wrote a guest blog about why he’s sticking with Drupal…

I recently read a Torchbox blog explaining why they’re dropping Drupal. There’s a contrast between their reasons and my experience as a reborn developer, using Drupal 8 for the first time. I’ve always dabbled in code but didn’t have time to tackle advanced challenges during my time as Director of Code Enigma. My deeper understanding stalled at version 7. Now I’m back as a freelancer and my first contract has been to re-platform an intranet from D7 to D8.

So, here’s some aspects of D8 that I really like.

Symfony

One reason Torchbox gave for moving away was the tight integration with Symfony. Before I got into the code I might’ve agreed, but it turns out Symfony makes life easier because it applies a standard software model.

Symfony is in line with the MVC model so it’s no bad thing to get a refresher on that and object-oriented code. After initially getting into Drupal, my object-oriented coding knowledge withered. Prior to D8, Drupal allowed developers to be so free-form and procedural that O-O diminished. It seems anyone with a development background will find Drupal easier to grasp now because of Symfony.

Symfony has a consistent structure which helps when creating something new by observing an existing pattern. I’ve experienced this creating an ical feed. The feed I needed didn’t exist but I could analyse the RSS feed and adapt. That compensates for the fact that Googling ‘D8 problems’ is not as simple as D7 due to its shorter history.

Both Symfony and Drupal are PHP frameworks, and it’s suggested PHP is in long-term decline; I’m not convinced; I’ve been hearing this since 2001. It’s more likely PHP got a massive boost in the early days because it was easy to get into. There’s been an inevitable decline as alternatives arise, but I bet it’ll still be a major player in ten years. It’s not a bad idea for a development agency to build expertise in alternative languages like Python, but it isn’t a case of one over the other.

Twig

Twig has become Drupal’s templating engine, as part of the adoption of Symfony and has an improved debugging system. I don’t need to figure out when some obscure logic is being applied — just switch on debugging and inspect the source code to see which template is being used, with a list of alternative suggestions. Also, there’s generally a suggestion of which preprocessing function to use so you can can access data before it gets rendered. You can use the preprocessing functions to get to the data before it’s rendered, or you can use Twig debugging to view the variables being passed to Twig in a file cache. Code Enigma developers used to have to remove Drupal markup and replace it with a designer’s preferred markup, so D8 and D7 are night and day.

You can integrate your Drupal Twig templates closely with tools like Patternlab, which will also output Twig templates. Those can have variables that are populated from one source in Patternlab, but populated by Drupal in your site. You achieve that using the Components module, then using Twig’s support for embedding and extending templates.

If you’re working on a design-led project, the team can create and test patterns with end users, without waiting for full Drupal integration. I’m aware that in practice, design and development run the risk of making assumptions that ignore real-world complexity. But the number of times you say “sorry, Drupal doesn’t do that” will be a lot less.

More in core

You may question how this all helps the site-builder, The person who primarily plugs in and configures modules without writing custom code. Undoubtedly there are fewer contributed modules for D8 so a site-builder can struggle if a particular module isn’t there. But, it’s possible to build a lot more using Drupal core. With views and media now in core, you can achieve a lot without adding contrib modules. Also, core includes more external libraries such as CKEditor. Certainly, there are a few contrib modules I’d generally still add automatically, such as Paragraphs and Webform, but those are both available for D8.

I think building sophisticated sites by sticking together modules designed by different people was always questionable. Even without D8 there are other forces that question the idea of assembling complex sites like lego: responsive design, front-end frameworks, user-centred design, to name a few. The idea that customers use an open source CMS and build anything they wanted really cheaply hasn’t stopped being true because Drupal has changed; it was never really true in the first place.

Drupal console

Console is a tool for running shell commands to carry out miscellaneous tasks. Most of the time, the tasks can be just as easily done using Drush, another command-line tool, but I do find Console useful for generating new ‘things’ such as entities. For example, I’ve just built a content entity to hold a particular type of data that needs to be searched in a Drupal intranet but gets generated elsewhere. It took ten minutes to build the entity using two console commands. Certainly in this case, the data schema is simple but still … ten minutes to build the necessary entity with permissions, theme components, menu routes, CRUD forms, and a listing. Also, relating this back to the site-builder, I could teach someone to do this in no time, so the site-builder with fairly basic coding skills could extend a site without having to wait for contrib modules.

Configuration files

D8 has a system for exporting and importing configuration between database and yaml files so config can be included in version control. It also means you can build and test a new feature and quickly recreate it in another environment, either manually or as part of automated deployment. There’s plenty of scope for merge conflicts and problems where it’s unclear whether something is content or config (blocks and webforms for example). But it’s an improvement on D7 with a mish-mash of Features and Ctools being used to get things into code. What invariably seemed to happen was a Feature would get overridden and it wouldn’t be clear how safe it was to revert. Doing all config as very granular YAML files makes it easier to see where a production site has deviated from the staged or backup version.

Release cycle

One problem used to be upgrading after a major version release. It was difficult explaining to customers that moving to a new version might cost as much as building the site in the first place. Also, that it might be impossible to do an upgrade if a site relied heavily on contrib modules. In D8 there’s been a move to semantic versioning, and new features can be included as minor releases. For example, media has now become part of Drupal core. Reducing the risk that major subsystems used to make a working site are developed outside core, leaving you screwed if the system you require doesn’t have a compatible version. Moreover, if all the systems needed are either in core or custom modules, it’s not going to be a nightmare when Drupal 9.0.0 is launched.

Debugging

In previous versions of Drupal, it was common to make a change to your site, such as adding a new module, then get a blank screen or WSOD. To debug you might’ve dug into server error logs and issue queues (assuming your environment allowed this). In D8 you get a great backtrace of where/what went wrong.

One caveat about improved debugging is that I think it’s more or less essential to have a tool like Xdebug running, which probably means you’ll be running virtual machines in your development environment. One reason for Xdebug is that the Devel module debug tools for D7 don’t exist in the same form, and the objects that a D8 process builds in the course of assembling a page can be deeply nested. A debugger allows you to drill into those.

Arguably, the need to run a VM with Xdebug reinforces the case that Drupal is no longer a simple CMS that can be used by anyone who can download and enable modules. But that’s not my primary concern. What I’m interested in is whether D8 is a good platform for development, and I’m convinced it’s a major improvement on what’s gone before, and much more enjoyable to work with.

Conclusion

My real message is that coming back to Drupal as a developer has been refreshing. With previous versions, creating a web application didn’t always feel like development — it could feel like simply sticking modules together until things broke, then figuring out why. Now it’s a more coherent platform, providing a consistent set of techniques for building. I’m confident Drupal will still seem like the best solution to plenty of online communication challenges for a long while to come.