WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 4 years ago

#12044 closed defect (bug) (fixed)

Wrong path for uploaded files

Reported by: wpmuguru Owned by: ryan
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)

comment:1 wpmuguru4 years ago

  • Keywords needs-feedback added

Sounds like a configuration issue. Can anyone reproduce the problem?

comment:2 freddyware4 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]

comment:3 freddyware4 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.

comment:4 ryan4 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.

comment:5 ryan4 years ago

Also, please test against latest trunk. [12850] and [12851] may have fixed this. They fixed a problem where the basedir wasn't being correctly set to BLOGUPLOADDIR.

comment:6 ryan4 years ago

  • Milestone changed from Unassigned to 3.0
  • Owner set to ryan
  • Status changed from new to assigned

comment:7 freddyware4 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.

comment:8 ryan4 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?

comment:9 freddyware4 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)
}

comment:10 ryan4 years ago

Currently, old ones still retain their paths. We might update them in the future, but as of now that is by design. I think this ticket can be closed as fixed now, agreed?

comment:11 freddyware4 years ago

  • Keywords needs-patch removed
  • Resolution set to fixed
  • Status changed from assigned to closed

Agreed. Closing.

Note: See TracTickets for help on using tickets.