Bug #91443
closed
Environment Variable in SiteConfiguration gets cached
0%
Description
I have set up an environment variable in the htaccess file ..…
SetEnvIf Host "^domain1\.com$" ERROR_CONTENT_SOURCE=t3://page?uid=1489
SetEnvIf Host "^domain2\.com$" ERROR_CONTENT_SOURCE=https://domain3.com/404/
... and use it in the yaml file of the site configuration:
errorContentSource: '%env(ERROR_CONTENT_SOURCE)%'
If I now open domain1.com/xyz, the desired error page appears. If I then open domain2.com/xyz, the error page set up for domain1 appears - but if I clear the cache first, the correct error page appears. The other way round it is exactly the same: the variant that is called first is set in the cache.
Updated by Benni Mack over 4 years ago
- Status changed from New to Needs Feedback
Hey Ben,
yes - this is on purpose. If we would consider env vars for every request, we would need to parse the Site Configuration on each request, which would drastically slow down the performance. Can you explain your set up and what you are trying to achieve?
Updated by Benjamin Robinson over 4 years ago
I have a multilingual project, where some of the languages are still in work and should not be published yet. I can remove the affected translations from the language-menu and set them to noindex via TypoScript, but then hreflang tag links from the other languages would still be generated ( see issue https://forge.typo3.org/issues/91353 ).
For this reason I have to disable the languages completely (enabled:false in config.yaml). A deactivated language can only be viewed in the FE if you are logged in in BE at the same time under the same domain.
Sometimes the editors forget to log into the backend before they try to access the FE. Then the error handling is triggered. But the error handling fails and produces an entry in the error log, because the internal 404 page (internal page of the deactivated language) is not accessible.
And for this reason I would have to define a different (external instead of internal) 404 page for deactivated languages.
———
I would also like to use the env vars for the "base" entries of the translations in config.yaml to switch between the applicationContext. I know that I can now also manually enter baseVariants for the translations, but these entries will be overwritten if someone makes changes afterwards using site modules in the backend. Here it is also problematic if the entries are cached.
Updated by Timo Webler almost 4 years ago
An other use case, is the usage of the environment variable HTTP_HOST for static routes.
For example a robots.txt file as static routes with an entry for a sitemap.
routes:
-
route: robots.txt
type: staticText
content: |
User-Agent: *
Allow: /typo3conf/ext/*/Resources/Public/
Allow: /typo3temp/assets/
Disallow: /t3lib/
Disallow: /typo3/
Disallow: /typo3conf/
Disallow: /typo3temp/
Sitemap: https://%env(HTTP_HOST)%/de/sitemap.xml
The content of the robots.txt is always cached with the first hit of HTTP_HOST and not for every root page within the TYPO3 instance.
The usage of references like %base% can also not used, because the base variants was not evaluated at these point.
Updated by Georg Ringer 4 months ago
- Status changed from Needs Feedback to Closed
hey,
still closing the issue because caching is required here.
you can of course still use a custom middleware to implement alternatives but we won't change it in core - hope you understand
for previewing languages, I can btw recommend https://packagist.org/packages/b13/authorized-preview
Updated by Benjamin Robinson 4 months ago
Yes, I understand that. Thanks for the link.