The state of configuration

I remember that I promised you a tour. The tour ticket is non-refundable, but flexible. It can be changed at any time and includes lounge access. Give me a ping and we’ll find a date.

Interesting. I wouldn’t think of that as configuration, personally. I’d consider that part of content, and thus would approach it as a page element that takes some context, which is the page it’s on, or some other relation from the page that it’s on. (In Drupal speak I’d use Panels and the Groups module, which supports exactly that.)

Of course, part of the fun of a CMS is that the content vs config line is sometimes… squishy. But they have very very different lifecycles and workflows, so lines need to be drawn somewhere. Where is the question.

Hey everybody,

@crell thanks for the summary.

My personal gut-feeling is that we should distinct between

  • (System) Configuration - currently TCA/LocalConfiguration/ExtensionConfiguration - which affect the whole system. I think PHP in general is very useful (and we only have PHP and Services.yaml in this case, except for the definition)
  • and “Settings”

Settings are e.g. “Site Settings” (currently per-site in YAML), TypoScript constants (currently in sys_template.config DB field) or FlexForms.

For any kind of “Settings”, we should provide a GUI, which would write to DB and overloads settings files, so both deployable but overridable per-page.

So one of the strengths of TYPO3 is to change certain things (the color of my website) via the GUI but keep the System Maintenance out of that scope should be pushed forward. Having a “maker bundle” or a dev-package to allow these things could be possible, but just not shipped with Core (as it is in production and possibly read-only FS on my Azure Cloud).

Dropping the GUI (and per page settings) is probably going to loose the majority of people who use this to solve their custom needs.

3 Likes

Limiting GUIs to DB changes would already be a good step.

True, technically nothing stops us from having two configuration pools for different purposes. That would simplify some things, and we could still use much of the same tooling internally.

The concern I have would be where to draw the line between the two, and to that point, what happens when someone really really wants a config object that’s in one pool to behave like it’s in the other, because No Doubt Very Reasonable Reasons™?

The next chapter in the saga has been posted here: Configuring a better configuration

The concern I have would be where to draw the line between the two, and to that point, what happens when someone really really wants a config object that’s in one pool to behave like it’s in the other, because No Doubt Very Reasonable Reasons™?

I think that this is not a no go per se, but it will lead to technical limitations. As we say in Switzerland: “Du chasch nid s Gipfeli und s Foifi ha” (you can’t have the croissant and the money for it). The drawback could be that if you want to be able to have some configuration object work like another, you might not be able to deploy it to a standard cloud and have to build your own (speaking of deployable configurations on a file base), whereas you might be able to deploy database configuration if you want to, but you’ll have to build your own deployment process for this, as TYPO3 would not be able to cover such a niche use case.

In any case, this whole configuration discussion is very interesting and I’m eager to read your next article (that’s what I’m heading to now).