nginx – Network admin pointing to root as opposed to subdirectory
-
Using nginx, I’ve installed WordPress to /blogs and enabled network sites.
All my main site links point to example.com/blogs, but when I go to network admin the links point to https://www.example.com/wp-admin/network/ instead of https://www.example.com/blogs/wp-admin/network/
Here’s the multisite section in my config:
define('MULTISITE', true); define('SUBDOMAIN_INSTALL', false); $base = '/blogs'; define('DOMAIN_CURRENT_SITE', 'www.example.com'); define('PATH_CURRENT_SITE', '/'); define('SITE_ID_CURRENT_SITE', 1); define('BLOG_ID_CURRENT_SITE', 1);
If I tried changing PATH_CURRENT_SITE to /blogs, I’d get a db connection error.
Thanks.
-
You are right.
In my configuration in Github, there is a bug (that I fixed now). The
root
should point to the path of the non-WordPress installation.You need to check
root
directive and also alltry_files
directive.
If you only changeroot
path, try_files may fail.To make things simple… U can paste your conf on https://gist.github.com/ so that we can have a look at it.
To crosscheck my config, I created a demo setup at https://sub.rtcamp.net/blogs/
I also put a physical file in root dir and its working fine – https://sub.rtcamp.net/info.phpThough if you want to host another wordpress or any application which relies on rewrite-rules in https://sub.rtcamp.net/ then things will be slightly different.
The conf I used earlier this evening was yours copied and pasted from https://rtcamp.com/tutorials/wordpress-nginx-multisite-subdirectories-in-subdirectory-itself/
I’m just going to test Pothi’s config, but since wordpress is only dealing with the server block built specifically for it, I’m at a loss (as as Mika, I think) why WP keeps creating URLs that point to the root.
Pothi,
Thanks for letting me see your config (which I’ll test in a moment) but I think you’re misunderstanding my question.
Your config currently has:
# Redirect www.domainname.com/anything to domainname.com/anything server { listen 80; server_name www.domainname.com; return 301 $scheme://domainname.com$request_uri;
I’m talking about redirecting domainname.com/anythingthatisnotwordpress to www.domainname.com/anything as my site (and all it’s Google love, etc) is at WWW. and I’m only dropping the “www” for Worpdress per Mika’s suggestion.
but since wordpress is only dealing with the server block built specifically for it,
Actually WordPress is not dealing with anything itself.
Its nginx decision to pass some requests to different part of wordpress for certain conditions.2 questions:
- Do you have any wordpress-like app in root-dir
- This may sound lame, but have you made changes to my config – there are many things you need to change: path, domain, folder-name, fastcgi_pass value, etc
Also, wordpress wp-config will have following in your case: (if there is a mistake there)
define('MULTISITE', true); define('SUBDOMAIN_INSTALL', false); $base = '/blogs/'; define('DOMAIN_CURRENT_SITE', 'yourdomain.com'); define('PATH_CURRENT_SITE', '/blogs/'); define('SITE_ID_CURRENT_SITE', 1); define('BLOG_ID_CURRENT_SITE', 1);
Can you verify value for
$base
and others?I created a specific document root for the WP (non-www) server block and created a /blogs subir in that.
Yes, I changed the path, domain, folder-name, fastcgi_pass value, etc to my values. The install at domain.com/blogs worked fine EXCEPT the URLs for network admin point to root instead of /blogs and yes, the wp-config changes WP suggested are wrong too as the install suggested:
define('MULTISITE', true); define('SUBDOMAIN_INSTALL', false); $base = '/'; <-- WRONG define('DOMAIN_CURRENT_SITE', 'domain.com'); define('PATH_CURRENT_SITE', '/'); <-- WRONG define('SITE_ID_CURRENT_SITE', 1); define('BLOG_ID_CURRENT_SITE', 1);
As Mika and I have mentioned above we’re not sure why a /blogs install that appears to work makes urls and config suggestions pointing to root. It’s driving me nuts. ??
I’m talking about redirecting domainname.com/anythingthatisnotwordpress to https://www.domainname.com/anything as my site (and all it’s Google love, etc) is at WWW. and I’m only dropping the “www” for Worpdress per Mika’s suggestion.
@hgrianevans
You are right. I didn’t understand what you meant earlier and now. ??Anyway, let me clarify my configuration…
The following server block…
# Redirect www.domainname.com/anything to domainname.com/anything server { listen 80; server_name www.domainname.com; return 301 $scheme://domainname.com$request_uri; }
doesn’t really care, if you use WordPress or non-WordPress based site or if you use both. ?? It takes care that your domain is served consistently with (or without) ‘www’, depending on what you choose to do with your domain name.
If your site uses ‘www’, you don’t have to drop it to use your non-WP site at the root and your WordPress site at ‘blogs’ sub-directory. Here’s what it’d look like, if my/your site is with ‘www’…
# Redirect domainname.com/anything to www.domainname.com/anything server { listen 80; server_name domainname.com; return 301 $scheme://www.domainname.com$request_uri; } # Process requests to www.domainname.com server { listen 80; server_name www.domainname.com; index index.php; ....
Also, www issue can be fixed separately!
My advise would be to use common server{..} block in your case (as your main site needs www prefix)
Add following as a first rule…
server { server_name example.com www.example.com; #other stuff if ($host = 'www.example.com' ) { rewrite ^/wordpress/(.*)$ https://example.com/wordpress$1 permanent; } #other stuff }
Above has a cavet that part of sites outside /wordpress/ folder will be accessible using WWW as well as non-WWW.
You can and another condition with some more work. Nginx doesn’t support NEGATION in regex/location rules so be careful on this part.I’m so coffee-deprived right now! [gotta make a mug!]
Sadly the fact that non-WP can be accessed with or without www is a problem because there are tens of thousands of pages in the non-WP parts of the site and I’d be afraid of Google duplicate issues.
The part that’s really, really not understandable is why as I showed above that 90% of the URLs are pointing correctly to /blogs and the network admin ones are pointing to /wp-admin and not /blogs/wp-admin. What the heck is happening in the install process that causes that? Is it grabbing some malformed PHP variable during the install process?
I thank all you guys. I just wish I could understand the install errors.
My advise would be to use common server{..} block in your case (as your main site needs www prefix)
IMO, it only complicates things further (we already see a complication in the way the WordPress is recommended to be installed without ‘www’). Instead, it can be done with two server blocks. Please let me clarify…
server { server example.com; # usual stuff to process WP multisite install location /wpmuinstall { # try_files } location / { return 301 $scheme://www.example.com$request_uri; } } server { server_name www.example.com; # usual stuff to process non-WP site location /wpmuinstall { return 301 $scheme://example.com$request_uri; } location / { # try_files } }
Pothi,
Kettle’s on…brain’s getting ready. ??
Just curious, why do you need a try_files in the non-WP section? Isn’t the try files stuff just for WP? Or is it beneficial for the non-WP stuff as well?
try_files is not wordpress specific
hgrianevans wants to use mix on www and non-www. I generally use separate blocks but his case common block will make it easy to maintain config going ahead.
About your config, its clean and nice but in practice there will be many more location blocks (php file, static assest, etc) which will need to be copied in both places.
location cannot be used outside server{..} block otherwise I would have voted for your config.Also, 2-server blocks will become further complicate if user decide to use plugins like super-cache and root-site also uses wordpress! Just imagine where it will lead…
I did not say main site will be left as it is. Just some more rules needed to force WWW for main site.
I cannot provide them as I don’t know your about your main-site ??
Its hard to guess exact rules you need without seeing your main site
Just curious, why do you need a try_files in the non-WP section? Isn’t the try files stuff just for WP? Or is it beneficial for the non-WP stuff as well?
As rahul286 has already mentioned, try_files is not WP specific. Usage of try_files is entirely optional, depending on your Nginx configuration of your non-WP site. Just replace it with your own configuration for the non-WP site.
hgrianevans wants to use mix on www and non-www. I generally use separate blocks but his case common block will make it easy to maintain config going ahead.
I understand what hgrianevans wants to achieve. I just put my opinion. There is nothing wrong with your suggestion.
IMO, it is even easier to maintain, if hgrianevans installs WordPress with ‘www’. ??
- The topic ‘nginx – Network admin pointing to root as opposed to subdirectory’ is closed to new replies.