Hi All,
i think supplying built-in debugging tools is not the way to go, the module loading process just needs to be more stable. There should be no possible way to corrupt module info in DB. There are several ways where things can go wrong, for example: Question: There are entries whose files do not exist, do you want to delete them? Yes: I want a working shop, No: I want rubbish in my DB? Why would anyone ever want to choose no? If no is chosen, you'll get "Module cannot be loaded" if you have moved the module. Logging off and on fortunately brings up the dialog again. When a module is moved, sometimes the wrong path is still in DB (aModulePaths). The module appears in the list, but empty, no title or anything, this shouldn't be possible. Deleting aModulePaths helps in this case. Blocks never get updated or removed once written. I wrote myself a module that removes blocks when deactivating a module, all info is in the module anyway. Regards, Frank Zunderer Zunderer IT Beratung Waldstr. 22 82205 Gilching 08105-777250 0173-8362768 [email protected] Von: [email protected] [mailto:[email protected]] Im Auftrag von OLIGOFORM GbR Gesendet: Mittwoch, 17. Juli 2013 14:25 An: [email protected] Betreff: Re: [oxid-dev-general] How to remove modules completely +1 for that, Joachim! oliver Am 17.07.2013 um 14:19 schrieb Joachim Barthel <[email protected]>: Guys from OXID, take it as an experience and offer us in future some built-in functions, because trying one module after the next and deleting thing somehow in the database doesn't look very serious, esp. when you have to do this at the customers shop ;-)
_______________________________________________ dev-general mailing list [email protected] http://dir.gmane.org/gmane.comp.php.oxid.general
