A hosting provider I use provides a WordPress environment in which everyone has a 'staging' version of the site and a 'live' version.

Their control panel has the option to pull from live, so populating the staging site entirely with the files and data of the live one.

It's then easy to work on changes to the back and front end, and test without risk of hurting the live site. Then a quick 'push staging to live' and the new work is live in about 10 seconds.

I've been playing around using GIT with CouchCMS to try to develop a similar system with some success but figured this is such a useful idea that it might well be a good plan for the future as a standard CouchCMS feature at installation time to be enabled or not, with (perhaps) a master control panel required as well as the LIVE and STAGING site 'normal' Couch admin pages.

[trendoman]

Did you use that "staging-live" feature yourself? If so, how was your experience? If not, kindly share your opinion why I wasn't useful for you.

Yes I use it all the time. My WordPress clients ask me to do some work for them so I do it on their staging site and get them to approve it before I push it to live.

Also very handy for checking if a WordPress plugin or other software patch will break anything and have the chance to fix it first before going live.

It's really excellent.

If I get my own solution formalised before CouchCMS offers it as standard I'll post how I did in Tips N Tricks.

[trendoman]

Ok, now I see how it could be useful. Mostly for testing things on production for compatibility or showcase features.

To put things in perspective - there could be a button "pull from live" to populate demo site.
Once "pull from live" clicked, following could happen -

a) all files and folders from the root of original website will be copied to a subfolder /test/ if disk space allows.
b) database tables will be copied to tables with prefix "test_" within the same database
c) config.php in /test will be amended in following places

Code: Select all

define( 'K_SITE_URL', 'http://localhost/test/' );
define( 'K_DB_TABLES_PREFIX', 'test_' );

d) htaccess in live website will be created / amended to disallow random visitors/bots to /test/ folder.

Once "push to live" clicked, following could happen -

a) changed files will be copied to live version, overwriting old ones
b) database tables will replace original tables without prefix within the same database
c) and d) can be skipped

I believe all steps above could be easily coded with basic php skills?

P.S. Personally, I keep 2 versions (if ever needed) on localhost, then upload to my demo server for client to review the features and pay, next I overwrite changed things on client's live server.
I could see myself using the discussed addon to Couch (publishing my code on their server for approval) only with reputable and trusted clients.

Yes I have a similar process planned. Was wondering about using some git commands to do some of the process and track changes also but this would potentially be a bit awkward with uploaded files on the server.

Hadn't thought about the possibility of clients taking work without paying. I don't have that problem so much as 99% of my clients are hosted by me also. Good point. And I like your solution except for one important factor... that the environment is inevitably different on your 'demo' server than on their 'live' server.

With the live and staging sites running on the very same server the chances of seeing something different in staging to how it will look when pushed live are far lower.

Oh also, pull from live makes it easy to pull in all the client's own CMS changes and uploads, and then work on that as a whole.

I suppose however having them on separate machines entirely does mean server patches can be applied and tested on one before roll-out.

Swings and roundabouts.

My work in progress:

Code: Select all

    //////////////////////////////////////////////////////////////
    // delete live backup if exists, this function accepts a prefix to match with all db tables
    $ae->mysqlDeleteTables("backup_couchwww");

    // rename live ones excluding users, same params but optional exclude regex
    $ae->mysqlRenameTables("couchwww", "backup_couchwww", "/users/"); 

    // duplicate dev ones to live, again excluding users...
    $ae->mysqlDuplicateTables("couchdev", "couchwww", "/users/");
    //////////////////////////////////////////////////////////////

    //////////////////////////////////////////////////////////////
    // File system. (note my CouchCMS installation and config files are OUTSIDE the 
    // public visible folder by use of a symlink
    $ae->filesDeleteFolder(ROOT . "backup_public_html");
    $ae->filesRenameFolder(ROOT . "public_html", ROOT . "backup_public_html");
    $ae->filesCopyFolder(ROOT . "dev", ROOT . "public_html");
    //////////////////////////////////////////////////////////////

[trendoman]

except for one important factor... that the environment is inevitably different

What exactly have you experienced to be different? Couch is not demanding, at large, and most localhost solutions (i use ospanel.io) allow quickly switch among php-apache-mysql options. Configs do not matter, except for popular php extensions - gd, exif, mbstring etc.

I do not agree atm it is an important factor for Couch, because we are talking about testing new features of existing website on a proven couch-supported hosting contrary to deploying a brand new website on client's untested hosting.
So, my 'demo' and their 'live' are very similar.
As a responsible developer, one can prefer environment-independent solutions, similar to various ways Couch offers to send emails. I.e. I use phpmailer addon no matter if mail() is available and it helps avoid issues as well.

If you host clients and often busy with code edits, congrats - you seem to enjoy same-server preview solution. It may even be synced with your local dev machine. For as few as 2-3 small jobs per year I can't say it is a welcomed and first-needed feature. I could help you with it, though, to test or partly code.

You make very good points.

Having experienced the effortless push-pull system for WordPress by a third-party host (one that I resell for) however, it is something I'll definitely be getting going.

Thanks for your offer of help!

[trendoman]

Relevant to thistopic - this code by @tim and @KK is a good example of work with db https://github.com/fallingsprings/couch ... r/database

Oh nice I didn't know that existed! TY!