[wp-trac] [WordPress Trac] #12037: bad image paths from wp_get_attachment_url after 2.8

[WordPress Trac]

#12037: bad image paths from wp_get_attachment_url after 2.8
--------------------------+-------------------------------------------------
 Reporter:  wpmuguru      |       Owner:            
     Type:  defect (bug)  |      Status:  new       
 Priority:  normal        |   Milestone:  Unassigned
Component:  Multisite     |     Version:  2.8.1     
 Severity:  normal        |    Keywords:            
--------------------------+-------------------------------------------------
 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.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/12037>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software