This project is read-only.

Manually enabling a module

Topics: Core, Customizing Orchard, General, Troubleshooting
Oct 17, 2011 at 6:18 PM

So. I disabled the Publish Later module, under the suspicion that it may have added Apply/Save buttons that simply don't do anything (for some reason, the Publish Now button is the *only* one that will reliably save anything), and the site died, per this issue: [workitem:17114]. Claimed to have been fixed almost a year ago, clearly not fixed. Either that or core dependancies aren't being tested properly when enabling/disabling a module.

Anyway. I'm hunting for a method of manually re-enabling that module, since at the moment, I can't do *anything* on the site. Every single page errors, even on the admin. I downloaded everything from the App_Data folder into my local version, and determined that the DB doesn't specify that setting. Google isn't helping either, as all the results are for doing it through the admin panel, which obviously doesn't help me right now. So the question is, where the hell is that setting stored? My site is dead until I find it.

Oct 17, 2011 at 6:26 PM

Did you try through the command-line?

Oct 17, 2011 at 6:29 PM

I have no idea how I'd accomplish that on a live site. The local copy of the database is just fine. I don't have remote access to that server, only FTP.

Oct 17, 2011 at 6:38 PM

You said you downloaded everything and tried locally. That's why I mentioned the command-line.

Please re-open the bug if it is reproducing on 1.3.

Oct 17, 2011 at 7:20 PM

I'm on 1.2.41, and I don't see how the CLI would accomplish anything. I pulled down the database, and in doing so, proved that module activation settings are not stored there. Running the utility against the local module won't do me any good, as there's no issue locally, even with the production DB. That's why I'm saying, I just need to know where that setting is stored so I can flip it manually.

Oct 17, 2011 at 7:27 PM
Edited Oct 17, 2011 at 7:28 PM

Err, listen, I'm trying to help here. The command line will help because it has commands to enable and disable features that can work when all else fails. module activation settings *are* in the database and App_Data settings, you can trust me on that. How exactly did you determine that was not the case? Are you saying that your site works locally but not on the server? Did you pull absolutely everything from there? What error are you seeing exactly? Did you recycle the appdomain on the server?

Oct 17, 2011 at 7:34 PM

Sorry, I just get a bit testy when everything I find while searching on the subject says "yeah, we fixed it", and I'm staring right at evidence to the contrary. This site was supposed to go live a couple weeks ago, and Orchard has been causing issues keeping us from achieving that goal, and we're all a bit pissed right now.


None of the constructors found with policy 'Orchard.Environment.AutofacUtil.DynamicProxy2.ConstructorFinderWrapper' on type 'Orchard.Blogs.Services.BlogPostService' can be invoked with the available services and parameters:
Constructor 'Void .ctor(Orchard.ContentManagement.IContentManager, Orchard.Data.IRepository`1[Orchard.Blogs.Models.BlogPartArchiveRecord], Orchard.Tasks.Scheduling.IPublishingTaskManager)' parameter resolution failed at parameter 'Orchard.Tasks.Scheduling.IPublishingTaskManager publishingTaskManager'.

My evidence for saying that it isn't in the DB is that I pulled down the entire App_Data folder from the production (1.2.41 release build) site into my local project (1.2.41 dev build), didn't change anything else, and everything works. All my content types are there, and the Publish Later module that I disabled in production is enabled locally. The only folder I've really been keeping synced between the two versions is my Theme, and a couple custom field type modules. Everything else has been kept separate.

And what do you mean by "recycle the appdomain"?

Oct 17, 2011 at 7:44 PM

Aaaand it just magically decided to work again... will Orchard automatically re-enable any depended-on modules that are disabled when it restarts? The only difference between an hour ago and now is that my session timed out...

Oct 17, 2011 at 7:59 PM

Well, we only close bugs that we actually fixed, but regressions happen. What I mean by recycling the appdomain is to force the container of the app to restart, by touching web.config or by restarting IIS. Waiting for a timeout does the trick too...