Migrating Content

[nurkka]

Hi all!

I am relatively new to RockMigrations and admittedly don't (yet) understand every aspect. In my last project, I worked successfully with a local DDEV processwire installation and manually deployed that to a staging and a production server.

The client now had some changes and extra wishes after the launch, which I implemented in my local version of the website. In the meantime, the client also made changes on the production website. So now, I have two different versions of the websites's content in the database.

Of course I have the migrations for fields and templates in my migrations files, so this is not a problem. But I will definitely lose the changes I made locally to existing pages, like adding the newly implemented content elements and their content, because now, after the website's launch, I can't simply overwrite the production database with my local one.

Is there a way in RockMigrations, to write Migrations to add content to existing pages?
In my case, I used RockPageBuilder, and added new RockPageBuilder blocks to several pages, and filled them with new content.

How do you deal with such a situation in your workflow?

[bernhard]

Hi @nurkka thats a good question 🙂 

I'd love to have some kind of migration feature for RockPageBuilder content, but unfortunately it's not there yet. What is already there is an API for blocks, so it's already quite easy to work with block data from the API (https://www.baumrock.com/en/processwire/modules/rockpagebuilder/docs/api/).

What I usually do in such situations is to always create content on the live site. This is the single source of truth for content. When using RockShell all content changes to your live site are just one command away:

rockshell db:pull production

But if you have lots of content it might be worth to write a simple script that uses the block api. Or maybe others have some creative ideas as well?

[nurkka]

My last project has finally been launched, but there were still a few subsequent changes that I made locally in my DDEV. So, I downloaded the DB and newer files from the remote server, made the changes locally and then uploaded the whole thing again. By doing that, I accidentially deleted contact form entries that had arrived in the meantime. That's no problem in this small project, but leads to the conclusion, that one could not use such a workflow in websites with any frontend user generated content - even if it is only a simple contact form that saves its entries. Also timestamps of pages and log data like from ProcessChangeLog would not be preserved.

Unless one would have a second database and “somehow” collect all user-generated data in the second database.

So the idea would be: one database for core, modules, fields, templates and settings – and another database just for "user stuff" like contact forms, log data, etc.

Would be interesting, if there are any approaches for this, or if anyone has ever done this before!

[bernhard]

1 minute ago, nurkka said:

Would be interesting, if there are any approaches for this, or if anyone has ever done this before!

Just use RockMigrations for everything that you add or remove. That's it. Once you push to production RockMigrations will kick in and do everything that you did locally also on the remote system.

If you have to add lots of content for whatever reason then just add that on the production site (eg on a new unpublished page) and do a db:pull instead of pushing your local database to the remote.

[nurkka]

Thanks @bernhard ! And if the client already changed and added content, one could possibly use a tool to export pages on the remote server and import them in the local environment, if that is necessary. I'll have a look at ryan's ProcessPagesExportImport module.