Image Editor
The “first run” of a simple image editor has been in WordPress 2.9-rare for about two weeks. It lets the user crop, flip and rotate an image. It also has an option to scale the original (largest) image and to restore the originally uploaded version. There is a multi-step undo and redo support. Changes can be applied to all image sizes or only the thumbnail. The initial code is by Stephan Reiter author of the Scissors plugin.
Currently when saving an edited image all previous intermediate image sizes are kept and the meta data for them (filename, width, height) is moved to another postmeta field. This is necessary to avoid breaking any posts or pages where the image was inserted. The editing workflow (multi-undo, preview of each step) makes it unnecessary to edit an image more than once or twice, however if an image is edited 6-7 times the backup files would be 25-30.
There are couple of ways to avoid keeping unnecessary images, we could either track when an image was used in a post or a page, or we could have “standard” names for the intermediate image sizes. Tracking image use can be somehow problematic considering all the different ways content can be published in WordPress.
Renaming the resized images from [imagename]-150×100 to [imagename]-thumbnail, etc. seems the more viable option. This would also bring instant image updates in already published posts, however may also have some compatibility problems with plugins that expect the image size to be part of the filename.
Trac ticket for the image editor, suggestions and patches welcome 
sc0ttkclark, 
Alex (Viper007Bond) 5:02 am on September 26, 2009 Permalink |
You could also just use a shortcode for the image tag, although that may not be as user friendly. Then again, if you move domains, URLs, etc. you wouldn’t have to edit the post.
So instead of this:
You’d do this:
The URL, width, and height would all be dynamic and change if you changed the thumbnail size, etc. This is opposite of now where even if the filename didn’t contain the dimensions, you’re still left with hard coded width/height parameters in the image tag.
scribu 11:49 am on September 26, 2009 Permalink |
That would be nice. And it’s been requested several times in the past.
Xavier 4:47 pm on September 26, 2009 Permalink |
How would that shortcode handle differences between
http://blog.com/wp-content/uploads/2009/02/imagename-thumbnail.jpg
…and…
http://blog.com/wp-content/uploads/2009/03/imagename-thumbnail.jpg
…?
Beau 9:30 pm on September 26, 2009 Permalink
Since both uploads would have a unique id in the DB, it doesn’t matter if they have the same filename. The correct URL would be output dynamically, based on wherever it was stored (as referenced by the DB)
Andrew Ozz 12:57 am on September 28, 2009 Permalink |
Think this came up when we were doing the captions shortcodes a year ago and was rejected. Perhaps we can look at the pro & con again. Since all movies and other embeds will be handled by shortcodes it may make sense to extend that to include images too.
However I see a possible problem with that. The img tag doesn’t need any processing on display but a shortcode would need quite a lot as it seems we will have to do get_post() for the attachment. Also our shortcode parsing code/API doesn’t seem optimized enough to handle large quantity of shortcodes.
aarondcampbell 8:20 pm on October 3, 2009 Permalink
It is true that it can’t handle really large posts with lots of shortcodes. However, that’s definitely only affecting a very small percentage of people (if we’re really focusing on the 80-20 principle, it’s less than 20%). Do we really think that enough people will be writing stuff this long (and putting enough shortcodes in it) that we should worry about it? (That’s the post where I first ran into the issue…I tried to explain that it was just too long, but apparently it’s quite effective as it is).
I like the shortcode idea.
Andrew Ozz 2:31 am on October 5, 2009 Permalink
True, this is very rare at the moment but turning img tags into shortcodes would increase that number, perhaps a lot.
No, don’t think we can apply the 80/20 principle here. Would that mean we can break up to 20% of all published posts?
The problem is that even a shorter post with a lot of images will reach the backtrack limit or be very slow to display.
DD32 2:58 am on October 5, 2009 Permalink
> or be very slow to display.
Reminds me of the mention of storing filtered post contents along side the raw and serving those up instead of applying the expensive filters every load..
Andrew Ozz 3:19 am on October 5, 2009 Permalink
Yes, post_content_filtered is still in the posts table. Think there are few plugins that do this, not sure how well though as it bypasses all ‘post_content’ filters.
Alex (Viper007Bond) 3:38 am on October 5, 2009 Permalink
Perhaps storing a partially cached version would be best, i.e. just internal shortcodes. You’d break a lot of plugins if you rendered the entire content from a cached copy.
Jonathan Dingman 9:22 pm on October 1, 2009 Permalink |
Would that imply dynamic resizing?
ie, if someone changed the thumbnail size after already uploading the image, would it resize on the fly? (if specifying a thumbnail in the shortcode)
Denis de Bernardy 11:14 pm on October 3, 2009 Permalink |
Using a shortcode here would hammer the DB unless it’s properly implemented.
And this “it hammers the database”, btw, is the reason I had opened:
http://core.trac.wordpress.org/ticket/10882
I use similar code in two plugins of mine, and since you can’t rely on an attachment from being tied to a single post, I check for a post meta to make sure there are attachments (and which ones) before tossing a query.
Alex (Viper007Bond) 6:56 am on October 4, 2009 Permalink |
We also have to not forget about those who use TinyMCE and expect to see the image as is. A shortcode would be there as text.
Perhaps a TinyMCE plugin could AJAX fetch the image (based on ID) and replace the shortcode with the image during editing, then put it back to the shortcode on save. That way it’d still stay a WYSIWYG.
aarondcampbell 9:53 pm on October 4, 2009 Permalink
That’s a good point. It’s easy to forget about those using WYSIWYG
Barış Ünver 6:33 am on September 26, 2009 Permalink |
I’m concerned about the fact that WordPress is getting fatter and fatter each version. Is it really necessary? Couldn’t it be done with a plugin or something?
Or at least, are we gonna be able to se a lighter (official) version of WordPress? LitePress v2.9.0 maybe?
Alex (Viper007Bond) 9:14 pm on September 30, 2009 Permalink |
Filesize (aka fat) is not directly related to performance. The image editor for example has literally zero (no joke on the literally) impact on the front page of your site for example as it’s never loaded except in the admin area.
Andrew Ozz 12:15 am on October 1, 2009 Permalink
On top of that even in the admin it’s only loaded through AJAX so it doesn’t add any overhead anywhere.
aarondcampbell 8:22 pm on October 3, 2009 Permalink |
It’s all about the 80-20 rule. I think more than 80% of the people will use this on a regular basis. I probably won’t, but most of my clients will. I’m all for keeping code as lean as possible, but I’m also all for adding this support in. Let’s trim in other areas. Just my 2 cents.
Andrew Ozz 1:37 am on September 28, 2009 Permalink |
Another solution for the multiple image backup files would be to let the user decide. We can include a checkbox whether to delete the previously edited image (together with all sub-sizes). Since the suffix that is appended to the image filename contains a timestamp, we could do something like “This image was last edited 1 hour ago. If it wasn’t used in a Post since then you can remove the backup files by selecting this checkbox”.
On the other hand even the cheapest hosting accounts seem to come with a lot of storage so deleting backups would be unnecessary. Also a plugin can add a simple GUI to search the db and return a list of unused backup images that can be deleted. Not sure if something like this would be good for core.
Otto 6:07 pm on September 28, 2009 Permalink |
I think the key to this problem is the following: “This is necessary to avoid breaking any posts or pages where the image was inserted.”
Why avoid breaking those posts/pages? If somebody edits an image, then change the image itself. That’s what they will probably expect to happen.
Having to have them go and reinsert the changed image into the page/post is confusing and unnecessary. We don’t need to save the original. The user uploaded the image, presumably they have the original. An in-place editor should simply overwrite the existing files with the new ones, not try to preserve them.
Andrew Ozz 12:30 am on October 1, 2009 Permalink |
True, users that know what they’re doing may expect to break old posts when editing an image. However the majority will most likely complain that “the image editor breaks all old posts!”.
Also we cannot just replace the originally used image with the edited one as images are inserted with “width” and “height” attribs that in most cases will distort the edited image (as Viper007Bond pointed above).