Best way to experiment with example.com WordPress site while it is up and running on a VPS instance?


#1

I have example.com in WordPress multisite subdirectory setup on a VPS droplet. It is up and running. It should be like this:

example.com

example.com/de

example.com/ar

example.com/cn

VPS droplet is running Ubuntu 16.04 and hosts example.com. The stack used was LinuxEnginexMysqlPhp (a.k.a LEMP) stack.

But anyway, I want now to experiment with example.com somewhere and somehow so that I can still keep the live example.com intact up and running. The solution needed should streamline the two tasks:

First: do the experimentation with example.com website and when finished and everything looks good and working

Second: move the newly constructed example.com and replace the live but old example.com with almost zero downtime. This way, the visitor will not have the downtime experience.

I didn’t use EasyEngine to build the multisite example.com WordPress though, but from what I have learned it can simplify and shorten my mileage to accomplish the above. Do you recommend using it?

The question might be silly to most of you, but I am a new to all of this, so it would be nice if someone can point to a good step-by-step documentation to accomplish this testdriving or experimenation given the above scenario. Your help would be much appreciated.


Testing environment, how to access
#2

You should work with your hosts file.

If you need more assistance:


How to install WP for development without changing DNS
#3

Dear sir, thank you for your reply, but please don’t assume very much or super knowledge. I have now two VPS droplets:

VPS droplet 1 holds the old and live example.com on IP address: 1.1.1.1

VPS droplet 2 holds the test example.com on IP address 2.2.2.2

my local machine has IP address 9.9.9.9

so you said hosts file and I assume the one on my local machine in: \etc\hosts which contains this:

127.0.0.1       localhost
127.0.1.1       E6410

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

So can I have only my machine access the experimental example.com IP:2.2.2.2 while all other visitors reach the old example.com IP:1.1.1.1?

My goal is to experiment with example.com on IP:2.2.2.2 and then destroy the first VPS droplet when I am done and make the new webiste accessible to all visitors.

How to achieve this given the above hosts file?


#4

Exactly.

Place a line like the below to /etc/hosts (or /private/etc/hosts in case you are using Mac OS) on your own machine (the one from which you’ll access the development VPS):

2.2.2.2 yourdomain.com

You’ll from this moment on access the development VPS, but the rest of the universe will never know it.


#5

I did change the hosts file on my Ubuntu 16.04 local machine as follows:

sudo nano /etc/hosts

and added this line:

2.2.2.2 example.com

still didn’t work, I checked the sequence priority:

grep host /etc/nsswitch.conf

it was:

hosts:          files mdns4_minimal [NOTFOUND=return] dns

which should be correct since files (which must be /etc/hosts I guess) take the precedence over dns. I found this here. So what am I missing here? Why cannot my machine access the domain name of the new droplet IP address? it still refers to the old droplet of the live domain.

However, it worked only when I used a different domain name, I used literally the example.com and put that line in the /etc/hosts file:

2.2.2.2 example.com

and it worked! so I have now WordPress site called example.com and I can log in and modify from my local machine, really a good feeling. I can now play safely with everything without compromising the surfing experience of my visitors on the original site.

I can fiddle with this experimental website until I am satisfied with everything then what? I don’t see next steps very clearly. How can I implement the good modifications I did to example.com and have them placed on my OldDomain.com which is hosted on another droplet?


#6

Perhaps your internet provider uses some kind of cache (like Squid) between you and the sites you access. In such rare case the /etc/hosts trick won’t work as desired.

But if with example.com it worked, than I don’t know. :-/


#7

To follow this up - how can you test multiple sites with the setup? using the IP in server name directive does not seem to work with easyengine. Dunno why - but simply doesn’t.

Is the only solution in that case to have only one site active? (by remving sites-enabled symlink?). Usually just switching around the IP in server name from config to config file should work - however it doesn’t. There must be somewhere a hidden file configuring this. It seems to always direct to the first site ever enabled with easyengine, instead of to the site having the IP in the server name or drop back to the default nginx static website in var/www/html/.

Instead I get: nginx: [warn] conflicting server name “176.9.136.135” on 0.0.0.0:443, ignored

on sudo service nginx -t Which is crazy for my understanding - because that’s the standard way of specifying which website should respond when you go in via IP instead of domain name.

– so the only way is to setup a new domain for each website you want to test out. Still - the only thing you can test that way is if the page loads - on wordpress i.e. because of forwarding rules it’s basically impossible to get to wp-admin or login.

So you basically have to setup another test site - again with another domain and play in your real website and change everything to see if it goes through smoothly - note down any problems - try to solve them back on your old server - and then finally tell your provider to switch the servers (so your new server gets the old I.P. and the old server the new I.P.).

What I would do beforehand though - is change IPV6 to new server - very few people use it right now - so you can have a quick go at it live. ( I have about 10% IPV6 users - so it’s worth trying that out at night - and then if it works you can safely either change the DNS over - or let the provider switch the server rack - which if possible is always better because you don’t have to go into maintenance mode that way. ). If you’re even more tech savy you could run your wordpress database from a third server - for the switching time (or in general) - I’m not tech savy enough to do that (or don’t want to spend the time learning it).


#8