[wp-trac] [WordPress Trac] #15149: image_get_intermediate_size partly ignores 'path' and 'url' fields and has inconsistent return values
WordPress Trac
wp-trac at lists.automattic.com
Wed Oct 20 21:00:45 UTC 2010
#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):
the more i think about this, the more i am convinced that in the end there
is a more fundamental underlying question that should be answered:
does one want to give plugin authors the freedom to choose the location of
intermediate image sizes or not?
right now this is not the case (mainly because of what i detailed in my
posts above) and the file/directory structure is the following:
{{{
uploaddir/yyyy/mm/image.jpg
uploaddir/yyyy/mm/image-size1.jpg
uploaddir/yyyy/mm/image-size2.jpg
}}}
where image.jpg is the original image, the other two are resized versions
of it. finally, size1 and size2 usually have the form {width}x{height},
but they could also be set to something more readable like "thumbnail" via
filters. in the attachment metadata "sizes" field only "width", "height"
and "file" are stored and "file" is the filename of the resized image. the
path to the resized image is constructed as detailed above, by taking the
path of the original image and exchanging the filename with the one found
in "file".
when dealing with images, i think, however, that other structures can make
a lot of sense and it would therefore be good to have some flexibility in
this respect. in particular i am thinking about a structure like this:
{{{
uploaddir/original/yyyy/mm/image.jpg
uploaddir/thumbnail/yyyy/mm/image.jpg
uploaddir/medium/yyyy/mm/image.jpg
}}}
why is this in some cases a better suited structure? well, it allows you
to immediately find all files that belong to a certain size. for example,
it makes it very easy to delete all medium images. just delete the
corresponding directory. or what about renaming a size? just rename the
corresponding directory. with the structure wordpress imposes right now, i
have to traverse all of the year-month directories to find the
corresponding files and treat them one by one, based on their filename.
so, for some plugins it certainly makes sense to have a different
directory structure. therefore i think wordpress should offer this
flexibility. further, this could be quite easily achieved by storing the
"path" and "url" information in addition to the "file", "width" and
"height" information inside the metadata. it looks like someone already
thought about this, otherwise why would there be references to a "path"
and an "url" field inside image_get_intermediate_size().
whatever the decision is on this, i think that in any case the intention
needs to be made clearer. if sizes are to be distinguished only based on
their filename, references to fields like "path" or "url" that suggest the
opposite should go away. if paths are to be flexible, the above patch is
probably not enough, but it would be better to make sure that all sizes
have the corresponding fields and that the core as well as plugins rely on
these fields to find the location of a size, rather than computing it from
the "file" field.
i am looking forward to hear your thoughts on this.
--
Ticket URL: <http://core.trac.wordpress.org/ticket/15149#comment:3>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list