IFeatureEventHandler, Enabling/Enabled features order

Topics: Core, Writing modules
Feb 13, 2012 at 2:19 PM

I've a feature "MyFeature" which depends on "Taxonomy". When MyFeature is enabled I want to add some entries to the taxonomy and I want to remove the taxonomy entries when MyFeature is disabled.

When both MyFeature and Taxonomy are not enabled and I enable MyFeature then 1. MyFeature will be enabled and 2. Taxonomy will be enabled. I'd expected that 1. Taxonomy will be enabled and 2. MyFeature.

http://orchard.codeplex.com/discussions/272451 shows that I'm not the first one facing this problem.

Will this issue be changed in 1.4 ? Or is there any workaround allowing me to ensure that Taxonomy is enable before MyFeature gets enabled? 

 

 

Coordinator
Feb 13, 2012 at 10:19 PM

No, this is not changed in 1.4. What would be nice would be to have additional events such as OnFeatureEnabled or OnFeatureDisabling.

Feb 13, 2012 at 10:27 PM

:-(

Any idea how I can ensure that Taxonomy is enabled before MyFeature gets enabled?

Coordinator
Feb 14, 2012 at 4:17 AM

No. Whatever you have to do, I would do it later, for example in an EnsureWhatever function that you'd call on the beginning of a number of methods that you know one of which will have to be called the first time your module does something.

Feb 14, 2012 at 1:08 PM
Edited Feb 14, 2012 at 1:08 PM

From a UX point of view this seems to be not really nice as this would mean that a user needs to access our module at least once before they can go to the taxonomy settings.

My first idea of a workaround (http://orchard.codeplex.com/discussions/310576) also doesn't work - as it seems that the ShellDescriptor is only updated once after ALL features had been enabled/disabled and not after a state change of EACH feature :-(

It also seemed strange to me that disabling was done in the right order, just enabling was in the wrong/reversed order.

So I tried to locate the cause of this issue. I think I found the cause in ShellStateCoordinator.cs

In line 174 the order is Reverse(). - that's correct in the blocks above when disabling items, but seems to be wrong when enabling:

foreach (var entry in allEntries.Reverse().Where(entry => IsRising(entry.FeatureState)))

After changing the line to:

foreach (var entry in allEntries.Where(entry => IsRising(entry.FeatureState)))

the events are fired in the right order.

Is this correct? What should I do to ensure that the fix is included in 1.4?

 

Coordinator
Feb 15, 2012 at 1:22 AM

I'm not saying that it's ideal, just trying to find a workaround so you can go on with your module.

If you want that fix included, please file a bug and attach your patch. But I have to mention that I think this has been looked at before and it's not as simple as just writing this, if I remember correctly. In any case, we'll review it and make a decision from there.

Thanks.