Home > nginx, WordPress > Don't forget the $args!

Don't forget the $args!

August 2010 UPDATE: Read here for new information!

I just realized when trying to use the try_files shortcut that either the behavior has changed or the code I've used it for has never had to take advantage of it, but what happens when you do something like this:

try_files $uri $uri/ /foo/index.php?u=$uri;

Is that the query string is stripped out and the only thing PHP sees is the $_GET['u']

to fix this, it's easy enough:

try_files $uri $uri/ /foo/index.php?u=$uri&$args;

I never noticed this behavior in WordPress (I've been using try_files with it for a while without noticable issue) but it was an issue with Drupal (which uses the Front-Controller Pattern just like WP does) and custom code we've written.

UPDATE: depending on what custom WordPress plugins you may be using that rely on the $_GET params, you should add this. This should be the final recipe from what I can tell. 🙂

I haven't asked Igor if the behavior has changed slightly with it, but the changelogs have not mentioned any behavior changes, from what I can tell.

Anyway if you notice your pagination or other GET params are being dropped, you might want to take a quick look at that 🙂

Categories: nginx, WordPress
  1. Brian
    June 17th, 2009 at 16:37 | #1

    I saw this in the thread and switched to this from

    if (!-e $request_filename) {
       rewrite ^/(.*)$  /index.php?q=$1 last;

    but this try_files version doesn't work with the stable or dev version of Global Redirect.

  2. mike
    June 18th, 2009 at 01:05 | #2

    What version of Drupal or WordPress, what version of nginx, and post the server {} block?

  3. Ferodynamics
    March 10th, 2010 at 17:44 | #3

    The syntax plugin you're using to show the code, it drops underscores, in "try_files" for example.

    Well, after clicking through 4 pages of your revisions I'm a little lost. What problem does this solve exactly? I'm using your code but permalinks aren't working.

  4. mike
    March 10th, 2010 at 18:16 | #4

    This should work no problem:

    try_files $uri $uri/ /wordpress/index.php?u=$uri&$args;

    (assuming /wordpress is where your wp files are hosted)

    Also, the syntax highlighter is showing underscores for me no problem?

  5. Matthias Marschall
    March 11th, 2010 at 02:48 | #5

    @mike Hm, unfortunately even this code permalinks do not work for me.

    WordPress lives in the root dir of my nginx, so for I use /index.php... with no dir in front.

    Wordpres 2.9.1, ngingx 0.7.65

  6. mike
    March 11th, 2010 at 13:37 | #6

    @Matthias Marschall
    Does this not work? Works for me using a recent nginx (0.8.x) and the latest WordPress -

    try_files $uri $uri/ /index.php?q=$uri&$args;

    Same thing just removing the /wordpress prefix...

  7. Matthias Marschall
    March 12th, 2010 at 00:27 | #7


    Hm, not really. Tried again with nginx 0.8.34. Maybe a look at my complete nginx.conf helps: http://pastie.org/866231

    Any help appreciated...

  8. mike
    March 12th, 2010 at 00:35 | #8

    @Matthias Marschall

    Try putting

    try_files $uri $uri/ /index.php?q=$uri&$args;

    inside of the location / block. or remove the location / block - I don't use one unless absolutely necessary. Also, you can always try the mailing list too 🙂

  9. Matthias Marschall
    March 12th, 2010 at 01:12 | #9

    @mike Ah, that did the trick. I removed the location and it works now! Thanks a ton!

  10. Dean Hall
    July 14th, 2010 at 23:12 | #10

    I've been constantly confused by everyone's need to use try_files for WordPress. What is the problem that it solves?

    location / {
    error_page 404 = /index.php;
    log_not_found off;

    index.php sends its own status code.

    Plus, I give it a -1 on elegance as now I have to pass a query string to index.php.

    I'm not trying to be a troll here; just asking an honest question.

  11. mike
    July 15th, 2010 at 04:36 | #11

    @Dean Hall
    By the very nature of it you're essentially relying on the webserver to 404 and executing the error_page. Because it's a 404, and intercepted further down the chain, it tries to log the not found, which you have to disable.

    To me that is purely not elegant in any sense of the word. There's a reason for the mod_rewrite style checks and try_files to exist. You're informing the webserver up front how to fall back instead of after it's exhausted the standard options and has to fall back to default error handling.

    I'm sure there is probably some sort of way to examine the specifics in an strace but I don't know it well enough to trust my findings.

    To me you should be handling 404's properly - logging them if you want and using error_page 404 as needed (although in theory you don't need that when covered by the WordPress try_files or rewrite check as it will pass the request to WP and WP will display its 404 page) - I just don't think using error_page as a rewrite tool is the right way to go about it.

    I was not aware so many people were feeling the "need" to use try_files for WP. It is the best solution according to Igor (which is why he implemented it) for things like this (from what I can tell...) and is more efficient (reference pending) than the mod_rewrite style if (!-e $request_filename) type call, which is typically what is done.

  1. No trackbacks yet.
You must be logged in to post a comment.