A feature that depends on a module with "hidden=true" in the .info file cannot be enabled in the UI. The hidden module will be marked as "missing" because the module list used in features_admin_form() explicitly filters out hidden modules (and features):

  ...
  $modules = array_filter(features_get_modules(), 'features_filter_hidden');
  $features = array_filter(features_get_features(), 'features_filter_hidden');
  ...

This same scenario exists on the Feature creation form, where hidden modules cannot be selected as dependencies. In my case, I added a dependency "manually" after generating the Feature in the UI. Is there a reason hidden modules are filtered out?

I was unknowingly working around this issue by enabling the feature with Drush, and only realized the problem once I went back to recreate it.

Thanks

CommentFileSizeAuthor
#5 Screen Shot 2017-12-18 at 12.48.35.png21.33 KBjohn cook
#3 features-fix_hidden_module_deps-2012004-3.patch511 bytespescetti
#1 features-fix_hidden_module_deps-2012004-1.patch509 bytesmdeltito

Comments

mdeltito’s picture

mdeltito commented
Issue summary: View changes

verbiage update

mdeltito’s picture

mdeltito commented
Category: support » bug
Status: Active » Needs review
StatusFileSize
new features-fix_hidden_module_deps-2012004-1.patch509 bytes

Correction: hidden modules ARE available for selection on the feature creation form. This now seems more like a bug, since features can generate a feature that it cannot enable.

The included patch simply removes the filter on the array of modules that is used on the Features management form.

mpotter’s picture

mpotter commented

mdeltito: doesn't that just cause hidden features to display on the Admin page, which removes the purpose of the Hidden flag in the first place? We need a patch that keeps the hidden features hidden from the admin page but still allows modules that depends on it to work. Haven't had a chance to try the patch myself but was just looking the code, so correct me if it's actually ok.

mpotter’s picture

mpotter commented
Issue summary: View changes

extra info

pescetti’s picture

pescetti commented
Issue summary: View changes
StatusFileSize
new features-fix_hidden_module_deps-2012004-3.patch511 bytes

My use case:

  1. Module M is hidden
  2. Feature F1 depends on module M
  3. Feature F2 depends on feature F1

At both admin/modules and admin/structure/features I was seeing module M reported as a missing dependency.

The attached patch (reworked from the original) fixed it for me. Both admin screens are now clean.

The patch was also tested in the following scenario:

  1. Feature F1 is hidden
  2. Feature F2 depends on F1

Feature F1 was kept hidden at both admin screens, and no errors were displayed.

john cook’s picture

john cook commented
Status: Needs review » Reviewed & tested by the community

I've tested the patch by pescetti in comment #3.

The hidden module no longer appears as a missing unmet dependency.

When the hidden module is enabled, it appears on the Modules page and in the Dependencies section when rebuilding the feature. This is the same with or without the patch.

The code only touches one line and it appears to be OK.

I'm going to set this issue to RTBC but will also rerun the tests to make sure that it is still current.

john cook’s picture

john cook commented
StatusFileSize
new Screen Shot 2017-12-18 at 12.48.35.png21.33 KB

The tests passed so it looks like everythings OK.

donquixote’s picture

donquixote commented
Status: Reviewed & tested by the community » Needs work

Why would we depend on hidden modules at all?
Aren't these usually for testing purposes only, and not meant to be enabled or depended upon?
https://www.drupal.org/docs/7/testing/hidden-modules-and-themes

Perhaps someone could educate us about hidden modules, or why they would be needed in some uses cases with features.

I am setting this to "Needs work", because having this information e.g. in the issue summary is essential before this can be committed.