by @ghanshyam
What is your idea about?
The idea is to ship and maintain a TYPO3 extension that adds first-class, context-driven
configuration for real-world deployments.
TYPO3 already has clear file-based configuration entry points
(config/sites/*/config.yaml, settings.yaml, csp.yaml, and
config/system/settings.php).
What is missing in practice is a single, predictable convention for environment-specific overlays that:
- Loads automatically from the active application context (TYPO3_CONTEXT).
- Names files consistently beside the base files (e.g. stage.settings.yaml,
local.settings.php) instead of copying whole trees or scattering conditionals. - Protects shared base configuration when integrators use the Site Management
backend in staging, local, or testing contexts.
space_config implements that convention and documents it for administrators, integrators,
and developers.
What must be achieve by 31st of August 2026?
TYPO3 projects typically need different configuration per environment (production vs staging
vs local CI). Core does not define one standard for file-based environment overrides across
sites and global system settings. Teams therefore fall back to patterns that are hard to review
and easy to get wrong:
● Duplicated config/sites trees or manual merges → configuration drift between
environments.
● Ad-hhoc logic in additional.php and elsewhere → hidden behaviour and fragile
debugging (“which file actually won?”).
● Context-agnostic backend writes → saving sites in non-production can overwrite the
same config.yaml / settings.yaml that production relies on.
The result is operational risk, slower onboarding, and no shared vocabulary across agencies
for “how we do environments.” space_config addresses that with explicit files, explicit
merge order, and explicit write routing.
How does your Idea align with the strategic goals for TYPO3 v14.
For TYPO3 as a platform, the impact is more predictable, safer multi-environment operation
and less accidental production misconfiguration:
â—Ź Stability: Clear separation between canonical base config and context-only deltas
reduces surprise at deploy time.
â—Ź Collaboration: One documented pattern lowers onboarding cost for integrators and
makes audits easier (override files are obvious in the tree).
â—Ź Trust in the backend: Context-aware writes mean day-to-day work in staging or local
is less likely to corrupt production-bound files.
â—Ź Long-term architecture: Because the design uses public extension points (events,
DI, documented loader), the work can inform or complement future core direction on
context handling—without blocking teams that need a solution now via the extension
Budget for this idea?
7.500 Euro
My Name
Ghanshyam Bhava