In SDL Tridion Sites 9.1, which was released last week, the page region functionality has received a small update. Besides a few bugfixes, the main enhancement is in the so-called synchronization of pages.
First of all, if you don’t know exactly what I mean by ‘page regions’, you can read up here. Done? Then you will know that regions are a way to group the component presentations on a page. You do this by applying a Region Schema to a page. This is a new type of schema, introduced in 9.0, which defines (among other things) which types of components and which component templates are allowed on a page.
Synchronization
If something changes in the design of your regions, synchronization comes into play. You may know about synchronization already. It has been around for a while. It makes sure that changes to content schemas are applied to a component, with the least possible loss of data. For example: if you change the order of 2 fields in a schema, synchronization makes sure that the order of those fields is changed in the component also, so you don’t lose that data.
So what does this have to do with regions? What happens if something changes with regards to the Region Schemas? To be more precise, we’re interested in two scenarios:
- The editor selects another Region Schema for the page
- A developer changes the Region Schema itself
In both scenarios, Tridion 9.1 behaves much better than its predecessor. Before, Tridion would simply remove all component presentations from the page, albeit with a polite warning message. Imagine a page with 15 component presentations on it – the mere act of changing the Region Schema will remove them all, and the editor will need to manually add them back again!
In Tridion 9.1, the synchronization functionality has been enhanced to make our lives easier. It now understands about regions.
Examples
Imagine you have a page which uses Region Schema (or Page Schema) ‘Regions Type 1’, which defines 2 regions: RegionA and RegionB. The page has 4 component presentations, organized like this:
- Page 1, using Regions Type 1
- RegionA
- Component Presentation I
- Component Presentation II
- RegionB
- Component Presentation III
- Component Presentation IV
- RegionA
Now, the editor replaces the Region Schema ‘Regions Type 1’ with another schema, called ‘Regions Type 2’. This schema defines 2 regions as well: RegionA and RegionC. When you open the page in the CME, it is now automatically synchronized, and will look like this:
- Page 1, using Regions Type 2
- RegionA
- Component Presentation I
- Component Presentation II
- RegionC
- Component Presentation III
- Component Presentation IV
- RegionA
As you can see, no information is lost. Component Presentations I and II stay in the same region, because both Region Schemas happen to define a region with that name. RegionB is gone of course, but the Component Presentations in it have been moved up to the level of the page itself. The editor can now decide what to do with them: include them in RegionA, move them to RegionC, keep them where they are, or delete them.
Please note that CPs I and II can only be added to RegionA if the constraints defined in the new Region Schema allow this. If not, you will find these component presentations on the page level also.
The second scenario
Let’s look at the second scenario now. The page is still using Region Type 1, but a developer decides to change this schema. He adds a region called RegionC and removes RegionB. Now when the editor opens the page, it will be synchronized as well. The end result is exactly the same as in the previous scenario: CPs III and IV are now on the page level. You don’t lose any information.
As I said, small changes perhaps but very useful. Please note that SDL have yet to implement the so-called ‘User-defined regions’, which I talked about in this blog post and for which I submitted an official Idea on SDL’s Ideas site. Please go and upvote it if you want.