-
Christian Kuhn authored
The frontend rendering aims to not load the full TCA including columns settings to reduce rendering time for full cache pages. This approach is ridiculous complex and using it is so hard to get right for developers that even core patches in this area are usually broken. The current situation is neither simple nor transparent. Currently, if no page cache entry exists during rendering, the whole ext_tables.php are executed, the page is rendered and stuffed to cache. While the full TCA is available at this point, it is reduced to the 'ctrl' sections for the next run, without 'columns', and stuffed to cache. On next access, the cache entry is used, ext_tables.php and TCA is not fully loaded. This leads to all sort of problems, if for example those pages contain USER_INT plugins that rely on some TCA settings. Furthermore, it might happen, that different plugins or the core then requires the ext_tables files more than once, which leads to funny problems if some developer does not know this and uses require_once instead of require inside ext_tables.php. Issues like that are very hard to track down. The current implementation relies on the methods TSFE->includeTCA(), TSFE->getCompressedTCarray() and GeneralUtility->loadTCA(), where especially includeTCA() with its parameter is so hard to understand that it is impossible to use in a correct way without digging through the content rendering for hours. The patch obsoletes all three of the above methods. Instead, from now on, the bootstrap in the frontend is configured to always load the full TCA including columns sections, even in full cached context. The only exception are eID scripts, but the existing API to load additional TCA in the eID controller is modified to also load all. On the downside, this patch costs around 30% of additional performance for the rendering of full cached pages. As soon as there is some USER_INT on a page, or if a page is not cached, the overhead is around zero. So, this patch costs performance for 'simple' pages, while it is of no effect for anything more complex. The goal is to reduce developer headaches at this point and to make the frontend rendering better predictable and more easy to maintain. It is furthermore one step to implement a better configuration handling in the long run. Change-Id: I5aecd542abe92f2de4ee0d40b5db44c493d304a3 Resolves: #45107 Releases: 6.1 Reviewed-on: https://review.typo3.org/17978 Reviewed-by: Oliver Hader Tested-by: Oliver Hader Reviewed-by: Wouter Wolters Reviewed-by: Anja Leichsenring Tested-by: Anja Leichsenring Reviewed-by: Christian Kuhn Tested-by: Christian Kuhn Reviewed-by: Mattias Nilsson Tested-by: Mattias Nilsson
d7b5d829