In less than 12 months, Drupal 7 will be end-of-life and no longer supported. Plan your upgrade to Drupal 10 now.

Defining boundaries between custom Drupal modules

I recently made a change to a Drupal project with several custom modules.

As part of the change, there was a method that was no longer being used, so I went ahead and removed it.

There were no tests for this part of the codebase, and the existing tests were still passing.

My change was successfully finished and deployed, including removing the unused method.

A few days later, we noticed cron jobs were no longer running on the website.

The method I'd removed was attempting to be called from within a different module.

Because it no longer existed, it was causing an error and stopping the cron job from running successfully.

When I re-added the method, the cron jobs worked again.

There were no dependencies set in either module's .info.yml file, though that would only prevent you from uninstalling either module.

It wouldn't prevent me from deleting code used by another module.

Here's the thing

This is why I've been experimenting with architectural testing. To ensure that modules only use their own code and to start enforcing layers within each module.

Then, if I had the same situation again, I'd know straight away that there was an issue and not have to wait for the bug to be deployed to production.

- Oliver

P.S. Do you need immediate access to an expert Drupal Developer? With my Drupal development subscription, make unlimited requests for a fixed monthly price in less time than posting to a job board!

Was this useful?

Sign up here and get more like this delivered straight to your inbox every day.

About me

Picture of Oliver

I'm an Acquia-certified Drupal Triple Expert with 17 years of experience, an open-source software maintainer and Drupal core contributor, public speaker, live streamer, and host of the Beyond Blocks podcast.