I think the problem is not Updare Manager itself. Check with Query monitor… you will find some plugin checking for updates on servers that are not respondidg (not your).
This includes my test site where the only plugins are mine.
I think it’s more of a limitation than a problem. It’s simply that each plugin will have to make its own request (even if they’re all pinging the same server) and this can add up. To resolve this, core would have to recognize that the requests are going to the same server and make a “bundled request” (for lack of a better term) and get all the data in one request. Obviously, this would also need to be accounted for in the Update Manager plugin, too.
1 Like
This is how core does. But it’s more difficult to implement this in Update Manager. The problem is not in the update server but in the client, because each update client (even if the code is the same) acts like an individual instance.
1 Like
I’m probably the only person who would run enough of my plugins on one site to notice and I’ve accepted there is a small delay (far better that than no update manager).
2 Likes
We have the API endpoint set up now for plugins, @james what would integration into core look like from the directory?
I am not sure yet. I guess the next steps would be to look at what data CP sends to WP.org for plugins, and how WP.org responds. Then make sure we have the same data available for the CP directory.
1 Like
That was my approach in Update Manager, too.
I guess a better question is, is this a breaking change that would have to wait for v2?
I would guess yes, because it’s probably going to require redesigning some stuff in the dashboard (for example, making it clear whether a given plugin comes from WP or CP). But we need to start with a PR or a branch anyway in order to evaluate that.
I had also been thinking that we would release v2 when this specific feature is ready, so it’s more a matter of waiting for the thing to be ready than waiting for v2.
I have just tested https://git-updater.com on my plugins and it works like a charm. It’s free to use, and/or could be forked (I guess).
Testing it, I see not only the update works, but even “view details” and “enable auto updates” do work (NOTE: I tested it on a WP Install, for now. To use that plugin on CP we would need to at least bring down its minimal requirement of 5.2 and perhaps adapt the code)
All the developer would need to do is add a header entry in his/her plugin pointing to the respective repo.
It even has add-ons for gists, which might be just useful for our plans to add snippets of some sorts.
It opens the possibility to develop a plugin for WP (by making it require WP 5.0 at least and putting it on the WP Repo) in parallel with the (same) plugin developed for CP (by making it require 4.9.x and adding the header to the plugin (or theme))
No remote server needed, it all uses GitHub (and a bunch of other repos)
The user on the other hand will need to download the Updater Plugin, and add a Git Token to it (but that is dead simple, once the user has a git account, there’s a simple-to-follow step description).
To avoid the user not installing that plugin for some reason, of course the developer could add a check and only activate the plugin if said updater is already active/installed.
I think I will incorporate this into my plugins to come (if I can manage to make the updater install/work on a CP install), if not hosted on WP.
Currently all are on the WP repo so it won’t change existing plugins, but for the future I think this might be a cool solution, at least until we have a core updater in CP
Sharing here in case some other developer would be looking for other ways to ship updates.
For my own notes, it might be simpler to follow this How To Deploy WordPress Plugins With GitHub Using Transients — Smashing Magazine and create a new plugin with settings just for CP.
This is actually why nobody wanted to use it anymore. Yes, it does work with ClassicPress. It’s just too much to ask. I think most of us tried it in the early days (as well as the fx-updater). I examined the best aspects of both plugins and wrote Update Manager as the solution. 
3 Likes
Yeah that makes total sense… I also thought of that, specially since the “add token” likely will generate some “scare”.
I still prefer it to not having any update at all, and I don’t want to setup server(s) for updates only, for reasons.
Long story short, I can’t setup subdomain on my VPS easily as it is not offering this (perhaps there is a way to do it, but I don’t know how) and would need a new domain, + costs per month for the server, and all for free plugins… + I would have to maintain that server and carefully be sure it is not somehow compromised, whereas Git is all free and maintained and relatively secure. Zero headache with zero cost, I like that.
I already invest too much free time in this and other projects, so I do not want to spend a single dime of real money, to be honest, if not absolutely necessary.
My finances are “designed” to survive in very-low-requirement countries and I cannot really afford sending more than I already do 
, even if it is “just another few bucks a month”. I know it might sound “stingy”, however that’s what allows me to work only a few hours per week, instead of making 40 hours marathons 
Anyway, of course not expecting others to follow the same path…
2 Likes
If you’re running ClassicPress on your site, you can install Update Manager there. It doesn’t need a dedicated server. It can even update plugins on the same site where its installed. No problem.
As a workaround if your site is not running on ClassicPress, you could install ClassicPress in a subdirectory of your current site and serve your updates from there instead.
All this time and effort should be spent on the directory’s integration and update mechanism So we can get it done and out the door as quickly as possible.
1 Like
Ah i didn’t get that!
Yes sure my site is on cp
Now I just would have to use my plugins lol.
Ok thou this seems even simpler than with git as it requires no interaction with the user on the consumer side
Will check into it….
@viktor - you are right that we should put effort in our own updater stuff.
However do you know how to do it?
Because I don’t. I’d be willing to do it of course, however I bet that will be really lost time.
Just because I can code a plugin, doesn’t mean I can change the WP code updater to be cp.
That’s another pair of shoes to me.
I already kinda struggled with the jQuery update I initiated and as you can see I don’t know how to proceed 
Comes to add, I’m not so sure we even understand what it means.
It’ll for example mean that while now we only don’t get updates for WP plugins above 5.0 - after we change our update mech, we don’t even receive anymore plugin updates for actual compatible plugins
That’s probably also why this is all 2.x territory, which by as far I know is very, very far away and we should probably first have some replacements for the most important plugins.
So until then… i don’t think investigating easy solutions is a waste of time.
Of course I might miss something, and as said… everyone’s free to wait or use other tools, like the already available one.
Your users will (even if unknowingly) be glad you went with Update Manager. It really creates a seamless, native experience without any extra work on their part. We (meaning me, @anon95694377, @Simone, @azurecurve, and others) went through these same dilemmas back in the early days… Now we’re all using Update Manager.
2 Likes
To be honest I sat back and let you lot think about it the best method of updating and come up with a solution I then used.
This and the next two posts in the series cover using Update Manager with plugins.
3 Likes
We need to break this down into more manageable pieces while Wade is working on the directory itself. For example, first small step would be:
Don’t sell yourself short. You’re doing good. Everyone hits a wall at one point or another. But doing the job is the best way to learn. Getting help when you’re stuck is important. You struggle, you learn, and you grow.
We can start moving some of those things here:
I think it would be good for us to breakdown what we are looking for, where people can help (prior to open sourcing) etc all in a dedicated place.
I think a great first issue is the data as mentioned by James and Viktor