[wp-trac] [WordPress Trac] #15149: image_get_intermediate_size partly ignores 'path' and 'url' fields and has inconsistent return values

[WordPress Trac]

#15149: image_get_intermediate_size partly ignores 'path' and 'url' fields and has
inconsistent return values
-------------------------+--------------------------------------------------
 Reporter:  whoismanu    |       Owner:                 
     Type:  enhancement  |      Status:  new            
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Media        |     Version:  3.1            
 Severity:  normal       |    Keywords:  has-patch      
-------------------------+--------------------------------------------------

Comment(by whoismanu):

 Replying to [comment:4 Denis-de-Bernardy]:

 denis,

 thanks for your answer. i will try to address all of the points you raise.


 > Well, the reason I asked is I wrote a plugin (Uploads Folder) which
 tinkers around with these pieces of data and moves files around in the
 uploads folder to reflect the URL of whichever piece of data they're
 attached to. And no later than yesterday, I was writing a different one
 which organizes files as so:
 >
 >  - wp-content/images/fullsize
 >  - wp-content/images/midsize
 >  - wp-content/images/thumbnails
 >  - wp-content/videos
 >  - etc., while keeping the existing date or URL-based organization, if
 any.
 >
 > Both plugins cater to the need of access-restricting some files but not
 others.

 bc of plugins like uploads folder. i had a look at your plugin and it
 doesn't use the "path" and "url" fields. all it does with respect to
 attachment metadata is to fetch the filename from the "file" field of the
 "sizes" metadata. as i wrote in my second post this should be no problem,
 it is not affected by the patch.

 (btw, i guess you have a bug in your plugin in the get_path() function
 where it says:

 {{{
 $path = get_option('upload_path');
 $path = trim($upload_path);
 }}}

 this is somewhat unrelated to this discussion, but i figured it might be
 helpful for you to know :-))


 > Both are a bit hacky, in the sense that I had to make do with the
 lacking of the API, but they work.
 >

 sure, you can make it work. i also didn't want to imply that it is not
 possible to organize attachments in a structure different from the
 standard one. in fact i am doing exactly this in the currently available
 beta version of my photoq plugin. but like you say, it is only possible
 through "hacks". it thus works for my plugin, however, it stops working
 when interacting with other plugins that deal with attachments. the reason
 is that throughout wordpress it is assumed that the resized images are
 files with a different suffix in the same directory. while i can make my
 plugin respect the "path" and "url" fields that i populated, other plugins
 do not care about them because wordpress itself does currently not
 properly support them.

 > To be frank, the key points that bothered me had more to do with missing
 filters than with anything. In particular:
 >
 >  - the thumbnail URL filter isn't always applied (image downsize needs
 to be used in some cases to work around this)
 >  - filters are missing to properly change where the file gets stored
 without things interfering with file deletion when attachments are
 deleted.
 >  - the send to editor filters are inconsistently applied throughout the
 application.
 >  - hard-coded links in posts aren't automatically changed when
 attachment file urls change, leading me to think that some URL rewriting
 would be welcome to abstract this stuff in posts.
 >

 so there are more problems in this respect than i thought. however, i am
 not sure that one can work around my problem easily. i think it is really
 more a fundamental problem than the issue of adding a few filters. to me
 the question really is, whether a resized image is a (renamed) file in the
 same directory as the original, or whether there is flexibility as to
 where it can be located. you can also nicely see this in the
 image_make_intermediate_size() function where it says

 {{{
 $resized_file = apply_filters('image_make_intermediate_size',
 $resized_file);
 return array(
         'file' => basename( $resized_file ),
         'width' => $info[0],
         'height' => $info[1],
 );
 }}}

 although there is a filter, its effect is partly reversed by the hardcoded
 call to basename and the fact that other fields like 'path' or 'url' that
 could hold the directory information are missing (i.e. it implies that a
 resized image is represented through the tuple 'file', 'width', 'height'
 only, where a better name for 'file' whould actually be 'filename').

 > Getting back to your patch, it seems to me that we should also (or at
 least) split _wp_attached_file and the resulting meta in two, so the
 subfolder can be filtered based on the file being displayed. And the same
 for what is returned by wp_uploads_dir() -- the latter currently lacks
 context. This would also beak backwards compatibility, but in a way that
 makes things, I suspect, more flexible when we mess around with uploaded
 files.

 not sure i am able to follow your thoughts here. _wp_attached_file and
 _wp_attachment_metadata are already separate custom fields. also, i am
 less concerned about the uploads dir, which i can easily set/change
 through the upload_dir filter, than about the fact that currently
 wordpress seems to be missing a standardized way to retrieve the location
 of resized images.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/15149#comment:5>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software