I’m researching how to approach a migration of a site that is using the legacy Grid over to using the Block Grid Editor.
The legacy grid has the concept of rows, columns/cells, and controls and I’m trying to see if there would be a way to replicate this with the Block Grid Editor.
My initial idea was to create Blocks to represent the row configuration, which would be:
100
50/50
33/33/33
Then, add Areas to these blocks so that the areas act as columns/cells. This would work but I’m missing the “Cell configuration” as there are no way to add settings to an Area.
Anyone that have made a similar migration where cell settings were used, how did you approach it? Or have anyone performed a similar migration with a totally different approach?
I’ve been thinking about solving it like in the example below by wrapping blocks in a “style-container” that could hold these kinds of settings. It would probably work if this is considered an edge-case but not optimal for situations where most of the areas need settings.
Hi all,
not being able to add settings to an area has been frustrating for me too.
However, in UmBootstrap I have templates for Layouts and Features that help make things easier and I think should help with the issues you have.
Also using CSS Utility classes in the area aliases is something I use all the time.
with a bit of by convention for prop names (areaAliases).. passes the colsettings down.. var classes = element?.Value<string>($"{alias}Classes") ?? string.Empty;
Not ideal, would be much nicer to have settings on areas
We’ve done something similar for one website, this one only had two columns but now I’m looking at a website with a 4 column layout so the “tabs-on-row”-approach kind of felt clumbsy - but would indeed work.
Thanks @deanleigh =D I’m mainly looking at this to migrate a site that have configuration on the cell level so I need a way to replicate that using the block grid. I’ll have a look at UmBootstrap. Cheers!
@BillyDigi Thanks for sharing some more insights and screenshots! It’s indeed a interesting approach - I’ll have to play around with something similar to see how it feel. Cheers!
I started with the approach of wrapping blocks in a container, but requiring editors to add an extra container block was adding too much complexity.
So now I’ve got an Area Settings block type, which has a settings model and an empty content model. The Area Settings block can be added to any area. The area template reads the settings from the first Area Settings block in the area, if one is present.
It is possible to add multiple Area Settings blocks to an area - I don’t think there’s a way to prevent that - but only the first one will be used.
I contributed this to uSync Migrations (along with some other stuff in the same PR), so that’s how area settings are migrated there now (previously they weren’t migrated at all).