And if I may add, after you fixed the syncing between the module state in the db and the module state in the module directory, please make onActivate handlers more comfortable.
A common use case for onActivate is adding new database tables and columns. However there are obstacles: 1. There is no method to empty tmp/, you have to implement that yourself 2. There is no reasonable way to introduce new multilangual database tables. If you make such a table known to the system by extending oxLang, you still won't have it available in onActivate, therefore no views are created. It might be possible to do this by manipulating the relevant config parameter on the fly, but that is still an ugly hack. And please add error messages! You never know what went wrong. If the module doesn't activate I expect a decent error message! And if the onActivate handler is not found, I expect a decent error message as well! At the moment developing with the new module system is no fun at all, please feel free to improve on that. regards Gernot Payer ________________________________ Von: [email protected] <[email protected]> im Auftrag von Joachim Barthel <[email protected]> Gesendet: Mittwoch, 17. Juli 2013 22:09 An: [email protected] Betreff: Re: [oxid-dev-general] How to remove modules completely Maybe my last statement was too short or misunderstandable: I do not want to have a built-in function for fixing problems caused by a not sufficient implementation. The module loader itself has to be extended. - Joscha has reported, that upgrading a module with new blocks kills the mechanism - I found out, that moving the module one level deeper (by inserting the vendor folder) kills it - ... Therefore, please take some time and make the really good and powerful idea of module registration to a stable solution, which - doesn't come to a deadlock on standard situations - displays error messages, when the data (eg. metadata.php) are wrong Cheers Joachim Joachim Barthel ----------------------------- OxAds<http://exchange.oxid-esales.com/de/Marketing/Produktmarketing/OxAds-0-3-Stable-CE-4-3-x-4-7-x.html> -- OxProbs<http://exchange.oxid-esales.com/de/Datenmanagement/Produktdaten/OxProbs-0-4-Stable-CE-4-3-x-4-7-x.html> -- Piwik-Plugin<http://exchange.oxid-esales.com/de/Controlling/Data-Mining/OXID-Plugin-fuer-Piwik-0-10-Stable-CE-4-3-x-4-7-x.html> -- jxAttrEdit<http://exchange.oxid-esales.com/de/Datenmanagement/Artikel-bearbeiten/jxAttrEdit-0-2-Stable-CE-4-7-x.html> -- jxExcptns<http://exchange.oxid-esales.com/de/OXID/Weitere-OXID-Extensions/jxExcptns-0-1-1-Stable-CE-4-7-x.html> -- jxSales<http://exchange.oxid-esales.com/de/Shopping-Prozess/Kundenmanagement/jxSales-0-2-Stable-CE-4-7-x.html> 2013/7/17 Arturas Sevcenko <[email protected]<mailto:[email protected]>> Interesting, alone - we couldn't reproduce it. But actually we were interested in investigating this issue (Frank thanks for your useful hints!) and will request a task for that. Actually, the debugging functionality was intentionally published as a module as we wanted to avoid users with no technical knowledge to play around with it. Well - the module should have been made more official. Arturas Sevcenko Software Developer From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Frank Zunderer Sent: Wednesday, July 17, 2013 4:39 PM To: [email protected]<mailto:[email protected]> Subject: Re: [oxid-dev-general] How to remove modules completely 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<tel:08105-777250> 0173-8362768<tel:0173-8362768> [email protected]<mailto:[email protected]> Von: [email protected]<mailto:[email protected]> [mailto:[email protected]] Im Auftrag von OLIGOFORM GbR Gesendet: Mittwoch, 17. Juli 2013 14:25 An: [email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]> http://dir.gmane.org/gmane.comp.php.oxid.general
_______________________________________________ dev-general mailing list [email protected] http://dir.gmane.org/gmane.comp.php.oxid.general
