We recently upgraded a TYPO3 11 installation to 12. We have a multisite installation where many sites have a constants file included with something line
<INCLUDE_TYPOSCRIPT: source=“FILE:fileadmin/xyz/constants.txt”>
( I know this is deprecated in 13, but this will be another problem).
Up until TYPO3 11, when changes to this file were made, and the page cache for a page was cleared, those changes would be picked up and show up in the frontend.
Since TYPO3 12, this is no longer the case. Clearing the page cache does not reload the included constants file. Only the admin with the “flush frontend caches” button can clear these caches, but that is undesirable for us as as we need our users to be able to make changes and clear only their own page caches.
I could not find any documentation for this change or bug report. So the question is whether this is by design or a bug.
I have tested your setup in TYPO3 v12.4.29 and v13.4.8, and I’m able to reproduce the issue: Clicking the “Clear cache for this page” button (lightning icon) on a page does not clear the cache for an included TypoScript file (even as an admin). Clearing the cache using the global clear cache menu (only available to admins), does clear the cache and changes in the TypoScript file become visible.
I have submitted a bug report as an issue on forge.typo3.org. Please watch the issue to be alerted if there is progress on the issue or questions from the developers. Please also update the issue with any further information omitted by me.
I’m note sure if what we see here is due to an intentional limitation, but it is strange that it works with one type of cache clearing and not the other. I can see some security issues with allowing your (non-admin) users to edit the content of TypoScript files, and letting those files reside within fileadmin/. As you say, this exact functionality is only possible with INCLUDE_TYPOSCRIPT, and not with @include.
Thank you for checking this out and submitting the bug report.
I also understand your concerns about possible security implications. However, I do not see any other way to allow non admins to change certain parts of their sites (it’s a multisite setup).