![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
#27934 closed defect (bug) (invalid)
$wp_plugin_paths is null in plugin_basename
| Reported by: | dsawardekar | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Plugins | Version: | 3.9 |
| Severity: | normal | Keywords: | |
| Cc: | Focuses: |
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
@
12 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
@
12 years ago
Related: comment:105:ticket:16953
#4
@
12 years ago
- Milestone 3.9.1
- Resolution → invalid
- Status new → 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
@
12 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
@
12 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