Re: Wordpress Multi-Site Converting Apache to Nginx

Server NGINX
1

Side Note: It appears the forum is down.http://forum.nginx.org says,
“The database connection failed. Please check your database
configuration
in include/db/config.php. If the configuration is okay, check if the
database server is running.”

That’s not what ^~ means.

The manual says, “If the longest matching prefix location has the “|^~|”
modifier then regular expressions are not checked”. Which means that a
^~ location will have a higher priority than a regular expression rule,
right?

What request do you make?
Which one of the above locations does the request match?
What output do you expect?
What output do you get?

First rule:

location ^~ /wordpress/ {
try_files $uri /wordpress/index.php =404;
}

What I intend: “If the URL starts with “/wordpress/”, then do not check
any regular expression rules. Instead, load the requested URI directly.”
What happens: when visiting “wordpress/” I get a blank page.
The Log:
2014/04/30 02:39:06 [debug] 27354#0: post event 00007F68E8FD9010
2014/04/30 02:39:06 [debug] 27354#0: delete posted event
00007F68E8FD9010
2014/04/30 02:39:06 [debug] 27354#0: accept on 0.0.0.0:80, ready: 1
2014/04/30 02:39:06 [debug] 27354#0: posix_memalign:
0000000000E79F90:256 @16
2014/04/30 02:39:06 [debug] 27354#0: *5 accept: [REMOVED MY IP] fd:9
2014/04/30 02:39:06 [debug] 27354#0: *5 event timer add: 9:
20000:1398825566351
2014/04/30 02:39:06 [debug] 27354#0: *5 reusable connection: 1
2014/04/30 02:39:06 [debug] 27354#0: *5 epoll add event: fd:9 op:1
ev:80000001
2014/04/30 02:39:06 [debug] 27354#0: accept() not ready (11: Resource
temporarily unavailable)

That’s it, no error.

Second Problem Rule:

I have updated this rule to be a regex rule:

llocation ~ ^/(wp-(content|admin|includes).*) {
try_files /wordpress/$1 /wordpress/$1/index.php =404;
}

What I intend: “If /wp-content followed by anything, or /wp-admin
followed by anything, or /wp-includes followed by anything: Silently (no
browser redirect) show the same URL as if a /wordpress/ directory were
inserted in front. ie. “/wp-admin/bob” becomes
“/wordpress/wp-admin/bob/”, but does not do a redirect. If a directory,
load index.php inside the given directoy.”
What happens: I visit /wp-admin/ and get wp-admin.php, dumped as plain
text.

It’s not passing to PHP.

But I have a PHP block:

location ~ .php$ {
try_files $uri =404;
fastcgi_split_path_info ^(.+.php)(/.+)$;
fastcgi_index index.php;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_pass unix:/var/run/php5-fpm.sock;
}

So it should be passing to PHP?

2

On Tue, Apr 29, 2014 at 11:33:57PM -0400, Nick Rahl wrote:

Hi there,

That’s not what ^~ means.

The manual says, “If the longest matching prefix location has the
“|^~|” modifier then regular expressions are not checked”. Which
means that a ^~ location will have a higher priority than a regular
expression rule, right?

Correct.

location ^~ /wordpress/ {
try_files $uri /wordpress/index.php =404;
}

What I intend: “If the URL starts with “/wordpress/”, then do not
check any regular expression rules. Instead, load the requested URI
directly.”

Ok, so long as your idea of “load the requested uri” matches nginx’s.

According to Module ngx_http_core_module, that should probably try to
send you the content of /usr/local/nginx/html/wordpress/index.php or
404.

What happens: when visiting “wordpress/” I get a blank page.

What does

curl -v http://whatever/wordpress/

show?

Is your blank page a http 200 with no content, or a http 200 with some
content that the browser shows as blank, or some other http response?

directory were inserted in front. ie. “/wp-admin/bob” becomes
“/wordpress/wp-admin/bob/”, but does not do a redirect. If a
directory, load index.php inside the given directoy."

try_files probably doesn’t do what you think it does.

The final argument does an internal rewrite. The other arguments are
served as files in the current context, unless they end in “/” in which
case the “index” value is involved.

What happens: I visit /wp-admin/ and get wp-admin.php, dumped as plain text.

curl -v http://whatever/wp-admin/

The logs will show which location is used. Can you see which
file-on-the-filesystem wp-admin.php is returned?

(I don’t see anything in your provided config which would associate
wp-admin.php with a request for /wp-admin/. I would have expected the
file /usr/local/nginx/html/wordpress/wp-admin/index.php to be returned.)

It’s not passing to PHP.

The initial request will have a “location” chosen.

A subrequest will have a “location” chosen.

“just serve this file” will not have a “location” chosen.

But I have a PHP block:

location ~ .php$ {
try_files $uri =404;
fastcgi_split_path_info ^(.+.php)(/.+)$;
fastcgi_index index.php;

For info: those two lines probably don’t do anything useful here.

  include fastcgi_params;
  fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
  fastcgi_pass unix:/var/run/php5-fpm.sock;

}

So it should be passing to PHP?

Not unless there’s a request or subrequest that best-matches this
location.

Good luck with it,

f

Francis D. [email protected]