"The Internet" has an endless supply of helpful articles that make the complex job of a web developer much easier. Most of them emphasize a result in the form of refined, sanitized code that gets the job done, which is usually what readers are looking for.
But what about the process? What about the scrappy, hacky, embarrassing nonsense that was vital to the final product? All developers have some tricks, but we rarely talk about them publicly. Hacky code gets lost to Git. One-line solutions get stashed in personal notes. Scrappy tricks get shared with co-workers but otherwise remain unknown.
Unknown no more! It’s about time these things were celebrated and shared more publicly. They may not be pretty, but they’re crucial to many projects.
Execute Code with a Form Alter
Sometimes you just need to execute some PHP code in Drupal. Maybe you need to edit an entity that isn’t available in the UI. Maybe you’re writing a hook_update_N and don’t want to iterate that pesky N every time.
For situations like this, the humble form_alter hook does excellent work as a testbed for code. It's very easy to add to any module, and then all you have to do is refresh any form to test out your unrelated code. Make sure you move the code to the correct place once you’re done.
Manipulate Config Files Directly
You’ve almost certainly edited configuration files in your projects by changing something in the UI and then exporting it. Most of the time this approach works great, but sometimes it's much faster to do the inverse by changing the configuration files and importing them.
Perhaps you have to set up many different roles on a site, each of which shares a central core of editorial permissions for all the various content types and paragraphs. Clicking every single box on every single permission is going to take far too long. Instead, you can simply build out one role and export it, and then copy the mess of new permissions into all of the other roles files, and one config import later you’ll have all of the roles updated. This saved a lot of time.
Use Drupal to Solve Drupal
There is so much going on within Drupal Core and its myriad libraries – so much so that the whole system can feel like an inscrutable black box that happens to be extendable. However, if you have a local version of Drupal running, by definition you have all of its code running in front of you. This allows you to do things like put Xdebug breakpoints directly into Core files to see what they’re doing.
Perhaps you’ve found a cool Drupal function online that isn’t working the way you expected it to. You can search that function in your local repo to see how Core uses it. Unsure how a piece of code is supposed to work in conjunction with other systems? Find an automated test that uses said code. Having trouble extending a class? Search Core for the words “extend ClassName” and take a look at what its contemporaries do.
In short, Drupal Core itself is a great source of information and should not be discounted. In fact, if you really want to get crazy…
Don’t Sometimes Hack Core
One of the holy tenets of Drupal is that you never hack Core. This is generally excellent advice, since a hacked version of Core is harder to update, less compatible with contrib modules, less secure, and open to a myriad of other problems.
This dictum, while snappy and easy to remember, overlooks some important nuances. It would be more accurate to say “don’t create new functionality by hacking Core.” However, if you need a quick testbed for an idea or are trying to understand how something works, hacking Drupal is an invaluable tool. This can be done to:
- Add specific conditionals to catch where things weren’t working in the expected way
- Edit a field widget directly to make sure your idea works before going through the effort of building your own widget
- Temporarily disable an annoying error message that was interfering with something you’re working on.
As long as you undo the change and don't build any functionality on top of your hack, then this is a totally valid tactic. Besides, if you break your local Drupal code too much, you can always re-install Core by deleting it and re-running “composer install”.
Conclusion
At Chapter Three, our projects are replete with inelegant tricks of the trade like these. They’re the developer’s equivalent of duct tape: they get the job done quickly when nothing else will. Figuring out scrappy, creative workarounds to thorny issues is a big part of what developers do all day. It’s time these tricks got their due credit.
Are you a developer with your own bag of Drupal tricks? If so, we would love to hear from you. Please send us your tips and tricks via social media or to us directly. We’re always eager to learn what others in the developer community are doing.
