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.
3 Likes
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.
2 Likes
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.
1 Like
Just forked it to make code adjustments where necessary via https://github.com/bahiirwa/self-hosted-updater. Will ping when version 1.0.0 is ready.
2 Likes
Be sure to namespace or re-prefix your code to ensure you don’t fatal error sites that may be running plugins with the original fx-updater plugin.
1 Like
Definately. Would love to see some of the fixes you made on your side. PRs are welcome 
1 Like
In deciding whether to fork the plugin or rewrite the functionality, I came up with a “wish list” that consisted of the following items:
- no theme support needed
- no group support needed
- better file/directory structure needed
- better function names needed
- better performance needed
- fully object-oriented and namespaced
- better markdown support needed
- fix update modals
- incorporate icons
- pull data from my Plugin Directory plugin
With this many items to deal with, I chose to rewrite the functionality entirely. If you have specific questions about how to fix the fx-updater plugin modals/icons, hit me up on Slack.
3 Likes
So, my update manager plugin (which I’ve dubbed Update Manager for unknown reasons,) is going to be released publicly. It only works with plugins, but, it does a better job than any other I’ve seen. It’s thorough, yet performant. 
This is really geared toward those who want to serve remote updates, but, don’t have a place to store all that data. I could have interfaced with the GitHub API, but, I wanted this to be dead-simple for even the newest of plugin authors.
While I originally built it to support my Plugin Directory plugin updates, it was very little work and code to add support for reading plugin data from text files – 2 functions and a conditional. After installing the Update Manager plugin, you can create an update endpoint just like a new post. There’s an editor so you can fill in your plugin properties just like the readme.txt file that you’re already used to! To push a new version, just bump the version number there. All the information you enter there is parsed and used to populate the remote modal windows, table rows, and, of course, to serve your plugin updates!
The extra assets are self-discoverable. For example, header images and icons – just put them in the right spot with the right name and they just work. Additionally, I’ve built in support for svg, png, and jpg images – in that order of preference – using the traditional WP filenames and specs, so, if you already have assets created, they’ll be immediately translate.
If you dig into the code, you’ll see how utterly simple it would be to integrate something like updates for premium plugins that query for updates along with a license key, for example.
Anyone interested in testing it?
6 Likes
Yep, I’ll give it a go.
Odd name though. How did you ever come up with Update Manager?
4 Likes
Yes, I’m interested.
3 Likes
Great, I’m interested too!
2 Likes
Eyes 
peeled
2 Likes
Thanks for expressing interest. I’ve fast-tracked the project and anticipate a release next week. This has become a blocker on this end, preventing me from getting the rest of my plugins out there. It will have docs and all… appreciate your patience and support!
Edit: the Update Manager plugin for ClassicPress now has a home on the web – you know, if you’d like to check in on the progress of docs and get excited (or bored) with the possibilities.
6 Likes
Just wanted to stop in with a quick mid-week update.
I’ve made a lot of progress on the Update Manager plugin and am still anticipating a release this week. It may be over the weekend, just to be sure I’m not rushed. There will be full documentation and I went beast-mode with the code comments for those who like to dig in. One really great feature is the ability to test your plugin updates before pushing them out to your end users – this should prevent any embarrassing (not to mention time-consuming and costly) errors, you know, like, pushing an update that produces a fatal error that whitescreens a bunch of sites. Or whatever.
The final tasks are to get the remaining texts translatable, finish off the code comments, create a simple example plugin to test with, reexamine all variable/function/method names for clarity, and do a final inspection of all input and output for cleanliness. Oh, and finish the docs, and, and…you know the drill.
I hope you are excited.
PS. If you make nice comments, they’re going in my “What users are saying…” section on my site.
7 Likes