NGINX Rewrite of dynamic JS/CSS files via PHP 404 Errors #703

Closed
DevinWalker opened this Issue Mar 6, 2013 · 10 comments

Comments

Projects
None yet
3 participants

First off - awesome theme, I love it. I recently made the switch over to NGINX and it's going smoothly for the most part except for this one issue. I'm using a plugin called Easy Fancybox and the author uses a PHP file to create dynamic CSS. The filename is: /plugins/easy-fancybox/easy-fancybox.css.php?ver=1.3.4 and is returning a 404 error:

Here's my current site config file:

server {
listen 127.0.0.1:8080;
server_name dev.sitename.com;
root /home/deployer/sites/dev.sitename.com;

location / {
index index.php;
try_files $uri $uri/ /index.php;
}

location ~ .php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}

Roots theme clean URL rewrites

location ~ ^/assets/(img|js|css)/(.)$ {
try_files $uri $uri/ /wp-content/themes/sitename/assets/$1/$2;
}
location ~ ^/plugins/(.
)$ {
try_files $uri $uri/ /wp-content/plugins/$1;
}

}

I've changed themes over to Twently Twelve and don't receive the 404 error - so that leads me to believe something with the Roots rewrites is causing this to happen.

I stumbled upon this thread about the same subject and STILL couldn't figure it out: http://wordpress.org/support/topic/plugin-easy-fancybox-easy-fancybox-not-working-after-switching-hosts

Unfortunately, apparently I'm too noob with nginx to figure this out but it seems like an issue with the NGINX rewrite itself. That's why I'm also posting this issue here.

FYI - I also posted this in the Google Group https://groups.google.com/forum/?fromgroups=#!topic/roots-theme/yOGIw7Gt9uU

Owner

retlehs commented Mar 6, 2013

is that the only file 404ing? can you hit other files from plugins directories with the rewrite?

/cc @singlow

Yes I can hit pretty much all other files without problem. I'm assuming if there's another PHP file with similar naming convensions the same would happen (ie somefile.js.php or somecss.css.php ) I'm turned off the pretty URL rewriting and it seems to have fixed the 404 but I don't get the nice permalink structure.

Contributor

singlow commented Mar 6, 2013

I would first try moving the "location ~ .php$" block after the Roots rewrites. I suspect that this block is catching the url before it is rewritten to add the wp-content path segment.

server {
  listen 127.0.0.1:8080;
  server_name dev.sitename.com;
  root /home/deployer/sites/dev.sitename.com;

  location / {
    index index.php;
    try_files $uri $uri/ /index.php;
  }

  # Roots theme clean URL rewrites
  location ~ ^/assets/(img|js|css)/(.*)$ {
    try_files $uri $uri/ /wp-content/themes/sitename/assets/$1/$2;
  }
  location ~ ^/plugins/(.*)$ {
    try_files $uri $uri/ /wp-content/plugins/$1;
  }
  # End Roots clean URL rewrites

  location ~ .php$ {
    fastcgi_pass 127.0.0.1:9000;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include fastcgi_params;
  }

}

Sometimes the order of the location blocks in your nginx config matters, but I don't understand it too well yet.

I believe I tried that (tried a number of variations) but I will give it a shot again and report back!

Contributor

singlow commented Mar 6, 2013

Since the two Roots rewrites use try_files, the try_files should cause the locations to be re-evaluated on the new URL, resulting in the PHP FastCGI block being applied to /wp-content/plugins/easy-fancybox/easy-fancybox.css.php?ver=1.3.4.

However, if the PHP block gets precedence, it will pass the /plugins/easy-fancybox/easy-fancybox.css.php?ver=1.3.4 URL directly to the PHP FastCGI process and PHP will report a 404 error or a script not found error.

Since all three blocks are regular expressions, they should have precedence based on the order they appear in the config, according to the Nginx Docs.

Owner

retlehs commented Mar 20, 2013

@DevinWalker any update?

I ended up disabling the pretty permalink rewrites on my site. With that this issue was fixed.

Contributor

singlow commented Mar 20, 2013

OK. Did you try the fix in this thread without success or not try it at all. Just like to know whether we should set up our own test.

I cannot confirm that the fix above works. I believe I did try it, among other fixes but cannot be 100% certain.

Owner

retlehs commented Apr 20, 2013

closing for now, will re-open if necessary

retlehs closed this Apr 20, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment