Short answer is nope. For some reason the old Nginx and Apache rewrite confusions popped to my mind; all that is just confusion and misinformation. Textpattern doesn’t depend on any web server in particular, and Textpattern 4.6 itself will add additional abstraction with its Textpattern_Server_Var and Textpattern_HTTP_Request and potential upcoming actual page routing module.

The main confusion is that we use mod_rewrite. We don’t. Or we do, but its job is minimal as it only acts as a bridge. Like with any other routing based system, whether it be PHP CMS or Ruby framework, its only function is to direct normally unaccessible requests to our index file, so that Textpattern can handle the requests and serve a page.

So, how does rewriting work in Ngnix? Or in any other server for that matter then? Well, just point your requests to index.php and you are set. In Ngnix you only need single statement in addition your generic PHP, and site — duh, configuration:

try_files $uri $uri/ /index.php?$args;

That’s equivalent to our rewriting — without rewriting. Define a single try_files directive from HTTP core module it directs requests to index.php and should be set. Textpattern checks REQUEST_URI as seen by PHP, which you should be passing to PHP already in your generic PHP configuration. E.g:

fastcgi_param REQUEST_URI $request_uri;

And you should be getting the correct dynamic page for a clean URI of /or/404/textpattern/error/page.

Final word: so web server agnostic?

That depends, but function-wise, yes. But — er — there are some oddities. Even in 4.6-dev, diagnostics page itself is all Apache. It checks for Apache related stuff and Apache only. Not that it’s wrong, but you get whole a lot of nothing when running something that isn’t Apache, or even mod_php. Not that we could even report anything else.

Have tips, tricks or feedback? Let @gocom on Twitter to know.