Anton Timmermans

August 9, 2023

Django signals are a better version of WordPress hooks

When trying to upgrade your WordPress developer skills you might run into the Human Made engineering handbook. On the page about modularity is says: "Actions and filters are actually an implementation of the Mediator pattern, and mediating between different parts of code is where hooks truly shine". I love that take. What I don't love is that in WordPress it's usually the only way to extend. Also hooks have a ton of problems.

But now I have found Django signals. They are a way better implementation of hooks. Mainly because instead of using strings as identifiers, signals use code identifiers as identifiers, crazy right? So now, in my IDE, when I need to know where a hook is used, it just knows. Instead of having to use search, which immediately breaks with `"{$old_status}_to_{$new_status}"` hooks. Yes, an IDE can build support. But signals are first class Python citizens.

And by convention every app specifies it's signals in a `signals.py`. So it's really convenient to know which signals are available. I'm loving it.

It slots right into my engineering opinion of WordPress: The WordPress PHP codebase makes tradeoffs that reduce code quality, but increase ease of learning. That's a worthwhile tradeoff, but it could have better code quality while still having the same ease of learning. The tradeoff is not optimized.