@1stepforward - you might want to consider fx-updater for handling this. I use it for my personal utility plugin and theme. It does a great job and works exactly the same as updating any other plugin.
The idea of having to install a plugin to update another plugin doesn’t much appeal to me.
100% agree.
However, I did find a (non-critical, though still important) issue with the fx-updater plugin. If a user is on the updates page and they click for “more info” about the update, the modal window is missing a lot of data and tabs. It looks broken. The issue is simply that the update endpoint doesn’t spit out all the fields needed to populate the display. I’ve managed to get it fixed on my end without too much trouble. That said, I should note that the updates do indeed work great, it’s just that one modal dialog that detracts – and I suspect few users ever even click through to that view, so, it’s really a small issue; just something to be aware of.
I have taken a look at this in the past but was put off by the fact that it appears to have been abandoned. It hasn’t been updated in 3 or 4 years. I also looked at Reaktiv Remote Repo but that’s even more out of date.
But I’m glad you mentioned it though as I’d more-or-less dismissed it and it’s good to see that it is perhaps still worth considering.
Have you found fx-updater to be reliable and secure despite it not having much TLC recently? I note that @anon71687268 had a relatively minor issue with it.
I totally understand that. I mentioned something similar the other day (albeit slightly tongue in cheek).
It works really well and the docs are very clear too. I had no problem setting it all up. I contacted the dev to ask him a question and he was very responsive. He’s just not maintaining it any more. Not sure about the security of it. I’m only using it on my own sites, but that may be more of a concern when you start updating 3rd party sites.
I wasn’t aware of the problem that @anon71687268 mentioned but he seems to have worked out a fix. If I knew a little bit more about coding I’d fork it myself, but it might be a good candidate for someone else to take over. 
Yeah, it’s one of those plugins that just continues working because the developer didn’t do anything wonky to get the task done. I only discovered the modal issue by accident…it’s easy to overlook. I created a PR that attempted to address some of this, later realizing that it could actually (appropriately) be handled via the fx-updater plugin. I closed the PR, but, it shows screenshots of the default display and an “after” (meaning after applying some code-fu to the fx-updater plugin) at the end of the thread. I can give you some pointers if you need.
Post here if you have any problems. But just follow the docs. The only issue I had was trying to run my utility plugin on the same site as the fx updater. I got a naming conflict which I didn’t bother to sort out. I uninstalled the utility plugin as it wasn’t necessary on that site anyway.
I’ve split this into it’s own thread as it evolved into a topic of its own on the other thread. 
I was using the fx-updater and had some issues as I run it through some phpcs et al. Maybe we should fork it as we await CP directory.
I did kind of fork it…but, it’s pulling the extra data from my onsite Plugin Directory which won’t be applicable to others. I’m also planning on removing theme update support from my install. If someone is interested in creating a public fork, though, I’m happy to share my findings. Here’s where I’m at with it:
All the data above is coming from an endpoint on my site. The only thing I haven’t quite worked out yet is the icon on the updates page…that one is a little trickier and will take some exploration.
I’m using the theme update facility with my theme, but it would be very rare for me to need to use it. So if this was dropped from the fork it wouldn’t worry me.
The main thing I’d like to see in a fork is for it to reference CP version, not WP version in the plugin panel. I’m not sure how this all connects in with other checks though.
I don’t have it in front of me at the moment, but, I believe I pulled those values from my plugin directory, rather than using them from the fx-updater plugin.
So what are the values in those fields doing? Are they needed for any checks anywhere?
Sorry, I was incorrect. Those values are coming from the fx-updater plugin. Here’s what I’m using:
The value of 4.9.99 ensures that the table row shows “100% compatibility” as WordPress continues to iterate 4.9.9, 4.9,10, 4.9.11 … 4.9.99
Unfortunately, this same value is also used in the modal display…
So, to solve that problem without actually changing the value, I just did a jQuery one-liner to target that particular item and gave it my own markup:
jQuery(document).ready(function($) {
$('ul li:contains(4.9.99)').html('<strong>Compatible up to:</strong> 1.1.1');
});
Note that the value 1.1.1 is hardcoded here; A slight amendment is needed to make it properly dynamic.
Ah, yes… These same warnings were reported to me by @omukiguy. I had missed them entirely. And this is how I even ended up down the rabbit hole. 
… this was just a few days back.
Edit several months later: Since I wrote my original comment below, Code Potent’s Update Manager plugin has become the standard solution for our community. It will also be the base for the official ClassicPress plugin directory. There will still be a bit of work required by plugin developers to switch over to the official directory when it’s out, and we’ll make this as easy as we can. In light of this I am invalidating my original comment below.
I understand the idea here, but actually installing the GitHub Updater plugin sounds like a pretty good solution for now.
The reason is that once ClassicPress v2 is out, most (all?) plugins will be hosted on GitHub anyway, so transitioning from ClassicPress v1 + GitHub Updater to ClassicPress v2 should be fairly straightforward. This way, plugin developers shouldn’t need to make any changes or introduce custom code related to updates, and site owners just need to install a plugin once on each site, and then basically all of the “built for ClassicPress” plugins will receive updates without needing to do anything else.
So, are you saying we will also need this plugin for V2. Or just V1, and it will be “built in” to future versions?
No, you won’t need this plugin for v2. I think using the GitHub Updater plugin will be an easier transition than requiring every plugin author to implement the fx updater though, since the GitHub thing is closer to the way v2 will work.
OK. Sounds like the GitHub updater plugin is the best way to go then, as an interim measure.
I’ll probably stick with my approach though as my stuff is more “in-house” - it won’t ever go on the directory.
