In the Features list UI, if a module has a conflict with another module that is already disabled, it would be nice if the color of "conflict" was dimmer to distinguish this case from "real" conflicts.

In other words, if I disable a base distro feature that I *know* I have cloned and customized, I don't like having both of them still show as being in conflict all the time, since it doesn't actually cause any site problems. Compared to a *real* conflict between two enabled modules.

CommentFileSizeAuthor
#8 features-conflicts-modules-colors-1426452-8.patch2.94 KBmpotter
#7 features-conflicts-modules-colors-1426452-7.patch3.04 KBmpotter
#6 features-conflicts-modules-colors-1426452-6.patch2.94 KBmpotter
#5 features-conflicts-modules-colors-1426452-5.patch2.94 KBmpotter
#1 features-conflicts-modules-colors-1426452-1.patch2.79 KBrypit
#1 Screenshot28.47 KBrypit

Comments

rypit’s picture

rypit commented
Status: Active » Needs review
StatusFileSize
new Screenshot28.47 KB
new features-conflicts-modules-colors-1426452-1.patch2.79 KB

Attached is a patch that "greys out" conflicts with disabled modules, and makes bright red conflicts with other enabled modules.

Grayside’s picture

Grayside commented

That seems like it might be too extreme. There are two basic situations in which you need to know about a conflict:

  1. Something is wrong, and you need information to try fixing it.
  2. You are about to turn on another feature, and need to know it won't break anything.

Theming in this case shouldn't entirely de-emphasize the disabled conflict. What might make sense is considering, as a separate issue, including enabled, conflicting features in the site's status report. That's already a trained "check this for problem states" and would reduce the confusion implied by this issue for site builders and developers dealing with Use case #1.

mpotter’s picture

mpotter commented

Actually, I really like this one.

My situation is a bit different:

3. You have purposely cloned a feature from a distribution and changed it (and then disabled the distro feature).

In this case I no longer care that my feature conflicts with the disabled distro feature. De-emphasizing this helps me distinguish from features with *real* conflicts vs the "known" conflict with the disabled module.

hefox’s picture

hefox commented 
@@ -89,13 +89,20 @@ function template_preprocess_features_admin_components(&$vars) {
 function theme_features_module_status($vars) {
   switch ($vars['status']) {
     case FEATURES_MODULE_ENABLED:
-      $text = !empty($vars['module']) ? $vars['module'] : t('Enabled');
+      $text_status = t('Enabled');
+      $text = !empty($vars['module']) ? $vars['module'] . ' (' . $text_status . ')' : $text_status;
       return "<span class='admin-enabled'>{$text}</span>";
     case FEATURES_MODULE_DISABLED:
-      $text = !empty($vars['module']) ? $vars['module'] : t('Disabled');
-      return "<span class='admin-disabled'>{$text}</span>";
+      $text_status = t('Disabled');
+      $text = !empty($vars['module']) ? $vars['module'] . ' (' . $text_status . ')' : $text_status;
+      return "<span>{$text}</span>";
     case FEATURES_MODULE_MISSING:
-      $text = !empty($vars['module']) ? $vars['module'] : t('Missing');
+      $text_status = t('Missing');
+      $text = !empty($vars['module']) ? $vars['module'] . ' (' . $text_status . ')' : $text_status;
+      return "<span class='admin-missing'>{$text}</span>";
+    case FEATURES_MODULE_CONFLICT:
+      $text_status = t('Enabled');
+      $text = !empty($vars['module']) ? $vars['module'] . ' (' . $text_status . ')' : $text_status;
       return "<span class='admin-missing'>{$text}</span>";

this switch statement contains a bit of duplicate logic

$text_status = t(...);
$class = '...'
break;
}


$text = !empty($vars['module']) ? $vars['module'] . ' (' . $text_status . ')' : $text_status;
return '"<span class="$claass">$text</span>"

would prob make it a bit cleaner to read.

mpotter’s picture

mpotter commented
StatusFileSize
new features-conflicts-modules-colors-1426452-5.patch2.94 KB

Cleaned up per hefox and also added a new class to the Conflict status. Added a new css color for this that is somewhere between pure gray and the orange conflict color. With the new classes you should be able to theme this however you want on your own site.

mpotter’s picture

mpotter commented
StatusFileSize
new features-conflicts-modules-colors-1426452-6.patch2.94 KB

Bah, here is version without the tab character.

mpotter’s picture

mpotter commented
StatusFileSize
new features-conflicts-modules-colors-1426452-7.patch3.04 KB

Darn it, try again.

mpotter’s picture

mpotter commented
StatusFileSize
new features-conflicts-modules-colors-1426452-8.patch2.94 KB

One more time!

hefox’s picture

hefox commented

Haven't applied and tested, but looks good now

mpotter’s picture

mpotter commented
Version: 7.x-1.x-dev » 6.x-1.x-dev
Status: Needs review » Patch (to be ported)

Going ahead with it then. Committed 7dcff49

  • mpotter committed 7dcff49 on 8.x-3.x 
    Issue #1426452 by mpotter, rypit: Added Conflicts with disabled modules...