The harbingers of glorious Spring have arrived in Western New York. The gradually warming air smells of moist earth and recently the birds that flew south to warmer climes half a year ago have surreptitiously returned to renew their habitation in the many beautiful trees that grow everywhere here in sunny Tonawanda, NY.
Drupal just turned 25 and that is to me a testament to its usability and extensibility and general awesomeness. The world of software development is brutal, and only the truly performant survive. It’s true of software and software developers alike. Frankly, I believe that if Drupal was not good it would not still be around.
Drupal has come a long way since 2005, the year I was introduced to it. Symfony Framework was a tough pill to swallow for many Drupal devotees including myself, but it was for the best. I love Symfony Framework when I am building out custom functionality in Drupal. From my limited perspective as a dev, it’s so much easier to build minimalist code solutions that leverage Drupal’s already impressive list of internal services built in a modern PHP framework.
More often than not in my career, I seem to always end up as the person who is called in to fix broken Drupal sites. I’ve internalized the worst, most egregious and disenfranchising situations that I have been exposed to as a Drupal developer as vital learning experiences. Lessons to myself along the lines of “Here, there be dragons.”
I’ve listed 5 pesky but persistent problems that I have seen Drupal sites plagued with since D7, the start of my experience with Drupal. Please remember that the following observations are just my opinions based on my limited experience.
The top 5 Drupal mistakes I still see all the time.
1. Modding the core.
Drupal core is the foundation of all functionality in Drupal. It’s standard practice in the world of CMS to separate any codebase into specific folders to denote their intended use. In any CMS there is always a section that is understood to be managed by the software vendor. Drupal core is the same, its produced and managed by an amazing team of dedicated developers. Modding Drupal core not only voids all intended warranties but also disconnects it from automatic security updates. Security updates are possible through manual patching, but I have never seen a non-Drupal developer prioritize Drupal recommended patching. Ever. It simply does not happen. Modding the core also disconnects Drupal from automatic PHP minor version updates. That usually results in years long version freezing. When an enterprise freezes the code at one PHP version sooner or later that tech debt will consume every new feature request for the next 12 months. I’ve seen it happen. It ain’t pretty. Please don’t change the code in the Drupal core folder yourself. If you need custom functionality, put it in a custom module, as per the decades old documented recommended practice. No matter how good a dev you are you can’t compete with Drupal’s hardcore team of dedicated experts…
2. Not using Composer.
Repeat after me: “Drupal is managed with Composer. This is my Composer. There are many like it, but this one is mine.” Composer is arguably one of the most useful and at the same time most frustrating package management utilities ever invented. Many a dev has burned hours untangling software package dependency conflicts. Not using a Composer based workflow in Drupal costs a lot of money in the long term. In my experience in the last 5 years what I see is Drupal sites built initially using Composer, but once that initial set up is complete, that development team is followed by developers that simply copy-paste module code into the CMS and enable it the way I used to do for Drupal 7. This is the wrong approach for Drupal 10 and 11 because since Composer has become mainstream in the last decade, almost all devs contributing directly to Drupal are bundling their add-ons using Composer. That means that if you don’t use Composer for all your installs in Drupal you have a very good chance of not installing required supporting libraries the Drupal code needs to run correctly. Not only does this break stuff, but it makes Drupal run poorly and not have a finished professional look and feel when it runs.
3. Not leveraging Symfony Framework.
This is a big one. I have seen all kinds of code styles written into a Drupal codebase, and to a certain extent it will work, but not well. The Drupal team has been working for years to make Drupal faster. Symfony is one of the ways Drupal breaks PHP speed limits. A lot of Drupal builders talk about caching but the biggest performance gains I notice in Drupal is when the application code is firmly based on functionality that is in Symfony already and is leveraged correctly. Too often I see developers writing boilerplate functionality like form sanitization or file handling code when they could just use existing functionality already written in Drupal. Before you start coding anything in Drupal look under the hood. Chances are that the building blocks for your project already exist to some extent. The bigger your site and the more traffic it gets, the more potential it will have for poor performance and poor stability unless you work within the parameters of the framework.
4. Poor platform integration.
I have two main complaints here. The first is that in about 70% of the Drupal sites I have worked on in the last decade, the developers stood up the application on a default Apache install. Yes Apache is designed to work out of the box. Yes, it’s the best scaling multi-threading web server in existence powering over 70 percent of websites. It confounds me to this day as to why people don’t configure it once they install it. The state of PHP environments is no better in some cases. Poor PHP memory configuration settings, anorexic server memory resources, and improper use or over dependency on PHP extensions are all culprits but when these two are combined in a big soup of fail, there is no way in the world that a Drupal developer can develop anything performant in Drupal. It’s no joke. This paradigm has plagued Drupal for so long that it has been the genesis of dedicated hosting platforms for Drupal like Acquia and Pantheon. These web hosting platforms are built specifically for Drupal, and my experience is that they work better than most on-prem solutions cooked up by the IT department in any enterprise. While I agree with dedicated hosting I am mindful that it would be better to train developers to have these platform skills rather than send them out into the wilderness with a laptop running Docker and a head full of shiny promises. The only thing your server admin should be doing on your LAMP stack is performing upgrades to server software like the Apache service and the MySQL service. It’s up to the Drupal dev to own the PHP environment and the web server config. That’s all I have to day about that.
5. Altering the Drupal Database from its baseline.
Every database engineer that I have ever worked with struggled with extensibility in their data structures. Like the old saying, “No battle plan survives contact with the enemy.”, no custom database schema ever survives contact with the product owner. The database in many respects define the extensibility of any application so it’s very hard to anticipate the actual use and performance of an application when it’s built from the database schema on upwards. Later on when you want to improve and expand, you change the database structure for the new functionality and the entire application codebase needs to be refactored at great cost to the product owner. Drupal is different. When you want a new table for your data developers should use Drupal’s database API for data operations and table management. Drupal manages its own database. It’s quite impressive to me because I have observed that no matter how much data you cram into a Drupal database it always returns content at the same speed. This is perfect scaling, and you will not have to become a database engineer to appreciate that all the heavy lifting has been done for us in Drupal. If you need a new schema it is defined in an installation file. Alterations or additions to any Drupal database schema are then done with an update hook in production. It’s so easy and stable and has no negative effect. There is absolutely no rhyme or reason to alter a Drupal database manually, and I wish I would stop walking onto Drupal jobs where that has been done.
In conclusion, Sam Altman recently expressed his heartfelt appreciation for the contributions of software developers like myself. As he begins to forget how hard it’s been to create all this, and we shift into the AI era I am mindful that although Drupal fully supports user based AI interactivity, I am not aware of any Drupal specific LLMs or config files for AI Agents that would ensure total Drupal methodological adherence. That’s something I might work on and, if I get it working, I will share it with you, and you can test it out… Perhaps when all we devs die out our knowledge will persist in some LLM somewhere like a ghost in the shell, or a memory fragment.
Happy Spring. Happy Drupaling.
End of line.
