Make WordPress Core

Opened 4 years ago

Closed 2 years ago

Last modified 2 years ago

#17547 closed defect (bug) (worksforme)

Image upload issues - Size reported as 0x0

Reported by: David_Miller Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.1.2
Component: Upload Keywords: reporter-feedback
Focuses: Cc:


When I upload any image of any size to my wordpress installation the image uploads fine, but the size is reported as 0x0 and has only one option of inserting it as a full-sized image!

Further inspection of this issue has led me to believe that it lays with wordpress not inserting the correct (if any) meta data for the attachment into the database.

As you can see in the image below, the meta data is present and this image shows all options of inserting the image in the post at all sizes specified in the WordPress media settings panel.


But as you can clearly see from the image below, when the meta data is missing it shows you can't post the image at any size except full which is stated as 0x0px - Clearly something is wrong!


Many people have had and are still having this issue since 2.5. There are quite a few forum threads relating to it with not a single word from anyone from WordPress.

Several tickets have been submitted to the WordPress Trac system with the issues going unresolved. This is a major problem and many people have reported it, yet nothing seems to have been done.

Sources :






If any solution exists to this problem, please let me know, I have been searching for weeks now to no avail. When I talk about solutions, I do not mean using plugins to "regenerate thumbnails"! Yes I know this works, but it does not solve the problem as its only a temporary fix. Plus it needs to regenerate the images every time you upload a new image.

Side note :
I have tried a completely new installation of WordPress with and with out plugins on a completely different database. I have uploaded and re-uploaded the WordPress files also.

This is the type of image I am uploading. I took it on my Nikon D3100 and compressed to 80% @ 960x768 which makes it 83KB so it's not exceeding any upload limits and I am still having problems.


My host claims it is not their fault and they have recompiled apache and php for me, the php memory limit is also set to 128mb and file upload size is limited to 8mb.

A phpinfo() can be seen here : http://www.millerswebsite.co.uk/info.php

My original complaint can be seen on the forums here : http://wordpress.org/support/topic/image-upload-issues-size-reported-as-0x0?replies=10

Change History (14)

comment:1 follow-up: @kawauso4 years ago

  • Keywords needs-testing removed

Can you provide a SQL database dump of an affected site? Not too sure how to try and reproduce this otherwise.

comment:2 in reply to: ↑ 1 @David_Miller4 years ago

Replying to kawauso:

Can you provide a SQL database dump of an affected site? Not too sure how to try and reproduce this otherwise.

I got moved onto another server, it looks like it may have been down to resources. Not enough of them to process the image correctly and then the script timing out. Of course I cant test this no more as it works perfectly now I'm on a new server.

If you take a look at http://www.millerswebsite.co.uk/images/meta%20data.jpg you can see _wp_attachment_metadata had data in it, when it was messing up, that data did not exist in the table, thus showing the available sizes of the images were 0x0.

I feel that this still needs looking into further, as many people are experiencing the same issue as I did if you look through the forums.

comment:3 follow-up: @theApe4 years ago

  • Cc theApe added
  • Version changed from 3.1.2 to 3.2.1

I think it's because newer photo editing suites like Adobe Photoshop CS5 have dropped support for JFIF metadata in jpg images when saved for web. Lots of common programs are still using JFIF rather than EXIF, with EXIF being the new standard. So without JFIF the WordPress image uploader is not seeing the required data as it's not looking at or for the EXIF data. I'm not sure if this is related to WordPress or the server WordPress is running on, but is probably related to the server.

Version 1, edited 4 years ago by theApe (previous) (next) (diff)

comment:4 in reply to: ↑ 3 ; follow-up: @hakre4 years ago

Replying to theApe:

I think for the image size not JFIF nor EXIF data is processed, but the standard PHP function is used. I can't specifically say so, but just in case this should be checked.

I'm wondering if that only appears on some sites or if it reproduceable with specific images (as one of those probably added/linked in this ticket).

comment:5 follow-up: @dd324 years ago

  • Version changed from 3.2.1 to 3.1.2

The version field is to record the earliest reported version that a issue applies to (for tracking purposes). Please do not set it to the current version unless it was introduced with the latest version.

comment:6 in reply to: ↑ 5 @theApe4 years ago

Replying to dd32:
Thank you for correcting the version dd32. I didn't know that.

Last edited 4 years ago by theApe (previous) (diff)

comment:7 in reply to: ↑ 4 @theApe4 years ago

Replying to hakre:
I can reproduce the issue with the same image (save for web, Adobe CS5, jpg) on various sites on the same server (dedicated virtual), but there is no issue on an alternative shared server I have access to. So unless this becomes a wide spread issue in time this isn't a WordPress bug, but a server configuration problem?

comment:8 follow-up: @sheeptastic4 years ago

I have just experienced the same problem, but it may have a different cause so it may need a different thread. Forgive me if I'm posting in the wrong place.

The problem occurs with pictures that have special Scandinavian characters in the IPTC description field - specifically the 'ÆØÅ' characters. Whenever I would upload a picture like that, WP fails to report the size of the picture (0x0) and breaks the encoding of the special characters when it autofills the description field. When I took these characters out of the description field and reuploaded the picture, I had no problems. Tried it on a vanilla 3.2.1 install.

The picture was exported using Lightroom 3.4, which, as far as I can dig up, should export metadata in UTF8; this might be a LR problem, but in any case, there is a problem with the upload/metadata interpreter.

This is the offending picture: https://docs.google.com/leaf?id=0B6VUerM5DAaUNjI1YmFkMGYtZmRjOC00Yjc2LTlhMzktNjBkOWU1NTA3MDQy&hl=en_US

Let me know what other information would be needed to debug this problem. Hopefully someone can reproduce it with the picture above.

Last edited 4 years ago by sheeptastic (previous) (diff)

comment:9 in reply to: ↑ 8 @SergeyBiryukov4 years ago

Replying to sheeptastic:

Whenever I would upload a picture like that, WP fails to report the size of the picture (0x0) and breaks the encoding of the special characters when it autofills the description field.

Couldn't reproduce any thumbnail/size issues with your photo on my install (checked 3.2.1 and 3.3-trunk).

I could, however, reproduce the broken encoding in the description field. There's already a ticket for that: #9417, and the latest patch is still good for 3.3-trunk.

comment:10 @sheeptastic4 years ago

Thanks, excellent. I don't know why it affected the upload function then, but it works perfectly after the patch, also in the production site where I first saw the problem.

comment:11 @bigrob81813 years ago

  • Version changed from 3.1.2 to 3.4

Using wordpress 3.4-beta4-20800.
When trying to upload photos for either featured images or in the media gallery, most of the time I am getting errors. Sometimes it works, after multiple attempts.

Image data does not exist. Please re-upload the image. (after the upload browsing the file)
Operation timed out after 25000 milliseconds with 0 bytes received (during the upload)

It looks at though the upload is working properly, as using the browser uploader goes all of the way to 100% and then stalls at waiting for site.

comment:12 @helenyhou3 years ago

  • Version changed from 3.4 to 3.1.2

Version number indicates when the bug was initially introduced/reported.

comment:13 @DrewAPicture2 years ago

  • Keywords 2nd-opinion removed
  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Severity changed from critical to normal
  • Status changed from new to closed

No activity in 16 months, and I can't reproduce it. Feel free to reopen if you continue to have issues.

comment:14 @SergeyBiryukov2 years ago

  • Keywords needs-patch removed
  • Resolution changed from invalid to worksforme
Note: See TracTickets for help on using tickets.