Question
TYPO3 site baseVariants fallback order and CLI versus web context drift
Dev Orbit
0 reputation · 30 Nov 2025, 19:32 UTC
12.9K views
Loading…
0 reputation · 30 Nov 2025, 19:32 UTC
In TYPO3 v9–v13, each site defines a static base URI in config/sites/<identifier>/config.yaml and optional baseVariants that override it when a condition evaluates true. Conditions are evaluated against the application context derived from TYPO3_CONTEXT and the runtime environment. Consequently, a web request and a CLI invocation can resolve different bases.
The documentation does not prescribe whether the static base should be the production value with local overrides, or the local value with production overrides. When no variant condition matches, TYPO3 silently falls back to the static base; a local-first setup that sets base to a localhost URL and only overrides production via a variant will serve localhost links whenever the production condition fails. There is no fail-fast guard that errors when the resolved base disagrees with the incoming Host header.
Setting TYPO3_CONTEXT only in the web server vhost leaves CLI entry points such as the scheduler on the default context, so base resolution can differ between frontend rendering and cron tasks. baseVariants also do not touch [SYS][trustedHostsPattern], [SYS][reverseProxyIP], [SYS][reverseProxySSL] or cookie domains, so a correct base can still be rejected or loop behind a proxy.
What is the recommended fallback strategy for the static site-base value to avoid silent localhost leakage in production? How can a project enforce that the resolved base matches the public host without custom middleware? Does TYPO3 provide any built-in diagnostic to surface context drift between web and CLI base resolution?
35775 reputation · 30 Nov 2025, 23:23 UTC
Set the static base to your production URL and use baseVariants only for local/development overrides. This prevents silent localhost leakage when a production variant condition fails to match.
typo3# config/sites/mysite/config.yaml
base: 'https://www.example.com/'
baseVariants:
-
base: 'http://localhost:8080/'
condition: 'applicationContext == "Development"'
-
base: 'https://staging.example.com/'
condition: 'applicationContext == "Testing"'
With this arrangement, a failed condition in production (e.g., TYPO3_CONTEXT not set) still resolves to the correct public URL. The reverse—static base as localhost with a production variant—leaks localhost links whenever the variant doesn't fire.
TYPO3 core does not validate that the resolved base matches the incoming Host header. The built-in approach is configuration discipline:
[SYS][trustedHostsPattern] with your base domains in config/system/settings.php or AdditionalConfiguration.php. This rejects requests with unexpected Host headers before routing.[SYS][reverseProxyIP] and [SYS][reverseProxySSL] if behind a proxy so getIndpEnv('TYPO3_SITE_URL') reflects the public scheme/host.[FE][cookieDomain] and [BE][cookieDomain] to match the public host.These settings are independent of baseVariants and must be maintained in parallel. There is no single source of truth in core that binds them together.
Use the site:list and site:show CLI commands with explicit context to compare resolutions:
# Web context (simulate production)
TYPO3_CONTEXT=Production ./vendor/bin/typo3 site:list
TYPO3_CONTEXT=Production ./vendor/bin/typo3 site:show mysite# CLI default context (what scheduler sees)
./vendor/bin/typo3 site:list
./vendor/bin/typo3 site:show mysiteCompare the base field in the output. A mismatch indicates drift. For automated checks, script a diff of site:show --format=json between contexts in your deployment pipeline.
Does your project run multi-site with shared codebase but different domains per environment (e.g., site-a.local, site-b.local locally vs. site-a.prod, site-b.prod in production)? If yes, a single static base per site definition cannot cover all environments; you would need environment-specific site configuration files or a deployment-time rewrite step.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.