Staging –> Live

Agree! Would be super practical ??

My take on this is a little harsher…

While I’m reluctant to criticize free software, I think that the description of the plugin is currently misleading and will cause trouble for people wanting to use it in a typical way. That typical way being… 1. Copy production to stage. (WORKS GREAT, THANK YOU SO MUCH!) 2. Make changes to stage. 3. Copy stage to production. (NOPE)

Now, I’ve just done steps 1 and 2. I was extremely pleased with how easily the software handled this. One programmer to another, I say, “nice job, Rene.” However, I just got to step 3 and see that there is no feature to handle stage-to-prod, and I’ve seen Rene’s advice to copy files over and use separate database migration tools to handle it. I’m fairly disappointed, because my entire hope was to find a tool that would keep me from needing to go into this, and the plugin description represents itself as making staging easy with no mention of the feature gap.

Stage-to-prod is not just a nice extra feature to have. It is the obvious complementary feature for prod-to-stage. You would not bother with creating a staging site unless you intended to copy the changes back to prod–that use case is implied by the term “staging”. Not having stage-to-prod is like having backup software that doesn’t include restore. Or compression software that doesn’t include decompress.

It’s fine to create a free tool that just does prod-to-stage, and I’ve got no right to complain about it since it’s free. But Rene, you should really represent that the stage-to-prod feature is absent in the plugin description. Because otherwise, you are causing me to waste my time using your product.

Going back to fiddling with wp-config.php and phpMyAdmin scripts to get some janky stage-to-prod working. sigh

-Erik

Hi Erik,

thank you very much for your thoughts. I absolutely appreciate it. Constructive criticism is useful.

> But Rene, you should really represent that the stage-to-prod feature is absent in the plugin description. Because otherwise, you are causing me to waste my time using your product.

Generally, i do not think that there is need to mention all possible features a plugin is NOT able to handle instead describing its capabilities.

But in this particular case i will mention explicitly that WP Staging is not able to write changes back to live site at the moment. So no one else will fall into this “trap” like you did.

I am already working on additional functions for WP Staging which brings the most wanted feature but this is a very complex process and it needs more time.

Hope you will come back from time to time to see if i make process with it.

Regards,
René

René, thanks for not getting frustrated with the criticism. I hope you will continue with WP Staging. There’s doesn’t seem to be a good simple WordPress plugin now that handles staging. Maybe with a little work, WP Staging will become the “default choice” for people. Also, I would happily pay money for WP Staging if it handled stage-to-prod in the same easy way as it does prod-to-stage. Good luck in your efforts!

Hello,

since you guys are talking about essentially the same thing I’d like to submit a question for, let me chip in with a suggestion / possible solution. Would you see the following as a viable approach(or are there any problems I haven’t foreseen)?

1. You setup a single github repository for your site. One repository, one master branch.
2. You setup Revisr in your production WP version and connect it with the github repository.
3. You use WP Staging to create a staging WP version – by definition it is also connected to the same github repository
4. You do some work on the staging version and push it to the github repo.
5. You test the changes in the staging version and make any necessary further changes, which you again push to the github repo.
6. Once happy with the result existing in the staging, you switch to the production version and pull the changes from the github repo.
7. If you find any breaking change or any change you want to revert back from, you identify the working version in the commit history and revert to it in the staging version. Then you push this revert to the github repo and pull the change in the production version – the process is similar as in the case of adding a new feature.

What do you think of this? Are there scenarios I’m missing? Would it work at least for simple scenarios of small teams managing a WP site not needing to make changes simultaneously?

Thanks for your feedback, hopefully it’s an idea for a solution for you too. At least until WP-staging provides push to production features:)

Erik – if you are looking for a paid solution that lets you push both ways, then you could do worse than taking a look at WP Stagecoach.

I’m not affiliated in any way, just think it’s a pretty good solution.

WP Staging is a great plugin, and if Rene manages to implement push to live site then it will become an outstanding one. Great work Rene!

There’s a huge need for a tool to migrate from Staging to the Live Production site. Erik did a great job describing this need.

But this is a very hard problem to do correctly. Here’s the challenge. Let’s say you copy from Live to Staging on day 1. You now have all your current user data on the Staging site. Then you take 2 weeks to add your enhancements to the Staging site, to test it, and to have some other people test it as well. During this 2 week period your users are making further changes to the Live site, but this additional data is not in your Staging site.

So you can’t simply pull your entire WP environment from Staging to Live or you will lose all the user data added during that 2 week period. You need to move the meta data but not the user data.

Many plugins seem to intermingle their user data with their meta data in some tables. This means there is no way that Rene or any other plugin author could provide a tool that works in all cases since he isn’t aware of the internal data structures of every single plugin.

If anyone is aware of a good solution to this please let us know. It seems like a major deficiency of the WP ecosystem.

Thanks,

Mike