Feature #89836

Do not auto-update PackageStates.php if ext folder is missing

Added by Stefan P 11 months ago. Updated 8 months ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Extension Manager
Target version:
-
Start date:
2019-12-03
Due date:
% Done:

0%

PHP Version:
Tags:
Complexity:
Sprint Focus:

Description

Consider this scenario:

  1. Dev has local environment
  2. Dev pulls latest git state with changed compsoer.json
  3. Dev opens Backend
  4. PackageState changes, because dev forgot to run composer install first and the core updated PackageStates due to missing ext-folders
  5. 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."

History

#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?

#2 Updated by Stefan P 10 months ago

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.

#3 Updated by Georg Ringer 8 months ago

  • Status changed from Needs Feedback to Closed

closing this issue for now

Also available in: Atom PDF