PHP block in nginx with fastcgi_cache

WordPress Nginx
#1

In the fastcgi + nginx tutorial, the block for PHP is:

  
location ~ .php$ {  
		try_files $uri /index.php;   
		include fastcgi_params;  
		fastcgi_pass unix:/tmp/php-fpm.sock;  

		fastcgi_cache_bypass $skip_cache;  
	        fastcgi_no_cache $skip_cache;  

		fastcgi_cache WORDPRESS;  
		fastcgi_cache_valid  60m;  
	}

However, I get blank pages when I do that. In instead of this code, I’m then using something similar to the one in Wordpress Codex Nginx:

location ~ \.php$ {  
	# Zero-day exploit defense.  
	# http://forum.nginx.org/read.php?2,88845,page=3  
	# Won't work properly (404 error) if the file is not stored on this server, which is entirely possible with php-fpm/php-fcgi.  
	# Comment the 'try_files' line out if you set up php-fpm/php-fcgi on another machine.  And then cross your fingers that you won't get hacked.  
	try_files $uri =404;  

	fastcgi_split_path_info ^(.+\.php)(/.+)$;  
	#NOTE: You should have "cgi.fix_pathinfo = 0;" in php.ini  

	include fastcgi_params;  
	fastcgi_index index.php;  
	fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;  
	fastcgi_pass unix:/tmp/php-fpm.sock;  

	fastcgi_cache WORDPRESS;  
	fastcgi_cache_valid  30d;  
    }

This is the only way I found out to avoid blank pages and fastcgi_cache seems to be working. The question is: Am I doing a good thing or the change I was forced to do in the code has any negative point?

Thanks.

#2

You just need to update:

try_files $uri /index.php;

To

try_files $uri =404;.

Both of above prevents that so-called “zero-day” exploit!

Major part of Nginx page on WordPress Codex is written by me only. I wanted to replace /index.php with =404 for performance reason in each of our tutorials as well.

Finally, there is nothing wrong if you keep either block of codes. Both are safe.

#3

Hello Rahul,

The code I’m already using is:

try_files $uri =404;

But your tutorial suggests:

try_files $uri /index.php;

I couldn’t understand your last message. Do I have to keep “404” or may I change it to index.php, according to your tutorial?

P.S: I did some changes into your code to make it work with my mobile theme. I did it successfully. Thing is, though, the cache is only cleaned automatically for the desktop theme. In order to also clean it for the mobile version, I have to add a “1” at the end of the URL. I need to clean both http://mysite.com/url/ and http://mysite.com/url/1

I tried changing this (in purge.php file):

$this->purgeUrl( $homepage_url ); // Clears the homepage.

To this:

  
$this->purgeUrl( $homepage_url ); // Clears the homepage (for desktop).  
$this->purgeUrl( $homepage_url ) . "1"; //Clears the homepage (for mobile).

I repeated it similarly for taxonomies, single post, etc, but had no success in the automatically purge (but the manual purge works as expected, which proves that the nginx configuration is okay). As the plugin is written by you, do you have any idea about what can be wrong? Or have any suggestion for me?

Thanks.

#4
I couldn’t understand your last message. Do I have to keep “404″ or may I change it to index.php, according to your tutorial?

Both will work. Use 404. I did not get time to update tutorials but we use “404” everywhere.

Regarding purging different versions, it is going to be tricky. As of now we simply purge entire cache if there is some critical change.

You can modify nginx-helper plugin to purge multiple version by setting up different user-agent string.

#5

What is value of fastcgi_cache_key that you are using?

#6

$scheme$request_method$host$request_uri$mobile";

If a mobile device is detected, $mobile is set to 1. If it is a desktop, nothing is done with $mobile, than it keeps a null value.

#7

Looks nice. :slight_smile:

Can you check if manual purge is working by:

http://mysite.com/purge/url/ and http://mysite.com/purge/url/1/

Before purging make sure you have cached both versions.

#8

Hello Rahul!

I checked it. Yes, manual purge is working for both pages http://mysite.com/purge/url/ and http://mysite.com/purge/url/1 (there’s no “/” after 1).

#9

I think when you are trying to purge http://mysite.com/purge/url/1 , there might be internal rediect to http://mysite.com/purge/url/1/

Can you try debugging on this line?

#10

Hello Rahul,

I don’t think it is a redirect as if I purge manually with the last “/” I get 404 Not Found. The variable $mobile is just being used to add a a “1” at the end of the URL, not a “/”. Also, when I try opening http://mysite.com/posturl/1 (without “purge” in the middle and withour the “/” at the end), I can view the mobile content.

Is the line $this->purgePost( $_post_id ) . “1”; correct? I don’t have experience with PHP. I tried to modify the plugin adding the code as I mentioned before, but I don’t know if I did it in the right way.

#11

UPDATE: I’ve edited the plugin code, duplicating the necessary lines according to what I suggested in the other posts. Worked. :slight_smile:

#12

@igid26

Sorry for delayed reply. Please make sure you maintain copy of your changes locally.

There is a pull-request for nginx-helper there - https://github.com/rtCamp/nginx-helper/pull/56

This means on next update your changes might get lost. :expressionless:

We will add option to purge multiple variations of page someday in nginx-helper.

Idea is to provide a textbox where people will add suffixes and then nginx-helper with just append url + suffix and create a purge request for each suffix.

#13