4.0 is broken in FPM/FastCGI servers

I’m also having problems with it, my setup consists of Nginx (1.2.1) and PHP (5.4.6 with FPM). I guess it has something to do with rewrites, since there isn’t any proper files anymore.

not worked

Please complete explanation

Ok… tricky, tricky, but I seem to report some success!

In my case, I use ISPConfig on top of my server (because it makes everything to more convenient to manage), which means that I have to do things slightly differently. I cannot have two location / { } blocks.

But it works for me having the rewrite rules outside the location block, e.g.

location / {
	 try_files $uri $uri/ /index.php?$args;
}
	rewrite ^/sitemap(-+([a-zA-Z0-9_-]+))?\.xml$ "/index.php?xml_sitemap=params=$2" last;
	rewrite ^/sitemap(-+([a-zA-Z0-9_-]+))?\.xml\.gz$ "/index.php?xml_sitemap=params=$2;zip=true" last;
	rewrite ^/sitemap(-+([a-zA-Z0-9_-]+))?\.html$ "/index.php?xml_sitemap=params=$2;html=true" last;
	rewrite ^/sitemap(-+([a-zA-Z0-9_-]+))?\.html.gz$ "/index.php?xml_sitemap=params=$2;html=true;zip=true" last;

For the sake of completeness, in my case, due to the needs of other plugins, my own configuration is slightly different:

location / {
                try_files $uri $uri/ /index.php?$is_args$args /index.php?q=$uri&$args;
        }

                rewrite ^/sitemap(-+([a-zA-Z0-9_-]+))?\.xml$ "/index.php?xml_sitemap=params=$2" last;
                rewrite ^/sitemap(-+([a-zA-Z0-9_-]+))?\.xml\.gz$ "/index.php?xml_sitemap=params=$2;zip=true" last;
                rewrite ^/sitemap(-+([a-zA-Z0-9_-]+))?\.html$ "/index.php?xml_sitemap=params=$2;html=true" last;
                rewrite ^/sitemap(-+([a-zA-Z0-9_-]+))?\.html.gz$ "/index.php?xml_sitemap=params=$2;html=true;zip=true" last;
                # other rewrite rules below this line...

Most of you might not need such a complex try_files statement.

I just tried only

location /testblog/ {
          try_files $uri $uri/ /testblog/index.php?$args;
}

without any specific sitemap rules and that also worked.

After a few tests it seems that the rewrite rules, in my case, really need to be outside the location / {} block — where actually all the remaining rewrite rules are (e.g. to get rid of the last slash when logging in to /wp-admin/ and so forth). However, I cannot claim that this is ‘universal’.

The good news is that it’s working. I still have to fix those rules to do the same thing for robots.txt, and then I’m done! Or, rather, then I have to fix this on dozens of sites… some of them multi-site installs, which have a slightly different configuration…

The bad news is that this shouldn’t be necessary! The whole point of WordPress’ new rewrite engine is that it shouldn’t require any other rules…

jepp, at the moment I can’t really say why it is not working with the WP rewrite system by default…

I only can say that with the following rule, everything seemed to work during my tests:

location /testblog/ {
          try_files $uri $uri/ /testblog/index.php?$args;
}

That is also the line from the WordPress example of the Nginx Documentation about try_files.

BTW, just as an explanation, my slightly-more-complicated try_files rule is needed for some of the oddest plugins to work. The Nginx documentation for WordPress definitely recommends the simpler line — which ought to work for most well-written plugins.

Of course, a few plugins are not so nice… 🙂

As for the “need” for the rewrite rules, as said, in theory, WordPress’ own rewriting engine should handle all rewriting without the need for some extra help from nginx’s configuration — that was the whole point for actually building a new rewriting engine from scratch and packing it with WordPress, namely, the ability to do URL prettification, no matter what webserver runs beneath WP. I have no idea why it fails with this sitemap plugin. I have certainly several dozens of rules on WP’s rewriting engine, coming from other plugins, which work flawlessly without the need for some “extra help” from nginx’s configuration.

The only difference I see is that somehow sitemaps and robots.txt are “special” static files, but why that should be different from a regular site post/page/other type of content totally baffles me. It simply doesn’t sound logical to me. And clearly it doesn’t affect everybody.

I will need to try out with some sites with fewer plugins; it’s possible that there is something interfering with this…