Actions
Epic #89107
closedIntroduce Site Settings
Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Site Handling, Site Sets & Routing
Target version:
-
Start date:
2019-09-06
Due date:
% Done:
100%
Estimated time:
(Total: 0.00 h)
Sprint Focus:
Description
Site settings should provide a possibility to configure site-wide settings (for example storage PIDs) for use in all contexts. This allows for setting e.g. storagePid in site settings so they can be used for Backend modules and the same value also in TypoScript setup (as constants).
In addition, all site settings can be put in VCS as they are configuration (similar to site configuration already) but overriden by integrators in the database via Constants for FE.
Prerequisites:
- Existing site
Starting point: Sites module
- A site has a new button "edit settings" to reach the site settings module
- The site settings module has the same interface as the constant editor / extension configuration (can be refactored to a different syntax at a later point - we want to keep settings in the same format and switch to yaml for constants and site settings in one step, providing a fallback to the legacy syntax; as step one: make reusing of constant editor files/config possible)
- The site settings get read and written to a file called "settings.yaml" next to the corresponding sites config.yaml (similar to how constants are saved)
- The site settings are readable / accessible via the sites object (and in all cases where that is accessible)
- The site settings interface is build from various Settings.typoscript configuration files provided by extensions in Configuration/Site/Settings.typoscript (these contain the interface definitions - see constants for syntax)
- When starting to parse TypoScript constants (TemplateService), all configuration values of the site settings are applied BEFORE the actual constants, so constants can overrule Site Settings.
- Make site settings language aware
- Add possibility to restrict an extensions site settings to specific sites only (question to be discussed: should we implement a general possibility to load extensions based on the current site?)
- Benjamin Kott is working on a revamp of the constant editor configuration format / gui - which can then be used for both site settings and constants
Actions