Do not auto-update PackageStates.php if ext folder is missing
Consider this scenario:
- Dev has local environment
- Dev pulls latest git state with changed compsoer.json
- Dev opens Backend
- PackageState changes, because dev forgot to run
composer installfirst and the core updated PackageStates due to missing ext-folders
- Dev has to fiddle around to get a correct state again
The core should only update PackageStates when explicitly an extension-related button is clicked or a command is executed or when the LTS version changed (e.g. upgrade 8 -> 9).
If there's a mismatch between PackageStates and ext-Folders there should be just a warning without auto-altering the PackageStates file instead. Like "There's a mismatch between configured and installed extensions, please check."
#1 Updated by Benni Mack 10 months ago
- Status changed from New to Needs Feedback
This sounds like a wild scenario. I would strongly recommend in your case to use typo3-console and the generatedpackagestates command and NOT worry about packagestates anymore. This is a very complicated scenario (failsafe, extensions with a broken ext_localconf.php etc). In any case, there will be some changes in future TYPO3 versions regarding PackageStates, modifying the current status is really complicated, so I would not "patch" this in current versions. Is that OK with you?
Also, maybe a git post-pull hook could be used to automatically run composer install?
One other nice idea: If your composer.lock and composer.json mismatch, this should be displayed and put PackageStates into read-only mode?
Since this is an annoyance at development time and not a runtime bug this is fine for me.
I always found that the core is updating system files way too lighthearted, not only PackageStates, but also LocalConfiguration for example.
Re-interpreting/reporting configuration changes at runtime is fully OK, but actually changing "physical" files should always be an explicit action.