This project is read-only.

Cleaning up erroneous modules?

Topics: Administration, Installing Orchard, Troubleshooting
May 16, 2011 at 3:05 PM

Is there any way to clean up, and by that I mean, completely remove all trace of, a module ever being installed?

The reason being, I came to roll out a site today, installed orchard core, got the latest modules I depended on (which included Contrib.Voting and Contrib.Reviews) and deployed my own module and theme. However, it turns out that the latest Contrib.Voting (which other modules depend on) has introduced a breaking change (changed the interface for IVotingService - method signature change from GetResults to GetResults with different params etc tsk! tsk!). As the other modules like Contrib.Reviews don't use this new interface yet, the dynamic compilation fails.

My work around was to remove the Contrib.Voting module, get the v1.0 release from orchard gallery and install that. However, because it's already known about 1.2 before now, the data schema is a little out of whack and so the module doesn't work (and I appear to get two "Voting" modules in orchard).

How do I remove all trace of this Contrib.Voting module without completely re-installing orchard?

May 16, 2011 at 7:32 PM

If you must, you need to go into the database and do it from there. Until someone builds a clean-up module.

May 17, 2011 at 1:06 PM

Would I be right in thinking I could drop the appropriate record tables and remove the data migration record?



May 17, 2011 at 1:11 PM

There are a few other possible tables to investigate, such as content definitions and part definitions. But yes, that's the basic method.

May 17, 2011 at 3:45 PM

I was thinking I'd build a module to do the clean up like this, but it feels a bit drastic. Maybe I'll just update the reviews module and submit a patch.

I guess it throws open another question about dependencies across teams in this modular eco-system. By rights, a published contract shouldn't change - the voting module should have continued to honour it's service interface that other modules depend on - is there any mechanism for module authors to specify an exact version of dependencies? Not even sure that could help though, I'd already installed 1.2 of voting before I installed reviews so reviews would have just failed install in this scenario but I'd of been in no less of a pickle ;)

May 17, 2011 at 6:10 PM

You can't specify a specific version for a dependency. It is correct that interfaces should not change in principle once published and depended on. Rather, a new one should be exposed. In practice, anything and everything will happen I'm sure, and things will break from time to time. Dependency management is not an easy problem ;)