If you ever experience the error ERR_INCOMPLETE_CHUNKED_ENCODING in WordPress (you should be able to find this in your Nginx error log) then you should check the following things:

  • Nginx and PHP-FPM should both be run as the same user
  • The directory /var/lib/nginx and all underlying directories should be chowned to that user

I my case Nginx and PHP-FPM were both running as Apache, but the directory /var/lib/nginx was owned by nginx:root. This meant the dir has to be chowned to apache:apache to fix the problem:

Don’t forget to restart nginx & php-fpm to be on the safe side.

This config is working for me including regeneration of style images after being flushed.

In case you are searching for why you can still get a 504 gateway timeout when you have already increased max_execution_time in php.ini: try adding this to your fastcgi_params file:

UPDATE: Turns out this was also happening when we were running an Nginx + HHVM server. Of course I went searching for a max_execution_time value but as far as I could tell HHVM doesn’t have that and it turned out to be this nginx timeout once again.

Just added Varnish to the config of this server and the blog should now be loading within 30ms 🙂
This is just a test post to see if cache is purged on new posts.

UPDATE: Works just fine! Now to minify css & js and add expire headers to all statics (if they aren’t set yet) in nginx.
UPDATE2: So the blog is fully minified and expire headers are being set. Varnish is running in front of it and if you’re lucky you will see response times of around 12ms 🙂

So I just ditched my previous VPS at TransIP and setup my new one at DigitalOcean since they are cheaper, faster and still have a location in Amsterdam. For the same price as TransIP I also get a backup service and a really, really nice interface to handle my server. The disk bandwidth is insane, all the way up to 340MB/s compared to my old 70MB/s max.

So far I’m very happy! Note to self on setting up nginx though, check the fastcgi_params file to make sure it looks like the block below, otherwise it won’t work:

Specifically the SCRIPT_FILENAME, otherwise you will just get white pages.

So I am busy writing an import script and had imported some 3000 products already when I decided to test a new configurable in the browser. Turns out it was giving a 404 so I decided to reindex catalog_url using the command line:

After a while I got a Magento indexer.php out of memory error which is strange because I have this server specifically setup for this import with a royal 3GB memory limit in php.ini.

So I checked out indexer.php to see what it was doing and it includes abstract.php. There, I found this function:

The first line looks for a .htaccess in the Magento root folder and proceeds to load anything starting with php_value. And guess what I found in said .htaccess file:

What the hell is that doing there, and why the frack is a shell script loading that??!?!?!
Fixed with a simple # infront of said line and my indexing proceeded without problems…