In the previous post, I covered staging setup in preparation for a headless WordPress + GatsbyJS site build. I was the sole developer on the project – and while I was working, the marketing & SEO teams were also hard at work on adding/editing posts and pages, and keeping SEO up to snuff.
So, how could I ensure that their work would remain intact when it’s time to launch the new site?
Enter the Pull Script
The solution to keeping the new site development in sync with the latest content from production was a bash script. This bash script would run from the staging server. The high level overview of its functionality is as follows:
- SSH into the production server
- mysqldump and pipe the contents back to staging
- Save SQL database dump as a [website.domain].sql file on staging
- Run a search/replace on the .sql file to replace production domain with staging domain strings, then save as [staging.website.domain].sql
- Import [staging.website.domain].sql into the staging database
- Run SQL commands to purge unnecessary data, clean up, and activate specific plugins
Step #6 was an interesting challenge. The reason this step was necessary is because the production WordPress instance had some loose ends to tidy up:
- A couple dozen abandoned tables from old plugins.
- Old outdated WordPress tables from a few major WP versions back.
- Extraneous plugins that didn’t exist on staging.
Using SQL commands within the bash script, we could handle this cleanup automatically, every time the database was pulled/sync’d from production to staging. This meant that we could have new posts published or edited on production, and I could run this script and use the latest content + SEO updates during development, and keeping any unnecessary data out.
If you’re interested in having these steps broken down in more granular detail, please submit a request and I’ll carve out the time to write it up.