Duplicate Backend Layout Identifiers in Page TSconfig – Missing Uniqueness Check
0 reputation · 09 Jul 2026, 13:12 UTC
0 reputation · 09 Jul 2026, 13:12 UTC
The goal is to guarantee that each backend layout defined in Page TSconfig uses a unique identifier so that the backend layout dropdown reflects all available layouts and the rendered column structure matches the intended definition.
In TYPO3 10 LTS and 11 LTS the Page TSconfig parser processes entries under mod.web_layout.BackendLayouts. without checking whether already exists, allowing duplicate keys to be registered silently. When duplicates occur, the dropdown shows a single entry but the internal layout object used for rendering is taken from the last definition processed, which can cause unexpected column assignments and is hard to detect in multi‑extension projects.
Given this silent overwriting behavior, what practical steps can integrators take to identify duplicate identifiers during development or deployment? Are there configuration hooks, scheduler tasks, or extension points that can enforce uniqueness at runtime? Does a future TYPO3 release plan to add validation similar to the Site Configuration system?
31775 reputation · 09 Jul 2026, 16:09 UTC
In TYPO3 10 and 11 LTS, the Page TSconfig parser does not enforce uniqueness for keys under mod.web_layout.BackendLayouts. If multiple definitions use the same identifier, the last one processed silently overwrites all previous entries. This results in a dropdown that appears correct but renders columns based on the final definition, making it difficult to debug in complex, multi-extension environments.
Because the overwriting happens during the merge process, standard TSconfig viewing tools may not highlight the conflict. Use these steps to identify duplicates:
vendor/bin/typo3cms typo3:tsc:compile
Review the resulting files in typo3temp/tsconfig/compiled/. While the final array will only show the winner, comparing the source page.tsconfig files across extensions will reveal the duplicates.mod.web_layout.BackendLayouts to ensure no two extensions or configuration files use the same key.TYPO3 does not currently provide a built-in uniqueness validator for backend layouts similar to the Site Configuration system. To enforce this at runtime, you can implement a custom check via a backend hook or a scheduled task.
You can intercept the layout retrieval process to log warnings when conflicts are detected. Add a hook to ext_localconf.php targeting the layout utility:
$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['backend/layout/BackendLayoutUtility.php']['getBackendLayouts'][] = \MyVendor\MyExtension\Hooks\BackendLayoutHook::class . '::checkDuplicates';
In the hook class, compare the keys of the loaded layouts. If the count of unique keys differs from the expected count of definitions (if tracked), or if you are iterating through raw TSconfig arrays, log the duplication to the TYPO3 system log using GeneralUtility::log().
Integrate a custom PHP script into your CI/CD pipeline that parses all page.tsconfig files. The script should load the files, simulate the merge, and throw an error if the same key is encountered more than once before the application is deployed to production.
As of current versions, there is no official roadmap item to bring Site Configuration-style validation to Page TSconfig layouts. Validation remains the responsibility of the integrator through external linting or custom extension hooks.
To provide a more specific automated script, please specify if you are using a custom BackendLayoutProvider or if your layouts are defined exclusively via TSconfig.
Use comments to ask for clarification. Post a solution as an answer.
31,775 reputation · 09 Jul 2026, 15:39 UTC
In the Install Tool go to Configuration → Page TSconfig. After selecting a page, click the View raw TSconfig button to see the merged source from all extensions and user TSconfig. Use your browser’s find (Ctrl+F) to search for a layout identifier, e.g. MyLayout. If the term appears more than once, you have a duplicate key that will be silently overwritten by the last definition processed.