Make WordPress Core

Opened 3 years ago

Last modified 19 months ago

#20652 reopened defect (bug)

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

Reported by: rajcz Owned by: dd32
Milestone: Future Release Priority: normal
Severity: normal Version: 3.3.2
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

sub.something.com - this is virtual subdomain from mod_rewrite

dirs are

/www/something.com/sub.something.com - 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/something.com/sub.something.com/plugins

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 3 years ago.
phpinfo() from Pavel
fs.php (4.8 KB) - added by dd32 2 years ago.
20652.unit-tests.diff (1.4 KB) - added by dd32 20 months ago.

Download all attachments as: .zip

Change History (21)

comment:1 @dd323 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 http://sub.something.com/phpinfo.php 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/something.com/sub.something.com/' );

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

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

comment:2 @rajcz3 years ago

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

Version 0, edited 3 years ago by rajcz (next)

@dd323 years ago

phpinfo() from Pavel

comment:3 @dd323 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', '/sub.something.com/wp-content');
define( 'FTP_CONTENT_DIR', '/sub.something.com/wp-content/plugins');

comment:4 @rajcz3 years ago

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

comment:5 @rajcz3 years ago

  • Cc pavel.ondrej@… added

comment:6 @rajcz3 years ago

  • Severity changed from major to critical

Any news?

comment:7 @dd323 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 sub.example.com path, the 'example.com' directory would be used twice, resulting in /www/example.com/example.com/ instead of /www/example.com/sub.example.com/

comment:8 @dd323 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

comment:9 @rajcz2 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.

comment:10 @rajcz2 years ago

  • Version set to 3.5

comment:11 @dd322 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.

comment:12 @rajcz2 years ago

Sorry for delay - I will sending you it now

comment:13 @adamsilverstein2 years ago


comment:14 @dd322 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.

@dd322 years ago

comment:15 @ryan23 months ago

  • Milestone changed from 3.6 to Future Release

@dd3220 months ago

comment:16 @dd3220 months ago

Attachment 20652.unit-tests.diff​ added

Unit tests to show this failure.

Based off of the Unit tests added in [25053]

comment:17 @dd3220 months ago

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

comment:18 @dd3219 months ago

  • Component changed from Upgrade/Install to Filesystem
Note: See TracTickets for help on using tickets.