image upload fails w/o error in FF, Chrome – posts after 5 min in IE

You may have a very slow, over burdened, over loaded server. Can’t say and not sure. Firefox in general is twice as fast as either IE or Chrome. What is your URL so that I can check?

If your host are doing some maintenance work or upgrades then this will be a temporary problem and will go away when they finish. Please do contact your host tech support and tell them too.

I had a similar problem before and the only way I solved it was by changing my hosting provider.

Hi Peter, thanks for the reply.

It’s not a busy server. We’ve worked with our hosting provider over several weeks to try to pinpoint the problem, and the most useful information that we have is that Linux can post quickly and add images successfully with no delay, but the problem is reproducible in Windows and Mac.

I don’t know your URL but you can use

https://tools.pingdom.com/fpt/

to do
1. Full page test
2. DNS Health
3. Ping and Trace Route

They will show you if there are potential bottle necks on your server side. The pingdom analysis will show up everything about your server.

Also you could use
https://sitecheck.sucuri.net/scanner/
to check if your website is infected with malware.

Another potential bottle neck is if you have spyware or malware on your PC. I am using both AVG and Spybot Search and Destroy to protect my PC.

Lastly do look at if you modem has problems – swap modem or PC.

What is in your .htacess file? Try renaming to .htaccessold and see if there is a speed difference. Some .htaccess code does clash with any cache plugin. eg ExpiresActive On, ExpiresByType image/gif …

Also remove ETags by including this in your .htaccess file

Header unset ETag
FileETag None

see https://www.askapache.com/htaccess/apache-speed-etags.html

I do not know whether any of this will help you.

Hi Peter,

WOW!! What FANTASTIC resources!! I’ll find those very useful going forward – THANKS!

For the actual issue at hand, the Pingdom tools suite and Sucuri scanner both gave the site full good health and green checkmarks.

.htaccess file was stripped down until it only had the popular, generic permalinks script recommended in many other posts for WordPress, to create pretty URLs, but the problem persisted.

The only other thing we’ve found is that even though the files and DB don’t reference it anywhere at all, if we change the real host (ourcompany.com) to point to the name of my dev server (development.com, where I use a modified hosts file to access as if it were a live site), everything works fine. We can’t find where it is getting the reference – browsers are clean and cleared, DB and files have been searched – there’s just nothing. Additionally, our marketing person has never had access to my dev environment url and does not know its name, but she also has the posting issues.

We’re giving up at this point and creating a new site, new DB, and a new dev environment that will use the same name as the site does when live.

I sure appreciate the helpful, meaningful responses. Thank you, and if I ever figure out what went wrong, I’ll post it here.

I had nearly an identical problem that you had, Deborah. I have no idea why, but when I upgraded to WordPress 3.4, I all of the sudden couldn’t upload large media files. Large being less than 10 MB.

Just like you, I wasn’t getting any errors and I disabled plugins, changed themes, etc. The difference is that I’m using Macs and didn’t have IE to actually get things to upload.

I contacted my host about it and then using developer tools in various web browsers, I somewhat got it narrowed down to an async-upload.php issue, but it turns out that it was a php.ini problem.

After about a week of looking into it and having a different issue pop up, it turned out that the post_max_size and the memory_limit were changed in the php.ini file following the upgrade.

Actually, in the midst of this issue, it got to the point where I couldn’t even make a post of just text and it turned out when I called tech support that the post_max_size was coded in megabytes when it should have been in bytes. So when it was coded at 150MB, it was seeing it as 150 bytes for some reason. I’m assuming that the memory limit was the same.

The guy I was talking to with tech support actually changed the post_max_size to the equivalent of 150 megabytes, but actually in bytes. I don’t remember the number, but it as something like 157,000,000 bytes or so if my math is close. He had to look in a PHP manual to figure that out. For some reason certain values inside the file are measured in megabytes and some not.

Either way, make sure you upload file sizes are correct as well as the post_max_size and the memory_limit and that hopefully will help.

I’m not a code guy, I have just figured out enough about files to be dangerous. My head would explode if I had to look into this stuff.

Good luck,

BRATCH

Thank you Bratch, but for me this is happening for any file, not just large files. Even a 14kb gif fails.

Hi bratch77, there is another limit on php memory size and it is on the server side. I found that out by accident when both my sites were hacked and I had move host. What I learned from that experience was that there is a default php memory size limit set by the host tech support and whatever size we define in the WordPress files will be overridden by the system limit if the system limit is smaller.

Hi deborah64554, I would be very interested in knowing how you managed to solve the problem. I will check back every so often. After my site was hacked I began questioning the performance of my old host and their horrible support. They never admitted that their server was overloaded. And again, by accident, I discovered a simple method to check if the server was overloaded. This method is not foolproof and I don’t guarantee it provides 100% accurate results. It is just a guide.

As I was backing up all my files on the old host I used to wait from anything between 35 minutes to one and a half hours for the root level .zip file backup to me made on the server. In cPanel you can back on the server and you can do a backup while downloading the backup. This was just a pure backup on the server.

When I moved to a new host it took me less than 2 minutes to do the same back up! Then I realised the if the server is too busy responding to other website requests (shared hosting) its response to my site request would be slowed.

Time how long the server takes to create a backup. I estimated from the response of my new host, that it takes about 35 seconds per 100MB of .zip file created. One of my websites was about 220MB and it took just over a minute to create a .zip backup. So if you give your host server some extra time due to peak demand, … high activity on the server …etc, when you are doing the backup up, anything less than 2 minutes per 100MB should be a good figure. I do not know if others will consider 2 minutes per 100MB too slow. My new host creates back at about 35 seconds to 60 seconds per 100MB.

It turns out this entire issue was caused by load balancers on our RackSpace servers.

marking this as resolved :]