I've been filtering through google to try to find an answer to this, but I still can't find one that fixes my issue. I have migrated a website to a new server. The framework is Symfony 2.8 on php5.6 using Nginx and PHP-FPM.
Here is a screenshot of the config.php page.
To resolve this, i've tried...
Changing the user for Nginx and php-fpm to both the user I log in with and Nginx, both didn't work
I've opened up the privileges on the cache and log folder to 777 within the app folder, and that didn't work, nope.
I've tried assigning the cache and logs folder to nginx:nginx, no go.
I've manually assigned app.php, app_dev.php, and the console file to have the umask(0000) and umask(0002), nope.
Restarted the Nginx service and php-fpm service after each change, nodda.
I've restarted the entire server thinking something might be stuck, but you guessed it. No!
That leaves me here. I've gone through everything that I can think of and it baffles me that Symfony still won't recognize the directory as writable. It seems like the most simple thing, but... nope.
Anything will help, please pass anything along.
After countless hours of research and scraping the internet for details, I have found the answer! I'm posting it here in case someone else is having the same issue... and hopefully I can save them some time. This took up two days of my life that i'll never get back.
For whatever reason, SELinux was causing this error. I came across this issue on superuser stack exchange, and it told me to temporarily disable SELinux to test. After running sudo setenforce 0 everything came back up. I then completely disabled it and everything has been working fine since.
This happened suddenly and i'm still unsure of the reason. The site worked for about a week before this was triggered.
You should read this to setup you directories permissions http://symfony.com/doc/current/setup/file_permissions.html
I always go for the point 3. with Debian/Apache, Unfortunately i never tried it with nginx.
Some albums do not load using koken and I get this error INCOMPLETE_CHUNKED_ENCODING on Chrome. I'm using nginx 1.6.2, CentOS 7, Koken 0.22.4. I'm using graphicsMagick 1.3.23, ImageMagick 6.9.2, PHP 5.6.21 and MySQL 5.1.73.
Related issue
After checking some related issues about INCOMPLETE_CHUNKED_ENCODING like:
This on the apache help blog
Another one here
And finally this one
I solved it by changing the permissions on my /opt/nginx directory to the nginx user. It may be related with the last referenced post.
when you give a response too big for Nginx, it uses this directory to
write as a working directory for temporary files. If the worker
process cannot access it, Nginx will terminate the transmission before
it completes, thus the error INCOMPLETE_CHUNKED_ENCODING.
I have used WordPress on Cloud9 successfully previously, but I can't even get a new one to start via JetBrains IDE.
I have two machines: one Windows (XAMPP) and one Mac (MAMP) and getting the same "502 Bad Gateway" error when the browser tries to login to the WordPress dashboard page.
I downloaded a fresh WordPress copy, set up my database and ran index.php in the WordPress root folder. That does take me through the database questionary and up to the WordPress login page, and then the browser hangs there. It tries to load something and nothing happens. If I halt the browser and refresh, I'll get the 502 error and I'll keep getting this error on ANY OTHER files that I try to run from now on (it feels like something server-related breaks from within the IDE and I have to restart it).
The PHP 7 interpreter seems to be working fine, because I don't have an issue running any other of my non-WordPress projects.
The project address is http://localhost:63342/wordpress/, but I noticed this below link is shown in the PHP-CGI server window:
/Applications/MAMP/bin/php/php7.0.0/bin/php-cgi -e -b 127.0.0.1:56502
Does this PHP CGI pointing to a different port number mean anything? I am new to WordPress and it was a breeze starting one in Cloud9, but I just don't understand why it doesn't work in PhpStorm 10.
As I said, there is the same problem on two machines (Windows, Mac, MAMP, XAMMP, and PhpStorm), so I know it is me who's missing something here.
I recommend you use Varying Vagrant Vagrants WordPress (VVV).
It's a better solution and will help you achieve better results without too much hassle.
I would recommend you to use a simple editor like Sublime Text or Atom and install packages. I have personally lost many hours trying to get PhpStorm, MAMP, LAMP, and XAMPP work the way they should.
I managed to solve my problem. It was the port number causing it to crash. My MAMP port number is 8888 (XAMPP is 80) and when I set up PhpStorm a year ago on both machines somehow I entered 63342 as server port number!
This never created any problem for me whatsoever running dozens of PHP projects since then, but obviously, it mattered to WordPress (dashboard). I went to PhpStorm settings and corrected the port number so it matches MAMP/XAMPP and all is working fine now.
It was a pretty basic (and silly) mistake to make on my part, but that wasted two full days in which I could have been teaching myself WordPress and developing themes/plugins.
Yes, it worked for me after configuring the built-in server port to 80 (I have used XAMPP)
Setting steps in phpstrom: Configure the built-in web server
I want to simply POST and PUT image files to a server test.com, using apache2. This should result in storing the image file at the desired location. Lets say /srv/web/images/
What would be a working vhost configuration? Are there any modules that need to be activated? I am using apache2 on an ubuntu 12.04 server.
I think by default this is disabled in apache for obvious resons, nobdoy should be able to write to a server in the default configuration.
I want to simply secure it with http auth ("user1" / "pass1").
All the documentation and questions I find deal with PHP, but I thought should be possible using simply a REST URI and apache2 without PHP or cgi or a C program.
(Note: I am interessted in a solution without webdav (but I am not sure if the webdav module supports HTTP PUT which would be OK). And this question has got nothing to with forms or browsers, As an example the upload could use the program curl.)
Update: I found this message:
http://mail-archives.apache.org/mod_mbox/ant-ivy-user/201004.mbox/%3C4BBCA487.8000401#nitido.com%3E
It seems there once was a module mod_put, which is no longer in the repos of ubuntu. And that webdav has built in the functionality of PUT and DELETE.
If so, I am still unable to understand how to do the right VHOST configuration for simple FILE PUT operations.
I think nowadays for this kind of stuff you configure apache with WebDAV.
I'm running WP 3.0.1 on a shared host using PHP5. I'm having issues uploading files that are a little larger via the media uploader in the admin section of WP.
Every time I try to upload a file thats over a few megabytes, it uploads, says its crunching, then gives me a big red "HTTP Error." - nothing more.
This only happens on files that are a little larger - ie a 20mb .mp3 file. A 5mb file seems to work fine. Whats weird is in the past we've uploaded 40mb files without a problem.
--
Here's the steps I've taken so far to try and remedy the situation:
Double checked php.ini to ensure increase upload, post and memory size were high enough.
Updated .htaccess to include filter the security mod I found elsewhere.
Double checked all file permissions via ftp to ensure they were 755.
Called the host - "They don't support 3rd party scripts" (I hate IPower)
Tried with different audio files of similar size.
Disabled all plugins
--
Do you guys have any more ideas regarding what might be causing the vague "HTTP Error." problem?
Thanks in advance.
I had a similar problem with Nginx and PHP5-FPM (and WordPress 4.1).
Symptoms: the file (< 5MB, so relatively small) is partway through the transfer, as indicated by the progress bar, when suddenly you get the HTTP error message.
Even if you've set upload_max_filesize in your php.ini, you should also check post_max_size is (at least) as big. Remember to restart php5-fpm.
If it still doesn't work, edit your nginx.conf file (in Debian/Ubuntu it's /etc/nginx/nginx.conf) and add this in the http block:
client_max_body_size 100m;
Then restart Nginx.
One of our clients, had the same issue.
Finally we found out that the wordpress "HTTP Error" when uploading images, was happening due to a change on the server side. The hosting comany, decided to add APC accelerate to the server in order to increase server's stability and speed. APC accelerate should work only with FastCGI and not with su, so they set PHP to run as FastCGI.
When using PHP as FastCGI, if you try to upload a file larger than 128KB, an error "mod_fcgid: HTTP request length 131388 (so far) exceeds MaxRequestLen (131072)" occurs and causes an 550 internal server error.
This happens because the value of MaxRequestLen directive is set to 131072 bytes (128KB) by default.
One way to correct this (if server uses Plesk), is to edit /etc/httpd/conf.d/fcgid.conf and set MaxRequestLen to a higher value, for example 15MB (MaxRequestLen 15728640).
If server uses cPanel, this change can be done via the WHM of the server.
So, if you can upload images up to 128KB, this is the solution to your problem.
Put this line in your wp-config file:
define('WP_MEMORY_LIMIT', '64M');
The problem, as you've already inferred, is in the size of your file upload. Just to remind you, HTTP isn't really built for transferring large files ... it can do it, but not always, and not very well. You're running into an issue where your host is cutting off the transfer because the file is too large. It's most likely a server setting somewhere that you don't have access to.
Since "they don't support 3rd party scripts" I'm guessing you're in a shared hosting environment, which is why something could change on your server without you doing anything. Possible solutions:
Get a different host
Use a dedicated server
Transfer your larger files via FTP rather than from within WordPress.
I had the same issue whenever I tried to upload media, except I got the "HTTP Error" on files larger than 124Kb! WP 3.3.1, PHP 5.2.
I called my host and they upped memory to 64M (also changed this in wp-config) and upload_limit to 8 MB (default was 2 MB). This didn't work so I resorted to almost everything else, from tampering with the .htaccess to reinstalling WP to installing a fresh WP on another server, but everything pointed to a server issue. I called the host again and spoke to another technician who increased the allowed HTTP Request Length setting.
For future readers, just managed to find the solution to this one after a tough day of searching.
There's a setting in the fcgid.conf file (for me in /etc/apache2/mods-enabled): FcgidMaxRequestLen. See https://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html#fcgidmaxrequestlen
I set that in bytes to an appropriate length and everything works. It seems that apache have changed their thinking on the default value (which is now 131072 bytes):
Before 2.3.6, this defaulted to 1GB. Most users of earlier versions should use this directive to set a more reasonable limit.
server maybe have imagick installed as default library , for a fix for wordpress
I put the following code into my functions.php file. It works!
add_filter( 'wp_image_editors', 'change_graphic_lib' );
function change_graphic_lib($array) {
return array( 'WP_Image_Editor_GD', 'WP_Image_Editor_Imagick' );
}
For me, "http error" issue occurred when php is running in fast cgi mode.
"MaxRequestLen" from mod_fcgid was limiting file upload size and wordpress was throwing "http error".
You need to add the following configurations in your httpd.conf (apache2.conf on ubuntu 14) :
<IfModule mod_fcgid.c>
# 20MB
MaxRequestLen 20000000
</IfModule>
I tried all the commonly suggested php.ini changes as well as wp-config changes with no luck. Finally found someone suggesting to look at the XHR async-upload.php details in my browser and found out that our firewall was flagging the upload as a trojan (MalAgent.H_9218 to be specific) for some reason. So don't forget to check there, it could identify other possible upload issues as well.
Chrome instructions:
Hit F12 and select the network tab, then attempt an upload with WordPress, make sure the filter row is on either All or XHR, in the left bottom pane find and select async-upload.php, in the right bottom pane select preview.
In my case solved by switching off Adblocker extention in browser
Our problem was that our load balancer ran out of hard disk space. Be sure to setup a log rotation that deletes the oldest logs after a period.
Our problem actually was client side: people tried to upload via drag and drop from OneDrive, files that have not been locally synchronised but showed up in the OneDrive folder. Resulted in "-200" error message. If file is on local harddrive, it worked fine.