Fixing contrib javascript

Helping contrib point the gun away from it's foot since 2012

In my previous post about javascript maintainership, I stated that If core JS doesn’t get in your way, as far as I’m concerned, I did my job. While true, it’s pretty much Level 0 of my ambition. I do have an overreaching Evil plan1 2 and first I want to talk about where it comes from.


I started contributing to Drupal in 2011, I’d been using it for a couple of years but didn’t really run into problems. Then I got a job to work on a website for a pretty big brand and with some fairly complex mapping functionalities. They needed to draw lines on a map so I used the OpenaLayer module and a ton of custom code. The Drupal integration of the OpenLayers library does some pretty wierd stuff and I wasn’t really happy about it so I send a few patches and eventually became maintainer of the module — and found out that it’s hard to maintain a big module with lots of users.

Those maps were showing up in views, ajax views (it looks broken, probably is, no idea). I ran into various javascript bugs of the ctools module. Sent patches. Thankfully most of them made it in so I didn’t have to worry about a patched ctools. The jQuery UI patch for ctools modal was the most fun, had a solution that monkey-patched the JS all over the place.

At that point I was pretty horrified by the quality of javascript code in contrib and there were a number of problems I would see in pretty much every contrib module I’d use. So I looked into core javascript — originally to understand why is OpenLayers recursively calling Drupal.attachBehaviors — it became obvious that all the modules copy pasted some piece of core JS and tweaked it.

To fix contrib, core had to be fixed.

Evil plan

Drupal powers some huge sites out there so improving Drupal actually improves the web. My real ambition is to use Drupal to make the web a better place and stop seeing horrible javascript everywhere.

Originally the plan was for Drupal 9 because there was a huge amount of work. That’s until my first big clean-up patch was committed by Dries 14 days after I opened the issue. Seeing how quickly that got in, there was hope and the plan was put in motion.

Achieve Good

The very first thing is to gain people’s trust, and the best way to do that in Drupal is to fix critical bugs and write change notices. Recruit a minion and make him work on a complex major performance bug, refresh the aging JS and get it to follow best practices or help out a review-starved team so they owe you — don’t worry they know how to “Friendly blackmail” too.

Plant Evil

Now you have some opportunities to push for and use trojan patches[^3]:

New world order

In the end, what does it mean for contrib? Here is what I hope contrib authors will do:

  1. run JSHint and fix every. single. error.

there is not 2., I know you guys are just as lazy as me. JSHint will find bugs and it will make you a better JS developer. I’m not shooting for perfect, I only wish that one day I’ll be able to say Drupal javascript? It’s not just good, it’s good enough!. For the smartypants™ that already run JSHint, there is a follow-up post talking about jQuery, Vanilla JS and what you can do if you have time to spare.

Run JSHint. If you don’t know how to fix a JSHint error, ping me.

Help Drupal make the web a better place, thank you.

  1. It’s not really an “Evil plan”, it’s because “Good plan” just doesn’t sound as good.

  2. Sure, trust that guy 1, see what happens.

  3. Better known as excuse to be able to say but look we’re already doing it like that there, it’s for consistency patch.