Easy Updates Manager began as with any WordPress plugin: a line of code.

My History with Easy Updates Manager

For me, it started with a problem. I inherited an agency problem where plugins were modified and the only solution was upping the version number in the core plugin file.

As I pondered a solution, I had some initial thoughts that others would find such a tool useful. The ability to disable plugin and theme updates would be an awesome tool in a developer’s arsenal.

I had two initial requirements:

  1. The plugin must absolutely work with WordPress multisite
  2. The plugin must be easy to use

I began coding the plugin and released the code to GitHub. I was proud of the result.

Disable Updates - Plugins Screen

Disable Updates – Plugins Screen

 

Disable Updates - Theme Screen

Disable Updates – Theme Screen

Releasing on WordPress.org

The next step was releasing the plugin on .org. I figured others would find the plugin useful. Then I did my due diligence before releasing the plugin: I searched for similar plugins.

There was a plugin I found called Disable Updates Manager by Matthew Sparrow. It was very close to my plugin, but it did not work in multisite.

Disable Updates Manager

Disable Updates Manager

I made a crucial decision at this point. The plugin already had ten thousand installs and an established user base. The owner was also very active in support, so I figured I would contact Matthew and see if I can help make it multisite compatible.

Matthew’s Perspective

Matthew released Stops Core Theme and Plugin Updates when he was 13. He was brand new to coding and originally released the plugin to stop plugin and theme updates.

In his words: “It wasn’t the best made plugin. In fact, it was probably the worst coded most unprofessional plugin on the repository.”

I attempted to upload it to the WordPress Plugin Directory. This was around early September in 2013. It took me almost a month before I finally figured out how to upload the plugin so that it would show after it was approved. – Matthew Sparrow

In the summer months of 2014, Matthew added the settings page for the plugin.

Because of the settings page being added, I changed the name of the plugin to Disable Updates Manager. This is when the plugin really started to get some downloads. It went from getting maybe 5 to 10 [downloads] a day, to getting around 40-60 a day – Matthew Sparrow

In the fall of 2014, Matthew put the plugin on GitHub to get some help from the open source community. He remembers getting help.

[A volunteer developer] basically recoded half the plugin and added a ton more features. The most notable feature being to disable themes and plugins individually (the first plugin in WordPress to do this). I was left alone to attempt to maintain this plugin on my own. I did ok, until I reached the limit of my coding at that time. I sort of just left the plugin to die come the end of December of 2014. I kept up support, but that was it – Matthew Sparrow

In February of 2015, Matthew and I crossed paths.

The Making of Easy Updates Manager

It was around February of 2015 when I emailed Matthew through a contact form on his site.

I saw your plugin on .org and was very impressed. I was looking for a good GUI for disabling individual plugin/theme updates.

The main issue I ran into was lack of multisite support, so I decided to use some of your code in a custom plugin I wrote last night.
https://github.com/ronalfy/Disable-Plugin-and-Theme-Updates

Instead of releasing my version on .org as a competing plugin, I was wondering if there was a possibility of collaboration to bring multisite support in with your plugin.

If you feel multisite support is out-of-scope, perhaps we can agree on a plugin/theme header to support that we can read on activation and automatically mark a theme/plugin as not upgradable.

I’m on skype (ronalfy) if you’d like to chat. If you do add me, please include a note you’re from mpswp so that I don’t block you (I get a lot of spam contact requests).

Thanks so much,

Ronald Huereca

From my perspective, Matthew was very willing to take on help. He saw my GitHub plugin, installed it, and saw the future of the plugin.

He gave me free reign to recode the plugin, and adding a plethora of features to make it the first of its class.

We decided based on the features to rename the plugin Easy Updates Manager, create a YouTube channel, create a wiki full of documentation, and continue with support.

The main thing I was concerned with, multisite support, was highly emphasized in the plugin architecture.

Matthew describes the current success of Easy Updates Manager, which currently has over 300,000 downloads and 80,000 installs.

[The history of Easy Updates Manager is] how it went from a fun summer project to an epic WordPress plugin.

The Danger of Plugin Abandonment

Easy Updates Manager is a success story on how two developers collaborated to turn a dying plugin into a successful one.

I asked Matthew what kept him from putting Easy Updates Manager up for adoption or just flat out abandoning the plugin.

I made about 10 other plugins that all failed and that I put up for adoption. No one adopted them so I got them deleted off of the WordPress Directory. So since Easy Updates Manager was the best plugin out of them all, I sort of wanted to hold on to it. I also wanted to learn more coding so that I could hopefully come back to the plugin and continue development.

Before you came though, abandoning the plugin was an option that I was seriously considering.

– Matthew Sparrow

Takeaways

If you have a good plugin idea, code it how you like it. You’ll learn development that way. Then when you are ready to release, find out if there are similar plugins. If there is something similar, see if you can contribute to the plugin. I would argue most successful development relationships start with a pull request.

When I asked Matthew for advice for someone starting a new plugin or contributing to an existing one, he said:

First of all, never give up on your plugin. I sort of wish that I didn’t get rid of all those other plugins. You don’t just create a plugin and it magically gets thousands of downloads. Just like how you don’t create a website and expect to get thousands of views on the first day. It takes work to get downloads. It may also take a few plugins before you finally get one that hits off.

Also, make sure that you are able to continue to support the plugin. If you just create the plugin and then don’t answer any support questions and don’t update it every once in a while, then the plugin will go next to nowhere.

Make sure that your plugin is unique. It is different from all the other plugins out there. Think of new features, think of good ideas. Don’t just create another contact form plugin 🙂

For people contributing to an existing plugin… look for a GitHub page or something that the author is active on. If it is not a professional company who is making the plugin and trying to make money off of it, they will most likely be more then willing to add you as a contributor. If there is no GitHub page, don’t post in the support forum [sic], instead, look on the authors profile page or website for contact information (like you did). Also if you are contributing, don’t be pushy about getting your name put down as a contributor on your first pull request. Be patient and then they will add [sic] build up more trust and add you.

Do You Have Your Own Plugin Success Story?

Please leave a comment. I’d love to hear from you. Write your own plugin success story. I welcome links in the comments.

Advertisements

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *