Make WordPress Core

Opened 12 years ago

Last modified 5 years ago

#20652 reopened defect (bug)

Install plugins with FTP upload, virtual subdomain, bad base dir?

Reported by: rajcz's profile rajcz Owned by: dd32's profile dd32
Milestone: Priority: normal
Severity: normal Version: 3.3
Component: Filesystem API Keywords: needs-patch has-unit-tests
Focuses: Cc:

Description (last modified by dd32)

Hi anybody!
I have problem with install plugins with FTP module in WP.

Everything show as OK, but plugin directory is bad. I have subdomain - this is virtual subdomain from mod_rewrite

dirs are

/www/ - here is WP installation, subdomain is virtual from rewrite in httpd.conf

After install - WP say everything OK - but one thing is bad.
Upload is in bad directory - plugin I can found in
no in /www/

Is here some way to fix it automatticaly or I can must edit config and basedir of ftp? Why is here this bug?

Thank you !


Attachments (3)

info.htm (63.3 KB) - added by dd32 12 years ago.
phpinfo() from Pavel
fs.php (4.8 KB) - added by dd32 11 years ago.
20652.unit-tests.diff (1.4 KB) - added by dd32 11 years ago.

Download all attachments as: .zip

Change History (22)

#1 @dd32
12 years ago

  • Component changed from Plugins to Upgrade/Install
  • Description modified (diff)

Hi Pavel,

Could you attach the output from phpinfo() as an attachment here (or, if you're worried there might be sensitive information there, you can email it to me directly at dion at wordpress dot org) so I can check to see what the paths PHP is seeing?

(to get the phpinfo() output, simply create a file called 'phpinfo.php' which contains the following: <?php phpinfo(); and put that into your WordPress folder that you're having the problem with, and load in your browser. After you've saved the page, or copied it to an email, you can delete the file )

Next, When you connect via FTP to the server, what directory do you see? I assume you see the www directory, and nothing higher than that?

Finally, You should be able to work around this temporarily (by that, I mean, until the bug is fixed) by adding this define to your wp-config.php file:

define( 'FTP_BASE', '/www/' );

There is also FTP_CONTENT_DIR and FTP_PLUGIN_DIR available, but hopefully the single BASE constant should work.

Last edited 11 years ago by dd32 (previous) (diff)

#2 @rajcz
12 years ago

I added phpinfo here...
After login to ftp in root are two dirs ( and

EDIT: Dont forget - update WP core with ftp is ok..

Last edited 12 years ago by rajcz (previous) (diff)

12 years ago

phpinfo() from Pavel

#3 @dd32
12 years ago

I added phpinfo here.

Thanks, I just removed a few private details from the file to be on the safe side and re-uploaded it.

Since you say core upgrades work well, I'm not sure what to think, and will have to investigate it closer, unfortunately, that's not something I can do today, so I'll have to come back to this on the weekend.

I assume you're using the default location for plugins? wp-content/plugins?
As a workaround, you'll need to define this:

define( 'FTP_CONTENT_DIR', '/');
define( 'FTP_CONTENT_DIR', '/');

#4 @rajcz
12 years ago

Ok, im tried this workaround now. But problem is still here. Plugin was uploaded to /

#5 @rajcz
12 years ago

  • Cc pavel.ondrej@… added

#6 @rajcz
12 years ago

  • Severity changed from major to critical

Any news?

#7 @dd32
12 years ago

  • Milestone changed from Awaiting Review to 3.5

Related: #20934

The cause here is that the full path is searched for in each subdirectory, which causes path tokens to be searched for twice. Simply limiting the recursive searches to only find the remaining path appears to fix it, and shouldn't have any unintended side effects.

For reference, the filesystem paths being tested here are:


If you're searching for the path, the '' directory would be used twice, resulting in /www/ instead of /www/

#8 @dd32
12 years ago

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

In [21222]:

WP_Filesystem: When recursivly searching for a directory path, only search for unfound directory entries. This solves a case where the same directory may be entered twice inadvertantly when nested directories using the same name exist. Fixes #20652

#9 @rajcz
11 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened
  • Version 3.3.2 deleted

Problem is still here.. We tested in 3.5. now.

#10 @rajcz
11 years ago

  • Version set to 3.5

#11 @dd32
11 years ago

  • Milestone changed from 3.5 to 3.6
  • Severity changed from critical to normal
  • Version changed from 3.5 to 3.3.2

@rajcz: Is there any chance of getting access to a WordPress install + FTP account on a server experiencing the problem? a test site of course. You can contact me off-trac at [dion at wordpress dot org] if that's possible.

I'll re-test this and see if I can duplicate it again over the weekend.

Re-opening on the 3.6 milestone for now, will reclose it and open a new ticket if it turns out to be a different root cause.

#12 @rajcz
11 years ago

Sorry for delay - I will sending you it now

#13 @adamsilverstein
11 years ago


#14 @dd32
11 years ago

  • Keywords needs-patch needs-unit-tests added

Confirmed that although the paths I tested with worked OK, the paths on a failing test server still failed.

Attached is a non-unit-test test (run it in ABSPATH), It creates a fake virtual filesystem in memory and runs operations against that. Not everything is supported (yet) but it's a start to being able to create some proper tests for this functionality.

As it is now, If one scenario is fixed, It's almost impossible to tell if another known working test case will cease to function without having a VM of every known configuration known to man available to test on.

11 years ago

#15 @ryan
11 years ago

  • Milestone changed from 3.6 to Future Release

#16 @dd32
11 years ago

Attachment 20652.unit-tests.diff​ added

Unit tests to show this failure.

Based off of the Unit tests added in [25053]

#17 @dd32
11 years ago

  • Keywords has-unit-tests added; needs-unit-tests removed

#18 @dd32
11 years ago

  • Component changed from Upgrade/Install to Filesystem

#19 @chriscct7
9 years ago

  • Version changed from 3.3.2 to 3.3
Note: See TracTickets for help on using tickets.