Following up on this old feature request. We are using a quite advanced item-set in out article type, to create rich articles with all sorts of content blocks.
Trying to keep track of the different blocks is quite cumbersome, as the titles are non exisitent while editing, and they show some text from the first editable field once the article is saved and reopened/page reloaded.
The answer from @ase mentions that “Later on you will be able to manage the header title yourself.” Any chance of bumping this feature? Anything is helpful here. Live changing the header, or on onBlur, would be great. Also, the possibility to control how the title is created. In our case, it’s possibly a bit tricky, as each item in the item-set is again an option-set (text block, video block, map block etc). Ideally we could set some prefix in these options that could populate the header of the item.
But any kind of live-ish update or control over the header would be appreciated.
Ah… I see now you are already using this feature, but it does not apply to the optionset inside?
We’ll look into our opitons here. For 7.0 we are testing out template literals for a similar use-case, maybe it could be used here as well?
It works well indeed with any editable field within the option set inside. However, my request is more one of being able to override/customise it somehow. In the case of no editable fields within the scope, for instance. We have several blocks with only content selectors within them, where the header only gets the default text.
Also, the header doesn’t update until the entire page is reloaded. Would be great with at least update on save, on onBlur, or even live.
Hi! We have made rather big improvements to this for both itemSet and optionSets in the upcoming Content Studio 3.2. Would be nice to get your feedback after you have tested that. ETA any day now…
I’ve have the time to play around with this for a few hours now, and here’s my first reactions.
The good
I love the contextual “Add above” / “Add below” links for item sets. A real time saver!
When content is (a single) multi choice option set, the heading is nicely populated with translated titles of selected options. It feels predictable.
What I’m struggling with
When the inner content of the item set is a single choice option-set I get the option name attribute as the title field instead of the translated value or the label. Bug?
(Perhaps not related to the changes here) The extraction of text from a htmlarea field needs some tlc. HTML tags should be stripped, and far less text should become the title.
I’m still missing the option to control the title myself in any way. At least I would like to say how deep inside the structure it should look for “presentable” fields.
When the inner content of the item set is several option sets (in my case two) at the root level, it seems random which option set gets preference. I guess I would prefer that it was the option set that was defined first in the content-type xml, or even better that I was able to indicate this with attributes within the content type xml config.
I’ll stop here for now. Thanks for listening and trying to improve this!
It is a bit hard to understand the first issue you describe. I did not see your full type definition, but why would you put an optionset within an ItemSet like this? Why not use optionSets directly and skip the itemSet alltogether?
Basically, if you have an itemSet, and it only contains an optionSet things should/could probably be modelled in a different way.
I’m not quite sure which issue you’re referring to, but I’ll try to elaborate. We’ve built an editorial system to work around the shortcomings of htmlArea. To build richer articles we’re using content blocks of various types
Content block (option set, mandatory, single selection)
Text
Video
Gallery
Quote
etc…
Special settings for content block (option set, non-mandatory, multiple selection)
Color settings
Sidebar options
Various formatting options
etc
item 2…
item 3…
An article consists of an infinite number of content block items. One benefit is that it’s really easy to make reusable isolated parts of the different content blocks for use on i.e. landing pages.
To get a bundle of blocks we need to wrap them in an item set. It works well, but the challenge, and basis for this request in the first place, was some way to visually keep track of all these content blocks that together make an article.
I hope this makes sense. It’s perhaps more complex use of your system than was initially thought of from your end, but you call yourself XP. And htmlArea isn’t very X or P, macros or not
Tnx for the feedback. There is no technical limit to how you can structure things, however for your specific requirement, the best way to model this would be to replace the itemSet with the single select optionset. You could then place the other options within these options. This would give you a more intuitive and simpler UI, as well as data structure.
Remember, you can also use mixins to avoid repeating similar schema fields within each option (if needed).
NOTE: I have discovered a small, but very annoying bug in the implementation of single select optionset that causes the option type to “disappear” when typing within it. This will be fixed so you will always see the name of the option you selected I.e. Text, Video, Gallery - and the first text typed within it in the header. This makes much more sense.
Hmmm. Interesting. I would love a simpler UI. So you are saying I can have an infinite number of single choice option sets? And simply add more occurrences like it was items in an item set? The data would be stored in an array named as the option set?
I would need to repeat the options within each option though, but this is an easy mixin I suppose.
If this works, it raises a few questions. What would be the best way to change the data structure for my existing data? Are there any «best practices» for doing this? I don’t care about preserving versions, if that helps.
Your proposed solution would save me one «level» of data, which is always nice
Indeed, and even more than I expected. Solution is now so good that, at least for our use cases, I no longer see the need for a custom attribute to control the title. The recursive algorithm that “guesses” a good title, combined with the micro subtitle, does the job perfectly.
I was very concerned that you released a feature that actually killed data by mistake. Functionality that alters/removes data should absolutely, and in every case, have automated tests! However, I was very glad that it was promptly adressed when I submitted the issue.
Altogether, these new features have made the CMS part of XP tons more useable for our somewhat advanced usage. With the upcoming image control enhancements for the htmlArea field I will be a lot more proud to show Content Studio to our editors! (Now we instruct all editors to NOT use images in htmlArea fields)
