Content migration plan

#1

Hi,

We have two running environments, development and stage, as we are currently testing out Squidex. We are using Squidex for

  • Page Content
  • Translations

We would like to ‘migrate’ content from development to staging environment automatically during deployment without any manual intervention. The process should be similar to an incremental data migration in a environment which is already up and running.

I have the following questions in line with migration:

  • Schemas can be exported as JSON. Is there a way to programtically create the schema on the staging environment using this JSON?
  • How should new content be added to Squidex on Staging environment? Do we have to add content records as an HTTP call? Is there any bulk insert? Translations and page content have a unique key (string)

My understanding is that backups are not suitable for such scenario.

#2

Hi there,

so far there is no automated way to implement this, but you could implement something by using the API. You can also create schemas using the API.

Backups create whole new apps and are not suitable for the this scenario. I was thinking about implementing something like this before but so much stuff can go wrong that it is hard to build a good UI for that.

#3

Hi Sebastian,

I’m trying to implement the same things. Could I ask is there a document for create/edit schemas by using API ?

#4

Have you seen the API documentation: https://cloud.squidex.io/api/docs?

you are looking for this endpoint: https://cloud.squidex.io/api/docs#operation/Schemas_PostSchema

There is a also a big fat link at the App dashboard :wink:

2 Likes
#5

I have integrated the management APIs into the client library: https://github.com/Squidex/squidex-samples/tree/master/csharp/Squidex.ClientLibrary

I have not tested it fully yet, but the code is auto-generated from the API. Would be great if you can help me testing it.

#6

We’ve got the same requirement. Currently we’re using the API and have separated out syncing the schema from syncing the content.

However, we have had issues with Reference fields. Syncing content for these has to be done in two passed, once to create the required records and then go back and update the reference fields. However, the second pass seems to miss-behave since we upgraded to v3.

A standard official tool would be much appreciated.

#7

Can you explain what you mean with “miss-behave”?

#8

We’re also getting to this point where we need to sync schemas, contents, rules, etc. from one app to another.

Having one application act as a parent application and sync down to it’s children.

I may give it a go trying to write some custom API’s for this.

#9

Also interested in this feature. We currently only have one dev environment that we are actively updating. Our plan is to backup it up and restore it as a new project to be used for production before launching.

Then forward we manually do the schema changes for production and development projects. It would be nice to have a way to synchronise this from the web ui.

#10

We are also trying to figure this out.

We would expect content changes to just occur on production, in the Squidex UI (until we build a frontend for it, perhaps).

But we think we’d want:

  • schema changes to occur in a “lower” environment, be tested there and then pushed up somehow as a new version of the schema (in unpublished state?)
  • content maintainers to see the gaps are between what their current content has and what the new version requires

We can write an interface to do this, but I wondered what aspects of this Squidex would already support.

#11

It is a really complicated topic and I do not have an answer yet. A lot of base work like versioning for every entity in Squidex is already done. But it is not solved yet.

For content changes you have workflows. The idea is that only Published contents land in your production environment and you can even create proposals to an published version. But there are is no solution for schemas yet. What other CMS systems like GraphCMS do is to have different environments for the whole set of schemas but I am not sure if this makes is easier.