Make WordPress Core

Opened 9 years ago

Closed 9 years ago

#31784 closed defect (bug) (fixed)

Plugin update gives notice

Reported by: kloon's profile Kloon Owned by: jorbin's profile jorbin
Milestone: 4.3 Priority: normal
Severity: normal Version: 4.2
Component: Plugins Keywords: has-patch
Focuses: administration Cc:

Description

When updating a plugin with the new shiny interface on the plugins page it throws a notice of undefined index.

PHP Notice: Undefined index: plugin in /srv/www/wordpress-develop/src/wp-admin/includes/update.php on line 279

Attachments (3)

31784.diff (930 bytes) - added by Kloon 9 years ago.
Make sure plugin index is set before passing it through
31784.patch (872 bytes) - added by mordauk 9 years ago.
Screen Shot 2015-06-01 at 9.11.24 PM.png (704.1 KB) - added by ryan 9 years ago.
Related?

Download all attachments as: .zip

Change History (24)

@Kloon
9 years ago

Make sure plugin index is set before passing it through

#1 @Kloon
9 years ago

  • Keywords has-patch added

Above patch makes sure the plugin index is set before it calls is_plugin_active

#2 @SergeyBiryukov
9 years ago

  • Milestone changed from Awaiting Review to 4.2

#3 @DrewAPicture
9 years ago

  • Owner set to SergeyBiryukov
  • Status changed from new to reviewing

#4 @jorbin
9 years ago

  • Keywords reporter-feedback added

Hi Kloon,

Thanks for reporting this. Which screen are you seeing this on? Is it all plugins or just some plugins? If it's some, which ones?

This may be related to #31738 and the fix there might need to be broadened.

#5 @Kloon
9 years ago

  • Keywords reporter-feedback removed

Hey @jorbin,

The only other plugin I had installed and active was query monitory which I use for debugging.

#6 @jorbin
9 years ago

@kloon

Which plugin was it that generated the notice? Query Monitor or a different one? And which screen was it on (for example plugins.php , plugins.php?plugin_status=upgrade , plugin-install.php )?

#7 @Kloon
9 years ago

@jorbin

I was testing it by setting the version number of query monitor back a version and then on plugins.php clicking the update link which triggers the ajax update by calling

update.php?action=upgrade-plugin&plugin=query-monitor%2Fquery-monitor.php&_wpnonce=

This ticket was mentioned in Slack in #core by drew. View the logs.


9 years ago

#9 @DrewAPicture
9 years ago

  • Owner changed from SergeyBiryukov to jorbin

#10 @DrewAPicture
9 years ago

  • Keywords close added

I can't reproduce this issue on latest trunk, though I suppose adding the isset() check couldn't hurt.

#11 @DrewAPicture
9 years ago

  • Keywords close removed
  • Milestone 4.2 deleted
  • Resolution set to worksforme
  • Status changed from reviewing to closed

Closing as worksforme. Feel free to reopen if you continue to see issues.

#12 @daronspence
9 years ago

Don't know if this helps but I just saw this today as well while testing my plugins with the shiny updates.

http://i.imgur.com/w7h0sk4.png

I think it may be related to Pippin's Software Licensing Add-on though. I'll shoot him a link to this thread.

#13 follow-up: @mordauk
9 years ago

  • Resolution worksforme deleted
  • Status changed from closed to reopened

I've seen this several times now. As far as I can tell, it only happens with custom plugin updaters, but it's still a bug in core (I think).

This comment describes the cause: https://core.trac.wordpress.org/ticket/29820#comment:73

@mordauk
9 years ago

#14 @mordauk
9 years ago

31784.patch uses $file instead of $plugin_data['plugin'] since $file will always exist, even if a plugin has modified the update data.

#16 in reply to: ↑ 13 ; follow-up: @jdgrimes
9 years ago

Replying to mordauk:

I've seen this several times now. As far as I can tell, it only happens with custom plugin updaters, but it's still a bug in core (I think).

This comment describes the cause: https://core.trac.wordpress.org/ticket/29820#comment:73

As a followup to my comment on the other ticket, I think that there actually was a custom plugin updater installed, but I don't recall know the exact one.

#17 in reply to: ↑ 16 @mordauk
9 years ago

Replying to jdgrimes:

Replying to mordauk:

I've seen this several times now. As far as I can tell, it only happens with custom plugin updaters, but it's still a bug in core (I think).

This comment describes the cause: https://core.trac.wordpress.org/ticket/29820#comment:73

As a followup to my comment on the other ticket, I think that there actually was a custom plugin updater installed, but I don't recall know the exact one.

That's the only time I've been able to make it happen.

#18 follow-up: @ryan
9 years ago

I'm seeing that on every page load of plugins.php with the 4.3-alpha-32681 nightly build.

#19 in reply to: ↑ 18 @ryan
9 years ago

Replying to ryan:

I'm seeing that on every page load of plugins.php with the 4.3-alpha-32681 nightly build.

Never mind. This cleared after a fresh update.

#20 @dd32
9 years ago

  • Milestone set to 4.3

This is definitely caused by a 3rd party update script not setting the expected keys. I have a feeling we might've added the plugin key at some point (a long time ago).

No harm in consistently using the same variable though.

#21 @dd32
9 years ago

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

In 32784:

Updates: Consistently use the same variable to refer to the plugin, avoids a potential PHP Notice when an external update script adds data without that key.
Props mordauk. Fixes #31784

Note: See TracTickets for help on using tickets.