Project

General

Profile

Actions
Copy link

Bug #91443

open

Environment Variable in SiteConfiguration gets cached

Added by Benjamin Robinson almost 4 years ago. Updated over 3 years ago.

Status:
Needs Feedback
Priority:
Should have
Assignee:
-
Category:
Caching
Target version:
-
Start date:
2020-05-19
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
10
PHP Version:
Tags:
Complexity:
Is Regression:
Sprint Focus:

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.

Actions
Copy link
 #1

Updated by Benjamin Robinson almost 4 years ago

  • Description updated (diff)
Actions
Copy link
 #2

Updated by Benni Mack almost 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?

Actions
Copy link
 #3

Updated by Benjamin Robinson almost 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.

Actions
Copy link
 #4

Updated by Timo Webler over 3 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.

Actions
Copy link

Also available in: Atom PDF