WordPress 2.6 was released only a few days ago, so it isn’t too suprising that there are some bugs. Â But this bug seems like it would have been very easy to catch.
From my investigation, it appears that WordPress 2.6 ignores the upload preferences that I have set. Â By default WordPress likes to upload files, such as images, into a directory commonly located in /wp-content/uploads/. Â From there it creates a hierarchy based on the date you upload a piece of media.
For some reason, I had changed my preferences a while ago to be /wp-content/mobile/photos/ ((Presumably because I thought the only photos I’d uploading using WordPress would have been from my mobile phone.)). Â The only problem is now that this setting is ignored, when I want to upload a photo through WordPress’ “Add media” upload tool, it results in a broken image.
This is fairly easy to fix even while I write a post, since I’m able to edit the HTML of the post. Â However, WordPress handles each piece of media the same as it would a post to your site. Â So there is all types of data stored in the database for each media file uploaded. Â Title, description, caption, thumbnail URL, original URL, being some of the metadata that is being stored. Â Most of these I can edit through WordPress, some of them I can’t.
Take a look at my photos page. Â There is a broken image there, not because the file does not exist, but because WordPress is looking in the wrong spot. Â Unless I edit my database manually I will not be able to get that image to display properly.
I’ll do that soon, but I’m hoping someone sees this post that can address the problem for the next release.
Addendum: As db pointed out in the comments, the files are going to the correct locations. It just seems that the reference to the file, being written to the database, is in correct.
Update on July 18: As Simon points out in the comments, this is not necessarily a bug but it is unexpectedÂ behavior. Â Read his comment for details on how to fix this in your 2.6 install, but it appears it will be “taken care of” in 2.6.1.