digitalart8

WordPress new image manipulation

After two months hard work the new image manipulation code finally is committed to core (changeset). This all was a team effort where I’m really happy to a part from. I worked together with Mike Schroder, Japh Thomson, Kurt Payne, Andrew Nacin and Cristi Burc?.

It started on the hack day at WordCamp San Francisco where I worked mostly with Mike and Japh on it and talked with other people for getting feedback on how to do this. After the hack day I worked most of the time with Mike on getting things done and getting great feedback from Scribu and Nacin. When most of it was done Kurt helped us out with unit testing all of the code and had some great feedback as well.

The reason

The reason of the change was to allow ImageMagick to be used since it gives better images. The upside of this all is that the code is easier to read and less integrated in core so it is really easy to use inside plugins. There were also some small bugfixes to the existing code.

The most awesome part of this is that you now can write your own implementation of image handling. If you really love WPThumb then with some work I’m pretty sure you can also use that as a implementation in WordPress.

Code Examples

Cropping

This is like the basic resize/crop example how WordPress deals with it. This will create a 100×100 image that is cropped and got saved as /path/to/image-100×100.png

$file = '/path/to/image.png';

$editor = WP_Image_Editor::get_instance( $file );
$editor->resize( 100, 100, true );
$new_image_info = $editor->save();

Change of Mime-type

You can also save it as another mime-type by doing the following ways of saving. The first one is setting the filename and it will look up the mime type from the extension. The second one you don’t need to know the filename and you just set the mime type.

$file = '/path/to/image.png';

$editor = WP_Image_Editor::get_instance( $file );
$editor->resize( 100, 100, true );
$new_image_info = $editor->save( '/path/to/image.jpg' );
// or
$new_image_info = $editor->save( null, 'image/jpeg' );

Things that need to be done

There are still a lot of things to clean out before 3.5 is going to be released. Since plugin developers can create their own implementation we still need to look how we can add stuff later without breaking their implementation.

Japh is also working on getting ImageMagick/convert working. This is doing all this things by using the commandline instead of using the Imagick PHP library. I’m really curious to see how that goes.

10 thoughts on “WordPress new image manipulation

  1. “The most awesome part of this is that you now can write your own implementation of image handling. If you really love WPThumb then with some work Iím pretty sure you can also use that as a implementation in WordPress.”
    I remember sharing a taxi with you in Lisboa. We talked exactly about this ;) I’m excited about what people will come up with (@joe_hoyle, hint hint).

    1. marko says:

      I will be working on some examples this month for preparing a presentation about this. Will see if I can create a cool example that includes WPThumb ;)

  2. Trevor Mills says:

    Hey Marko,

    I saw that you’re speaking at WordCamp dev in Toronto and am interested in your topic. I’m presenting there as well, so we’ll get to meet.

    I have a plugin that I wrote that allows users to customize the crop for any custom image size. It’s available at http://topquark.com/extend/plugins/custom-image-cropper.

    It breaks in 3.5 (not surprising). Good to know. I look forward to learning about the changes as I update that plugin.

    See you in a couple of weeks.

    Cheers
    Trevor

    1. marko says:

      I will look in to why it breaks since it shouldn’t break unless you do something really exotic. Since it should be backwards compatible ;)

      Hope to get back at you this week.http://markoheijnen.com/wp-admin/#comments-form

      1. Trevor Mills says:

        Hey Marko,

        I’m not sure if the actual image manipulation code breaks. I didn’t get that far.

        The breakage actually happens because of the way I inject the Cropper button. There were no WP hooks that I could use to get the button in there, so I ended up using jQuery to inject the button. It was reliant on the markup that was returned from WP when (1) an image had just been uploaded or (2) user clicked edit image.

        I suspect that the image manipulation will still work, though I have to get the cropper injected again in order to check it out.

        Cheers
        Trevor

        1. marko says:

          Yes you are correct. Since media now is a real post type that is changed.

          Maybe you can ask to add a hook for that at this ticket: http://core.trac.wordpress.org/ticket/22186

  3. David McDonald says:

    Is the WPThumb plugin expected to still work with 3.5?

    1. marko says:

      It still should work as expected. I’m playing with it so it can use the 3.5 functionality. Also the developers itself seems to play with it so if there is something that breaks it will be fix in core or in the plugin

  4. Japh says:

    Great work, Marko! It was a pleasure meeting you and working with you on this.

    I hope your presentation at WordCamp Developers Toronto went well too :)

    1. marko says:

      Thanks Japh, Had a great time working with you and learned a lot.

      My presentation went fine. Could have been better but I do now have lots of ideas on improving it. So I’m now going to work on that and going to build a Instagramish plugin to show how the new code can be used :). So for beginners it is still cool to see even when they don’t understand the code behind it.

Leave a Reply

Your email address will not be published. Required fields are marked *