In WordPress 3.5, GD has been abstracted out of core’s image manipulation functions.
What does that mean for you, you ask?
What’s cool?
- We add support for Imagick by default, giving better image quality to those who have it available on their host. This is particularly important if you’re using images with extended color profiles, since GD discards them outright.
- Imagick support requires Imagick 2.2.0+ compiled against Imagemagick 6.2.9+, for full support. If the required functions aren’t available, WordPress will default back to GD.
- You can create your own image manipulation engine, or extend ours in plugins to easily add additional functionality to WordPress.
Watch out for:
Any function or filter that receives or returns a GD Image Resource should be avoided if possible, since 3.5 represents core’s move away from GD’s direct use.
Deprecated Filters
Several filters have been deprecated, and will no longer function as they did previously. This includes any filter that expected to receive a GD Image Resource, as we can’t pass a GD Image Resource to it if another backend is being used. Instead, new filters are introduced that expect a WP_Image_Editor object.
It’s worth noting that if you’re using these filters, your plugin shouldn’t create a fatal error – it just won’t modify core’s functionality like it used to, and will fail silently.
Deprecated Filters
image_save_pre is now image_editor_save_prewp_save_image_file is now wp_save_image_editor_fileimage_edit_before_change is now wp_image_editor_before_change
While jpeg_quality is backward compatible in 3.5, if you want to change compression quality globally, you should use wp_editor_set_quality in the future, since it applies to other editors and formats that support quality setting as well (like PNG with Imagick). To change the quality on a single image you’re editing, see WP_Image_Editor::set_quality().
New Filters
wp_image_editors – modify array to re-order or add additional editor/engine classes.image_editor_default_mime_type – string; set default mime-type for WP_Image_Editor.
Deprecated Functions
wp_load_image() – use wp_get_image_editor() to load files instead.image_resize() – use WP_Image_Editor::resize()gd_edit_image_support() – use wp_image_editor_supports()
Need to Deprecate
There isn’t yet an alternative for load_image_to_edit(). This is because there is work towards creating an image container for a future version of WordPress. In the meantime, while decidedly not ideal, I’d suggest doing what core does: wp_get_image_editor( _load_image_to_edit_path( $post_id ) );
How do I use it?
A complete tutorial on the use of WP_Image_Editor is forthcoming, but this should get you started:
$image = wp_get_image_editor( 'cool_image.jpg' );
if ( ! is_wp_error( $image ) ) {
$image->rotate( 90 );
$image->resize( 300, 300, true );
$image->save( 'new_image.jpg' );
}
You can see full class documentation by taking a look at:
wp-includes/class-wp-image-editor.php
wp-includes/class-wp-image-editor-imagick.php
wp-includes/class-wp-image-editor-gd.php
Known issue
#22663 – Non-Square Rotates (non 90*x), followed by a crop, can cause improper results.
jltallon, 
lessbloat, 
[/edit]
Mark Jaquith 8:24 pm on March 6, 2013 Permalink | Log in to Reply
I think the session expired modal should darken the rest of the page. It kind of blends in as-is.
Mike Schroder 10:45 pm on March 6, 2013 Permalink | Log in to Reply
Agreed. I think that was initially left over from the “let’s let the user continue to work” mentality. If we’re going with “Your only path is to log back in,” then making it darken the rest of the page is appropriate.
lessbloat 3:16 pm on March 7, 2013 Permalink | Log in to Reply
I agree with @MarkJaquith. I took a quick stab at mocking it up:
Andrew Ozz 6:44 pm on March 7, 2013 Permalink | Log in to Reply
Was testing something similar too and agree it looks better. The only concern is that it will frighten the user when it shows.
Most commonly this will show on the Add / Edit Post screen (as the users spend most time there). Imagine typing a new post, uploading images, etc. and suddenly the screen with your work disappears and is replaced by the login screen telling you to log in again. I bet two “scary” thoughts would go through your head: “What happened to my post?” and “This asks for my password, is it legit?”. Additionally the screen change will most likely cut you in the middle of a sentence and can literally startle you.
In the original patch this was a two steps process: a non-modal (position fixed) warning shows first telling the user that the session has expired and asking to log in again. As the rest of the screen is visible this is not that scary (you can still see your work) and won’t startle you as most of the screen doesn’t change. Then clicking a link or a button in the warning opens the actual login screen in a modal.
Perhaps this is a better solution. Yes, one more click, but better user experience.
lessbloat 1:56 pm on March 8, 2013 Permalink | Log in to Reply
I think we can likely find a way to lessen the fear by getting the copy right. You could also bump the darker outer margin up (maybe double the margin), and perhaps lighten the opacity a tad, so that the user still can see some of the screen behind.
I prefer the one step (taking them straight to the login form), vs. showing an intermediary step (which looks more suspect than the log in form with the logo above it, to be quite honest). If they’ve saved their login details, they only have to click once (on the “Log in” button), and they are right back to their writing.
jltallon 12:52 pm on March 20, 2013 Permalink | Log in to Reply
+1 — Translucency allowing the user to see that their content is still back there, undisturbed, perfectly conveys the notion that “your session has expired, we need to re-authenticate you so that you can follow working as if nothing had happened”:
IMHO, you nailed it.