If I'm not missing something, module run_level can't be declared from module manifest files or environment/entry point, so it seems that there's no way of influencing core modules in general before they are manually switched ON in admin. Also, that means that there is no way to instruct the system that this module is "critical" for overall functionality.

There seems to be commented out code that would allow manifest run_level declaration in BModule constructor. Why is that commented out ?

What is the downside of allowing run_level declarations from manifest files ?

2 Answers


Hi, thank you for the question and sorry I've missed it.

I've disabled ability for module to force loading itself, to avoid breaking site or admin just by installing module's files. I believe it should be admin's decision to enable module manually.

Could you please provide a use case when module should be able to force loading immediately on files installation?


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.

Please log in or register to answer this question.

Know someone who can answer? Share a link to this