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

[rajcz]

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

Pavel

[dd32]

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.

[rajcz]

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

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

[dd32]

phpinfo() from Pavel

[dd32]

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');

[rajcz]

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

[rajcz]

Any news?

[dd32]

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:

/www/
   example.com/
      example.com/
      sub.example.com/

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/

[dd32]

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

[rajcz]

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

[dd32]

@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.

[rajcz]

Sorry for delay - I will sending you it now

[dd32]

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.

[dd32]

Attachment 20652.unit-tests.diff​ added

Unit tests to show this failure.

Based off of the Unit tests added in [25053]