Opened 15 years ago
Closed 8 years ago
#13071 closed defect (bug) (fixed)
Update bubble appears only at the second load
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 4.7 | Priority: | normal |
Severity: | normal | Version: | 3.0 |
Component: | Upgrade/Install | Keywords: | shiny-updates has-patch commit |
Focuses: | administration | Cc: |
Description
Change the version of a plugin and go directly to wp-admin/update-core.php page.
You will see the plugin update in the list but the bubbles on the menu appears only after a reload.
Attachments (7)
Change History (50)
#2
@
15 years ago
Related to this, if you run an upgrade, at the end of the upgrade, some JS should run that reduces the bubble count by 1 (or more if bulk), or clear the bubble all together if that's the case.
Both the Dashboard > Updates bubble and the Plugins bubble.
#4
@
14 years ago
Same thing happens if you directly visit /wp-admin/plugins.php?plugin_status=upgrade
when there's an update available. The yellow bar won't be there and you'll need to refresh before you can update.
#6
@
14 years ago
Similar (with a patch): #10884
In this case, any update checks hooked to a page/run on a page, need to be hooked before admin menu generation (which the load-$pagenow hook doesnt).
#9
@
10 years ago
- Focuses administration added
Okay, will mark as admin focus. The IRC chat makes it seem its just a matter of moving the plugin update code down. Maybe this could be done in 4.1
#11
@
10 years ago
Patch added, but I wasn't able to shift around lines of code as it's changed significantly since the IRC chat occurred.
#17
@
10 years ago
- Resolution set to fixed
- Status changed from assigned to closed
[30696] missed the ticket.
#19
@
10 years ago
- Keywords needs-patch added; good-first-bug has-patch needs-testing removed
- Milestone changed from 4.1 to Future Release
- Resolution fixed deleted
- Status changed from closed to reopened
#21
@
9 years ago
- Keywords has-patch added; needs-patch removed
- Milestone changed from Future Release to 4.6
13071.patch fixes the missing update row. wp_plugin_update_rows()
is hooked into admin_init
and therefore runs before wp_update_plugins()
is called, see https://core.trac.wordpress.org/browser/trunk/src/wp-includes/update.php?rev=37518&marks=689-691,696-698#L684.
This ticket was mentioned in Slack in #feature-shinyupdates by ocean90. View the logs.
9 years ago
#23
@
9 years ago
13071.2.patch uses the after_plugin_row
action instead. wp_plugin_update_rows()
and wp_theme_update_rows()
unregister the callback when they are called for the first time.
This ticket was mentioned in Slack in #feature-shinyupdates by ocean90. View the logs.
9 years ago
#26
@
9 years ago
- Keywords needs-testing added
13071.2.patch doesn't seem to work for me :-(
Changed the versions of a theme and a plugin and visited update-core.php
. The updates are shown in the list tables, but not in the admin menu. After a reload, the bubble in the admin menu is shown.
#27
@
9 years ago
- Keywords needs-testing removed
@swissspidy That's right, tt only fixes the tables. I don't think we can fix the admin menu in its current state.
#28
@
9 years ago
Ah, gotcha. Just read #31011 again.
Could we at perhaps add some JavaScript that increases the counter in the admin menu when visiting update-core.php
for the first time? Or is that too much of an edge case scenario?
#29
@
9 years ago
13071.2.patch seems to break custom updaters like https://github.com/restrictcontentpro/restrict-content-pro/blob/eb2d5e1f26cb17f54506c401835088a05b00dc91/RCP_Plugin_Updater.php#L60-L61.
Replying to swissspidy:
Could we at perhaps add some JavaScript that increases the counter in the admin menu when visiting
update-core.php
for the first time? Or is that too much of an edge case scenario?
A script in the footer should work since it's running after all the update checks. That's why it's visible in the toolbar. update-core.php
wouldn't be the only place, we need it for themes.php
and plugins.php
too.
This ticket was mentioned in Slack in #feature-shinyupdates by obenland. View the logs.
9 years ago
#32
@
9 years ago
- Keywords needs-patch added; has-patch removed
- Milestone changed from 4.6 to Future Release
Fixing the admin menu is something for another release.
#33
@
8 years ago
- Milestone changed from Future Release to 4.7
- Owner set to swissspidy
- Status changed from reopened to assigned
Could we at perhaps add some JavaScript that increases the counter in the admin menu when visiting
update-core.php
for the first time?
Let's do this.
#34
@
8 years ago
- Keywords has-patch needs-testing added; needs-patch removed
13071.diff is a first pass / proof-of-concept. I took the opportunity to clean up some JS parts as well. The overall solution seems a bit hacky though.
#35
@
8 years ago
@obenland I know you're busy with the plugin directory, but maybe you've got a few minutes to test the patch? You know the code quite well.
Basically it separates the update counter and actually updating the HTML across the site. It makes the code easier to understand. After that, wp_print_update_count_for_js()
is where the magic happens. It updates the counter and forces a refresh. That way, the update bubble always shows the correct when visiting plugins.php, themes.php or update-core.php.
Note that I haven't added a docblock yet and perhaps the function name can be improved.
#36
@
8 years ago
I think we should try to re-use _wpUpdatesItemCounts
(available as settings.plugins
and settings.themes
), that would allow us to get rid of the footer script hook. It also feels like refreshCount()
does a lot of the same things as deletePluginSuccess()
for example, I think there might be potential to optimize that.
#37
@
8 years ago
13071.2.diff tries to reuse _wpUpdatesItemCounts
for passing the update counts.
I am not sure about the similarities between refreshCount()
and deletePluginSuccess()
. The former refreshes the update counts everywhere on the screen, including the tabs on the plugin list table, while the latter only adjusts these tabs — and delegates updating the 'Update Available' tab to refreshCount()
. Not much I'd change there right now.
If anything, I'd want to get rid of the duplicate code inside deletePluginSuccess()
, but that's something for a new ticket.
This ticket was mentioned in Slack in #core by jeffpaul. View the logs.
8 years ago
#39
@
8 years ago
- Owner changed from swissspidy to ocean90
- Status changed from assigned to reviewing
This ticket was mentioned in Slack in #core by jeffpaul. View the logs.
8 years ago
#41
@
8 years ago
- Owner changed from ocean90 to swissspidy
Thanks @swissspidy. Found a few issues with 13071.2.diff. I fixed them in 13071.3.diff:
- The counter in
.subsubsub
didn't update for plugins becausesettings.totals.counts.themes
was used. Changed toitemCount
. - Yoda conditions should only be used for ==, !=, ===, and !==.
- Added a missing semicolon and DocBlock.
_wpUpdatesItemCounts
wasn't defined onwp-admin/themes.php
._wpUpdatesItemCounts
wasn't always defined onwp-admin/update-core.php
. Bulk theme/plugin upgrades have their own output.- The update script is printed in the header since [27280]. I couldn't find a reason for that so I changed the group.
postMessage
is still working for me. Needs some testing. - Changing the group allows us to use
wp_localize_script()
in all places.
IRC log: