WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#29950 closed defect (bug) (fixed)

Open_basedir issue Plugin installer modal

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

Description (last modified by dd32)

Hi.
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\domain.com) in E:\Domains\domain.com\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 6 years ago.

Download all attachments as: .zip

Change History (9)

#1 follow-up: @dd32
6 years ago

  • Keywords reporter-feedback added

Hi!,

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
6 years ago

  • Severity changed from normal to major

Hi.
No, it's a fresh instalation, there is no plugins enabled.
I just did download the wordpress 4.0 from wordress.org 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
6 years ago

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

Thanks!

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( '//profiles.wordpress.org/wordpressdotorg' )

_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

@dd32
6 years ago

#4 @dd32
6 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
6 years ago

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

Thanks a milion!

#6 @nacin
6 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: https://make.wordpress.org/core/handbook/trac/. Cheers!

#7 @dd32
6 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
6 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 6 years ago by dd32 (previous) (diff)
Note: See TracTickets for help on using tickets.