Image 01

WordPress Image Handling Sucks (WP Wednesday)

December 21st, 2009 by Colin Carmichael

WARNING: Today’s WordPress Wednesday post is a selfish rant – and two days early. So much for Christmas spirit. ;)

Yes, I said it. The words “WordPress” and “sucks” in the same breath. It’s a rare thing for a WP fanboy like me to do, but today, the Automattic folks deserve it.

This week’s release of WP 2.9 brought some awesome image editing tools to WordPress users – but the entire image handling system is still broken. It’s a kludge.

When you upload an image to WP, it “crunches” it – creating up to 4 versions of the image at various sizes (thumbnail, medium, large and original) on the server. These are now the ONLY sizes available to you in your posts. In addition, with the exception of gallery-generated pages, references to these images inserted into posts are specific to the pixel size (150, 300, etc.) rather than the relative size (thumbnail, medium, large, etc). Yes, you can change the pixel sizes of the relative sizes – but once an image is uploaded, you’re stuck with the settings of the day.

This wouldn’t bother me so much if I didn’t know that there was an alternative. Why can’t WP resize images on-the-fly at the server?

Example:
William Bundled Up
This image is located at http://colincarmichael.ca/wp-content/uploads/2009/12/SDC11443-300×199.jpg. See those pixel references in there? This image physically exists on the server. Very limiting.

In contrast, look at these: (from a Drupal site I run, the tech isn’t Drupal-specific)

URL: http://www.presbyterian.ca/photoresize/4398/600


URL: http://www.presbyterian.ca/photoresize/4398/300


URL: http://www.presbyterian.ca/photoresize/4398/150


URL: http://www.presbyterian.ca/photoresize/4398/news

See those pixel references in the URLs? There are no images on the server in those specific sizes – the server resizes the original image on the fly as required. See that last one with a relative size of “news”? The server resizes that to a size specified in the settings, in this case 250px.

There’s no reason that WordPress’ image handling could work the same way. You’d only need to store the original of the image on the server, and you could insert images of any size in your posts. Additionally, if you had “virtual” sizes defined such as full=600px, half=300px, thumb=150, etc, you could have images that would resize gracefully if your theme changes and you now need full to be 400px and half to be 200px.

So, Automattic, how ’bout it? Now that you’ve given us image-editing tools in 2.9, can you address the broken image-handling problem?

Pin It

Tags: , , , , , ,

10 Responses to “WordPress Image Handling Sucks (WP Wednesday)”

  1. Matt says:

    I do this on my blog, and there are good plugins for it. It can create a pretty large burden on the server, though, which is why we decided to delay implementation until the next version.

    Also, common mistake, but Automattic does not make WordPress.org, it’s made by many people (over 140 thanked in the announcement post) the vast majority of whom have nothing to do with Automattic, and some find it insulting when you refer to them as one and the same.

  2. Hey Matt,

    Thanks for stopping by. I appreciate the distinction between .org and .com and Automattic different role with each, but I hope you’ll appreciate that for a many WP users, WordPress is WordPress and WordPress is Automattic.

    Anyway, my frustration had more to do with the fact that WP has painted me into a corner with hard-coded image-sizes with no way to easily adjust now for a new theme with a wider content area.

  3. James says:

    I understand what you mean. Image resizing should be transparent to the end user.

    It took me a while to do it for my websites. You have to mess around with the actual server itself to handle redirects and such. I’m not so sure wordpress would work in every circmstance depending on how your server was configured. Example, CGI versus Apache Mod, Linux versus Windows.

    That’s probably why they don’t do it.

    As for the load on the server. You only need to compress it “on-the-fly” once and cache the results.

    Typically, wordpress is a big mashy mess, far from anything innovative at all… it’s really just popular. It will an eternity before they really hammer everything out, jmo… I mean they laid such a strange groundwork now they are stuck with it as many people have extended it.

    Hope that helps paint a picture…

  4. In 2.8 in the editor you can click on an image included in a post and manipulate resize controls. Has this changed in 2.9? What exactly are you referring to?

  5. WP is very compartmentalized.
    Trying to make a change to ALL elements is frustrating, to say the least.
    Not a true OOP implementation.

    But… I do believe there is a plugin for image thumbnail resizing up on wp somewhere.
    In one swoop, it will regenerate all image to your preferred size, as set in WP media prefs.

    (none of the above obviates the need for better image handling, just helps alleviate a bit).

    Personally, looking forwards to moving to Drupal in future.

  6. James says:

    I think I understand what your saying. While OOP might give you better “compartmentalization”, it’s still not going to change the architecture they are currently working with.

    I heard WordPress the newer version offers image editing capabilities, however it seems to repeat desktop editing functionality in the browser as opposed to “on-the-fly” image management.

    It seems you just have the ability to create new images for use elsewhere…

    OOP is really not beneficial in the sense that anyone can still write a mess in OOP code.

    Just wanted to come back and mention that regeneration is something I used to do with my CMS but it creates an issue with reusing the same image in multiple areas at different resolutions. An upper limit, sure, but a fixed size applied and recompressed against all images? It sounds like it could be CSS in which case it works, but not very well…

    I don’t want to give it away, but drupal is most certainly the closest one to having it set up right…

    You can tell by the folder naming structure…

  7. James says:

    But Drupal is still not “on-the-fly”… It looks like they compress at the point at which the resolution is applied in the settings rather than at the point at which the page is generated.

    Hence… each photo is still unique… Creates a large and unmanageable potential mess long term… jmo…

  8. James says:

    In any event… what ever happened to resolution independence? That’s what everybody should be shooting for… jmo… I mean SVG and VML is very real and give CSS another few years and presto… websites will jump from Windows 3.1 desktop bitmap graphics to scalable vector graphics Windows 7. Right?

  9. Yes, WordPress still sucks at handling images, and its the year 2014 now… Quite sad actually they cannot figure this simple problem out… Loading downsampled images on the fly is a far superior method, and more universal as well, compared to generating all the default sizes they have defined in their functions.php file….

    I’ve found that using a javascript called Adaptive Images has taken care of this quite well actually. But what still sucks about wordpress is that you have to crack open the functions.php file and scan to a line JUST TO SET THE THUMBNAIL SIZES, which in my opinion, is completely UNNECESSARY. The hard cropping feature is also, a huge waste of time in itself. CSS handles these perfectly using classes to display the images in different aspect ratios without creating multiple versions of the image. The Adaptive Images should create the sizes on the fly, so with that and the CSS cropping, we can avoid the infinite problem of HOW TO CROP YOU IMAGES!
    All of the users I have using wordpress ask the same thing, every single time, “whats wrong with my featured images, and why are their heads cut off?”

    There are other plugins that allow manual cropping of images as they are uploaded, but a bit more difficult to find for when inserting from the media library. And of course, this just creates unnecessary work and obstacles and bloating your servers storage. All the user should need to do is select a class, and maybe a dragging function to position the image in the CSS cropping…. Hey, after all, when a page is shared on a social network, we don’t want the crappy chopped up image now do we?

    Well, what if we deactivate the cropping of the thumbnails? Sure, but my point here is that WordPress is stupid when it comes to image sizes. There should by default, be options and buttons for CSS cropping settings, and stop making users download another plugin just to regenerate their thumbnails.

  10. Howdy. I found your blog the employment of windows live messenger. It is really an very well prepared post. I shall be sure to take a note of the idea accessible back to read through more of one’s helpful details. Wanted submit. I’m going to definitely gain.

Leave a Reply