WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 5 years ago

#12037 closed defect (bug) (invalid)

bad image paths from wp_get_attachment_url after 2.8

Reported by: wpmuguru Owned by:
Milestone: Priority: normal
Severity: normal Version: 2.8.1
Component: Multisite Keywords: reporter-feedback
Focuses: Cc:

Description

MU Trac Ticket: http://trac.mu.wordpress.org/ticket/1091

In 2.8, the way that the wp_get_attachment_url figures out paths seems to be incompatible with WPMU. That is, it will return the path to an image without a slash between the date-based folder and the base URL, if the parent post/page was created some time ago.

For instance, lets say the post was from 03/2009, so all images for this post would be uploaded into wp-content/blogs.dir/1/files/2009/03/ (assuming this is the first blog on the site). This image would be served at http://www.mysite/files/2009/03/myimage.jpg

If we retrieve images attached to the post during march, we'll be OK. But if we retrieve the images after 03/2009, all the images will get a URL of http://www.mysite/files2009/03/myimage.jpg, missing the trailing slash. This seems to occur from the way wp_get_attachment_url() figures out the path to images, using the wp_upload_dir() function. The wp_upload_dir function just gives the upload dir for whatever the current month/year is, not taking into account the current/month year of the post might be different.

Existing code:

if ( $file = get_post_meta( $post->ID, '_wp_attached_file', true) ) { //Get attached file
	if ( ($uploads = wp_upload_dir()) && false === $uploads['error'] ) { //Get upload directory
		if ( 0 === strpos($file, $uploads['basedir']) ) //Check that the upload base exists in the file location
			$url = str_replace($uploads['basedir'], $uploads['baseurl'], $file); //replace file location with url location
		elseif ( false !== strpos($file, 'wp-content/uploads') )
			$url = $uploads['baseurl'] . substr( $file, strpos($file, 'wp-content/uploads') + 18 );
		else
			$url = $uploads['baseurl'] . "/$file"; //Its a newly uploaded file, therefor $file is relative to the basedir.
	}
}

If we take out the junk 2.8 added to wp_get_attachment_url over 2.7, it works OK:

if ( $file = get_post_meta( $post->ID, '_wp_attached_file', true) ) { //Get attached file
	if ( ($uploads = wp_upload_dir()) && false === $uploads['error'] ) { //Get upload directory
		// if ( 0 === strpos($file, $uploads['basedir']) ) //Check that the upload base exists in the file location
		// 			$url = str_replace($uploads['basedir'], $uploads['baseurl'], $file); //replace file location with url location
		//else
		if ( false !== strpos($file, 'wp-content/uploads') )
			$url = $uploads['baseurl'] . substr( $file, strpos($file, 'wp-content/uploads') + 18 );
		else
			$url = $uploads['baseurl'] . "/$file"; //Its a newly uploaded file, therefor $file is relative to the basedir.
	}
}

This seems to be a change that happened in WordPress? 2.8, which works OK for core, but not WPMU. Seems like it could be related to to Ticket #1090.

Change History (6)

comment:1 @wpmuguru6 years ago

  • Keywords needs-feedback added

Still an issue?

comment:2 @miqrogroove6 years ago

I'm sure this has something to do with the fact that 'wp-content/uploads' isn't supposed to be hard coded anywhere in the attachment system.

comment:3 @miqrogroove6 years ago

I'm also confused by the explanation, because 'basedir' is not supposed to have the month and year path in it.

comment:4 follow-up: @ryan5 years ago

See #12044, [12850] and [12851].

comment:5 in reply to: ↑ 4 @nacin5 years ago

Replying to ryan:

See #12044, [12850] and [12851].

This still current?

comment:6 @nacin5 years ago

  • Keywords reporter-feedback added; needs-feedback removed
  • Milestone Unassigned deleted
  • Resolution set to invalid
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.