DRY: code to display update counts is redundant and buggy

Description

Approximately the exact same code exists in three places for collecting information on available updates and formatting a UI string for it: wp_admin_bar_updates_menu(), wp-admin/menu.php, and in wp-admin/network/menu.php.

Let's not repeat ourselves.

In addition, the hacky cut-and-paste nature of these three instances of code actually cause weird edge case bugs. This patch also fixes some other minor issues:

in wp-admin/menu.php, if is_multisite() and !is_super_admin() but !empty( $menu_permsplugins? ), the $plugin_update_count variable will be undefined.

in wp-admin/network/menu.php, if !current_user_can( 'update_themes' ) but current_user_can( 'update_core' ), the variable $theme_update_count referenced in the sum for $update_count will not be defined. A similar issue could occur with $plugin_update_count.

in wp-admin/network/menu.php, if current_user_can( 'update_themes' ), we print a useless <span class='update-plugins count-0'><span class='theme-count'>0</span></span>. We actually have CSS to then hide this stuff (#adminmenu li span.count-0, #sidemenu li a .count-0). It just shouldn't be printed.

in wp-admin/network/menu.php, if !current_user_can( 'update_core' ), the total update count of themes and plugins is not printed in the Updates label.

wp_admin_bar_updates_menu() would only add the ab-updates menu if !current_user_can('install_plugins') instead of checking 'update_plugins' and not checking 'update_themes' or 'update_core' at all.

Change History (9)

Would function_exists( 'get_core_updates' ) be more appropriate than is_admin() to make it more obvious what's being checked for? We're not not displaying the core update on the frontend because it's not the admin, but because it would fatal error.