WordPress.org

Make WordPress Core

Opened 6 years ago

Last modified 8 weeks ago

#13071 reopened defect (bug)

Update bubble appears only at the second load

Reported by: ocean90 Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 3.0
Component: Upgrade/Install Keywords: shiny-updates needs-patch
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 (4)

update.diff (886 bytes) - added by bswatson 23 months ago.
13071.png (414.1 KB) - added by ocean90 3 months ago.
13071.patch (772 bytes) - added by ocean90 3 months ago.
13071.2.patch (1.7 KB) - added by ocean90 3 months ago.

Download all attachments as: .zip

Change History (36)

#1 @ocean90
6 years ago

IRC log:

[18 Apr 10 18:25] * nacin * yeah, they're a page load behind.
[18 Apr 10 18:36] * nacin * ocean90: If we switch two giant code blocks in plugins.php, that one pageload delay goes away. I don't want to break anything else though at this point in the cycle
[18 Apr 10 18:37] * nacin * more or less, moving the admin-header.php call (and related code = 70 lines) down below the block that collects all the plugin information (= 100 lines)
[18 Apr 10 18:39] * ocean90 * nacin: so should i create a ticket at first?
[18 Apr 10 18:39] * nacin * If you want. set for 3.1
[18 Apr 10 18:39] * ocean90 * ok
[18 Apr 10 18:40] * nacin * It's low priority, rather minor, but easy to fix. just need to review 200 lines of code to make sure nothing would break.

#2 @nacin
6 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.

#3 @nacin
6 years ago

  • Milestone changed from Awaiting Triage to Future Release

#4 @Viper007Bond
6 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.

#5 @ocean90
5 years ago

  • Keywords needs-patch added
  • Priority changed from low to normal

#6 @dd32
5 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).

#7 @chriscct7
23 months ago

  • Keywords reporter-feedback added

Can you still reproduce this?

#8 @ocean90
23 months ago

  • Keywords reporter-feedback removed

Yes.

#9 @chriscct7
23 months 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

#10 @chriscct7
23 months ago

  • Keywords good-first-bug added

@bswatson
23 months ago

#11 @bswatson
23 months ago

Patch added, but I wasn't able to shift around lines of code as it's changed significantly since the IRC chat occurred.

#12 @bswatson
23 months ago

  • Keywords has-patch added; needs-patch removed

#13 @johnbillion
22 months ago

  • Keywords needs-testing added
  • Milestone changed from Future Release to 4.1

#14 @dd32
22 months ago

  • Owner dd32 deleted
  • Status changed from new to assigned

#15 @omarreiss
22 months ago

Tested and it works!

#16 @Yahire Furniture
21 months ago

Yes this is working for me as well

#17 @ocean90
21 months ago

  • Resolution set to fixed
  • Status changed from assigned to closed

[30696] missed the ticket.

#18 @johnbillion
19 months ago

In 31390:

Revert [30696] pending further investigation.

See #31011, #13071

#19 @SergeyBiryukov
19 months 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

#20 @dd32
19 months ago

In 31394:

Revert [30696] pending further investigation.

Props johnbillion.
Merges [31390] to the 4.1 branch.
See #13071. Fixes #31011.

@ocean90
3 months ago

@ocean90
3 months ago

#21 @ocean90
3 months 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.


3 months ago

@ocean90
3 months ago

#23 @ocean90
3 months 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.


3 months ago

#25 @swissspidy
3 months ago

  • Keywords shiny-updates added

#26 @swissspidy
3 months 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 @ocean90
3 months 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 @swissspidy
3 months 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 @ocean90
3 months 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.


3 months ago

#31 @ocean90
8 weeks ago

In 37978:

Upgrade/Install: Change priority for theme/update update rows.

wp_plugin_update_rows() and wp_theme_update_rows() are using the site transients update_plugins and update_themes which are set by wp_update_plugins() and wp_update_themes(). Both functions are hooked into load-plugins.php and load-themes.php. Therefore the update rows need to be registered after the transients were populated.

See #13071.

#32 @ocean90
8 weeks 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.

Note: See TracTickets for help on using tickets.