#27934 closed defect (bug) (invalid)
$wp_plugin_paths is null in plugin_basename
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 3.9 |
Component: | Plugins | Keywords: | |
Focuses: | Cc: |
Description
While upgrading to 3.9.0 I noticed a few PHP notices in plugin.php. The
upgrade was successful but I have strict error reporting turned on in
PHP that showed up these errors.
Warning: Invalid argument supplied for foreach() in /var/www/wp-dev/wp-includes/plugin.php on line 623
I'm using PHP 5.5.3 on Ubuntu, with individually symlinked plugins in
wp-content/plugins
.
Further investigation revealed that the cause is to do with parent
directory extraction in the plugin_basename
method.
Attached is a patch that adds a null check to the for loop that makes
this Notice go away.
Attachments (1)
Change History (9)
#1
@
11 years ago
Lots of reports of issues with this over the past few days:
https://wordpress.org/support/topic/invalid-argument-supplied-for-foreach-30?replies=15
Warning: Invalid argument supplied for foreach() in ... wp-includes/plugin.php on line 622
Related: #16953
Not certain about root cause yet, but I think a partial upgrade may be at fault.
#3
@
11 years ago
Related: comment:105:ticket:16953
#4
@
11 years ago
- Milestone 3.9.1 deleted
- Resolution set to invalid
- Status changed from new to closed
This is a very good indication that wp-settings.php was not updated as part of the update. I'd rather not suppress this error as it could just make the next support question even more opaque.
#5
follow-up:
↓ 6
@
11 years ago
Not sure if it's a partial install issue. I did a diff of the relevant files with the 3.9.0 tag to verify. No changes were detected.
Anyway I disable error reporting on production sites. Haven't seen this in production so far. So it's a development only issue I suppose.
#6
in reply to:
↑ 5
@
11 years ago
Replying to dsawardekar:
Not sure if it's a partial install issue. I did a diff of the relevant files with the 3.9.0 tag to verify. No changes were detected.
wp-settings.php
should have $GLOBALS['wp_plugin_paths'] = array();
on line 167.
The only other thing I can think of is that you somehow have a customised wp-settings.php
, or you're loading WordPress without loading this. We've seen this issue pop up before with WP-CLI, which uses a custom wp-settings.php
and had to be updated to match.
Patch with NULL check for $wp_plugin_paths