WordPress Image Handling Sucks (WP Wednesday)

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?

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?

Tags: , , , , , ,

8 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?