This project is read-only.

Uninstall Orchard module completely

Topics: Administration
Aug 23, 2011 at 7:33 PM

Hi all!

This might be some lame question, but I can't find a way to remove an Orchard module completely. I would think of an option that would wipe out any changes the module has done to the database (I understand this could be difficult as this is not only deleting the module's tables) and delete the module files. Or would something like this be undesired? Only deleting the module dir would also be an option as this would remove the module's features from the features list but leave any data intact, so no references would brake and later the module could be reinstalled and the data could be retrieved.

Aug 23, 2011 at 7:49 PM

You're not the first one to ask :) Would be a great module.

Aug 23, 2011 at 8:06 PM
Edited Aug 23, 2011 at 9:47 PM

Wow, that means I haven't find the discussion with the other ones :-). I think I could implement this as it doesn't feel like a complicated task (famous last words...). I think removing the module's directory would be something quite easy to code (and would bring an instant satisfaction by removing its features from the list), however would leave the module's now junk data in the database. But currently I don't understand Orchard's data persistence model enough to see the safe way of removing the module's data.

Edit: as I see the installation of a module and enabling of a feature makes quite a lot of change to the database, so I have to dig a bit deeper how a safe data wipe-out could be possible.

Aug 24, 2011 at 12:30 PM

Now I see that the PackageInstaller class in Orchard.Packaging.Services in the Packaging module does delete the module (or theme) folder. However its database traces and its content types still remain.

So the easiest approach would be to make a backend UI for this implementation, together with what the Delete Content Types module does (however I can't see any possibility to directly use this module, as the necessary code is written in a controller action, not a separate class).

This would still leave some rows and tables in the database, which I'm not sure how to remove. Maybe the Orchard\Data\Migration\DataMigrationManager class can help, as there is an Uninstall method. However this would only run the Uninstall methods in the migration class, what module developers are not required to write (and therefore never write as far as I can see). Fortunately this would still bring us closer to the solution as this would wipe out data migration entries from the database.

All in all, with my current knowledge: the deletion of the module folder, its content types (together with content items) and migration data is implemented and can be more or less used directly. The deletion of content parts is not implemented, but using the ContentPartDefinitionRecord is could be easily achieved. The only flaw is that I can't see a way to delete the module's own tables.

However I think something like this should be an integral part of Orchard as directly deleting record entries looks a bit shaky for me.

Aug 24, 2011 at 6:37 PM

We might need to add some UnistallFromXXX() management in the migration. Then everything could be possible. Also, we are planning to include the Delete Content Type features by default.

Aug 25, 2011 at 1:55 PM

Requiring an uninstall migration method would indeed be the best option in my opinion too.  If I know correctly, this is the technique Wordpress also uses. But still I think it would be mandatory to keep track of the database tables a module creates, and delete them automatically when the module is uninstalled, without explicitly having drop table commands in an uninstall method. (Maybe there is some way to tell what a module's tables are even today? I can only think of filtering tables from the schema upon their name, as they are prefixed with the module's name.) This way, an uninstall method would only have to deal with special rollbacks (like deleting own folders outside the module folder), but modules today in the gallery could also properly be uninstalled.

Aug 25, 2011 at 7:56 PM

I disagree: deleting the tables should not happen automatically. In fact, I would recommend that the user is always prompted, even if/when there is a down migration. Also remember there are several ways in which a module can go away (deleting the directory should always work for example, and then you won't have an opportunity to run anything, so no down migration). You should in fact be able, if you want to, to remove a module, then add it back and still have your data.

I would much prefer to have a cleanup option that removes unused tables that do correspond to some module, based on the naming convention, to anything automatic. Accidental data loss is a much bigger issue in my opinion than having some unused tables in the DB.

Aug 25, 2011 at 11:41 PM

I agree with your disagreement :-). By "automatically" I've meant "done by the framework", not by the programmer of the module (as in having to explicitly write an uninstall method). I too think that users should have an option whether they want to completely wipe out the module or to only delete its files, leaving its data intact.