Plugin Update does not update plugin update count on success

[technosailor]

I don't know how to make that title make more sense. If you have, say, 3 plugin update notifications and you update one of them, upon re-activation the plugin update notification should update from 3 to 2. It doesn't. I'll try to patch this if I have time, but may not.

[technosailor]

Here's initial API to move the plugin update notification to it's own function. Patch does not address ticket issue, but should make the rest easier without duplicating code. Adds function check_plugin_updates()

[DD32]

Are we talking about the Bubble showing 3 updates WHILE one of the updates are being carried out?

If so, some jQuery could be used at the end of the update page to decrease it.. if need be.. afterall, on that pageload, there ARE 3 updates, once you go into any other page there'll be 2 updates..

[technosailor]

After the upgrade has happened, there should be 2 remaining upgrades. The bubble should reflect that change without a page reload as it does for the comments bubble when a comment has been moderated. jQuery could do it. With the above patch, the jQuery could invoke an AJAX call to that API function. Not sure which way is better but my javascript fu is shady and would take me 29.25 hours to complete a simple task - even with jQuery. ;)

[DD32]

attachment 8992.diff added.

• Bugger,Dirty patch, Ignore the Theme installer in wp-admin/menu.php
• Moves function to a better location (It would've only worked in that location on the update page)
• adds some jQuery to decrease/remove update bubble. Note: Will still be wrong when doing multiple updates at once.. but better than nothing. Ajax is virtually out of the question for that.. Way too much latency to even be worth it for such small data..

[Denis-de-Bernardy]

See also #9303

[Denis-de-Bernardy]

Why could it not be possible to make the actual upgrade occur before anything is output on the page? in particular the menu.

[DD32]

Mainly because that increases the complexity of the code. No longer can things be echo'd straight away, they need to be stored in a var, kept around until the process finishes, and then be displayed in one large chunk.

As it is, The feedback rows are -supposed- to show up one by one.. but compression on many servers stops that.. But Not outputting anything can be disastrous, The user might not think anythings happening.. at least this way (for most people) it at least outputs the menu and header before any long processing happens, which makes people realise somethings happening.

[Denis-de-Bernardy]

see also #8095

[dd32]

Some dev-feedback would be nice here, Should the update bubble be updated inline, or should users just put up with the bubble being wrong on that page load?

We could update the bubble to be {updates}-1 on the upgrade pageload.. but that doesnt really fit either IMO.

this patch is probably stale though.

[Denis-de-Bernardy]

stale patch

[dd32]

Pretty sure this is a wontfix for now.

[strider72]

Confused -- isn't "wontfix for now" the same as "future release"?

I mean, this *should* be fixed if it can be. Why not just leave it as Open with future release target?

[dd32]

I mean, this *should* be fixed if it can be. Why not just leave it as Open with future release target?

Because whats the point in leaving something open thats just going to sit and rot for another few years until someone closes it then as exactly the same?