If you know about NGINX and servers, Webinoly is for you!
0 votes
61 views
by Talented
edited by

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.

by Talented

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

1 Answer

0 votes
by Expert

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.

by Talented
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.
by Expert
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.
by Talented

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).

Welcome to the Community site for Webinoly.

Our Optimized LEMP Web Server is a powerful set of commands for doing just about anything you could wish.

With Webinoly you can set up your NGINX web server in just one step.

* * * * * * *

To report a bug, please create a new issue on GitHub or ask a question here with the bug tag.

Donations

Webinoly Support Paypal Donations Webinoly Support Bitcoin Donations GitHub Sponsors

Your regular donations is what keep this project moving forward. If you like Webinoly, buy me a coffee or a beer to show support.

Affiliate Links

It is very important that any visitor to the site read the disclaimer, terms of use and privacy and legal statement before start browsing.

...