Take the 2-minute tour ×
WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.

Sometimes when I upload a picture (either with flash or browser uploader), I get a message like (this was with a 1.46MB jpg):

Fatal error: Out of memory (allocated 69206016) (tried to allocate 4000 bytes) in /home/ab64489/public_html/wp-includes/media.php on line 254

I am on a shared host, but the max upload size is 64MB. I've tried uploading other files (I made a zip of some random files, with the archive totaling ~58.1MB, and it uploads and crunches with no problem, so it's not the file size). It also seems that the upload works fine, but when it tries to crunch, then it encounters the error.

I've seen similar problems here and on other sites with no real solutions.

What could be the cause of this issue?

share|improve this question
    
If the problem occurs every time you try to upload a specific picture, then check the resolution of the image. Try reducing the resolution and see if the problem persist. –  SKCSK Nathan Mar 3 '12 at 23:11

2 Answers 2

up vote 1 down vote accepted

This isn't a Wordpress problem. There's no telling on a shared environment what the culprit might be. You probably don't have access to your php.ini config, nor do we know how many websites your hosting company has jammed on your server.

The very nature of a shared server is that each client shares the resources of that one server. If one website is using massive amounts of resources while you're trying to upload your image, that would certainly affect it.

The only real fix to this is getting onto a more controllable environment. I gave up on shared hosting a long time ago and went with a cloud server from Rackspace. I am in complete control and I don't have to worry about other memory hogs on the same box.

share|improve this answer

My solution (in wordpress 3.3.1) was to do the image compression myself, then add a single entry to the metadata table in the DB.

For the image compression, I noted the other correctly compressed files were all compressed to three consistent sizes: 150x150, Mx300, and Nx1024, where M and N would maintain the ratio of the original image.

In the metadata table, there was already an entry for my newly created post. Sort by post_id and then look for the entry with your post_id and meta_key = _wp_attached_file to make sure yours is there.

My corresponding row has meta_value = 2012/04/get_in_shape.png.

Now the fun part! Find a row (from a post which had its image correctly compressed) with meta_key = _wp_attachment_metadata and use its value of meta_value as a template for your new row.

In your new row, the values should be

`meta_id`  (null)  as it's an AUTOINCREMENT field
`post_id`  (your post id)
`meta_key` _wp_attachment_metadata
`meta_value`  (as below)

The following is a serialize()ed string with the data that worked for me for meta_value. It will not work for you without tweaks. If you can do all the above, you can certainly do the tweaks as well.

a:6:{s:5:"width";s:4:"3321";s:6:"height";s:4:"4153";s:14:"hwstring_small";s:22:"height='96' width='67'";s:4:"file";s:24:"2012/03/get_in_shape.png";s:5:"sizes";a:3:{s:9:"thumbnail";a:3:{s:4:"file";s:24:"get_in_shape-150x150.png";s:5:"width";s:3:"150";s:6:"height";s:3:"150";}s:6:"medium";a:3:{s:4:"file";s:24:"get_in_shape-240x300.png";s:5:"width";s:3:"212";s:6:"height";s:3:"300";}s:5:"large";a:3:{s:4:"file";s:25:"get_in_shape-819x1024.png";s:5:"width";s:3:"724";s:6:"height";s:4:"1024";}}s:10:"image_meta";a:10:{s:8:"aperture";s:1:"0";s:6:"credit";s:0:"";s:6:"camera";s:0:"";s:7:"caption";s:0:"";s:17:"created_timestamp";s:1:"0";s:9:"copyright";s:0:"";s:12:"focal_length";s:1:"0";s:3:"iso";s:1:"0";s:13:"shutter_speed";s:1:"0";s:5:"title";s:0:"";}}

See the path looking thing 2012/04/get_in_shape.png? That's the path to your file (with wp-content as its understood prefix). Note it's preceded by s:24 which is the string length of the value. Change the path to match your file, then change the 24 to match the length of the path you used.

Do that for each of the file sizes, save the new record, and you're golden.

DO NOT TRY THIS if you have little/no idea how to do it. Just sayin' there is a cheaper(*) method than moving to a new host.

(*) if learning all this in uni is considered cheap.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.