Pushing a site from "Staging" to Live"

vyas

Do you use a staging site(s) for wordpress ? If yes, what is your preferred method?

So far I preferred Gridpane for creating the staging site, and then pushing it to live using Gridpane (again). Also tinkered around with Server Avatar and exporting a site using All In One WP Backup (not recommended - too many links to update :-_)

Today, I used the "Push to live" feature of Softaculous for the first time.

The catch:
Live site was, say

blog.domainA.tld

Staging site was

domainb.tld

Both were on same hosting plan of course (DA, Singapore- Smallweb).

A quick and not so elegant screenshot:

Ympker

Softaculous Staging/Clone has been quite convenient for me tbh.

AIO WP Migration usually takes care of all the link updating. Can't think of any issues I faced there.

Maybe something like ManageWP could also be convenient?

havoc

Would avoid putting staging on a publicly accessible server at all in case it gets indexed and then the real site gets flagged as duplicate / copy.

Ympker

@havoc said:
Would avoid putting staging on a publicly accessible server at all in case it gets indexed and then the real site gets flagged as duplicate / copy.

Usually you could enable smth like pw protected and select no index in softaculous. But yeah, WP Local is also an option.

localhost

I typically follow this long arduous process:

`Right Click > Copy (source/ Staging)

Unplug mouse from Source
Plug mouse on Destination

Right Click < Paste (to destination/ Production/ Live)`

/s

bikegremlin

I use Softaculous when possible (the link's to my how-to on that).

When not, I use All-in-One WP Migration (again, my tutorial).

If all else fails - I do it "manually."

tjn

I use a self-hosted git repo (gitea) with a post-receive hook and the script below to rsync files over to my production servers.
This assumes that your staging DB and production DB don't need to match up (in my case they rarely do).

#!/bin/bash

REPO=<my repo>

# Dir paths on remote server
LIVE_BRANCH="master"
LIVE="user@host:/path/to/wordpress/public/"

if ! [ -t 0 ]; then
        read -a ref
fi

# Get branch name from ref head
IFS='/' read -ra REF <<< "${ref[2]}"
branch="${REF[2]}"

# Make tmp dir for extracting files and cleaning up .git (we dont want them on the live site)
tmpdir="/tmp/$REPO/$branch"
mkdir -p $tmpdir

git --work-tree=$tmpdir --git-dir="/path/to/repo.git" checkout -f $branch

# If pushing to LIVE_BRANCH, deploy on LIVE
if [ "$LIVE_BRANCH" == "$branch" ]; then
  rsync -vzre ssh "$tmpdir/" $LIVE
fi

# Clean up
rm -rf "/tmp/$REPO"

willie

Not wordpress but I've been involved with a dual production stack with BGP failover. To upgrade software, you would take the secondary server offline, update, it, bring it back online, then unplug the primary so you'd fail over to the new code. If something went wrong you could revert almost instantly. If it went ok, you'd upgrade the old primary and it would become the new secondary.

Hxxx

Doesn't make much sense to stage if you are just editing a page. In wordpress you can just duplicate the page into draft and work on it. However... editing full site wide design might be a suitable use case of staging.

evnix

not wordpress but in general PHP, I usually auto create a tar.gz file on every commit, you could include the snapshot of your DB in this as well(or just the diff).
Then I just push and unpack the tar.gz file, The solution looks a bit enterprisey(like java/jenkins or c# build processes).
But I feel I have a lot more control and makes it super easy to switch hosts,
I had written an article about this some time ago if you are interested:
https://returnzero.win/2021/01/08/php-deployment-probably-done-right/

tjn

@evnix said:
not wordpress but in general PHP, I usually auto create a tar.gz file on every commit, you could include the snapshot of your DB in this as well(or just the diff). [...]
I had written an article about this some time ago if you are interested:
https://returnzero.win/2021/01/08/php-deployment-probably-done-right/

I like it!
I just wish databases were more "modern" and easier to handle from a sysadmin/DevOps perspective.
Then again, short of using flat files, I can't imagine what that would look like.

vyas

@Hxxx said:
Doesn't make much sense to stage if you are just editing a page. In wordpress you can just duplicate the page into draft and work on it. However... editing full site wide design might be a suitable use case of staging.

Indeed. I maintain a copy of the wp install (hosted, not local but under maintenance mode, etc...) where I do all sorts of edits, adding images/ plugins, etc. Once ready, copy and paste the html + wp code to the main site. Have set up a weekly cron job to remove older versions of pages/ posts to keep the site lean and clean to the extent possible.

edit: Once can also set up a P2 account and get the same result. If you have a WP account, you can use it to log in to https://wordpress.com/p2/

Edit 2: Or using WP desktop app (or iAwriter in case of Mac)

tjn

@vyas can you tell us a bit more about what your cronjob does?

vyas

@tjn said:
@vyas can you tell us a bit more about what your cronjob does?

I don't recall the specifics (been over 18 months) -but I had an intern who set up using Gridpane's KB ...

https://gridpane.com/kb/how-do-i-create-cronjobs/

(we use Gridpane for the site(s) in question)

HTH

Edit: This one also (looked up in my notes)
https://crunchify.com/how-to-disable-and-delete-wordpress-post-page-revisions-change-autosave-and-trash-delete-setting/

mwt

I've used those Pantheon sandboxes (2 free) which have this feature. They actually use three: dev => testing => live.