Hello Dolly. Revisited.

The plugin Hello Dolly comes bundled with every WordPress installation and adds a line of the famous to the top of the WordPress dashboard. And it’s not always appreciated.

This is the most useless plugin ever created

Why???

For The Love of GOD, Why is this STILL on the Repo?

…are just 3 of the 1 star reviews for it.

Why is it included? Well, it’s not basically Matt wants everyone to learn the lyrics to one of his favourite songs. No, it’s included as an example of a basic plugin and how anyone can write one. It’s a demo.

But it’s been in the plugin directory for 15 years and probably existed for even longer, with no real updates during this time. And, as a demonstration, it’s now out-of-date. As an example of how to write a plugin, it’s no longer doing its job.

So, as a mini personal project, I’ve decided to bring Hello Dolly up to date. Sadly, I can’t make people love it.

First Look

Before I do any “proper” testing, the first thing I did was download the latest version and take a look at the code.

And, it’s small. It’s pretty much the most basic plugin you can get – it’s not going to show you how to code or give you a good start on hooks and filters. Instead, it’s really just a demonstration of the minimum requirements of ANY plugin – layout, structure and the basic requirements laid out by the plugin reviews team.

And, yes, I can see issues in both the code and the README (the latter of which is really, really simple. Too simple, I’d say).

PHPCS is your friend

Next, I ran the plugin code through PHPCS. I’m using the WordPress and WordPress VIP rulesets, which should give you a good, overall, set of minimum requirements.

There are 3 areas that this pulls the code up on…

  • Comment layout
  • Use of mt_rand (you should use wp_rand ideally, as it produces a “more” random solution. This function was added to WordPress after Hello Dolly was written, hence the omission)
  • More worryingly, though, there are 3 escaping issues, which means the plugin has vulnerabilities

README Validation

I pushed the README through WordPress.org’s own validator and got the following…

  • The Requires PHP field is missing. It should be defined here, or in your main plugin file.
  • No == Frequently Asked Questions == section was found
  • No == Changelog == section was found
  • No == Upgrade Notice == section was found
  • No == Screenshots == section was found
  • No donate link was found

A lot of this isn’t particularly concerning, but adding a lot more content would be a good way to show general expectations.

Indeed, take a look at their own example of a README file.

HTML & CSS Validation

The CSS passes muster, and the HTML that’s generated passes fine too.

A Second Glance

Now I’ve run all of the above, it’s time to take a further look at the code to see what’s missed.

  • The most obvious thing, to me, is the inline CSS – this would be far better enqueueing. That way it can be minimised, combined, and anything else that someone might want to do.
    As another example of good practice we can also provide both a minimised and non-minimised version of the CSS with the plugin, with the former being the one that the plugin loads.
  • The code could also do with a LOT more commenting to explain the what and why of it all, which is important to guide anyone new to plugins through it all.
  • Finally, there’s little translation going on here – I see one sentence being done but the core lyrics are not.

Anything Else?

Looking at the plugin support pages it doesn’t look as if there are any reported issues with the plugin and I can’t find an official Github repo for it, which means there isn’t a list of issues lurking there either.

As it’s part of core, I though Trac might yield an answer and, bingo, I was right. There doesn’t appear to be anything open, but it appears that some issues in recent years have been fixed (accessibility changes as well as suppressing the output in the block editor) – the changelog is pretty poor for this plugin.

Conclusion – what needs to change

Based on all of the above, the plan, right now, is to do the following…

  1. Make PHPCS recommended changes to code
    • Comment layout
    • Use of mt_rand
    • Fix the escaping
  2. Improved README, including a lot more of the basic tags
    • Include a more detailed changelog
  3. Add a full plugin header
  4. Add translation to the main lyric content
  5. Move CSS to an external script and enqueue it to WP Admin
    • Create a both a standard and minimised version of the file
  6. Add a ton of extra commenting, explaining fully what’s happening throughout the code

And, probably more important, it needs to do a better job of explaining its purpose.

Next Steps

My plan is to fork the plugin and make all of the above changes, dragging the plugin most definitely into the 2023’s.

It’s highly unlikely that I’ll be allowed to fork this plugin and add it back to the directory, as it will be too similar to the original. To this end, I’ve created a Github repo for what I’m going to call Hello Dolly Redux.

Even once the changes are made, I’m going to leave it open for others to contribute – either add things into the Issues log or even just add their own Pull Requests. I may even be brave enough to ask the core plugin review team to take a look to see if there’s anything else they can recommend 😉

Update: the initial release of Hello Dolly Redux is now available.

I’ve also added a Trac ticket for the core team to consider changes to the Hello Dolly plugin along the lines of what I’ve suggested here.

Talk to me!

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Discover more from David Artiss

Subscribe now to keep reading and get access to the full archive.

Continue reading