[wp-hackers] hacking image resizing
otto at ottodestruct.com
Tue Dec 8 17:30:59 UTC 2009
wp_generate_attachment_metadata is what creates the various sizes, at
upload time. That's where the "sizes" metadata is created.
It does this by calling image_make_intermediate_size for each separate
size. That function calls image_resize to do the actual work of
resizing the image, which uses a few gd functions to do the bulk of
the work (imagecopyresampled, imagetruecolortopalette, imagegif,
imagepng, imagejpg, etc).
This process can fail for a few reasons. wp_load_image loads the image
from disk by doing imagecreatefromstring( file_get_contents( $file )
). So if file_get_contents is unavailable, the whole shebang fails.
Basically, if the calls to the subfunctions fail to return valid
images for whatever reason, no sizes meta gets added.
On Mon, Dec 7, 2009 at 10:53 PM, Sergiy Kuzmenko <s.kuzmenko at gmail.com> wrote:
> I had a bit of a problem with image resizing. Images sized stay greyed out
> no matter what. GD library is enabled. In fact I tried it on two machines.
> It worked fine on my Fedora desktop but failed on on the Ubuntu (hardy)
> server. There is a thread in support forum about this (apparently I am not
> alone) so I suspected it might be a bug. Looking at the code and trying to
> find the root cause I discovered that on the machine where I have this
> problem the assoc. array containing image data has no "sizes" element
> required to trigger image resizing (wp-includes/media.php, function
> Apparently, this assoc. array gets loaded from $wp_object_cache where it is
> supposed to be initialized somehow at an earlier stage. And this is where I
> get stuck. It is not very obvious which code is loading that info into
> $wp_object_cache. Doing "grep -r sizes | grep -v .js" does not reveal
> anything worth attention. I wonder if someone could elucidate me on how
> image sizes get loaded into cache.
> Many thanks.
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
More information about the wp-hackers