Blank page on wiki root

[beernuts]

We are attempting to move our large installation from Apache to nginx. In testing, everything has been working fine, save for Vaultwiki. When we load up the wiki root, all we get is a blank page. Nothing is recorded in the error logs on these requests. Accessing the wiki does result in the access log recording the request, however, so I know that the domain mapping is correct. I can place an arbitrary PHP file in our wiki root and visit it and it executes fine. Only Vaultwiki is having an issue with the migration.

What are some things I need to try? I already opened up the vw_config.php and it is correct. As a matter of fact, if I change the VB root directive in that file to be wrong, I get an internal server error.

So I know that vaultwiki is being executed. It just isn't working.

Also, are there any nginx rewrite rules already written for vaultwiki?

[pegasus]

First thing you should try is modify vw_config.php and add the following:

ini_set('display_errors', 1);

If you get an error after doing this, then it may not be a problem with the rewrite rules.

However, nginx rewrite rules are a completely different animal. It may be something simple like nginx not telling PHP about the original request correctly. Please post your existing location blocks so we can see what, if anything, might need to be changed. Also please include your current Apache rules so we know how you expect it to be when it's done.

[beernuts]

Our current apache rewrite is very simple:

RewriteEngine On
RewriteBase /

RewriteRule ^Main:(.*)$ $1 [L,R=301]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)?$ showwiki_proxy.php [L,QSA]

We haven't even tried doing anything funny with nginx yet as far as rewrites. I just assumed that loading up index.php would generate the wiki index page. Our nginx location directive for the wiki subdomain is:

server {
  server_name wiki.site.com;
  root "/home/site/public_html/wiki";

  index index.php;
  client_max_body_size 10m;

  access_log /home/site/_logs/wiki.access.log;
  error_log /home/site/_logs/wiki.error.log;



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

  location ~ "^(.+\.php)($|/)" {
    fastcgi_split_path_info ^(.+\.php)(.*)$;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_param SCRIPT_NAME $fastcgi_script_name;
    fastcgi_param PATH_INFO $fastcgi_path_info;
    fastcgi_param SERVER_NAME $host;
    fastcgi_pass 127.0.0.1:9000;
    include        fastcgi_params;
  }
}

nginx rewrite rules are a completely different animal. Please post your existing location blocks so we can see what, if anything, might need to be changed. Also please include your current Apache rules so we know how you expect it to be when it's done.

[pegasus]

Unfortunately try_files cannot be used with PHP files. It has the unwanted behavior of not passing the request to the .php location block.

server {
  server_name wiki.site.com;
  root "/home/site/public_html/wiki";

  index index.php;
  client_max_body_size 10m;

  access_log /home/site/_logs/wiki.access.log;
  error_log /home/site/_logs/wiki.error.log;

  location /vault {
      rewrite ^ $uri last;
  }

  location / {
        if ($request_uri !~ \.(?:php|js|css)) {
	     set $redirect_url $fastcgi_script_name;

	     rewrite ^ /showwiki_proxy.php last;
        }
  }

  location ~ "^(.+\.php)($|/)" {
    fastcgi_split_path_info ^(.+\.php)(.*)$;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_param SCRIPT_NAME $fastcgi_script_name;
    fastcgi_param PATH_INFO $fastcgi_path_info;
    fastcgi_param SERVER_NAME $host;
    fastcgi_param REDIRECT_URL $redirect_url;
    fastcgi_pass 127.0.0.1:9000;
    include        fastcgi_params;
  }
}

[beernuts]

Your statement confuses me. We use try_files exclusively on vbulletin, wordpress, joomla, and other PHP sites without issue. The try_files and PHP location block are identical to what we use on wordpress for rewrites.

Granted, your configuration works, but I don't understand why. We are trying to stay away from if in our configurations as much as possible due to http://wiki.nginx.org/IfIsEvil

[pegasus]

From a technical standpoint, try_files doesn't maintain the original request on its own. It also expects that the found file takes URL parameters in the same format as the original request. When it doesn't, you need to use rewrite instead. Also, once you start using more complex rules, such as those for vBSEO, or for vBulletin 4 and VaultWiki combined, try_files is no longer adequate, because you need to test more than just "Does this file exist?"

I am aware of the IfIsEvil article from when we started using nginx here. But since that article was written nearly 2 years ago, there have been a lot of updates to nginx and some of the issues with if being quirky were fixed.

Still it doesn't always function exactly the way you might expect. It's not that if should be avoided completely, because as the article mentions, it is necessary in some situations - which you will typically run into if you use more than one software that was not written by you, or software that wasn't designed with nginx in mind.

It's better to try to understand if, rather than avoid it completely. Here is a good article: http://agentzh.blogspot.com/2011/03/...-if-works.html

A good rule of thumb when using if inside location blocks... make sure that every if block has a unique condition, so that only one if block will execute.

You have to be careful with location blocks themselves too: only the first block to match will be executed, unless the location changes, or a later block has an even more qualified condition. You'll start really loving nginx when you have location blocks for different softwares in different sub-directories, and then discover that the .php block never gets executed.

[beernuts]

I appreciate your help here. We're still learning the nginx ways along with its little nuances.