Make WordPress Core

Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#29950 closed defect (bug) (fixed)

Open_basedir issue Plugin installer modal

Reported by: allan-moraes's profile Allan Moraes Owned by: dd32's profile dd32
Milestone: 4.1 Priority: normal
Severity: normal Version: 4.0
Component: Upgrade/Install Keywords: has-patch
Focuses: Cc:

Description (last modified by dd32)

When I try to use the import option (Tools>Import) in Wordpress, this error occurs.

PHP Warning:  realpath() [<a href='function.realpath'>function.realpath</a>]: open_basedir restriction in effect. File(\\PROFILES.WORDPRESS.ORG\CHMARS) is not within the allowed path(s): (E:\Domains\ in E:\Domains\\wwwroot\testejorge\wp-includes\functions.php on line 1542

In my server linux, it's works! But when I try in my Windows Server, IIS7.5 and PHP same version of linux server, i have this error. The windows server and linux server have the same php.ini. Older versions of Wordpress, work.

Sorry my english.

Attachments (1)

29950.diff (1.2 KB) - added by dd32 10 years ago.

Download all attachments as: .zip

Change History (9)

#1 follow-up: @dd32
10 years ago

  • Keywords reporter-feedback added


As far as I can tell, this is most likely being caused by a plugin, can you reproduce it with all plugins disabled, or on a fresh separate WordPress install on the same server?

Perhaps further clarification is needed, are you seeing this on the import page, or when using a specific importer? Do you have any of the importers already installed?

#2 in reply to: ↑ 1 @Allan Moraes
10 years ago

  • Severity changed from normal to major

No, it's a fresh instalation, there is no plugins enabled.
I just did download the wordpress 4.0 from and installed. The error appears when I use the native import function in the tools menu. No I don't have another imports.
The bug occurs when I click in the Importer Blogger, Categories and Tags Converter, LiveJournal, Movable Type and TypePad, RSS, Tumblr and WordPress.
The bug do not occur in the Blogroll.

#3 follow-up: @dd32
10 years ago

  • Component changed from Import to Upgrade/Install
  • Keywords reporter-feedback removed
  • Milestone changed from Awaiting Review to 4.1


I've confirmed and tracked this down, it's in the Plugin Install popup, mostly around the Reviews tab.

The callpath to this is:

do_action('install_plugins_pre_plugin-information'), call_user_func_array, install_plugin_information,
links_add_base_url, preg_replace_callback, _links_add_base,
path_join, path_is_absolute( '//' )

_links_add_base() is incorrectly using path_join() (which is only for file paths, not url paths).
_links_add_base() only uses path_join() when a URL doesn't have a valid scheme, and since this is a schemeless URL, it falls back to path_join().

The most obvious fix is to Just replace path_join() with WP_HTTP::make_absolute_url(), which is designed for this sort of thing.

patch attached

10 years ago

#4 @dd32
10 years ago

  • Description modified (diff)
  • Keywords has-patch added
  • Summary changed from Open_basedir wp-admin/import.php to Open_basedir issue Plugin installer modal

#5 in reply to: ↑ 3 @Allan Moraes
10 years ago

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

Thanks a milion!

#6 @nacin
10 years ago

  • Resolution worksforme deleted
  • Status changed from closed to reopened

Hi Allan, bug reports are closed when they are fixed. worksforme is bug tracker speak for "we can't reproduce the bug". More here: Cheers!

#7 @dd32
10 years ago

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

In 30766:

In the links_add_base() callback, use a HTTP-aware URL joining function, rather than a filesystem joining function to avoid PHP warnings on certain systems.
Fixes #29950

#8 @dd32
10 years ago

  • Severity changed from major to normal

This has been a problem since 2.7 for any plugins that used a protocol-relative URL in their readme's (not even sure if they could do so though), although it was made worse in 4.0 when we started using Relative URL's in the API response. Additionally, windows systems are more likely to cause this warning due to the file-paths on such systems, and //hostname/ being a valid local-path.

I've gone with my above patch, with the knowledge that it should be made a more generalised function in the future (ie. not WP_HTTP namespaced).

Last edited 10 years ago by dd32 (previous) (diff)
Note: See TracTickets for help on using tickets.