Opened 10 years ago
Last modified 7 years ago
#32117 new defect (bug)
wp_get_attachment_metadata sizes array file misses path if using year/month organizing
Reported by: | thomask | Owned by: | |
---|---|---|---|
Milestone: | Awaiting Review | Priority: | normal |
Severity: | normal | Version: | 4.2 |
Component: | Media | Keywords: | needs-patch |
Focuses: | Cc: |
Description (last modified by )
wp_get_attachment_metadata returns array like this:
["metadata"]=> array(5) { ["width"]=> int(3072) ["height"]=> int(2304) ["file"]=> string(25) "2015/03/GC702D01_high.jpg" ["sizes"]=> array(4) { ["thumbnail"]=> array(4) { ["file"]=> string(25) "GC702D01_high-200x150.jpg" ["width"]=> int(200) ["height"]=> int(150) ["mime-type"]=> string(10) "image/jpeg" }
as you can see, "file" in the first level of the array contains year and month (as i do have turned on organizing in year/month structure for uploads), but "file" in the second level for (e.g. in this case) the thumbnail size is only the file name, without the path.
This is at least confusing, make it difficult to get the URL of the file - each size need to be then requested separately by wp_get_attachment_image_src function.
IMO optimal solution would be to use full path in both $metadata['file']
and $metadata['sizes'][$size]['file']
so the same name would have the same structure. But i do not know if it wouldn't have some compatibility issues.
Less optimal imo would be to add there also the path - it can be there only once in the top level, as all sizes are currently always in the same folder, but i think this could lock us from possible changes / plugin modifications etc. E.g. I think that it would be great, if it would be possible (and even default) to have size name, as a folder, so that we would have thumbnails in uploads/thumbnail, medium size in uploads/medium ... - this would highly reduce the number of images in one folder in default settings and would reduce the problems with displaying them on most systems. And also if we would want to delete some defined size, we could simply delete one folder and save space.
So the second optimal would be to show the path in sizes[$size]
subarray, e.g.
["metadata"]=> array(5) { ["sizes"]=> array(4) { ["thumbnail"]=> array(4) { ["file"]=> string(25) "GC702D01_high-200x150.jpg" ["path"]=> string(25) "2015/03/" }
Change History (7)
#2
in reply to:
↑ 1
@
9 years ago
Replying to jnz31:
seems like they updated this function by adding the 'url' parameter (i have wp 4.3.1 installed), but that one is wrong too, since it's missing the path to the correct folder. this is what i have, the whole "wp-content/uploads/YYYY/MM" is missing:
i think this is expected and right behaviour. $upload_dir may vary e.g. using CDN etc. Path is the crucial part.
#4
@
9 years ago
oh sorry, i missed you wrote about URL as my initial post was about path param. Yes, you are right, URL param is wrong, it should be $upload_dir . $img['sizes']['thumbnail']['path']
or not there at all.
#7
@
7 years ago
This problem is actually a little bit annoying ;) Seems the only native function for getting an attachment object by ID is wp_get_attachment_metadata()
but it doesn't actually return a path. I could very much be mistaken and of course the way it is may be on purpose.
I got around the problem by doing the following.
<?php $path = dirname(wp_get_attachment_url($img_id)); $image = wp_get_attachment_metadata($img_id, true); $image['path'] = $path . '/';
<?php print_r($image['path'] . $image['sizes'][$size]['file']);
seems like they updated this function by adding the 'url' parameter (i have wp 4.3.1 installed), but that one is wrong too, since it's missing the path to the correct folder. this is what i have, the whole "wp-content/uploads/YYYY/MM" is missing:
only option i see here is to get the upload directory and glue it to the path like so: