This project is read-only.

Optimising Orchard Dashboard: Sort modules on version in Gallery?

Topics: Administration, General
Oct 11, 2012 at 9:24 AM

I'm a new user of Orchard and right now im trying out som different modules for Orchard 1.5. 

Some of the old modules seems to fail to work cause they´re already implemented in the new release or maybe casue they are builded for the older version of Orchard.

Anyway. My suggestion is that the gallery should only show the modules that are compatible with the current installed version on the developers platform.


Is that a bad idea? 

Oct 11, 2012 at 4:57 PM

How do we know?

Oct 11, 2012 at 6:14 PM

By reporting module failure back to gallery server? Maybe not the easiest thing to implement but if done very neat feature. Taking if further gallery could keep track of number of active installation per module (vs downloaded) on specific version etc.,

Oct 11, 2012 at 6:31 PM

I recall there's been a discussion about that a while ago. The best way would be to have minimum and maximum supported Orchard version specified in each module manifest, instead of one as we have now. This information could be also be available in Gallery feed, making filtering very easy to implement.

@gkumik Reporting installation problems back to the Gallery and tracking active installations seems reasonable. I wouldn't use that information for filtering, though, as installation errors might also be the already installed modules' fault.

Oct 11, 2012 at 6:49 PM

One problem with that approach is module creators can't know ahead of time which future versions of Orchard their module will be compatible with.  


Firefox uses a similar method. In one project I used Selenium for testing, and to get the Selenium FF add-on to run I often had to hack up Selenium's packaged browser add-on to get it to run in the newer versions of FF. Everything was fine, it just didn't know at author time which FF versions it would continue to run on. The approach was pessimistic, and prevented modules from running that would run perfectly fine. I think it's actually fine in most cases for a browser because the popular add-on's are usually updated as FF releases new versions. But this could be annoying in a system like Orchard, where people create modules and then abandon them for months/years at a time, or forever. 

So this system would work as long as it were optional, e.g., search filter that you could turn off, and doesn't prevent you from installing older modules, or allows you to "force install" modules you know will work but just don't have the right metadata for newer Orchard versions.

Oct 11, 2012 at 6:59 PM

Exactly. That's not practical at all. I think only user feedback is the way to go here for version certification. But that would require changes to the gallery, which is unfortunately close to unmainatainable at this point.

Oct 11, 2012 at 7:08 PM

Why is the gallery unmaintainable? 

Oct 11, 2012 at 7:29 PM

For a lot of reasons. Running old code that is hard to upgrade (and we have zero time for it), deployment is very hard, the dual-server design is getting in the way, etc. It needs to be redone.

Oct 11, 2012 at 7:44 PM

Intresting.... It sounds totally like the Umbraco 5 situation just before they shutted down... Hope it dosen´t happens here. Really like Orchard so far. :P

Oct 11, 2012 at 8:12 PM
Edited Oct 11, 2012 at 8:12 PM

We're only talking about the gallery, to be clear, not Orchard itself. So I don't see how it looks anything like the Umbraco 5 fiasco.

Oct 11, 2012 at 8:28 PM

Thank you for the clarification. :)

Oct 11, 2012 at 8:38 PM

I agree that any improvement would require changes to gallery server and that setting supported max version in module is not practical. On the other hand I still believe that automatic or semi-automatic sending of errors, event (e.g.: enabled) or maybe even user/admin feedback from Orchard installation to gallery would be better than requiring users to do anything explicitly on gallery page.
@bertrandleroy how big is the delta between Orchard and Nuget packages, feeds? Maybe switch to plain/extended Nuget server is a way to go?

Oct 11, 2012 at 9:10 PM

Yeah, I agree with you guys that this max version-based filtering solution is not practical, especially when modules are being rarely updated, abandoned etc. User feedback would be way better.

@gkumik I guess building an Orchard "Gallery Server" module around NuGet server would be a good starting point for the new Gallery.

Oct 11, 2012 at 10:02 PM

@gkumik: just look at the gallery site and try to estimate how different it is from a plain nuget feed. The answer is close to 100%. I think we could use some sort of CMS as a starting point as well. Somebody knows of a good one?

Oct 11, 2012 at 10:09 PM
bertrandleroy wrote:

@gkumik: just look at the gallery site and try to estimate how different it is from a plain nuget feed. The answer is close to 100%. I think we could use some sort of CMS as a starting point as well. Somebody knows of a good one?


Oct 11, 2012 at 10:13 PM

We should ask Bernard. I think he's involved with some .NET CMS. 

Oct 12, 2012 at 10:19 PM

100% different feeds but still almost the same functionality ;) Gallery as the Orchard module.... maybe even better.