The Strucured Content Initiative came across this question developing a concept for simplifying the registration process for Content Blocks (Content Elements). We introduced this question into our editor survey in January/ February 2020:
“Do you use this option to switch between types of content elements?”
The result: 158 answered yes; 45 no
However, the majority of the participants were tech savvy or even developers. Here are some thoughts why this question still bothers us:
TYPO3 currently supports switching between content types with no data loss, even if the new CType doesn’t have the all the same TCA fields (for example, changing from FSC’s Textmedia →FSC’s Text →FSC’s Textmedia, the Textmedia asset relations are still in place). However, the “mystery” of where the images went, and that they magically appear again, is confusing for editors, and in many cases CType switching doesn’t really improve UX.
The CType feature is most useful when realizing that a Header CE needs bodytext, or a Text CE needs an image (for example, in WordPress there is a defined mapping for which types can be changed).
CType switching isn’t helpful when switching from complex CEs like an Accordion to Textmedia, because the related records are completely different, causing more editor confusion.
In our discussions we thought about things like defining data fields like “header,” “bodytext,” “media,” and “files” that support CType switching. Or to intorduce a “switchable to” mapping (similar to WordPress) to limit the choices for switching in the editing interface, so that only reasonable switches can be made.
We’d like to have your thought about it as well. Please give us a hand on this topic!
My only concern is that this might be too complicated in practice.
Some problems are created by switching the ctype (and also pages when switching the doktype, e.g. shortcut, link):
leftover content in fields that makes no sense but creates problems, e.g. when using Upgrade Wizards sometimes content is transformed - 10 year old content that no one has ever edited since and that is not useful creates additional obstacles (or even errors) if the wizard cannot convert it. I ran into this a while ago.
linkvalidator - currently the fields like bodytext are checked independently of the ctype so broken links are reported for fields that cannot be edited and that is not used in the frontend. This is no fun for the editors and actually makes linkvalidator unusable if you have a lot of these.
I see switchable types more in the sense of a “conversion wizard”. That is: preserve the fields available in both ctypes (old and new one) and throw everything else way, permanently.
Eg. media switched to text: assets are removed and also the usage count is decreased for all assets.
So content transformations are helpful and can save time, but we do not need to preserve unused stuff.
I think the same way was already written. Right now you can’t provide some generic logic in various places, because there might be leftovers. I would really like to have the explicit mapping or implementation. Everything else should be thrown away.
Regarding the “thrown away”: There is already a history built into TYPO3. If handled properly, there should be not data loss. Instead editors should be able to switch back to an older state at any time.
That way we won’t lose anything, except the UX for editors to switch back.
Maybe the feature can even be combined? So let’s say one created a Text + Media element and adds media. Then the element is switched to Text, the media is lost. Once someone switches the element back to Text + Media, a wizard will popup to allow to reuse the existing media, fetched from history?
Here you hit the toughest part of history handling. “External dependencies”.
Once a file is not associated anymore it can/will be deleted. Going back in history to this very point will never give you back a valid and working content element.
Files really reflect the complexity of all this.
Of course the wizard can work best effort, but then you need a generic way of handling any relations. (e.g. translations)
I don’t wanna block good ideas, but I am a big fan of features that end up in consistent data. The history can only provide this for the very simple use cases.
That was just another idea from myself on top of what I’ve read here. I don’t think anyone thought about that. I would also say that would be sugar on top of the actual idea of the structure content initiative.
For CEs only the currently defined structure should be saved and given to the template. In my experience the current switching feature is more appreciated by technical users than regular editors. The latter often don’t like magic things happening but are ready to do things manually.
In my opinion the current feature is to expensive in terms of complexity.
Personally I like (and use) the CType switching a lot. But I totally agree to the above points of “old” data which is still present or related. So if I understand it correctly there are these two options for improvement:
a) Switching the CType throws away not-needed content (e.g. from TextPic to Text would delete image refs). Switching back to TextPic would mean, image references has to be added again, which I don’t see as negative or editor-confusing aspect. It is consistent for the editor and avoids the problem of outdated content.
b) The switchable-mapping is a good idea, but I’m not sure if this is practicable: how will you define from which to which CType switching is allowed? If the mapping rule is defined by “Switching is possible if the target element uses exactly the same fields like the source element”, than it makes no sense in my opinion. Switching from TextPic to Slider would be not possible, because the Slider does not uses bodytext for example. What I want to say: if the possible switch-mapping-options are too limited for each element, the whole CType switching does not make sense anymore.
I’ve not enough background to vote for one proposed option, but if ‘defining data fields like “header,” “bodytext,” “media,” and “files” that support CType switching’ is seen under what I’ve written in a), than I’d vote for this.
Many thanks to all contributors on this topic. The Structured Content Initiative has evaluated your comments and closes this topic as follows:
The approach of a switchable-mapping was most voted, so we decided to keep this in our focus and address this issue in our future work. However, this will rather be a long term feature.