xip.io only works on default site
colin-marshall opened this issue · comments
@JPry thanks for this great base config. I am having trouble getting xip to work on a custom site. I followed your guide and as far I can tell I have Vagrant setup correctly because the default WordPress site (local.wordpress.dev) loads through xip. When I try to load any custom site with it, it just goes to the main vvv.dev page.
Here is a sample from my vvv-custom.yml file:
mysite:
repo: https://github.com/JPry/vvv-base.git
hosts:
- mysite.dev
custom:
admin_user: admin
admin_password: password
admin_email: email@gmail.com
title: My Site
db_prefix: wp_
multisite: false
xipio: true
version: latest
locale: en_US
themes:
- twentyseventeen
delete_default_plugins: true
delete_default_themes: true
wp: trueI noticed that when I create/provision custom sites they don't create a provision/vvv-hosts file, and there is one for default site. Could that be the issue? Thanks!
Hi @colin-marshall,
When I try to load any custom site with it, it just goes to the main vvv.dev page.
What host did you configure for your site, and what is the exact xip.io domain that you're attempting to use? I just tested an existing site and it's working correctly for me. I can double-check a newly provisioned site tomorrow when I'm at my main computer to make sure there aren't any bugs.
I noticed that when I create/provision custom sites they don't create a
provision/vvv-hostsfile, and there is one for default site. Could that be the issue?
No, there is no longer a need for the vvv-hosts file. This was something that was used in VVV version 1, but is no longer used in VVV version 2. Those files will still work for backwards-compatibility, but new sites should not use them.
Thanks for the response @JPry!
What host did you configure for your site, and what is the exact xip.io domain that you're attempting to use?
I'm changing the name because it's a client site, but following the same format I used mysite.dev and then mysite.192.168.0.109.xip.io. The default site local.wordpress.dev works at local.wordpress.192.168.0.109.xip.io.
No, there is no longer a need for the vvv-hosts file. This was something that was used in VVV version 1, but is no longer used in VVV version 2. Those files will still work for backwards-compatibility, but new sites should not use them.
I realized after I opened this issue that I transferred the default site from VVV 1 so that's why it had the vvv-hosts file. I noticed that the old default site from VVV 1 had this in wp-config.php:
if ( isset( \$_SERVER['HTTP_HOST'] ) && preg_match('/^(local.wordpress.)\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}(.xip.io)\z/', \$_SERVER['HTTP_HOST'] ) ) {
define( 'WP_HOME', 'http://' . \$_SERVER['HTTP_HOST'] );
define( 'WP_SITEURL', 'http://' . \$_SERVER['HTTP_HOST'] );
}I tried adding that to the wp-config.php of mysite.dev, replacing local.wordpress. with `mysite, with no luck.
I also noticed that vvv-nginx.conf looked like this for the default site:
server {
listen 80;
listen 443 ssl;
server_name local.wordpress.test *.local.wordpress.test local.wordpress.dev *.local.wordpress.dev ~^local\.wordpress\.\d+\.\d+\.\d+\.\d+\.xip\.io$;
root {vvv_path_to_site}/public_html;
error_log {vvv_path_to_site}/log/error.log;
access_log {vvv_path_to_site}/log/access.log;
set $upstream {upstream};
include /etc/nginx/nginx-wp-common.conf;
}For my custom site it looked like this, the difference being it was it missing the ~^ at the front of the xip server_name.
server {
listen 80;
listen 443 ssl;
server_name mysite.dev mysite\.\d+\.\d+\.\d+\.\d+\.xip\.io$;
root {vvv_path_to_site}/htdocs;
error_log {vvv_path_to_site}/log/error.log;
access_log {vvv_path_to_site}/log/access.log;
set $upstream {upstream};
include /etc/nginx/nginx-wp-common.conf;
} I added the ~^ to the beginning and then reprovisioned and I guess that reprovisioning just overwrote the vvv-nginx.conf file with a new one because I lost the ~^ afterwards.
Thanks for the details @colin-marshall. I'll take a look at what's going on in the code to see if I can track it down.
@JPry thanks for fixing this. I noticed in your commit there is no caret after the tilde. According to the Regular Expression Names section of nginx docs:
Regular expressions names
The regular expressions used by nginx are compatible with those used by the Perl programming language (PCRE). To use a regular expression, the server name must start with the tilde character:
server_name ~^www\d+\.example\.net$;
otherwise it will be treated as an exact name, or if the expression contains an asterisk, as a wildcard name (and most likely as an invalid one). Do not forget to set “^” and “$” anchors. They are not required syntactically, but logically.
I'm not the best with regex so I was just curious if you purposely omitted the caret and if so why? Thanks again!
I noticed in your commit there is no caret after the tilde.
Good observation 😄 The ^ character means that the regex must start at the very beginning instead of in the middle of the string. Similarly, the $ character indicates the very end of the string.
These are a couple examples:
~example\.\d+\.\d+\.\d+\.\d+\.xip\.io$matchesexample.192.168.50.4.xip.ioand alsofoo.example.192.168.50.4.xip.io~^example\.\d+\.\d+\.\d+\.\d+\.xip\.io$matchesexample.192.168.50.4.xip.iobut notfoo.example.192.168.50.4.xip.io
The reason for the omission is that I want to only conditionally include it. In the case of a subdomain multisite, you would want to leave off the ^, because a subdomain could be prepended. For all other domains, it's OK to include it since you won't have any other subdomains to match.
For many people, it might not make much of a difference to have the ^ anchor versus not having it.