nginx php-fpm PHP APC WordPress multisite (subdirectory) WP Super Cache

any chance of the global/wordpress-ms-subdir.conf for sub domains?

please please please !

Johnny

@johnnymestizo – If you could copy and paste both the WP and WP Super Cache rules from an Apache .htaccess file, I’ll give it a whirl. I don’t have any subdomain installs of WP multisite but I know nginx pretty well.

Here is my WordPress multi-site with sub-domains conf. I have adapted everything above and only changed the global/wordpress-ms-subdir.conf and obviously renamed it at will. I’ve added a couple of things to make it work with 3.1 as images started failing for me when I updated to it as well as a few suggestions from various sources. Truly feedback is always welcome.

# WordPress multisite sub-domain rules.
# Designed to be included in any server {} block.

error_page 404 = @wordpress;
log_not_found off;

# This order might seem weird - this is attempted to match last if rules below fail.
# https://wiki.nginx.org/HttpCoreModule
location / {
	try_files $uri $uri/ /index.php?$args;
}

# Add trailing slash to */wp-admin requests.
rewrite /wp-admin$ $scheme://$host$uri/ permanent;

# Directives to send expires headers and turn off 404 error logging.
location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
	expires 24h;
	log_not_found off;
}

# Pass uploaded files to wp-includes/ms-files.php.
rewrite /files/$ /index.php last;

# For multisite:  Use a caching plugin/script that creates symlinks to the correct subdirectory structure to get some performance gains.
set $cachetest "$document_root/wp-content/cache/ms-filemap/${host}${uri}";
if ($uri ~ /$) {
	set $cachetest "";
}
if (-f $cachetest) {
	# Rewrites the URI and stops rewrite processing so it doesn't start over and attempt to pass it to the next rule.
	rewrite ^ /wp-content/cache/ms-filemap/${host}${uri} break;
}

location ^~ /files/ {
	rewrite ^.*/files/(.+)$ /wp-includes/ms-files.php?file=$1 last;
}

# Uncomment one of the lines below for the appropriate caching plugin (if used).
#include global/wordpress-ms-subdir-wp-super-cache.conf;
# include global/wordpress-ms-subdir-w3-total-cache.conf;

# Rewrite multisite '.../wp-.*' and '.../*.php'.
if (!-e $request_filename) {
	rewrite ^/[_0-9a-zA-Z-]+(/wp-.*) $1 last;
	rewrite ^/[_0-9a-zA-Z-]+(/.*\.php)$ $1 last;
}

location @wordpress {
    fastcgi_pass php;
    fastcgi_param SCRIPT_FILENAME $document_root/index.php;
    include fastcgi_params;
    fastcgi_param SCRIPT_NAME /index.php;
}

# Pass all .php files onto a php-fpm/php-fcgi server.
location ~ \.php$ {
	# Zero-day exploit defense.
	# https://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 @wordpress;

	#fastcgi_split_path_info ^(.+\.php)(/.+)$;
	fastcgi_index index.php;
	fastcgi_pass php;
	fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
#	fastcgi_intercept_errors on;
	include fastcgi_params;
}

location ^~ /blogs.dir/ {
      internal;
      root /var/www/nginx-default/wp3/wp-content;
}

@hybridindie – It looks like subdomain is very similar to subdirectory. I do have a few comments though. By dropping a ‘root’ into the configuration, your configuration isn’t generic.

I’m not sure why fastcgi_split_path_info got commented out and WP doesn’t really utilize that approach anyway, so it probably doesn’t hurt anything.

Redirecting all 404 errors to WP is probably not a good idea. Invoking the WP engine is a resource utilization cost that should be avoided. I’m thinking you might be missing a rewrite somewhere that could eliminate the 404 handler altogether and revert the exploit defense mechanism back to “try_files $uri =404;”

I’m starting the 3.1 upgrade process myself, so I’ll post an updated config for subdirectory when I’m done.

Here is the configuration for multisite subdirectory I’m using for my 3.1 installation:

# WordPress multisite subdirectory rules.
# Designed to be included in any server {} block.

# This order might seem weird - this is attempted to match last if rules below fail.
# https://wiki.nginx.org/HttpCoreModule
location / {
	try_files $uri $uri/ /index.php?$args;
}

# Add trailing slash to */wp-admin requests.
rewrite /wp-admin$ $scheme://$host$uri/ permanent;

# Directives to send expires headers and turn off 404 error logging.
location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
	expires 24h;
	log_not_found off;
}

# Pass uploaded files to wp-includes/ms-files.php.
rewrite /files/$ /index.php last;

# For multisite:  Use a caching plugin that creates symlinks to the correct subdirectory structure to get some performance gains.
set $cachetest "$document_root/wp-content/cache/ms-filemap/${host}${uri}";
if ($uri ~ /$) {
	set $cachetest "";
}
if (-f $cachetest) {
	# Rewrites the URI and stops rewrite processing so it doesn't start over and attempt to pass it to the next rule.
	rewrite ^ /wp-content/cache/ms-filemap/${host}${uri} break;
}

if ($uri !~ wp-content/plugins) {
	rewrite /files/(.+)$ /wp-includes/ms-files.php?file=$1 last;
}

# Uncomment one of the lines below for the appropriate caching plugin (if used).
include global/wordpress-ms-subdir-wp-super-cache.conf;
# include global/wordpress-ms-subdir-w3-total-cache.conf;

# Rewrite multisite '.../wp-.*' and '.../*.php'.
if (!-e $request_filename) {
	rewrite ^/[_0-9a-zA-Z-]+(/wp-.*) $1 last;
	rewrite ^/[_0-9a-zA-Z-]+.*(/wp-admin/.*\.php)$ $1 last;
	rewrite ^/[_0-9a-zA-Z-]+(/.*\.php)$ $1 last;
}

# Pass all .php files onto a php-fpm/php-fcgi server.
location ~ \.php$ {
	# Zero-day exploit defense.
	# https://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)(/.+)$;
	include fastcgi_params;
	fastcgi_index index.php;
	fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
#	fastcgi_intercept_errors on;
	fastcgi_pass php;
}

Note the one extra rule. And, since I’ve been all over the place with changes, here is nginx.conf:

# Generic startup file.
user user {user} {group};
worker_processes  2;

error_log  /var/log/nginx/error.log;
pid        /var/run/nginx.pid;

# Keeps the logs free of messages about not being able to bind().
daemon     off;

events {
	worker_connections  1024;
}

http {
#	rewrite_log on;

	include mime.types;
	default_type       application/octet-stream;
	access_log         /var/log/nginx/access.log;
	sendfile           on;
#	tcp_nopush         on;
	keepalive_timeout  3;
#	tcp_nodelay        on;
#	gzip               on;
	client_max_body_size 13m;
	index              index.php index.html index.htm;

	# Upstream to abstract backend connection(s) for PHP.
	upstream php {
		server unix:/tmp/php-fpm.sock;
#		server 127.0.0.1:9000;
	}

	include sites-enabled/*;
}

And then in ‘sites-enabled’ is a symlink to each file in ‘sites-available’ as discussed at the top of this post. Then, in ‘sites-available/mysite.com.conf’:

server {
	server_name *.mysite.com;
	root /var/www/mysite.com;

	if ($http_host != "mysite.com") {
		rewrite ^ https://mysite.com$request_uri permanent;
	}

	include global/restrictions.conf;

	// Additional rules go here.

	include global/wordpress-ms-subdir.conf;
}

I haven’t changed the other files.

For subdomain, I’d start with subdirectory rules above and then tweak using rewrites in the ‘if (!-e $request_filename) { … }’ block and base the rewrites on the .htaccess Apache rules. This approach will work a lot better than redirecting everything to WP.

Hi Guys,

This is absolutely great stuff! I’m in way over my head, but thanks to some a lot of help from my host, I’ve now set up a WordPress MultiSite install powered by NGinx.

I’m doing this because I’m starting up a international non-profit social network for people with Cystic Fibrosis. Since the project is powered by WP Multisite + BuddyPress, things will probably get pretty heavy ,pretty soon. I figured that to keep costs low, I should REALLY think about setting up a decent infrastructure. After a lot of reading this seemed like the best solution, and I’ve taken the plunge!

Server setup was handled by my host, but we got stuck at the permalinks and multisite configuration, so I and ended up here.

After reading your detailed posts (Bigsite) I would like to ask you if you were interested in helping me out with the basic setup for NGINX and maybe HyperDB for the site? I realize this is not an easy task, and I’m willing to compensate you for it! but this is such an important aspect of my project, I would like to have it set up right.

If you’re not able to help me with this, that’s perfectly fine as well (this thread itself is a great starter) but I just thought I’d ask ??

@bowe – I’ve only had experience with migrating an existing WP site from Apache to nginx. nginx isn’t for the feint of heart. I have no experience with HyperDB – although I suspect that is my next upgrade of the site I work with.

I’ve discovered through my own adventures is that most people will get a ton more mileage out of using PHP APC and WP Super Cache together than using an alternative web server like nginx. After using PHP APC and WP Super Cache, I’d start playing with CDNs and scaling the database infrastructure to share the load with other computers. There’s only so much one machine can do.

If your problem with permalinks is short, feel free to post the specifics here as I could have missed something important in my config. Otherwise, use pastebin.com and copy your nginx configuration files there and then talk to the people on the nginx IRC channel.

The IRC channel for nginx is very active. The good folks there kindly look at nginx configurations all day long and help fix problems. One of the regulars there runs a few WP sites with nginx.

Nice write up bigsite.

I have a little mixture of questions:
1. What is the importance of adding a trailing slash to wp-admin requests?
2. What is the relationship between rewrite /files/$ /index.php last;
and rewrite /files/(.+)$ /wp-includes/ms-files.php?file=$1 last;
3. I use just rewrite ^.*/files/(.*) /wp-includes/ms-files.php?file=$1;
Is that better/worse/same?

There is no mention of fastcgi-caching in your configs, which possibly a reason why you are not seeing as much of a performance hike as you were hoping for, as it can be comparable to supercache.

Thanks for this great post. It could be a good idea if you add it to github or something like that :P.

Now multisite it’s working, except for the “main site”… For example: I’m developing local so to access the install I’m using https://wp/.

I created a new site on the network, so I can navigate without problems in https://wp/test, but if I try to enter https://wp, I just see a blank page (access and error logs doesn’t show anything special). I still can enter the admin dashboard through https://wp/wp-admin.

I don’t understand why this is happening or where should I look to find the problem. Can you help me?

or if someone wants to write this up for the codex that woudl be super fantastic. everyone with the ability to post in the forum can add it to the codex with the same login info.

Don’t worry about formatting or getting it “right”, someone else will clean it up if needed.

I create the Nginx page on the Codex, I hope it doesn’t bother you.

https://codex.www.ads-software.com/Nginx

Thanks again.

@bigsite: Thanks a lot for the tips and pointers! As a theme developer and designer I do know quite a lot about CDNs and caching/optimization. I did not know that the NGINX performance gain isn’t thatimpressive comparing it to Apache.

I’m currently moving hosts and waiting for the domains to be moved, but when that’s done I’ll dive into the Nginx configuration with my host.

Your steps look clear enough.. two questions though (If I may :-))

1: Is there a reason why you chose Super Cache over W3 Total Cache? I thought the later was better, but if you have a fully working Super Cache setup with Nginx I might go for Super Cache

2: How have you set up your CDN? Do you use W3 Total Cache for that, or a different plugin? And does that also need rewrites to work? (since .htaccess does not work on NGinx).

Finally; Maybe hybridindie can chip in about his Subdomains config file, and tell us if it does what it’s supposed to do :-). If we get that setup working, it would be nice to add it to the codex page as well.

Without this thread I would probably be lost ??

Now multisite it’s working, except for the “main site”… For example: I’m developing local so to access the install I’m using https://wp/.

Try https://wp.tld. It works for localhost but there logic in the blog lookup to handle that.

@graq – To answer your questions – I merely ported the rules from .htaccess that were generated by WordPress and WP Super Cache.

1. What is the importance of adding a trailing slash to wp-admin requests?

Mostly to point the user at the right location. I’m sure some code breaks if wp-admin without a trailing slash is passed into the WP codebase.

2. What is the relationship between rewrite /files/$ /index.php last;
and rewrite /files/(.+)$ /wp-includes/ms-files.php?file=$1 last;

The first rule checks to see if the directory is being requested. The second rule passes files to ms-files.php. ms-files.php only serves up multisite files and can’t handle directory requests. Again, these rules came straight out of .htaccess.

3. I use just rewrite ^.*/files/(.*) /wp-includes/ms-files.php?file=$1;
Is that better/worse/same?

Worse. “^.*” is unnecessary.

There is no mention of fastcgi-caching in your configs, which possibly a reason why you are not seeing as much of a performance hike as you were hoping for, as it can be comparable to supercache.

Not likely. By “performance improvements”, I was looking at CPU usage charts of before and after and stacked them up to a similar Apache configuration we were trying. I didn’t see nearly as drastic a difference for nginx vs. Apache for the same setup as PHP APC and WP Super Cache offered. But I did see a slight CPU drop which indicated to me that nginx is more efficient. However, it may not necessarily be worth the effort to switch servers. fastcgi caching won’t necessarily offer any benefit over other caching mechanisms such as WP Super Cache and may possibly get in the way of the normal operations of a WP caching system.

@bowe – To answer your questions:

1: Is there a reason why you chose Super Cache over W3 Total Cache? I thought the later was better, but if you have a fully working Super Cache setup with Nginx I might go for Super Cache

We chose WP Super Cache because we were previously using WP Cache 2 upon which WP Super Cache is based. Our setup is fully functional on WP Super Cache. We tried to use W3 Total Cache around the time WP 3.0 came out and ended up White Screening (WSOD) the whole site – that disaster took a whole day to fix. IMO, WP Super Cache is the easier and more stable static caching plugin. They are both comparable in feature set but I’m more familiar and comfortable with WP Cache 2.

2: How have you set up your CDN? Do you use W3 Total Cache for that, or a different plugin? And does that also need rewrites to work? (since .htaccess does not work on NGinx).

We don’t use a CDN (yet). Still, WP Super Cache should be rewriting the page content to point at the configured CDN prior to caching the page in the file system. From the nginx perspective, this is transparent and therefore no changes to the nginx configuration should be required unless, of course, you host your own CDN.