Four Short Things – July 22, 2019
All of these were collected and just about ready to go in February. And then I got busy? I don’t know.
The only instrumental ever banned from the radio
Reading about this made my day. I recognize the song, but had no idea it had been banned from radio.
Interesting bits:
- This is all via a Kottke post which linked to another Open Culture post which then linked to the post that covers the song being banned.
- It all makes a bit more sense when you consider the song title in the context of “The Rumble” from West Side Story, which was on Broadway just the year before.
- Still, an instrumental! Dick Clark had them on American Bandstand and was cautious not to mention the name of the song.
- This all serves as a new reminder for me to watch Rumble, the documentary, which covers the influence of Native Americans throughout rock and roll.
The best Paranoid cover
Weezer released an album of covers a couple weeks ago and one of those covers was Black Sabbath’s Paranoid. The Outline took this opportunity to write up a fairly exhaustive ranking of 21 different Paranoid covers.
My favorite, hands down, is Cindy & Bert’s Der Hund Von Baskerville:
The music is Paranoid, but the lyrics are not. Instead, they’re a take on the Sherlock Holmes story, The Hound of the Baskervilles.
Who spreads fear and terror
Automatically translated via Google from the original German lyrics.
Who destroys what he wants
Everyone is trying to hide
In front of the dog of Baskerville
My only wish is that it was longer than a minute and 21 seconds.
Weezer’s Take On Me Video
Starring Calpurnia, the band of Finn from Stranger Things. Fun throwback to the original video.
The best Lonely Island shorts of all time per Seth Meyers
“Seth Meyers Picks the Greatest Lonely Island Digital Short of All Time” is a title that explains itself.
I don’t disagree with Seth enough to really reorder these, but the Shy Ronnie sketches are a couple of the best.
Dealing with big WordPress plugins
This post has been sitting as a draft for over 2 years now and I don’t remember why I didn’t just hit publish at the time. I’m no longer at WSU, but I do still agree with what I wrote, so here you go!
May 15, 2017:
I spend quite a bit of time on plugins at WSU.
One of the challenges is finding the right way to provide a variety of features to 4500 users while not sacrificing security, performance, and stability.
Every time we need a feature, we’re faced with two options:
- Use an existing plugin.
- Create a new plugin.
The best, best, best answer is to use an existing plugin. When this happens, it means that something out there not only meets the requirements, but happens to align with our other guidelines:
- Has an open source license that is compatible with the GPL v2 (or later) license.
- Has an open development process and a well defined path to contribution.
- Solves a very specific need and does not contain a large amount of code.
- Passes a full code review by WSU’s web team or other trusted members of the web community.
When I started tackling all of this a few years ago, I made a few exceptions for some big WordPress plugins. A couple require licenses, a couple have a massive code base, and a couple have fairly closed development processes without a defined path to contribution.
At the time I figured the trade off was a great set of features with a relatively low level of effort. A few years later I now know that it’s these plugins that add the most overhead. Not financial overhead—the world of WordPress plugins is still priced so very low, but time and effort overhead.
There are a handful of smaller plugins we’ve had installed for years now without any kind of issue. They usually solve a limited number of problems and, because of the backward compatibility provided by WordPress, just work.
When a plugin gets big, it becomes more of a product than a solution. It often has a product team focused on improving the feature set, attracting more customers, and increasing revenue. Changes are made that adjust markup on the front end and UI/UX on the back end, all in an effort to improve the experience for the product’s customers.
As the maintainer of a diverse platform powering 1500 sites at a university, I’m more often looking for solutions rather than products.
To me, these are plugins that have made a handful of clear decisions and modified WordPress in a small way. Ideally, there’s a way to unhook each of the decisions or a way to build on the solution in a custom way. I can create a simple plugin that extends with decisions of my own.
So, building on an earlier writeup, if you find yourself in a position where you need to support thousands of sites and users and you have the opportunity to start from scratch, here’s how I’d approach plugins:
- Keep things simple.
- If a big plugin is useful, find the right way for it to be activated on only one site.
- Build extensions that provide access to the big plugin from other sites.
- Make your own plugins small and focused.
- Don’t get behind on updates.
I’ll stress a couple of these in more words.
If you give a site owner the ability to activate a plugin, there is a very good chance they will activate the plugin. 1500 sites later, you’ll be digging for hours to see who is really using the plugin when you want to reduce its impact. So make sure big plugins are only activated exactly where you want.
Don’t get behind on updates. The WordPress plugin model doesn’t really account for LTS releases, so security updates and bug fixes are shipped alongside UI/UX changes. If you’ve fallen for a big plugin and the product changes are causing an unexpected burden, you’re still better off updating and dealing with it now.
And get good at saying no in a productive way.