Sorry if I’m missing something, but what is the exact error message that you’re seeing?
Also, what is the size of the file you’re trying to upload and what are the values in your phpinfo() page for upload_max_filesize and post_max_size?
This link is a for a screenshot of the error.
http://pasteboard.co/13YotXlJ.png
- upload_max_filesize 2M
- post_max_size 8M
The item I attempted to upload for that screenshot has the following properties:
- Size – 177 KB (181,808 bytes)
- Size on disk – 180 KB (184,320 bytes)
- Height – 1920
- Width – 1080
shoot, I was afraid that was the error message since it seems to be a catch-all error that isn’t easy to debug.
A few ideas:
– Do you get the same error if you attempt to upload a pdf? If no, looking at your phpinfo() page again, is GD or Imagick installed and enabled?
– Do you get the same error if you use the “browser uploader” (/wp-admin/media-new.php?browser-uploader) as well?
– if you recently installed or upgraded WordPress it might be worth a try to re-install the WordPress core files (everything except wp-content) in case there was a problem with the install/upgrade.
– Does the response from the upload’s ajax request (use your browser’s developer tools i.e. chrome’s) give a clue of what is causing the error?
Aight here goes.
I am a system admin by day – but not an Apache admin by any means. I’m looking at that browser error… Found it in the combined log searching 500.
# Time Message
1 10/02/2015
08:46:24.000
108.162.237.114 - - [02/Oct/2015:12:46:24 +0000] "POST /wp-admin/async-upload.php HTTP/1.1" 500 799 "http://duvrazh.net/wp-admin/upload.php" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36"
Host: duvrazh.net Name: /var/www/duvrazh.net/logs/combined.log Category: Apache_duvrazh.net
I use Sumo to collect and search logs so I did a +/- 1 minute – http://pastebin.com/hNd3MKh1 – nothing stands out of these at me. Do GD and ImageMagick conflict when jpg support is enabled on both modules?
I know this goes against best practices but I’m going to go ahead and leave my phpinfo() in place – you’ll be able to take a look if it will assist. http://www.duvrazh.net/phpinfo.php
Thank you for your assistance jkovis.
Thank you for the additional information, to answer your question
Do GD and ImageMagick conflict when jpg support is enabled on both modules?
– My understanding is that WordPress will test for a set of ImageMagick functions it needs and if they’re not present then use GD. Everything you’re running is new enough that I don’t see that as being the cause of the problem.
If you haven’t already, you can try disabling all plugins and if uploading then works start enabling them one by one to see which one is causing the conflict.
Next, I’d recommend you add the following code to the top of your wp-config.php file, try uploading a couple more times, and then examine wp-content/debug.log to see if WordPress logs any errors to that file:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
Finally if that doesn’t work, you can also try to debug the upload script itself (wp-admin/async-upload.php) by adding code the following, trying an upload, and then checking wp-content/debug.log to see if any errors are being thrown:
$log = print_r( array(
'file' => __FILE__ . 'on line ' . __LINE__,
'request' => $_REQUEST,
'foo' => $bar
), true );
error_log( $log );
That’s a step up on the involvement required since I don’t have those logs being collected by Sumo. I’ll run those tests once I automated turning on debug mode with a bash script.
Thanks for the next step. I’ll post results this afternoon.
All that work for nothing. I made a couple extra files in ~ and made some aliases to put a site into debug and you know what?
0 -rw-r–r– 1 www-data www-data 0 Oct 2 18:04 debug.log
I had to touch the file… one didn’t create on it’s own. Either no errors are being thrown or the debug flag isn’t doing anything. My aliases modified both files btw.
I did a find debug.log from the site’s root directory but no joy. I’m thoroughly confused. These were all fantastic suggestions so far, I was certain this would unearth some kind of a clue.
That is strange and I’m not sure what else I could suggest to try to narrow down the cause. Sorry I couldn’t be of more help, but best of luck.
BUMP
Can anyone else offer any insight here please?
I figured it out. If you’ve configured your server, Debian Jessie in my case, to pipe php into FastCGI for multithreaded Nginx-esque speed, there is a FastCGI default value of 128kb for max post length.
This is insanely under-documented. Add the FcgidMaxRequestLen and desired value in bytes to your fastcgi.conf in /etc/apache2/mods-available like the following.
<IfModule mod_fcgid.c>
FcgidMaxRequestLen 26214400
FcgidConnectTimeout 60
</IfModule>
26214400 = 25 MB
8388608 = 8 MB
1048576 = 1 MB (for easy multiplication)