Bug #103009
open
Import of Initialisation Files not working in typical dev setup
0%
Description
When developing your extension, the import of your Initialisation/Files is not working because the path handling wont support the directory structure.
The "typical" setup will be the following:
{
"config": {
"vendor-dir": ".Build/vendor",
"bin-dir": ".Build/bin"
},
"scripts": {
"post-autoload-dump": [
"cd .Build/vendor && mkdir -p my_vendor && rm -f my_vendor/my_package && ln -s ../../.. my_vendor/my_package && cd -; fi",
"mkdir -p .Build/config/system && cd .Build/config/system && ln -sf ../../../Resources/Private/Build/additional.php && cd -; fi"
]
},
"extra": {
"typo3/cms": {
"web-dir": ".Build/Web",
"cms-package-dir": "${vendor-dir}/typo3/cms",
"extension-key": "your_key"
}
},
"minimum-stability": "dev",
"prefer-stable": true,
"require": {
"php": "^8.2",
"ext-SimpleXML": "*",
"ext-json": "*",
"typo3/minimal": "^12.4"
},
"require-dev": {
"typo3/testing-framework": "^7",
"typo3/cms-setup": "^12.4"
}
}
It can be seen in many many extensions and is documented here:
https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/Testing/ExtensionTesting.html
The "ProjectPath" will not contain your Extension folder and this will lead to non-existing paths:
https://github.com/TYPO3/typo3/blob/main/typo3/sysext/core/Classes/Utility/GeneralUtility.php#L2498
Like mentioned [here](https://forge.typo3.org/issues/102993), there is a setting, that we could use to solve the issue but it is not consistently used in the core:
assuming your setup utilizes a docker container and your extension code is mounted to /app:
$GLOBALS['TYPO3_CONF_VARS']['BE']['lockRootPath'] = '/app/';
The inconsistent path handling existed in earlier versions as well but this problem only affects TYPO3 12+ with composer mode. I guess before the package path has been typo3conf/ext/your_key and now its the absolute path (/app). So this seems to be related to the composer api of typo3.
Updated by Philipp Wrann 3 months ago
The issue (and many other issues related to this problem) may be solved very easily:
The package path for the local dev Package should be the symlinked one (.Build/vendor/your_vendor/your_package) insteadof the realpath. By doing that, the package will be "within" your project folder.
This bug is pretty severe and nasty, at this point i can't tell what it might affect as well!
What i noticed along the way: When generating keys for sys_registry, the core will sometimes strip the public path from the absolute path and it does that by using substring, with extensions stored in /vendor (not inside the public path), this will lead to wrong keys and might cause things to be executed twice!