Staging to production without overwriting content

[ad_1]

I have an issue with the process of updating the website I'm responsible for – we're hosted with Kinsta and are using their staging to make updates to the site, deploying once a day. There are 2 issues:

1) non technical team members keep updating the production site, which then gets overwritten when staging is pushed to production. Apart from revoking there access, is there a solution to prevent this? Only pushing specific pages?

2) doing a daily push is it very convenient as we are often required to make urgent updates. Also as we're syncing the whole site it's not quick, and we can't really do it several times a day

For context, development is done by 2 devs who I (non-technical person) manage, while there are a number of general users updating content.

Is this something git would resolve? Or is there some clever process I'm missing. Hopefully I can present the whole team with a good solution, that we can all grasp, so any pointers would be greatly appreciated.

[ad_2]
7 Comments
  1. Is there an option to build a manual or playbook or tell them to make changes on the staging environment in Kinsta rather than them messing around on the production site?

    You can give them restricted access to the staging no?

  2. I would suggest establishing an agreed-upon content freeze point in the day, requiring those with access not conduct any content changes during that time. Say 3pm every afternoon. Ensure those updates performed prior to then is synced to the development environment so that when the code updates push they carry with them the last content breakpoint.

    Aside from that (and perhaps more ideal) would be disabling the auto-push, and manually pushing out only the pertinent code update instead of overwriting production completely. Unless major structural changes push out every time I would think a manual push of only those code repositories with changes would do better for you.
    If there’s any concern of performance of updates, push that repo to a staging environment to test against current config of production prior to pushing to production….

    —edit to add—
    I agree with the recommendation by walkingsuitcase as well -perhaps best approach for most simple resolution — eliminate updates made on production by anyone other than development – content writers/product managers etc place their new content changes on staging with the knowledge that it will update that night.

  3. We would @ channel everyone we can and let them know it’s migration time and please stop all work. Also remind them If you do any work in production it will get overridden and you will have to redo that work again once the migration is completed. That will 100% be on them to redo the work.

  4. Production should be the source of truth. Content updates can be copied to other environments if you’re using the block editor.

  5. I would start by asking this question of your devs. Their skill level will significantly affect the solution to this problem.

  6. First question, why does it bother you guys that users keep adding content? They can’t add technical stuff that needs to be reworked, right?

    1. 1:1 copy of live
    2. Develop solutions, in plugins
    3. Test solutions
    4. Freeze production, 1 day
    5. 1:1 copy production -> staging
    6. Test staging with plugins
    7. Push staging to production

 

This site will teach you how to build a WordPress website for beginners. We will cover everything from installing WordPress to adding pages, posts, and images to your site. You will learn how to customize your site with themes and plugins, as well as how to market your site online.

Buy WordPress Transfer