Content Sync for outside of pages/reusable

Hi @CDumange,

From our hands-on migration from Kentico 13 to Xperience by Kentico, we've discovered a game-changing shift in how to move changes between environments! The old "stage everything" model is now brilliantly split into two powerful paths: content sync for editor content and CI/CD for system/schema changes.

Observations

In Kentico 13, staging could sync many object-level changes like page type definitions, custom tables, and forms. In Xperience by Kentico, content sync is mainly for actual content such as website pages, content items, and reusable content, while core object definitions and system/configuration items should be handled through CI/CD or Continuous Deployment depending on the object type. So the model is now more split: content goes through content sync, and platform/code/schema changes go through deployment pipelines.

Objects that belong to Content sync

These are the items Xperience by Kentico treats as content, not platform configuration or outside objects:

• Website pages.

• Content hub content items.

• Reusable content items.

• Reusable field schema

• Forms when you synchronize them as content.

• Linked pages/items, assets, taxonomy tags, and related content that are part of the synchronized content.

Objects that belong to CI/CD or deployment

These are the items that should be moved through Continuous Integration / Continuous Deployment or SaaS deployment, not content sync

• Content types and reusable field schema type definitions.

• Form definitions and form builder components.

• Channel definitions and channel settings.

• Workspaces.

• Languages.

• Member roles.

• Object type definitions and other system object metadata.

• Custom modules or custom integrations

• Code components such as page views, controllers, view component's, custom page builder components, custom form builder components, and sections.

  Thanks

  Nikhila

That's a beautiful answer (even if it smells IA very strongly).

CI and Staging were already existing in v13 so it's nothing new. My problem is that the "staging" feature has been demoted to a "content sync" and that it does not fill the same niche.

Here are a few cases that are absolutely not answered:

• You add a new image/page/xxx to qa. How do you know (as webmaster/admin/whatever) that ? How do you retrieve content that has not been synched ? Do we have to keep a list and do it by hand ? Guess ? Sync whole folders just to be sure (when it's not recommended in the doc)

• As of my test, modules values are not included in the CI in Xperience (they were in v13). Am I suppose to fill them by hands ? I have modules with hundred of values...

These aren’t edge cases, they represent real, day-to-day workflow gaps that can affect teams migrating from v13. I’d strongly encourage raising them on the Xperience by Kentico - Roadmap board with clear, concrete examples to help increase visibility and drive prioritization.

For the question: "if you add a new image/page/xxx to qa. How do you know (as webmaster/admin/whatever) that?"

The system does internally track (through the used-by feature) if an image was added to a page, etc., etc. When you go to sync a page, the sync feature will also sync items that the page depends on (your image you just added to the page). For linked content items, linked pages/forms are not displayed in the UI, but they will also be synchronized. Basically, a page should get there in whole.

For the question "How can I migrate module values"

Kentico's recommendation for module class data publishing is using SQL migration scripts to synchronize the database changes, because, as you mentioned, class data is not managed by CI/CD. The migration scripts work pretty well in our experience.

In summary, you are correct, the feature does work differently. It is not intended to be a full replacement to KX13's content staging. Most of the gaps are picked up in CI/CD, and the SQL migrations mentioned above. I also put some more thoughts on the differences between the features on my blog: https://www.mcbeev.com/xperience-by-kentico-content-sync-vs-content-staging

I'll put in my two cents on the Module stuff.

For the most part, I'm finding if the content in your modules needs to be synced, it may be time to re-look at using the module class for it to see if it can't be done in the content hub. The Content Hub does handle parent-child relationships and the API calls beautifully and speedily.

I still have a LOT of module classes, but these are usually environment specific things, not content that would ever sync. Granted, there are reasons to keep some data in a custom module class (ease of Query or External integrations or syncing operations). In those cases, writing a SQL script to migrate, or creating a custom syncing script is doable, although yeah it is a bit of a pain to have to recreate it.

Can you give us an example of some of the module data you push between environments?

As for settings, these really should either be in code as part of deployment pipeline, or we have now 2 different "Channel" setting modules that exist that you can add channel settings, and usually if you DO need to push something like that, it's pretty rare that you can't just manually do the copy. Again, if it's something changed and synced a lot, may be best to throw it in the Content Hub in a separate workspace.

First, thanks for all your answers.

@Nikhila, I'll definitively do that.

@Brian I'll check that but if we have to execute script, I'll probably keep them outside and keep control over them. I find it in a CMS to have to manage SQL scripts. Kinda outside of the whole paradigm :)

And yes, I saw that the page kept the link and you could sync them together. My problem is more: how do you know a page has to be synched. If you prepare a few pages (we have multiple people writing contents), it will be hard to track the content that has to be synched. For reusable content, you can at least order by modification date. Will help. But for pages...

Still feels like a major regression from v13.

@Trevor: It's mainly stuff that is not reusable. We have a few referentials, complex formular configuration, ... Stuff that does not belong in reusable contents. We also moved a lot of stuff to content hub :)

Have a great day all

If you prepare a few pages (we have multiple people writing contents), it will be hard to track the content that has to be synched.

@CDumange in KX13 we also used to recommend authoring content on a lower environment and then use Staging for "pushing it live". But I'm not sure though this is a best practice now with XbyK. With the workflow, preview, scheduled publishing with all connected items that you can select visually, and overall much better performance - I no longer see the reason for it apart from "the content team just got used to it".

Of course there are edge cases like wide restructuring of tree and similar things that need to "go live" in one shot, those cannot be solved in one environment. But most of usual content management tasks should not force you to use this staging model.