This project is read-only.

IFeatureEventHandler, Enabling/Enabled features order

Topics: Core, Writing modules
Feb 13, 2012 at 3: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. 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? 



Feb 13, 2012 at 11: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 11:27 PM


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

Feb 14, 2012 at 5: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 2:08 PM
Edited Feb 14, 2012 at 2: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 ( 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?


Feb 15, 2012 at 2: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.