WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#7265 closed enhancement (fixed)

Plugin update notification should generate bubble like comment notification bubble

Reported by: mdawaffe Owned by:
Milestone: 2.6 Priority: normal
Severity: normal Version: 2.6
Component: General Keywords: has-patch
Focuses: Cc:

Description

Attached fires the plugin update notification script more frequently and adds a little bubble on the plugins menu item when there are plugins ready to be updated.

Tested in FF3 and Safari only.

Attachments (7)

7265.diff (3.9 KB) - added by mdawaffe 6 years ago.
7265.2.diff (3.9 KB) - added by mdawaffe 6 years ago.
on every page load
7265.version1.diff (481 bytes) - added by DD32 6 years ago.
7265.3.diff (5.9 KB) - added by DD32 6 years ago.
7265.4.diff (1.1 KB) - added by DD32 6 years ago.
7265.5.diff (6.2 KB) - added by mdawaffe 6 years ago.
7265.5.2.diff (6.2 KB) - added by mdawaffe 6 years ago.

Download all attachments as: .zip

Change History (18)

mdawaffe6 years ago

mdawaffe6 years ago

on every page load

comment:1 mdawaffe6 years ago

  • Keywords has-patch added

comment:2 matt6 years ago

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

(In [8305]) Check for plugin updates more frequently, notify with double bubble trouble. Hat tip: mdawaffe. Fixes #7265.

comment:3 DD326 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

The action 'init' is fired before any administration includes are included, As such, The plugin update check is not run on any pages within the admin area.

One work around is to hook the check onto both init and admin_init, as admin_init runs after the admin includes have been included.

The other is to include admin includes before init is run.

See the 2 patches for the possible ways

DD326 years ago

comment:4 DD326 years ago

Er, Actually..

Theres no point hooking the plugin check to init at all, The code is not loaded for the WordPress front end, Switching it to hook admin_init only is the better solution. (7265.admin_init.diff)

comment:5 DD326 years ago

Or theres the 4th option of actually moving the plugin check into the front-end loaded code.. Which my patch does, My reasoning is the same as for the Core update checker, So that plugins may notify the blog owner of an update.

DD326 years ago

comment:6 DD326 years ago

Also included a grammer correction to the PHPDoc..

strpos($_SERVER['PHP_SELF'], 'install.php') !== false

Removed to allow admin pages with 'install.php' in them to be able to trigger update checks as well (eg. 'plugin-install.php' which is similar to #6990 - WP_INSTALLING is defined anyway.

comment:7 DD326 years ago

Eugh, Its late, Didnt notice function dependancies on get_plugins().

Honestly, I dont see the need for either of the update checks to be be run on non-admin hooks..

Final patch.. Someone else can decide on which route to take :)

DD326 years ago

comment:8 mdawaffe6 years ago

  • Milestone changed from 2.7 to 2.6

I think both core and plugin checks should run blog-side; I agree with DD32's original rationale: a plugin (or future core) could send emails or something when there are updates.

So I'd go +1 on .3.

And a +1000 to DD32 for catching the bug :)

mdawaffe6 years ago

mdawaffe6 years ago

comment:9 mdawaffe6 years ago

Messed up the attachment name, but 7265.5.2.diff:

Same as DD32's .3, but checks to see if is_admin and calls the appropriate hook. If blog-side, includes wp-admin/include/plugin.php (only if it hasn't checked in the last 12 hours) and goes from there.

Changing back to admin_init hook is definitely easier, but I think it cripples the feature a bit.

comment:10 ryan6 years ago

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

(In [8317]) Run plugin checks both admin and blog side. Props DD32 and mdawaffe. fixes #7265

comment:11 DD326 years ago

Thanks for fixing up the code mdawaffe :)

Note: See TracTickets for help on using tickets.