Hide localization fields and colPos in FormEngine

Discussion Topic

FormEngine currently allows to change the language, the localization parent or remove it, and also the colPos for tt_content. These options affect more than just setting a field to some other value.

Mainly:

  • Changing sys_language_uid allows to actually set a record from sys_language_uid=2 to sys_language_uid=1, even when another translation in sys_language_uid=1 exists, which is a simple “make multiple translations of a record” for the same language, resulting in a lot of different issues in FE and BE.
  • Changing l10n_parent might result in going into “connected”/“disconnected” mode without knowing what this actually means.

I propose to:

  • Move l10n_parent, sys_language_uid for pages (once pages_language_overlay is migrated) and tt_content into a hidden palette
  • Move colPos to a hidden palette in FormEngine
  • Restricting the DataHandler to disallow updating a record if there is already a translation for a parent accessible (should happen in DataMap)
  • Adding a button in PageModule to “remove translation parent” for a content element when in “connected mode” to go into “free mode”.

Impact

  • Restrict TYPO3 to only have max ONE translation per language of a record.
  • It won’t be easily possible anymore to change a record (pages/tt_content) to set a different language for an editor/admin
  • Changing “connected” / “free mode” should be done more explicitly in Page Module / FormEngine / List Module for connected records.
  • Changing colPos is only possible via page module then.

Pro

  • Avoid editors to "what did I do now?"effect and brick the system
  • Streamline behaviour on connected/free mode throughout further places in the Core
  • Lead editors to explictly switch between connected/free mode (if done in a proper switch in FormEngine instead, this could be quite helpful)

Con

  • sys_language_uid=-1 is not really possible anymore - (we need a better solution here)

Organizational

Topic Initiator: Benni Mack
Topic Mentor: Benni Mack

One use case for which I used the language field was to set a content element (mostly plug-ins) to “All languages” after it was created instead of adding a translation of that CE.

Other than that the fields are of no use really to editors.

For the switch between connected/free mode there could be some kind of wizard that takes care of the details to prevent weird mixed situations.

1 Like

One use case for which I used the language field was to set a content element (mostly plug-ins) to “All languages” after it was created instead of adding a translation of that CE.

I totally get that usecase.
If an plugin/extension handles language stuff on its own, that’s fine.
In this case I’d copy the CE over into all other languages and keep its configuration in sync with its parent.
Arguably an extension author should be able to define whether his/her extension handles languages on its own and if so trigger the automatic copying and syncing process of the core.

Sometimes the information from colPos and sys_language_uid could be helpfull for the editor, so I wouldn’t hide them, I would more like to get them disabled for editing.

One additional thing to consider is what should happen if we try to restore a deleted record.

Sometimes the information from colPos and sys_language_uid could be helpfull for the editor, so I wouldn’t hide them, I would more like to get them disabled for editing.

That’s a UI issue. Thus I’d still remove them from the TCA but add a wizard on top (or bottom) of the CE container.

One additional thing to consider is what should happen if we try to restore a deleted record.

UI should ask if all related children should be restored as well (although I’d opt for just restoring them right away)

I agree with all this:

  • Make colPos, language and parent a readonly field
  • Create a wizard for migration from connected to free mode
  • 1 record per language
  • Adjust the translation wizard to allow translation of a single CE as well. (We often do not need all CEs translated, just a few of them)

One extra-wish: Make some hard-core-mode, which allows an admin to fix wrong colpos/lang/parent stuff somehow via UI. We regularly need this when gridelements is in the game, to fix broken content.

Yes. Fully ack on that.

My original reason for this question came up when I looked at the current “all fields enabled in a content element” mode. This is a PITA when I want to edit text. Looks like I need to scroll to see the RTE. Does not feel right.

Maybe I’m going too far here, but:
Currently we are always trying to find the field type that “somewhat” fits what we try to make editable.
I am a huge fan of adding fields and editing UIs that totally fit what we want to show/edit.

So I’d add a dedicated rendertype for Markus’ hardcore mode.

1 Like

Do we ultimately come back to the point where palettes where actually hidden in the ui as secondary fields? :wink:

2 Likes

I like the proposal.

I would probably even go a step further and move the “metadata” like hidden, start/endtime, user groups, … outside the form, e.g. into a hidden area at the top right that is only visible when opened, or into a sidebar. This would make it easier for people to find that stuff in each record, w/o cluttering the normal fields area.

Collapsible palettes? :wink:

About hiding or making read-only the colpos… I am honest… I don’t know if it is a good idea, because sometimes (by accident or whatever) the wrong colPos is set and you deny one possibility to change it quickly (yes you can do it with drag and drop, but it is not always the easiest method)

I agree with that!

[EDIT]
I have just realized that maybe you could already make a “hard-core-mode”… with the be_groups ACL. Am I right?
you can already exclude the colPos from the eyes of the editors. Just as a wild idea, would it be possible to include in TYPO3 some “pre-filled” ACL (for profiles like “editor”, “advanced editor” etc? - obviously they would be editable - IMO writing the ACL by scrolling the infinite list of fields is one of the most time-consuming activities for the integrator)

Not quite. Because if you deny access via ACL DataHandler can not store the colPos at all and will result in default value for the DB field definition.
You would rather need to hide it way via page TSconfig

1 Like

what about an option to change a field from “full editable” to “show only” in the detail form (with the possibility to change the field in other ways than immediate edit)?

I guess we call that “read-only” :wink:

found XD https://forge.typo3.org/issues/53239

This topic was automatically closed after 14 days. New replies are no longer allowed.