Yesterday I released a version of Popularity Contest that removed all functionality and simply delivered a message that the plugin was discontinued and not recommended. It was the first time I’ve done this with a plugin, and it turns out I hadn’t thought through some of the ramifications of the changes I made. Here is a brief outline of what I was trying to accomplish and a mistake to avoid should you find yourself in a similar situation.
The reasons Popularity Contest had to die are outlined here. I also wanted to end it’s life in such a way that people weren’t left in the dark about what happened to it. That meant not just removing it from the WordPress.org repository, but updating the repository to let people know what had happened (and point them to the code, etc. if they wanted to continue with it).
I also updated the README so that the message shown to people when they were prompted to upgrade was as clear as possible.

Of course, it’s foolish to assume people will read things – you want to make the information available to those who do, but you shouldn’t assume people will read the notices before upgrading.
So we’ve established that people will upgrade without realizing that the plugin will
go away
once they do. I did realize this, but I didn’t think it all the way through.
There are functions in Popularity Contest that are expected to be used as template tags – calls that you add directly to your theme, if desired. When I removed those functions, I caused a situation where sites that were using them would break once they upgraded (until they edited their theme files to remove the template tags, or re-activated the previous version of the plugin).
So that’s the big gotcha – don’t remove any functions that may be coded into themes.
I released version 2.0.1 this morning to bring back the template tag functions in the plugin to avoid this situation. The functions no longer do anything, but at least sites that were using them shouldn’t crash when they upgrade the plugin.
This post is part of the project: Popularity Contest. View the project timeline for more context on this post.
@alexkingorg I initially read that as ‘How to End-of-Life a Penguin’, and was mightily confused.
@carlfish Stay tuned for my follow-up piece. 😉
@carlfish,
If Alex could EOL a penguin or panda or whatever the next “p” animal Google uses, the internet would beat a path to his site 😉
ROFLMAO! 😀 Nice one @carlfish!
Why not leave all the latest functionality in tack, but just add really annoying messages that show everywhere in wp-admin? Then nothing will break, but the users will know they need to move away from your plugin
As noted I the previous post, the plugin is considered harmful in it’s current state.
My take: take away the functionality (that is bad or harmful), dont break any themes or anything else vital. Nag, nag, nag through the admin interface. Maybe even autosend a nag mail to all users with admin rights.
Anyway Alex, much better handled than the 99.9% of plugins left to slowly rot away.
The problems are inherent – it’s not possible to remove them.
[…] plugin directory, he took a different route to ensure that people really stopped using the plugin.Click to read more about what the lessons are that he learned on how to “end-of-life” a WordPress […]
For some reason, and I have no idea why, Automattic is totally myopic/cavalier/secretive/dumb ~ whatever ~ about providing compatibility information about plugins.
You can see this displayed (or rather not displayed) every time you use WordPress to search through thousands of irrelevant, no longer current and outdated plugins.
Is it because they don’t think it’s important? Maybe ~ they only think that what THEY think is important, is important.
Is it because they don’t have the programming chops for it? Hardly ~ the information is/or should be contained in every plugin (Better Plugin Compatibility Control by Oliver Schlöbe adds version compatibility info to the plugins page to inform the admin at a glance if a plugin is compatible with the current WP version) ~ once it is installed.
Nice plugin, good attempt, but too late in the process, in my opinion.
Is it because that to come clean with everyone and admit that the bulk of plugins in the repository are out-dated, non-functional, damaging, or present a security risk, if used in the current release of WordPress? More likely ~ since it’s the only reason I can think of they don’t fess-up and be honest with us.
It would be the work of a moment or two, to include the embedded compatibility data from each plugin, in the search description list, so that you can make up your mind without wasting time digging into the interior or worse, installing and finding out the hard way.
With a simple compatibility of “3.2 – 3.3” or “2.8 – 3.5” in the search description listing you could make your own mind up whether its worth looking at.
So why don’t they do it? I leave you to draw your own conclusions. But what ever you decide is the reason, it can hardly be because you think Automattic, on this occasion, is doing anything else but serving its own interest. Whatever they may be.
It’s certainly not serving its customer-base by maintaining this deception. It’s high time Matt took the decision to be honest with WordPress users around the world, and show just much much outdated useless and potentially damaging junk lurks within the plugin repository.
Strangely enough, in doing so, I think he would earn respect and admiration for taking a decision ~ which is long overdue ~ and by taking it out of the hands of the luckless individual who’s job it has become to maintain the repository, and who doesn’t have the guts, intellect or wit, or for some other reason, is not willing to tell the king he is naked.
Do the right thing Matt, You know it makes sense.
In my opinion it is the people who hardcode functions into their themes who make mistakes, not the developers who declare their plugins end-of-life.
[…] seen some people indicating that calling plugin functions in themes is a bad idea (here’s an example comment to that effect). I think this is going too far – including a call to a plugin in a theme is […]
How to End-of-Life a WP Plugin
http://t.co/IXFq2or1
[…] blog http://make.wordpres[...]/Baja.comHow to End-of-Life a pluginCoolest WordPress sites?Develop for HiDPI displaysbbPress 1.x plugins retiringRyan bar trick: […]
How to End-of-Life a Plugin http://t.co/2trJOVlg via @alexkingorg
[…] a plugin and how Tim Ferris’ blog “broke” when he updated the plugin. That was my fault. As Matt noted in his story, he sent me an email letting me know the issue and I was able to push […]