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 | Owned by: | dd32 |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 3.3 |
Component: | Filesystem API | Keywords: | needs-patch has-unit-tests |
Focuses: | Cc: |
Description (last modified by )
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
Attachments (3)
Change History (22)
#2
@
12 years ago
I added phpinfo here...
After login to ftp in root are two dirs (something.com and sub.something.com).
#3
@
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', '/sub.something.com/wp-content'); define( 'FTP_CONTENT_DIR', '/sub.something.com/wp-content/plugins');
#4
@
12 years ago
Ok, im tried this workaround now. But problem is still here. Plugin was uploaded to /something.com/plugins
#7
@
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:
/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/
#8
@
12 years ago
- Owner set to dd32
- Resolution set to fixed
- Status changed from new to closed
In [21222]:
#9
@
12 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.
#11
@
12 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.
#14
@
12 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.
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 loadhttp://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:
There is also FTP_CONTENT_DIR and FTP_PLUGIN_DIR available, but hopefully the single BASE constant should work.