Hi, thank you.
There's a couple of use cases I could think off:
- Influencing install process and basic core code (for example adding project specific virtual pack in install process, or fixing the bug in Core). We would have to hack the core now, and it seems that manifest declared forcing is less evil then hacking the core files.
- Being able to install the custom developed eCommerce website (fixing the database sync problem during development). I know that this is rarely used, but it is very powerful way to control the development quality and cost. Now, we would have to declare the virtual pack and manually switch it on after installing Sellvana.
Even Sellvana is force loading some modules (SellvanaMarketClient) but it now does that from FComCoreMain::initModules() and FComInstallController::actionstep3__POST()
But the main thing really is that the person with enough access rights to change the file system should be considered as admin, probably even more technical admin then person with plain admin account (which will be merchant in most cases). What if developer develops some module which is critical for functionality, then merchant disables that module in backend. That might break the website also. I've actually just tested what would happen if I disable "FCom_LibTwig" from backend :-)
The manifest run_level ban has the perfect sense for modules installed via Marketplace, but for zip archived 3rd party modules outside the Marketplace, does it really makes a difference if website is broken when module is unzipped or switched on in backend ?
Finally it just seems very usable to allow both manifest and admin side declarations. The only downside that I could see is if that might introduce some conflicts between manifest and admin side declarations, but that should be possible to solve with priority rules or maybe having something like must use modules in separate folder which would then be hidden from manage modules.