Contao: Get rid of the back end settings module

[leofeyer]

This is the TODO list as discussed on the Contao Camp 2018 to get rid of the back end settings:

Entfernen

• [x] $GLOBALS['TL_CONFIG']['websiteTitle'] weg
• [x] Skripte komprimieren kann weg
• [x] „Auto_item aktivieren“ kann weg (siehe https://github.com/contao/contao/issues/203#issuecomment-442816612)
• [x] „Unterstützte Template-Formate“ kann weg
• [x] Datei-URL und Assets-URL nur in den Seiteneinstellungen

In die Gruppeneinstellungen (siehe https://github.com/contao/contao/issues/203#issuecomment-442025210)

• [ ] Datum und Zeit für’s BE in die Gruppeneinstellungen und für’s FE wie gehabt (Seitenstruktur)
• [ ] Elemente pro Seite in die Gruppeneinstellungen
• [ ] Elemente nicht verkürzen in die Gruppeneinstellungen
• [ ] „Erlaubte HTML-Tags“ in die Gruppeneinstellungen (siehe https://github.com/contao/contao/issues/203#issuecomment-442179316)
• [ ] „Erlaubte Upload-Dateitypen“ in die Gruppeneinstellungen
• [ ] „Maximale Upload-Dateigröße“ in die Gruppeneinstellungen
• [ ] „Maximale Bildbreite/höhe“ in die Gruppeneinstellungen

In die Seiteneinstellungen

• [ ] „Order-URLs verwenden“ in die Root-Seite
• [ ] „Leere URLs nicht umleiten“ in die Root-Seite
• [ ] „Suche aktivieren“ in die Root-Seite
• [ ] „Geschützte Seiten indizieren“ in die Root-Seite

In den Manager

• [x] Zeichensatz entweder weg oder in den Manager
• [x] Speicherzeiten entweder weg oder in den Manager
• [x] SSL-Proxy Domain in den Manager oder weg
• [ ] „Command Scheduler deaktivieren“ in den Manager
• [x] „Editierbare Dateien“ in den Manager und ergänzen um JSON, YAML Markdown
• [ ] „Maximale GD-Bildhöhe/breite“ in den Manager

Verschiedenes

• [x] Markup komprimieren ins Seitenlayout
• [ ] Maximale Datensätze pro DCA
• [x] Nicht zu synchronisierende Ordner in den Ordner-Einstellungen anpassen (.nosync)
• [ ] „Anfrage-Tokens deaktivieren“ prüfen und ggf. weg

Ohne Einigung

• [ ] „Erlaubte Download-Dateitypen“ ohne Einigung
• [ ] Standard-Zugriffsrechte ohne Einigung

@backbone87 /cc

[fritzmg]

Regarding all settings that are supposed to be moved to the user group settings: where would I define it for administrators?

[leofeyer]

Very good point! 👍

[fritzmg]

„Erlaubte HTML-Tags“ in die Gruppeneinstellungen
„Maximale Upload-Dateigröße“ in die Gruppeneinstellungen
„Maximale Bildbreite/höhe“ in die Gruppeneinstellungen

Furthermore, these settings are also used in the front end 😉

[fritzmg]

„Anfrage-Tokens deaktivieren“ prüfen und ggf. weg

Please only when something is done about https://github.com/contao/contao/issues/134 😁

[asaage]

I wonder how these setting would get merged if users are in multiple different groups.

[contaoacademy]

What about extensions which extend the settings module?

[Toflar]

They will still be shown. They should slowly migrate away from using it just like the core itself does :)

[fritzmg]

But how will extensions be able to provide additional settings for the Contao Manager? Is there some concept in place already?

[Toflar]

There will be. One simple basic concept about Contao 4 is that we are talking Symfony bundles here. We want extensions/bundles to be configurable like any other bundle which means like so: https://symfony.com/doc/current/bundles/configuration.html

This means, if I'm not using the Manager, I can just install the bundle and configure it the way I like. I can do it using xml, yaml or plain old php. I can store the configuration in my git repositories and deploy it like any dev would want to be able to do in 2018.
Using the Symfony configuration tree builder you can provide examples, validation, normalization etc. for whatever configuration values you could imagine.

The only thing that's missing in the whole puzzle is the GUI for the Manager. But it will be based on the Symfony configuration so you don't have to reinvent the wheel. So our GUI is just an extension to the already existing best practices. Right now people have to update the config.yml and the goal is that the Manager will do that for you. But for bundle developers nothing will change (except for maybe a little addition in the ManagerPlugin so that the Manager actually knows what to load). Static configuration must not go to tl_settings but to the container instead, so just follow the documentation linked above and ask the users to edit the config.yml until the Manager provides a GUI for it 😄

[leofeyer]

Regarding all settings that are supposed to be moved to the user group settings: where would I define it for administrators?

We definitely did not think about this. @backbone87 Any ideas?

[fritzmg]

Imho everything that is currently within __In die Gruppeneinstellungen__ should be moved to the application configuration. And additionally you could override them in the group settings. Thus you have some defaults that apply to everyone (including administrators) but are still able to override some settings for specific backend users or groups, if you want/need to.

Furthermore, I think we should create separate back end settings for these. And the front end settings will be edited either within the website root, or within the upload form respectively.

[fritzmg]

One setting is missing from the list: email of the website administrator. Should be moved to the manager as well, imho.

[ausi]

„Erlaubte HTML-Tags“ in die Gruppeneinstellungen

This would create problems. If for example one user creates a content element with an <iframe> in it, another user without this allowed HTML tag might edit the element and the <iframe> would get lost.

[backbone87]

Regarding all settings that are supposed to be moved to the user group settings: where would I define it for administrators?

We definitely did not think about this. @backbone87 Any ideas?

These kind of settings are different from permission settings (which arent needed for admins, since they are admins). But the settings we talk about apply to admins as well, so they need to be configured for them too. If you dont want it to be set up per user, we must enable groups for admin users.

[backbone87]

to be more precise, these are the settings that apply to all users incl admins:

• Datum und Zeit für’s BE in die Gruppeneinstellungen und für’s FE wie gehabt (Seitenstruktur)
• Elemente pro Seite in die Gruppeneinstellungen
• Elemente nicht verkürzen in die Gruppeneinstellungen

these are definitely permission settings, which could be ignored for admins:

• „Erlaubte HTML-Tags“ in die Gruppeneinstellungen
• „Erlaubte Upload-Dateitypen“ in die Gruppeneinstellungen

i am undecided on these, because they should be soft-limits to protect infrastructure:

• „Maximale Upload-Dateigröße“ in die Gruppeneinstellungen
• „Maximale Bildbreite/höhe“ in die Gruppeneinstellungen

[backbone87]

furthermore, these settings should be "self-editable" in your user profile:

• Datum und Zeit für’s BE in die Gruppeneinstellungen und für’s FE wie gehabt (Seitenstruktur)
• Elemente nicht verkürzen in die Gruppeneinstellungen

[leofeyer]

It turns out that $GLOBALS['TL_CONFIG']['websiteTitle'] is also used here:

What would we show there instead if we removed the setting?

[Toflar]

First one can just remain as is, imho. Hardcoded. And the second one can just be dropped?

[fritzmg]

furthermore, these settings should be "self-editable" in your user profile:

• Datum und Zeit für’s BE in die Gruppeneinstellungen und für’s FE wie gehabt (Seitenstruktur)

This is a bit dangerous, if it still remains a simple text input field. A regular user might define a date format that cannot be parsed by either PHP or the date picker JavaScript.

Date and Time settings for _back end input fields_ should be a dropdown with common, valid values.

Date and Time settings for the _front end output_ can remain as text input fields, since their invalidity cannot break anything.

[fritzmg]

First one can just remain as is, imho. Hardcoded. And the second one can just be dropped?

As an alternative, may be the first case can still be altered via translations or a template, if anybody wants to?

[leofeyer]

„Auto_item aktivieren“ kann weg

I don't remember why this can be removed. Did we agree on always activating it?

[leofeyer]

As discussed in Mumble on December 20th, we want to remove the checkbox from the back end settings and activate auto items by default. This way it can still be deactivated in the localconfig.php or config.yml.

[BugBuster1701]

• Datum und Zeit für’s BE in die Gruppeneinstellungen

Was passiert in dem Fall mit $GLOBALS['TL_CONFIG']['dateFormat'] bzw. $GLOBALS['TL_CONFIG']['dateFormat']? Wird das trotzdem gesetzt obwohl es ja nun nicht mehr aus der localconfig.php kommt?

[leofeyer]

Auf jeden Fall. Sonst wäre es ja ein BC-Break.

[fritzmg]

Some extensions like BackupDB rely on a websiteTitle being present. It is used to have a human readable identifier for individual Contao _installations_. May be the websiteTitle shouldn't have been removed and instead it should have been "rebranded" as an "Installation Title"?

[fritzmg]

editableFiles was removed in https://github.com/contao/contao/commit/c2e299087cb95579be717870329dd4f2b54a238b - however, no appropriate bundle configuration was implemented in its place, which is required for it to be editable by the Contao Manager.

[leofeyer]

contao:
    localconfig:
        editableFiles: 'css,csv,html,ini,js,json,less,md,scss,svg,svgz,txt,xliff,xml,yml,yaml'

[fritzmg]

@leofeyer yes, but is that the plan for the Contao Manager?

[leofeyer]

There is no plan for the Contao Manager yet.

[fritzmg]

But why is it removed from the back end setting? I don't really get the process here. imho nothing, that cannot be configured via the back end else where or via the Contao Manager should be removed from the system settings in the back end.

[leofeyer]

But it can be configured "else where", can't it? See https://github.com/contao/contao/issues/203#issuecomment-548348921

[fritzmg]

But it can be configured "else where", can't it? See #203 (comment)

But that's not really an argument. You can configure _all_ the (remaining) system settings via contao.localconfig. By that logic, we have to remove all system settings from the back end immediately?

The point is, it's a bad user experience that all of a sudden some settings cannot be configured either via the back end or the Contao Manager any more. What is the benefit of having to configure it through contao.* via the config.yml, from either an application developers, Contao developers or system user standpoint?

And regarding editableFiles specifically: your original post says:

„Editierbare Dateien“ in den Manager und ergänzen um JSON, YAML Markdown

It's marked as done, but you actually cannot configure the editable files via the Contao Manager. And neither is there an appropriate bundle configuration option to do so in the future (yet).

[Toflar]

I guess the point here is the following: The Contao Manager will never be able to provide additional information for contao.localconfig configuration. This is an arbitrary array with no validation and info at all. It can contain any key-value combination. It's not there to be the only way to configure a value. It's just there so you can configure it without having a localconfig.php.

So I agree that removing from tl_settings must be done when there's a proper bundle configuration alternative, which correctly validates, contains information etc.
So that when I run debug:config contao I actually see those possibilites 😏

[fritzmg]

Exactly. But I also think this should not be done, as long as the Contao Manager is not able to actually change any of these settings yet, in order not to degrade the user experience.

[Toflar]

Well that's another story. The Manager will very likely never have a UI with form fields but rather a way to support you writing the YAML configuration (showing e.g. the info from the configuration tree, validating etc.).
A UI with form fields would be a never-ending story and require huge development efforts which I don't think we'll be able to deliver. If you don't think about the simple key-value use case but things like array of values and nested stuff it becomes really, really difficult.
After all, YAML was invented for exactly that: A human friendly configuration format.

So our users will have to get used to YAML anyway.

[fritzmg]

But what is the benefit of doing that for any of the aforementioned user groups? A lot of people in the forum were told for the past one or two years, that they would be able to change settings like prepend_locale or url_suffix (and now more) in the future with the Contao Manager, as that was something that was previously easily configured in the back end of Contao. And I think all of them expect a UI with form elements.

When writing extensions for Contao, I also rather put system wide configurations into the back end system settings, as that is far more convenient than having to change the config.yml and rebuilding the application cache.

[Toflar]

When writing extensions for Contao, I also rather put system wide configurations into the back end system settings, as that is far more convenient than having to change the config.yml and rebuilding the application cache.

Configuration from within the app potentially kills the it and you're unable to fix it again. We cannot optimize caches, the container or performance. Nothing of all of that is possible and that's why the configuration of any app must happen outside of that app.
So this is something we dropped intentionally and for good reasons.

And I think all of them expect a UI with form elements.

They are free to expect whatever they want to expect. At the end of the day, somebody has to do the work and decide on what's humanly possible to do. If we find the people who want and can build a complete UI into the Manager, then fine. If we can't, we can't. Simple.
Anyway, the discussion about how the UI should be implemented in the Manager is not related to this discussion.
We're talking about replacing back end settings with bundle configuration.

[fritzmg]

Configuration from within the app potentially kills the it and you're unable to fix it again. We cannot optimize caches, the container or performance. Nothing of all of that is possible and that's why the configuration of any app must happen outside of that app.

I don't see how settings like editableFiles, allowedTags, allowedDownload, uploadTypes, maxFileSize or the whole chmod_legend can be optimized for caching or performance in some way. But may be you can enlighten me ;)

Anyway, the discussion about how the UI should be implemented in the Manager is not related to this discussion.
We're talking about replacing back end settings with bundle configuration.

In my opinion it is strongly related, as the configuration of a Content Management System like Contao is part of the user experience. At the very least, one should not be considered without the other.

[leofeyer]

The plan was to remove the "editable files" setting, but as discussed in Mumble on December 19th, we want to preserve it and move it to the bundle configuration.

[fritzmg]

Shouldn't this stay open? :)

[leofeyer]

Yes. It was closed automatically because I commented Fixes #203 in the latest PR. 😁

[fritzmg]

Another candidate are the timeout settings which have been removed in 77b024a3051725909fda1b9d4f1f13870a532e71 . They aren't even part of the original list in https://github.com/contao/contao/issues/203#issue-384740170

No bundle configuration has been provided though. Again: I am strongly against removing anything from the back end settings, if:

• the setting itself is still used by the core
• no alternative way of configuring this setting (i.e. via core-bundle configuration) has been provided

If a setting is removed from the back end settings module, _and_ it is still used by the core, then it _must_ be provided as a documented bundle configuration, otherwise it is too frustrating to figure out how to configure these things.

[aschempp]

The sessionTimeout is actually obsolete in Contao 4.5, but the other ones are not. However, there have always been config flags that cannot be set in the back end, if they are not supposed to be changed ("expert only", e.g. disableInsertTags)...

[fritzmg]

However, there have always been config flags that cannot be set in the back end, if they are not supposed to be changed ("expert only", e.g. disableInsertTags)...

Hmm, then may be it makes sense after all to document all localconfig settings separately. Should this go into the manual or dev docs then? Imho it is sort of relevant for both ...

[aschempp]

Should this go into the manual or dev docs then? Imho it is sort of relevant for both ...

I'd say the same place you document the config options 😉

[Defcon0]

I also agree to @fritzmg that it‘s a better user experience to be able to control global settings through a gui.

On the other hand I understand @Toflar ‘s arguments that it would be very hard to write a gui for handling everything that can be done in config yaml files.

From the perspective of a bundle developer (but would be similar to core): Maybe a compromise would be giving devs an interface to add global config that can be set in contao manager using a gui for simple cases, i.e. key value pairs. So we‘d have bundle configuration that can be made using an easy gui for simple key values (which is the majority I guess) which is then merged with higher priority with the „manual“ config in the yml files.

Would that be an option?

[fritzmg]

I still think that _getting rid_ of the back end settings (or a version of it) is _not_ something we should pursue. Yes, of course it makes sense to move some settings to other places (like discussed above) or move them to the bundle configuration.

But as a whole, I still think it makes sense from a UX _and_ DX perspective to have some sort of general back end settings.

Take the _Valid Slug Characters_ setting for example. Currently, this can only be set within a website root. This is fine for any content that is bound to a specific website root or page. However, where should it be configured for records, that are _not_ bound to a page? E.g. news categories, that aren't bound to any news archive and thus aren't bound to any page. Or content from your own custom DCA that do not need a reference to a page anywhere (or in fact cannot have one).

Sure, within your extension you could write a Configuration, so that the valid slug characters can be configured from the config.yml for example. However, it's much more inconvenient to have to manually define the valid slug characters in the config.yml, instead of being able to choose the desired option from a select (for which the Contao Core already provides its own event for its options to be expanded).

[fritzmg]

The sessionTimeout is actually obsolete in Contao 4.5

That's not true, the sessionTimeout configuration value is still used in Contao 4.5+ to automatically log out users due to inactivity. In order to increase the session timeout, you still have to increase _both_ the session timeout configured in PHP _and_ the one in Contao. The one in Contao has been removed from the back end settings.

[fritzmg]

The remaining localconfig variables that are not deprecated, still in use and have no bundle configuration or other back end setting counterpart are now documented in this PR: https://github.com/contao/docs/pull/630 :)