After updating to Features 7.x-2.0-alpha2, I am finding that some dependencies are not appearing in one of my features, and recreating the feature causes these dependencies to be dropped. Here is the contents of my feature's .info file:

name = Base
description = Sets up base configurations.
core = 7.x
package = Features
php = 5.2.4
dependencies[] = cas
dependencies[] = cas_attributes
dependencies[] = cas_ldap
dependencies[] = ctools
dependencies[] = fe_block
dependencies[] = features
dependencies[] = ldap_servers
dependencies[] = libraries
dependencies[] = strongarm
dependencies[] = token
features[ctools][] = ldap_servers:ldap_servers:1
features[ctools][] = strongarm:strongarm:1
features[features_api][] = api:1
features[field][] = user-user-field_address
features[field][] = user-user-field_firstname
features[field][] = user-user-field_lastname
features[field][] = user-user-field_phone
features[field][] = user-user-field_title
features[ldap_servers][] = work
features[variable][] = cas_attributes
features[variable][] = cas_login_drupal_invite
features[variable][] = cas_login_form

After either using the 'Generate feature' option or 'Download feature' options, a diff looks like this:

Vincents-iMac:d7 vincentmassaro$ git diff sites/all/modules/features/base
diff --git a/sites/all/modules/features/base/base.info b/sites/all/modules/features/base/base.info
index 510f22c..27d1d5c 100644
--- a/sites/all/modules/features/base/base.info
+++ b/sites/all/modules/features/base/base.info
@@ -3,16 +3,11 @@ description = Sets up base configurations.
 core = 7.x
 package = Features
 php = 5.2.4
-dependencies[] = cas
-dependencies[] = cas_attributes
-dependencies[] = cas_ldap
 dependencies[] = ctools
-dependencies[] = fe_block
 dependencies[] = features
 dependencies[] = ldap_servers
-dependencies[] = libraries
 dependencies[] = strongarm
-dependencies[] = token
+dependencies[] = text
 features[ctools][] = ldap_servers:ldap_servers:1
 features[ctools][] = strongarm:strongarm:1
 features[features_api][] = api:1

The Recreate features page does NOT show the cas, cas_attributes, cas_ldap, fe_block, libraries, or token modules as dependencies. Using drush fu base does not cause any changes to be exported. Thanks in advance.

Comments

vinmassaro’s picture

This behavior does not happen with 7.x-1.0 but occurs in 7.x-1.1-alpha1. Appears to have been introduced in http://drupalcode.org/project/features.git/commit/a48b0a47af58f0afd32984....

mpotter’s picture

Confirmed. Manually added dependencies are not saved in the feature in the new UI. Definitely a serious issue that I'll work on a solution for soon.

vinmassaro’s picture

Great, thanks. Can I safely downgrade back to 7.x-1.x with my Features that have been updated to 7.x-2.x? The only main changes I saw were that roles permissions arrays were defined with a named key instead of a number.

mpotter’s picture

Status: Active » Fixed

Fixed in commit 36714e8.

And yes, the actual export files are compatible between 7.x-1.x and 7.x-2.x. The permission fix works for 1.x also. If you re-export the feature with 1.x then your user permissions will go back to using a number instead of string key.

vinmassaro’s picture

Awesome, thanks for fixing this so fast! Didn't even have a chance to downgrade ;)

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

kristiaanvandeneynde’s picture

Status: Closed (fixed) » Active

Reopening this case because the fix did not cover the drush command features-export.

I looked at features.drush.inc and noticed some of the same functions are being used as in _features_export_build().
Is it safe to assume that the fix should still be ported to the Drush command?

I would normally write my own patch for this, but the underbelly of Features is a bit too obscure for me.
I did notice that the Drush commands are all pretty verbose, couldn't you "just" make them wrappers of the functions behind the UI?

For easy reference, see commit 36714e8.

kristiaanvandeneynde’s picture

Version: 7.x-2.0-alpha2 » 7.x-2.0-beta1

Tested and confirmed to be broken in beta1 by the way.

ianthomas_uk’s picture

Version: 7.x-2.0-beta1 » 7.x-2.x-dev

I got as far as tracing the dependencies back to features_get_info(), where I added the following debug just before returning:
print_r($cache->data['feature'][$name]->info['dependencies']);

But then I saw that the list of dependencies was infact now correct, which makes me wonder if it could be a caching issue (i.e. regenerating the feature using a cached version of the dependencies).

Setting version to 7.x-2.x-dev as that what a patch would be developed against. I'm running 7.x-2.x-rc2.

coredumperror’s picture

Priority: Normal » Major

I can confirm that this issue is still happening when upgrading from Features 1.0 to Features 7.x-2.2. Recreating my features using the Generate Feature button causes a huge chunk of apparently random modules to be removed from the dependency list, even though many are clearly required by the elements in the feature. For instance, permissions created by the Publish Button module are part of my feature, but the Publish Button module itself gets removed from the dependency list.

However, clicking Generate Feature and waiting for the page to reload shows a few new auto-detected dependencies, and clicking Generate Feature again adds some of the removed dependencies into the .info file. Further executions of Generate Feature show yet more missing dependencies being auto-detected. Though sometimes those new auto-detected dependencies are unchecked, and remain unchecked through multiple refreshes.

Eventually, through repeated use of the Generate Feature button, I was able to get to a stable state where refreshes would not detect any more dependencies, and all the right dependencies appeared to be in the .info file again (baring the ones which stay unchecked, and are apparently added to the .info file as features_ignore entries).

Very weird, and entirely possible to cause serious problems if not noticed immediately, but at least there seems to be a workaround.

coredumperror’s picture

Priority: Major » Critical

Wow, this is actually much, much worse than I thought. I ran into an especially large and complex feature on my way through updating all the features on my site, and this one didn't respond to the workaround of repeatedly regenerating the feature in order to get all the dependencies. But what makes it far worse, and the reason I bumped this up to critical, is that manually adding the dependencies which had been removed, then regenerating again still resulted in the dependencies getting dropped!

This bug is preventing me from adding necessary dependencies to this feature, and that is a critical issue.

  • mpotter committed 36714e8 on 8.x-3.x
    Issue #1834690 by mpotter: Fixed Dependencies not appearing and being...
blauerberg’s picture

It seems to be occurred by exceed to "max_input_vars" when creating large feature.
By increasing max_input_vars in your php.ini, this problem will be avoided.

mpotter’s picture

Priority: Critical » Normal
Status: Active » Closed (fixed)

This issue was already fixed and committed, except for potentially additional work needed for drush as reported in #7. Any additional work to address #7 should be added to a new issue with this issue marked as related to help the testbot handle the different patches.

#10 and #11 seem isolated to a specific user and certainly do not warrant either "critical" or "major" status. The fix mentioned in #13 should be tried.

This issue should *ONLY* be re-opened if the commit in #4 is bad. Any other related issues should be created as NEW issues.