What is Custom Code?
Custom code is any PHP code that is not in Drupal Core or in one of the publicly available Drupal modules. It is used by developers to create extra Drupal functionality and used to gap between what is technically available and what is missing.
Custom Code is unnecessary
If you want a certain functionality first do an extensive search on all the available Drupal modules. This can be tricky because someone can use different terminology to describe the same problem. So make sure you spend up to a few hours Googling your use case. Changes are someone else had the same issue and solved it with a module.
When this is not the case you should be wary. Maybe the functionality you want is so unique because it doesn’t make sense. Trying to make Drupal do things it wasn’t intended for can backfire. Go back and review why you want this specific function in your Drupal website. Might there be an easier way to do this? Or maybe another application or platform is more suitable? Think twice before plunging money into this piece of Custom Code.
Custom Code is expensive
Asking a developer to create, test and maintain Custom Code is expensive. Even the smallest Custom Modules cost around 2000 dollars. Which is justifiable because creating high quality Custom Code takes time, and you wouldn’t want it for less.
And if you think you just have to pay once and be done with it, think again. Every time Drupal has an update it can break the Custom Code. The developer needs to go in and fix it. This will cost money.
Custom Code unsustainable
Custom Code makes you dependent on the developer who created this piece of code. What happens if the code needs to be changed but the developer has moved on or isn’t available for a long period of time? You might end up with a broken website.
In theory it is always possible to let another developer take a swing at it, but most likely they will grunt at the code they get presented and will tell you it’s better to start from scratch. Which is fair, because it probably will be faster for them than to go through someone else’s code trying to figure out how they created the solution.
Compare this to an already available Drupal module which you can download and use for free. Every Drupal module has a maintainer who is responsible for bugs and feature requests. If this maintainer becomes inactive it is possible for someone else to pick up where they left. Everyone can report a bug or request a feature and multiple developers can look into a sustainable solution.
When you can’t avoid Custom Code
If you need to connect Drupal to another system, such as an internal CRM tool, it is impossible to avoid some Custom Code. The arguments above still apply, though. Is it really necessary to connect these systems to Drupal to sync data? If it only concerns a few instances every month maybe it’s something that can be done by hand. If it is a well known system there might already be a module available, so make sure to check that first.
Update: After posting this blog I got a few reactions and I feel like I need to nuance a bit. If you are a developer and you can create a solution writing 10 lines of Custom Code instead of using a couple of modules, then by all means go for it. This blog is intended as a cautionary tale for organisations wasting money on a small part of a Drupal website (Custom Code) where it could better be spent on other facets of the website. Let me phrase it this way: if the Custom Code costs more than a third of the total price of your Drupal website, there might be something askew making you reconsider.
How do you feel about Custom Code?
Let me know by leaving a comment. I'm interested to hear use cases where Custom Code is unavoidable or why Custom Code might be better than an existing module.
Also, don’t forget to subscribe to my Drupal newsletter of Drupal RSS Feed.
Comments
I agree with the thrust of your article. However, you also need GREAT due diligence in considering and then investing in contrib modules. Who is (are) the maintainer(s)? How many commits have there been in the last year and five years. Look at the maintainers profiles on Drupal.org. Are they in over their heads with multiple projects? Look at the issue queues. How quickly do issues get resolved? Is there a stable version of the module? If the module is in alpha or beta status how long has it been that way?
If you think you are going to proceed try a test installation on a test site. Do the installation instructions work? How well is the module documented, both technically and from a user perspective?
In short, be careful.
Valid points! Thanks for Sharing, Frank.
this cant be serious, right?
ask the people who are waiting for Rules how this turned out.
I've build numerous Drupal 8 websites, and although I really did miss the Rules module, I managed with other modules that are available, such as Business Rules or specific use case modules like Comment Notify and Registration Role.
It might not be easy, but it is possible.
I did a "Sustainable Drupal" presentation on this topic with additional ideas: https://drupal.tv/external-video/2018-10-30/sustainable-drupal-manifesto-brian-gallagher
Thanks for sharing, Brian!
Even with the nuance bit that you've added here ("if the Custom Code costs more than a third of the total price of your Drupal website, there might be something askew making you reconsider."), I think this misses the point about what makes Drupal so great.
Drupal is deliberately well-positioned for "ambitious digital experiences". i.e. the kind where extending Drupal's inherent abilities is often essential, e.g. for integrating with other services, making all manner of bespoke alterations, etc.
So I actually see this completely the other way around. If your site can be easily made *without* custom code, perhaps a simpler solution like Wordpress, Wix, etc may be a better/cheaper fit. Drupal really comes into its own for projects that *need* heavy amounts of customisation.
Of course, any such custom code needs to be done in a sustainable way, such as properly leveraging Drupal APIs, coding standards, and being well architected. So I would happily say that *bad* and/or *unnecessary* custom code should certainly be avoided.
I do believe Drupal can be great for large organisations with big budgets that require a lot of custom code.
But my point is that Drupal is equally great for small/medium sized organisations that hit a wall trying to use Wordpress or Wix.
For example I've built a Drupal website for a federation of medical specialists where they wanted to privately share content within groups. Doing this with Wordpress or Wix is (nearly) impossible. This is where the flexibility of Drupal comes in. Instead of spending a big chunk of the budget on custom code to create this functionality you can use already available modules.
Um...a Drupal site for under $20K? Not since D6. Last time I chatted to vendors their averages prices went something like:
- D5 $10K
- D6 $50K
- D7 $150K
-D8 $250K
- D9 - if you have to ask...
Even a cookie-cutter D8 site built from a distro for nonprofits was likely to cost you closer to $30k than $20K. You are talking about websites that don't exist. If an organization can't spend those amounts then Drupal is not the right solution for them.
It's true that Drupal websites do get more expensive. But I believe if you hire a Drupal specialist that knows it's way around Drupal modules you can save a lot of time and money. And 20K can take you a long way.
Drupal is enabling organisations to do more with a smaller budget.
I got a bid to take my D8 site to D9 that was $30K. I couldn't even upgrade for the absurdly low price-point you mention creating a Drupal site for. The proof of the pudding is in the eating. For D5 and D6 I saw tons of small and medium sized businesses and nonprofits on Drupal and now there are very few. Cost and complexity are the top reasons. Yes, Drupal can save you money, but it'll save smaller organizations far, far, far less than something like Wordpress, hell from what I can tell Drupal is more expensive than any other open source CMS out there. I've been using Drupal 15 years and I know my organization is done with it now...or more accurately Drupal is done with us. It left us and others like us behind and a $20K Drupal site built on anything other than a distro is practically impossible and has been for many years now.
> I got a bid to take my D8 site to D9 that was $30K.
That doesn't make any sense. How much did that site cost to build in D8? We've upgraded a bunch of D8 sites to D9, and they've taken in the range of 4 to 20 hours. This is for websites that cost between $20K and $100K to build initially.
I have no idea what they'd need need to do that would cost $30K. D9 is basically D8. There would need to have been thousands of lines of code relying on deprecated APIs that would need to be rewritten, I guess? I can't even imagine what that would look like.
If you have sites that cheap you're probably not using all the power of Drupal and have a different scale of problem. If you use Drupal for simpler sites then you have simpler problems than us, but not simpler than something other than Drupal. There are still significantly more sites still on D8 than on D9, despite the huge security concerns and that tells you a lot about how much complexity is involved for many of us. You can also go on Slack and see many Drupal channels full of folks hitting problems, a lot of them with Composer and a lot of others on the Drupal end. Hell there's a Slack channel just for discussing problems.
Our budget closer to double your max. We built on the bleeding edge and we end up with some shaky foundations, like modules that were core to us but then were never updated... but were too expensive to replace. Others I know who built in the first couple of years of stable D8 have had similar issues. Plus Composer was not the norm yet when we built the site so we retrofitted Composer a few years later, meaning Composer was fragile too and also fragile because of the dependencies of bleeding edge modules that have no upgrade path and use things no longer supported by Composer 2 and/or D9. We had to switch scaffolding as well and have hosting challenges to boot related to different requirements for D8 and D9 and CI processes.
More complex sites have far more complex challenges. Our next site will be more in the price range you mention because we will almost certainly have to pick something other than Drupal.