Opened 15 years ago
Closed 15 years ago
#12044 closed defect (bug) (fixed)
Wrong path for uploaded files
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 3.0 | Priority: | normal |
Severity: | normal | Version: | 3.0 |
Component: | Multisite | Keywords: | |
Focuses: | Cc: |
Description
MU Trac Ticket: http://trac.mu.wordpress.org/ticket/1088
Website: http://labs-wpmu.stage.mozilla.com
Our URLs for uploaded files look like this: http://labs-wpmu.stage.mozilla.com/jetpack/files//data/www/labs.mozilla.com-wpcontent/blogs.dir/3/files/2009/07/installnow.jpg
which result in 404's
We have our site in 2 folders: /data/www/labs.mozilla.com-wpcontent and /data/www/labs.mozilla.com-wpmu
and this in our wp-config.php: define('WP_CONTENT_DIR', '/data/www/labs.mozilla.com-wpcontent'); define('WP_CONTENT_URL', ' http://labs-wpmu.stage.mozilla.com/wp-content');
Been debugging this for days and no progress. Not sure where we are configuring wpmu wrong. Any help appreciated, thanks!
Change History (11)
#2
@
15 years ago
- Version set to 3.0
I'm seeing the problem too. Having redefined WP_CONTENT_DIR, the URL for uploads becomes http://rhhsweb.com/files//home/rhhsweb/wp-content/blogs.dir/1/files/2010/01/rhhs-web-wordpress-button.png instead of http://rhhsweb.com/files/2010/01/rhhs-web-wordpress-button.png .
Strangely, both versions of the URL work, because this line in .htaccess is stripping out the path:
RewriteRule ^(.*/)?files/(.*) wp-content/blogs.php?file=$2 [L]
#3
@
15 years ago
- Keywords needs-patch added; needs-feedback removed
I've tracked the problem to the vicinity of line 3256 in wp-includes/post.php where the logic checks for the string wp-content/uploads
in the file URL.
Consider that donncha had commented out this part of the code in the WordPress µ source code, noting that it "Breaks WordPress MU image upload path".
Something needs to be done about this if the same code is going to function for both multisite and non-multisite installations.
#4
@
15 years ago
Can you var_dump() $file and $uploads from that function? With that block commented out, MU is always falling back to the guid, which is very busted.
#6
@
15 years ago
- Milestone changed from Unassigned to 3.0
- Owner set to ryan
- Status changed from new to assigned
#7
@
15 years ago
- Cc frederick.ding@… added
I can confirm that this has been fixed by [12850] and/or [12851]. The URLs are now as they should be (http://rhhsweb.com/files/2010/01/rhhs-web-wordpress-button-150x86.png, for example).
As for var_dump()
, I don't think there's any point now, but I will show you what it looked like before updating to the latest trunk:
$file: string(80) "/home/rhhsweb/wp-content/blogs.dir/1/files/2010/01/rhhs-web-wordpress-button.png" $uploads: array(6) { ["path"]=> string(50) "/home/rhhsweb/wp-content/blogs.dir/1/files/2010/01" ["url"]=> string(32) "http://rhhsweb.com/files/2010/01" ["subdir"]=> string(8) "/2010/01" ["basedir"]=> string(55) "/home/rhhsweb/public_html/wp-content/blogs.dir/1/files/" ["baseurl"]=> string(24) "http://rhhsweb.com/files" ["error"]=> bool(false) }
I suppose the string for $file
should be just the filename as opposed to the absolute path, since the code appeared to stick $file
at the end of the $uploads['baseurl']
. But it seems to work for me now.
#8
@
15 years ago
In older versions of WP, the attached file included the full path. New uploads should have a relative path. Is that true for you with 12850 and 12851?
#9
@
15 years ago
That's correct; new uploads now have a relative path:
$file: string(32) "2010/01/24-230332-screenshot.png" $uploads: array(6) { ["path"]=> string(50) "/home/rhhsweb/wp-content/blogs.dir/1/files/2010/01" ["url"]=> string(32) "http://rhhsweb.com/files/2010/01" ["subdir"]=> string(8) "/2010/01" ["basedir"]=> string(42) "/home/rhhsweb/wp-content/blogs.dir/1/files" ["baseurl"]=> string(24) "http://rhhsweb.com/files" ["error"]=> bool(false) }
The older uploads are still stored in the database with a full path, it seems:
$file: string(80) "/home/rhhsweb/wp-content/blogs.dir/1/files/2010/01/rhhs-web-wordpress-button.png" $uploads: array(6) { ["path"]=> string(50) "/home/rhhsweb/wp-content/blogs.dir/1/files/2010/01" ["url"]=> string(32) "http://rhhsweb.com/files/2010/01" ["subdir"]=> string(8) "/2010/01" ["basedir"]=> string(42) "/home/rhhsweb/wp-content/blogs.dir/1/files" ["baseurl"]=> string(24) "http://rhhsweb.com/files" ["error"]=> bool(false) }
Sounds like a configuration issue. Can anyone reproduce the problem?