Using the fx-updater plugin to handle plugin updates

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.114.9.99

image

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.

Yes, I’ve just been playing with this. I put in 1.0.0 and 1.1.1 and it gives warnings.

1 Like

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. :smiley: … this was just a few days back.

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.

2 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.

1 Like

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 :wink:

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:

  1. no theme support needed
  2. no group support needed
  3. better file/directory structure needed
  4. better function names needed
  5. better performance needed
  6. fully object-oriented and namespaced
  7. better markdown support needed
  8. fix update modals
  9. incorporate icons
  10. 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. :slight_smile: 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 :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. :slight_smile: 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. :slight_smile:

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. :wink:

PS. If you make nice comments, they’re going in my “What users are saying…” section on my site. :smiley:

7 Likes

Excellent. Can’t wait to take it for a spin. I have an update to my utility plugin to go out to all my sites so am holding off to test it. The test before push option sounds really good.

2 Likes

12 posts were split to a new topic: ClassicPress Update Manager