Advanced site staging functionality

Question

Hi,

I happened to try Siteground's staging functionality, and I was thinking that it would be very nice if we could have something similar, only with the command-line. Here is how I envision it in my ideal scenario:

First, we could have a command like:

stage example.com -to=staging.example.com

which would:

1. Clone example.com to staging.example.com
2. Detect their connection somehow and show it as staging when you do a site -list. e.g.:
   + site1.com
   + example.com
      - staging.example.com (staging of example.com)
   + site2.com
3. Enable debug mode on wp-config.php
4. Password protect the entire staging site
5. Disable caching
6. Maybe an additional option to block any email notifications send to non-admins, in order to prevent accidental notifications to users (e.g. to customers of an eshop).

If you ran

stage example.com

without any parameter, it would search if a staging site exists and if it did, it would automatically perform the aforementioned actions to it, practically updating the existing staging site with the latest changes from the live.

Similarly, if you ran

stage example.com -to=example2.com

supposing that both example.com and example2.com already exist as separate webinoly websites, it would practically connect the two sites as live and staging and update the staging with the latest version of the live.

Then, a command like:

deploy staging.example.com -mode=[full | functionality | custom]

which would:

1. Create a full local backup of the current version of the live site (files and database). If an earlier backup from a previous deploy already exists, it gets replaced. It's not a versioning solution, so we would only need the backup just in case something goes wrong. In fact, it could even have an expiration date (e.g. automatically deleted after a day, a week, or a month).
2. Push the changes to the live site, based on the option set with -mode:
   • "full", would overwrite everything, no questions asked.
   • "functionality" (it probably needs a better name) would overwrite the plugins and themes folders as well as everything in the database except for the content-related tables like wp_users, wp_posts, wp_comments, woocommerce orders etc. Basically, the goal here is to update the plugins, theme and their settings but leave out anything content-related.
   • "custom", where you would be asked to specifically declare which folders and tables you want to exclude (or include).
3. Remove password protection (unless the live site already had one for whatever reason, in which case we keep it).
4. Enable caching, if the live site had it enabled
5. Disable debug mode
6. Enable back the normal email functionality

Finally, we would obviously also need a restore command in case something went wrong.

I know that it sounds a bit crazy, that it definitely needs more overall thinking and that it's probably out of the scope of this project, but maybe some parts of it could fit in.

Comments

I just posted a question for Cristhian over here which might appeal to you.

Answer 1

Hi Giorgos,

In fact, we already have most of these things you mentioned, but they are separate. It would be a matter of having a function with all of them together in one command.

I will take a note of it and leave it as a reference for future improvements ideas. The general idea is good!

Regards.

Comments

The first part (creating the staging site) should be easy for the most part.

What seems more complicated to me is the deployment part, especially on the most common scenario where you test your updates on the staging site and you want to push them to live, but without touching the actual content (posts, comments, users etc). Also, how will those two sites (staging and live) be considered as "connected" to each other and allow you to easily keep them in sync.

It would definitely be a great feature, though, if implemented.

---

Totally agree!

It's like a "partial" database export/import, I'm not sure how safe it would be in order to prevent inconsistencies with the not-synced tables, especially considering that some plugins don't follow the rules and sometimes they use the database in unpredictable ways.

---

Indeed. I did a little googling and I see that this seems to be exactly the problem here.

Siteground, which I took as an example because it seems to handle it in a nice way, offers two types of push: Basic, which is a full backup, and Advanced, which allows you to select which tables to synchronize, so it completely leaves the choice to the user. Maybe they thought about it too and decided that this is the safest way to deal with it (safest in a sense that you don't take responsibility for messing with the user's database and leave it entirely up to them).

---

A partial and similar feature has been released in v1.13.0.

• WordPress Environment Type will automatically enable/disable debug mode, search engine indexing, and cache settings.
• WP environment can be changed when cloning a WP site, and also overwriting (when cloning) an existing site is now allowed.

What do you think about it?

---

I haven't tried that yet, but I like that you change the Environment Type as well, given that's it's a very recent WordPress feature.

I like the features and looking forward to trying them!

Thanks for your great work

---

This feature was originally planned to be released the next year, but when I read about this new WP feature I realize that it was the perfect opportunity to do this just now.