Inform the editor of an unintended list_type change

[josefglatz]

Following scenario in a real world project

1. The TYPO3 instanced was initially developed and integrated in version 8.7 LTS.
2. After the upgrade process to 9.5 LTS, ext:content_defender was integrated. One allowed list_type entry solr_pi_results was forgotten to set in the backend layout configuration. (I found that out today)
3. A half year later an editor just edited the content element which exists already since before the upgrade process.
4. The outcome is, that a) the list_type was changed (you get no message in the backend; you overlook it because it is displayed in a different tab) to another allowed list_type OR b) if you set TCEFORM.tt_content.list_type.disableNoMatchingValueElement = 1 then the content element get's updated to an empty list_type without informing the editor.

In both scenarios (maybe there are more) the frontend is broken and you can't revert it (even not with the history/rollback functionality).

Is there an approach how to intercept such scenarios? Or makes it sense to extend content_defender/core?

Didn't come up with a proper solution

[Bunnyfield]

Actually this would be a job for the core, since you run into the same problems if specific values are removed from select boxes with TSconfig after they have been already used in production.

There should be a real warning similar to the language inconsistency messages telling editors, that the original DB value of a field is not available anymore.
Currently it is just another or an empty label within the selector and might easily be overlooked.

[josefglatz]

@IchHabRecht asked me to write down my expectations:

A task to check whether there are disallowed types of content elements

I could imagine a CLI task like contentdefender:check  next to @Bunnyfield 's very good point. This CLI task could check the content of all pagetrees or a particular tree whether all limitations for backend layouts are given. Probably a TYPO3 backend module is also needed to make problematic content elements editable.

[ursbraem]

Same just happened on some of our TYPO3 11 Sites this week, confusing the editors and us.

What would help a lot would be that the "Switch Form" warning would be displayed if (due to content_defender's restrictions) the supposed CType (not only list_type) could not be respected.

[ursbraem]

Still keep running into this from time to time, when a field type is missing in the allowed list: editors write into support and ask why their content has disappeared.

Maybe we could sponsor or contribute?

[IchHabRecht]

Hi,
I like the idea from @josefglatz to add a check command. I fear until supported by the core any other unwanted change due to configuration limitations aren't possible currently. At least I don't have any clue what can/needs to be done here for better experience. If a restriction was introduced after content creation what would you expect to happen with the content elements?

[ursbraem]

Hi!

If a restriction was introduced after content creation what would you expect to happen with the content elements

The current problem is that the element will open with a default type and be saveable as such. And then it will disappear in the frontend. So in my view, the expected behaviour would be:

• A legacy element is present but it's type has been disallowed in the meantime with content_defender
• User tries to open/edit it
• Content defender prohibits opening (or saving) the element

[IchHabRecht]

Upcoming feature hype ^^

It would be great to get 2 or 3 more days to cover stability and more features. I will call out tomorrow on social media. If you would like to support me, please get in contact.

[domibwagz]

@IchHabRecht I can test this, where can I pull the feature?

[IchHabRecht]

Hi @domibwagz,

@IchHabRecht I can test this, where can I pull the feature?

There isn't any branch yet where this can be tested. I'm currently working on some bugfixes beforehand.