Please help!

Topics: Administration, Troubleshooting
Nov 30, 2011 at 2:07 PM
Edited Nov 30, 2011 at 2:10 PM

Hi,

After installing the counter module I have 

500 - Internal server error

 

this is a live site and it is down now. Please help. How to restore it to the previous state? I can't even access my dashboard.

The site name: http://inferta-usa.com/

 

p.s. Just to clarify about the counter module it is this one:

http://gallery.orchardproject.net/List/Modules/Orchard.Module.NGM.ContentViewCounter

Nov 30, 2011 at 2:15 PM

remove the counter folder from the modules directory till you fixed it.

Nov 30, 2011 at 2:22 PM

Thanks! That helped. Appreciate your response

Developer
Nov 30, 2011 at 2:41 PM

Have you installed its dependency, Contrib.Voting too?

Nov 30, 2011 at 3:04 PM

No I haven't. I will try now. Thanks for advice. It was not very clear that it is a prerequisite...

Developer
Nov 30, 2011 at 5:33 PM

Yeah, currently there is no mechanism of enforcing dependencies other than requesting users to install them. This will change a bit in the next release, though.

Coordinator
Nov 30, 2011 at 5:44 PM

Yesterday I pushed a changeset preventing extensions from installing if they are not tagged with the correct OrchardVersion in the manifest.

Today I will work on preventing extensions from activating if they are missing a dependency: this issue.

Nov 30, 2011 at 5:54 PM
Piedone wrote:

Have you installed its dependency, Contrib.Voting too?

Contrib.voting has also crashed my system. All other modules are installing great... from local machine.

 

orchard is a great cms

Coordinator
Nov 30, 2011 at 6:01 PM

How can Voting crash your system, it's pure awesomeness !

Nov 30, 2011 at 6:39 PM

well I had 500 internal after installing it... :)

Nov 30, 2011 at 6:46 PM
sebastienros wrote:

Yesterday I pushed a changeset preventing extensions from installing if they are not tagged with the correct OrchardVersion in the manifest.

Today I will work on preventing extensions from activating if they are missing a dependency: this issue.

About this ... how will it work? e.g. my modules that declare Orchard 1.2, will they literally refuse to install on Orchard 1.3, even though in fact they are still compatible? Will there be a way to specify a version range, e.g. 1.2+ (or does it assume that version or above anyway) ... or will we just have to release multiple versions of the same package if we want to support multiple versions of Orchard?

Coordinator
Nov 30, 2011 at 7:50 PM

If you say 1.2, it will work on 1.3.

If you say 1.3, users with old Orchard version won't be able to install this module's version.

If 1.3 breaks your old module, then YOU should release a fix. This scenario should not be expected as we tend to provide default implementation for new methods, or method overloads.

Nov 30, 2011 at 8:32 PM

Ok that's great, at least in most situations forward compatibility isn't the problem. (Actually there's an upcoming issue with 1.x because I use a SettingsDictionary in one model and the storage mechanism has changed as you will know... But I can maintain separate versions for a while for just that module.)

Nov 30, 2011 at 9:39 PM
Edited Nov 30, 2011 at 9:40 PM
sebastienros wrote:

Yesterday I pushed a changeset preventing extensions from installing if they are not tagged with the correct OrchardVersion in the manifest.

Today I will work on preventing extensions from activating if they are missing a dependency: this issue.


Thanks for this.

Our internal testing of Orchard found it extremely fragile because of this with a workitem of, "Disable the ability to Enable Extensions from the Production Release" because we can't afford to bring down the entire site if someone decided to enable an extension.

This will help a lot.

Though, it still doesn't address rogue extensions that are just poorly coded.  As I do vet all code in a module before enabling them in development environments, I doubt everyone that uses Orchard will do the same.

Coordinator
Nov 30, 2011 at 9:47 PM

Note that you actually should not enable the gallery at all in a production environment, in principle, and independently of this bug. Modules should be installed on dev boxes and then deployed.

Nov 30, 2011 at 11:47 PM

If you're in a situation where you can't afford problems on your production server, then you definitely shouldn't be installing anything "blind". On my server I have a crude staging system - a SQL script to clone the database, and a Powershell script which uses robocopy to clone the entire physical site. Then I can test any new modules or updates directly against my current database and files. You could take this further and integrate automated unit tests to guarantee important business functions are still running. Orchard has plenty of testability rolled in, including SpecFlow which lets you test a whole load of front end stuff that's normally very hard with unit testing. How far you want to go really just depends how mission critical your application is.