Hmm…this is a tricky set of conditions and implications to work through.
- I’m intending to make a highly customizable main page for our marketing groups, where we can add content layouts to a main column to customize the layout to best meet their various needs (e.g. Admissions, Academics, About Us, Giving, etc.)
- One goal is to try and put the ability to customize these pages in the hands of editors while keeping things easy and intuitive. One universal page template, avoiding custom blurb/profile types and widgets for each block they want to add, for instance.
- I want the updatability of CLv2, so if there’s a need to update layout structure, we don’t have to find an restamp all the relevant pages.
- I want the customizability of CLv1– choose the layout type you want, then the options for appearance– to avoid having excessive layout definitions, needing to make and maintain various iterations, etc.
CLv2 Bug?
I converted one of my content layouts to use CLv2 and played around with them a bit. I see what you mean about class/styles not applying, and why it is. I also stumbled on some odd behavior.
- I added a content layout where each block has 4 editable regions.
- I added some content to each editable region of two blocks and saved on a page.
- I edited the original content layout definition to add another editable region.
- When I refreshed the page, the saved content was added linearly, bringing the first editable region content of the second block into the first block.
If I attempt the opposite, moving from 4 to 3 editable fields, we see a similar result:
So, CLv2 can be edited, assuming the editable fields never need to change number, order, or purpose. So, for instance, I couldn’t swap the text/image in the HTML because the data would be applied assuming the original order. Seeing this, I think I’m leaning towards following Jon’s example and sticking to CLv1…
Ideas for a CLv3
Thinking through all this, I feel an ideal CLv3 content layout would be something like, “a profile widget that uses page-defined data.” Especially for layouts with lw_layout_block and potentially infinite blocks, something that provides widget-like structure without needing to define custom type(s), working in the dashboard, unique tags, etc.
To give some idea of what’s in my mind, with no assumptions of feasibility and no expectations for anything like this:
Configuration
<widget type="template">
<title>Picture Card List</title>
<description>Create an array of cards with an optional image. Ideal when each item has an image, or for instances where lists need more than a list, less than an accordion.</description>
<content>
<div class="col picture-card-list" data-lw-layout-classes="true">
<div class="row picture-card lw_layout_block" data-lw-block-classes="true">
<div class="picture-card-image editable" data-lw-editable-name="image">
<div class="lw_layout_image" data-width="200" data-height="200"/>
</div>
<div class="picture-card-text">
<div class="picture-card-title editable" data-lw-editable-name="title">
<h3 data-lw-placeholder="Add Title (H3)"/>
</div>
<div class="picture-card-subtitle editable" data-lw-editable-name="subtitle">
<h4 data-lw-placeholder="Add Subtitle (H4)"/>
</div>
<div class="picture-card-body editable" data-lw-editable-name="body">
<p data-lw-placeholder="Add Text, Links, etc"/>
</div>
</div>
</div>
</div>
</content>
<args>
<arg id="layout_class_options">blue, image-right</arg>
<arg id="block_classes_options">red, yellow, blue, image-left, image-right</arg>
</args>
</widget>
Editor Experience
- Overall experience is the same: add a layout to a page, add or remove blocks, add content to defined editable fields, reorder blocks.
- If
layout_class_options is defined, then can use a UI to choose predefined classes/styles to apply to this instance of the content layout. (Bonus: a way to define what each class does.)
- If
block_class_options is defined, then can use a UI to choose predefined classes/styles to apply to apply to the current block. (Bonus: class definitions.)
Saved Widget
A very rough idea, given I don’t know what data structures are possible.
<widget type="content_layout">
<arg id="type">picture_card_list</arg>
<arg id="layout_classes">image-right</arg>
<arg id="block_1">[image: "{image widget}", title: "Apples", subtitle: "Any color, any season.", body: "<p>This is why you need to eat more apples.</p>", classes: ["red"] ]</arg>
<arg id="block_2">[image: "{image widget}", title: "Bananas", subtitle: "Enjoy as-is, or in pudding.", body: "<p>This is why you need to eat more bananas.</p>", classes: ["yellow", "image-left"] ]</arg>
<arg id="block_3">[image: "{image widget}", title: "Chokeberries", subtitle: "Gotta keep the pattern going.", body: "<p>This is why you need to eat more chokeberries.</p>", classes: ["blue"] ]</arg>
</widget>
Intended Results
- Defined classes for the layout and blocks could allow for developers to have one content layout definition with many CSS variations.
- The
lw-x-classes is how developers define which element should receive the classes.
- Named editable fields could help keep content in the intended spaces when the editable regions in the content layout definition are changed or reordered.
- If a new editable region is added and not defined in an existing layout’s data structure, it is assumed to be blank. The region is defined in the data structure on save.
- A risky situation lingering would be the behavior of the system when a developer needs to remove or rename an editable region.
If nothing else, one can dream. 
