Subscribe to
Posts
Comments
NSLog(); Header Image

More on WordPress 2.1 Borking Image Uploads

As I wrote yesterday, WordPress 2.1 severely breaks image uploading in several ways:

  1. It automatically creates thumbnails I don't want (or need).
  2. It ignores path components and instead appends the path to the filename.
  3. It creates unnecessary (or unwanted) data in the wp_postmeta table.
  4. It creates unnecessary (or unwanted) data in the wp_posts table.

I can deal with the last two via a cron job that removes these items from the databases. They're more headache than actual "broken-ness."

Today I discovered yet another way in which image uploading in WordPress 2.1 is broken: it renames my images! In the XML below, you'll see I've attempted to upload "test_image.png" to "sw/". WordPress instead creates a file called "swtest-image.png" (along with a thumbnail).

I ran this query in ecto, but I also did similar tests in MarsEdit. WordPress behaves the same in both cases.

Request with URL:
http://nslog.com/xmlrpc.php
and data:
<?xml version="1.0" encoding="UTF-8"?>
<methodCall>
<methodName>metaWeblog.newMediaObject</methodName>
<params>
	<param>
		<value><string>1</string></value>
	</param>
	<param>
		<value><string>admin</string></value>
	</param>
	<param>
		<value><string>******</string></value>
	</param>
	<param>
	<value><struct>
	<member>
		<name>bits</name>
		<value>REMOVED</value>
	</member>
	<member>
		<name>name</name>
		<value><string>sw/test_image.png</string></value>
	</member>
	<member>
		<name>type</name>
		<value><string>image/png</string></value>
	</member>
	</struct></value>
	</param>
</params>
</methodCall>
Response:
<?xml version="1.0"?>
<methodResponse>
  <params>
    <param>
      <value>
        <struct>
  <member><name>file</name><value><string>/server/path/to/site/imgs/swtest-image.png</string></value></member>
  <member><name>url</name><value><string>http://nslog.com/imgs/swtest-image.png</string></value></member>
  <member><name>type</name><value><string>image/png</string></value></member>
</struct>
      </value>
    </param>
  </params>
</methodResponse>

3 Responses to "More on WordPress 2.1 Borking Image Uploads"

  1. As you can see, WP 2.1 has a lot of new image uploading code. I'm sorry to hear that it breaks your expectations. Let me try to address some of this, but I should warn you first that I very rarely use XML-RPC with WordPress. Please let me know when I'm completely off my rocker.

    1. Unwanted thumbnails: Thumbnail generation can be turned off via plugin (there is currently no User Interface for it). I'm happy to provide more details.

    2. Upload path: If you're curious, this is the changeset that broke it. To be honest, I'm not sure if the 2.0 behavior of allowing custom paths was intentional or a "feature", so I'm not sure if the new 2.1 behavior is a bug or a fix. It seems a lot of people expect things to work like 2.0 did, so we may as well call it a bug. I've discussed this with some of the other developers, and we're working on a solution. In the meantime, the path is also pluggable. I imagine (though have not tried) that a plugin could be written to sort all this out.

    3 and 4. This is very much intentional. Images in WP 2.0 uploaded through WP's native image uploader are treated like a special sort of post. They have their own entry in _posts (and therefore in _postmeta). Each has its own post page for people to comment on and so forth. WP 2.1 simply brings xml-rpc uploaded images inline with images uploaded natively.

    Thanks for the feedback. Anything else causing problems?

  2. mdawaffe said on January 31, 2007:

    I should warn you first that I very rarely use XML-RPC with WordPress.

    Yes, and unfortunately that seems to be a "flaw" shared by many WordPress developers, from what I've heard. 🙂

    mdawaffe said on January 31, 2007:

    1. Unwanted thumbnails: Thumbnail generation can be turned off via plugin (there is currently no User Interface for it). I'm happy to provide more details.

    Please do. I imagine it's a simple plugin call, but I've not yet investigated it. I'm sure others would appreciate it as well.

    mdawaffe said on January 31, 2007:

    2. Upload path: If you're curious, this is the changeset that broke it. To be honest, I'm not sure if the 2.0 behavior of allowing custom paths was intentional or a "feature", so I'm not sure if the new 2.1 behavior is a bug or a fix. It seems a lot of people expect things to work like 2.0 did, so we may as well call it a bug. I've discussed this with some of the other developers, and we're working on a solution. In the meantime, the path is also pluggable. I imagine (though have not tried) that a plugin could be written to sort all this out.

    For now, I've commented out the "sanitize_file_name" call in xmlrpc.php. That seems to have solved the "path" problem, and will likely (temporarily) solve the "_" renaming issue as well.

    mdawaffe said on January 31, 2007:

    3 and 4. This is very much intentional. Images in WP 2.0 uploaded through WP's native image uploader are treated like a special sort of post. They have their own entry in _posts (and therefore in _postmeta). Each has its own post page for people to comment on and so forth. WP 2.1 simply brings xml-rpc uploaded images inline with images uploaded natively.

    Fair enough. That's not how I use images at all, and I certainly don't want comments on my images or any such thing, so for now I'll keep my nightly cron job to remove these extra "posts" and the metadata from my database(s).

    Thank you for taking the time to come here to comment. I'm certainly willing to help with more testing if you'd like to send some files, and I remain interested in hearing how to disable thumbnails via a plugin.

  3. [...] WordPress 2.1, I encountered a few problems uploading images. One of the problems was solved with a plugin that disables the creation of a thumbnail. Two others [...]


Trackback URI | Comments RSS

Leave a Reply

Please abide by the comment policy. Valid HTML includes: <blockquote><p>, <em>, <strong>, <ul>, <ol>, and <a href>. Please use the "Quote Me" functionality to quote comments.