fix: use standard TYPO3 XLF label keys for backend modules#92
Conversation
TYPO3's BaseModule resolves module labels by appending standard key suffixes (mlang_tabs_tab, mlang_labels_tabdescr, mlang_labels_tablabel) to the XLF path. The module XLF files used non-standard keys (title, description, short_description), causing empty labels that trigger DropDownButton validation errors (InvalidArgumentException 1667645426). Rename translation unit IDs in all 4 module XLF files to match the keys TYPO3 expects. Signed-off-by: Sebastian Mendel <info@sebastianmendel.de>
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request addresses critical backend module loading and display issues within TYPO3 by standardizing the translation unit IDs in the module's XLF files. By aligning these keys with TYPO3's expected format, the system can correctly resolve module labels, thereby preventing Highlights
Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.Scanned FilesNone |
There was a problem hiding this comment.
Automated approval for solo maintainer project
This PR has passed all automated quality gates:
- ✅ Static analysis (PHPStan)
- ✅ Code style (PHP-CS-Fixer)
- ✅ Unit & functional tests
- ✅ Security scanning
- ✅ Dependency review
See SECURITY_CONTROLS.md for compensating controls documentation.
There was a problem hiding this comment.
Code Review
This pull request addresses a critical bug causing 503 errors in the backend by correcting the translation unit IDs in the backend module XLF files. The changes replace non-standard keys (title, description, short_description) with the TYPO3-standard keys (mlang_tabs_tab, mlang_labels_tabdescr, mlang_labels_tablabel) across all four module language files. This ensures that module labels are resolved correctly by TYPO3's BaseModule, preventing the InvalidArgumentException. The changes are consistent, correct, and directly fix the root cause described.
The 'admin' module group was introduced in TYPO3 v14. On v13, only 'tools' exists as the admin tools parent module. Using 'admin' causes the vault modules to silently fail to register on v13. Change to 'tools' which works on both versions: - v13: 'tools' exists natively - v14: 'tools' is an alias for 'admin' Signed-off-by: Sebastian Mendel <info@sebastianmendel.de>
There was a problem hiding this comment.
Automated approval for solo maintainer project
This PR has passed all automated quality gates:
- ✅ Static analysis (PHPStan)
- ✅ Code style (PHP-CS-Fixer)
- ✅ Unit & functional tests
- ✅ Security scanning
- ✅ Dependency review
See SECURITY_CONTROLS.md for compensating controls documentation.
## Summary - Fix backend module using `parent => 'admin'` which only exists in TYPO3 v14 - On v13, the `admin` group doesn't exist — modules with a non-existent parent silently fail to register - Changed to `parent => 'tools'` which works on both versions: - v13: `tools` exists natively as the admin tools group - v14: `tools` is an alias for the new `admin` group ## Context `composer.json` declares `^13.4 || ^14.0` support, but the module registration only worked on v14. Same issue was fixed in nr_vault: netresearch/t3x-nr-vault#92 ## Test plan - [ ] Install nr_llm on TYPO3 v14 — LLM module appears under Admin Tools - [ ] Install nr_llm on TYPO3 v13 — LLM module appears under Admin Tools - [ ] All submodules (Providers, Models, Configurations, Tasks, Wizard) accessible from docheader dropdown
… RTE - Add seed-pages.sql with demo page tree (4 pages, 5 RTE content elements) - Add seed-pages host command for manual re-seeding - Auto-import seed data (pages + Ollama config) in install scripts - Auto-activate cowriter RTE preset via page.tsconfig (TYPO3 standard) - Update Makefile: use ollama-pull target, handle errors gracefully Upstream fixes released for dependency issues discovered during testing: - nr_vault v0.4.1: XLF label keys + module parent v13 compat (netresearch/t3x-nr-vault#92) - nr_llm v0.2.2: module parent v13 compat (netresearch/t3x-nr-llm#74) Signed-off-by: Sebastian Mendel <info@sebastianmendel.de>
… RTE - Add seed-pages.sql with demo page tree (4 pages, 5 RTE content elements) - Add seed-pages host command for manual re-seeding - Auto-import seed data (pages + Ollama config) in install scripts - Auto-activate cowriter RTE preset via page.tsconfig (TYPO3 standard) - Update Makefile: use ollama-pull target, handle errors gracefully Upstream fixes released for dependency issues discovered during testing: - nr_vault v0.4.1: XLF label keys + module parent v13 compat (netresearch/t3x-nr-vault#92) - nr_llm v0.2.2: module parent v13 compat (netresearch/t3x-nr-llm#74) Signed-off-by: Sebastian Mendel <info@sebastianmendel.de>
… RTE - Add seed-pages.sql with demo page tree (4 pages, 5 RTE content elements) - Add seed-pages host command for manual re-seeding - Auto-import seed data (pages + Ollama config) in install scripts - Auto-activate cowriter RTE preset via page.tsconfig (TYPO3 standard) - Update Makefile: use ollama-pull target, handle errors gracefully Upstream fixes released for dependency issues discovered during testing: - nr_vault v0.4.1: XLF label keys + module parent v13 compat (netresearch/t3x-nr-vault#92) - nr_llm v0.2.2: module parent v13 compat (netresearch/t3x-nr-llm#74) Signed-off-by: Sebastian Mendel <info@sebastianmendel.de>
Summary
Two TYPO3 v13 compatibility fixes for backend modules:
1. Fix XLF label keys for module registration
The 4 module XLF files used non-standard translation unit IDs (
title,description,short_description) instead of the TYPO3-expected keys (mlang_tabs_tab,mlang_labels_tabdescr,mlang_labels_tablabel).TYPO3's
BaseModuleresolves labels by appending these standard suffixes to the XLF path — non-standard keys result in empty labels. Empty labels causeDropDownButtonvalidation to fail withInvalidArgumentException(code 1667645426), producing a 503 error in the backend.Affected files:
Resources/Private/Language/Modules/overview.xlfResources/Private/Language/Modules/secrets.xlfResources/Private/Language/Modules/audit.xlfResources/Private/Language/Modules/migration.xlf2. Use
toolsparent for v13 compatibilityThe module used
parent => 'admin', but theadminmodule group was introduced in TYPO3 v14. On v13, onlytoolsexists. Changed toparent => 'tools'which works on both:toolsexists nativelytoolsis an alias foradminRoot cause
XLF:
BaseModule::createFromConfiguration()(line ~251) appends:mlang_tabs_tabto thelabelspath when resolving module titles. The XLF files usedtitleas the translation unit ID, which doesn't match, resulting in an empty string. TheDropDownRadioitem'sisValid()check requires a non-empty label and throws when it's missing.Parent:
composer.jsondeclares^13.4 || ^14.0support, butparent => 'admin'only works on v14. Modules with non-existent parent silently fail to register.Test plan