[wp-hackers] Image Management Enhancements in 3.3?

[Mike Schinkel]

On Oct 2, 2011, at 10:49 PM, Dion Hulse (dd32) wrote:

> Ah, well yes it does have that functionality.. Just not through those handy
> Classes.
> The File upload handlers have (for a long time) accepted any upload that you
> trigger them with, and has the ability to set custom image sizes which might
> be croped. There's hooks for meta geenration at which you can trigger other
> image manipulations (such as croping a image via POST data).
> Ultimately, it's not handed to you on a silver platter, but the
> functionality you need are there - I suspect you'll write it yourself though
> out of frustration from there not being a clear example as how to achieve
> that all though.

Thanks. I've been through all of the image management code in WordPress 3.2. My secret weapon(tm) PhpStorm+Zend Debugger makes it pretty easy it figure out pretty much anything I need to understand in WordPress core.

The problem with what's there is mostly too coupled to existing UI use-cases in WordPress that don't apply to our needs, and using it is more trouble than writing it directly. There are of course some function I can and am using/will use, but overall it's not what we need; the coupling is too high.

For example, here are (some of) the WordPress core functions that contain the raw image functionality needed:

wp_save_image()
wp_crop_image()
wp_load_image()
stream_preview_image()
_crop_image_resource()
_flip_image_resource()
image_resize()
wp_save_image_file()
wp_stream_image()
media_handle_upload()
wp_handle_upload()
media_upload_image()
media_upload_file()

Let's take a look: 

wp_save_image() accepts an attachment_id and assumes that $_POST has values for 'fwidth', 'fheight', 'target', 'do', etc. and a lot more coupling.  So it can really only be used for the use-case where admin-ajax.php is called with $action is 'image-editor.'

wp_crop_image() is useful, and I'll probably use it. Ironic though that sitting beside wp_save_image() you would not expect it to take 9 parameters when wp_save_image() takes one and is used in completely different contexts. So much for API consistency. :)

wp_load_image() is useful and I'll probably use it, but only marginally so because it doesn't do much more than call imagecreatefromstring().

I could continue, but hopefully you get the idea.  I think it'll actually be easier to write the classes then retrofit whatever WordPress core has in place of the code we write where possible. Trying to deal with the dependencies during development of those classes when it's hard to even know what the dependencies are is probably too much trouble during initial development.

So a set of consistent and easy-to-use Image/File API classes for WordPress would be really useful. And since we need them for a project I guess that's what we are going to build.  We'll use whatever we can from core and we'll write code for where WordPress doesn't have what's needed.

-Mike