You are here

Remove orphan module detection

On the clean up page shown after disabling a module, the admin user is invited to disable possible orphaned dependencies or leave them.

This is done by checking modules and clicking 'Disable selected modules.'

This feels really counter-intuitive, as every else in Drupal core or features you check things you want to keep, not things you want to remove.

This page should match that -- keep the checkboxes but label the column 'Enabled' like on module admin, and change the button to 'save settings'. To make it clear what is going to happen, the boxes should probably be initially selected -- add a tableselect checkbox at the top to allow quickly deselecting all the modules listed.

Comments

I'm not sure I agree with this - the action being taken here is "Turning off modules", and it's not just a page that "saves settings". It's actively taking a further step, and therefore I think the checkboxes should positively reflect that action.

Thoughts from anyone else? I'd love to know what the Sprocket guys think as they were the ones who initially requested this feature.

It is an action, but having the UI visibly mean the reverse of what a checkbox + module name normally means results in the user having to do brain contortion to figure it out -- it's like negative statements on checkbox labels.

Features will enable needed modules for me, but by staying quiet when they're disabled, it'll just leave cruft behind. Shouldn't it at least tell me about it? And if it can tell me, it might as well offer to do it too (I don't want to have to visit the modules page afterwards).

It has an issue with false positives, granted, but shouldn't it be fixable by only taking the now un-depended modules that was actually dependencies of the feature just uninstalled? I thought it was supposed to do that.

I don't see how features can ever make an accurate decision on what those modules are. For install profiles some of those modules may have been enabled from the profile and not from a feature. Some may have been manually enabled. I currently get offered to disable modules when enabling a feature. I even was offered to disable the feature I was enabling. While it has merits in theory in practice I don't think it quite works and is often more confusing than helpful.

I think at most it should just state that these modules were part of the feature you disabled and you may want to disable them also, but even that should be an optional message.

Even if you could get a perfect list of modules that have no current dependencies, that still doesn't mean a user will want to disable them - I just got prompted to disable date and entity api among many other modules that are fairly fundamentally important to my site. Even if I disabled the last feature module using a date field, that has no bearing on whether or not I want to continue using the date module.

In other words, I don't think your future usage of other modules is really much related to features to begin with.

+1 to removing this feature. Lots of other modules come with example Features (Flag and Rules come to mind), and leaving these features disabled means that you'll always get "orphaned dependencies" for those modules.

We want to encourage people to provide Features integration with their modules. We want to encourage people to provide example code. The current behavior punishes module creators for their "good" practices, by insisting on a poor user experience for their install base.

Alternatively, we could do a proper implementation: record when a Feature *which has previously been enabled* is disabled, and offer a tab in the Features interface that lists Orphaned Dependencies based on that list of disabled modules. Then we can display an admin message sitewide that prompts the administrator to review this page. We could also have a way for users to mark an orphaned dependency as "ignored" so it doesn't produce these messages in future.

But that sounds like a lot of work for something that is peripheral to Features at best.

I'm all for this also. Anybody who wants this functionality added back to Features will need to submit a patch with a much better way of handling orphan detection. This was definitely causing more trouble than it was solving. Committed this removal to f77f1d8.