Upgrading to 7.x-1.0-rc2 (from rc1) breaks taxonomy creation

Changing to critical then this problem is rather critical.

• Do you mean the taxonomy vocabularies?
• Is this during installing a site? Enabling on a preexisting site?
• Is it all features with vocabularies? If you make a new feature with a vocab, does and enable however you were enabling, does it have same problems?
• Remove features_include(TRUE); from features_modules_enabled. Vocab support is provided by features; the commit you reference is mostly about ctools intergration with that sole line being the only one unrelated to ctools. The line triggers features_include which goes through and includes any default files.

Make sure the [feature].features.taxonomy_vocabulary.inc (think that's the file) is included at during install process
See what the diff is saying (install diff module).

I've just encountered this issue as well.

It only occurs when installing through Drush (both 4.5 and 5.1) with an install profile that uses a feature that has vocabularies.

Manually installing works fine.
Using drush to enable the feature once the site is installed works fine.

When features_include(TRUE); from features_modules_enabled is commented out the install works fine.
I suspect that somewhere along that chain a bit too much is being re-set, but I'm no features/ctools/drush expert.

I suspect features_include is a red herring; including it triggered the bug, but my guess is another function is bugged.

I'd be really curious what happens during the first features_rebuild after the module is enabled
inside _features_restore (think that's the name)

if ( currently reverting that feature module) {
.. see if taxonomy_vocabulary file has been included, etc.
}

Also, I'd be curious if moving the features_include to the top of the features_modules_enabled helps.

I think the problem is that previously features_include() was called for the first time after all the dependencies (like taxonomy) of the feature were installed and enabled.

With the features_include call in the features_modules_enabled function the first call of features_include() moves up to the point where the features module is installed.

This causes features_get_components() to statically cache the available components which at that point is limited to only the installed modules so far.

My solution was to extend the $reset parameter to the features_get_components() call:

foreach (features_get_components(NULL, 'file', $reset) as $file) {

I'm not sure if this is a 100% solution, so I'm attaching a patch and marking for review.

Hm, fix makes sense. However, will slow things down a bit, but likely can clean that up #1530386: Avoid unnecessary cache rebuilds and improve installation performance

Semi duplicate #1265168: Rebuild the file list properly when a feature is enabled or disabled

Based on comments here and in #1265168: Rebuild the file list properly when a feature is enabled or disabled, patch should address the issue + works in the base case that clears that cache when features_include(TRUE) is called + makes sense + simple patch = RTBC

Fix + tests.

My was it painful to reproduce the error.

Missing addition of new file (added vocabulary to export)

My was it painful to reproduce the error.

I can imagine. I got a headache just trying to think of where to start writing a test for this.
Yours is quite elegant and appears to work as it should (if we ignore the sneaking in of unrelated coding standard fixes ;)
Note that it can crash on taxonomy_features_api() not existing when combined with related bugs.

Confirming RTBC.

With the patch from #14 applied to RC2, I get the following errors, with or with out the patch from #1530386: Avoid unnecessary cache rebuilds and improve installation performance (commet 6) also applied.

WD registry: PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'FeaturesEnableTestCase-class' for key 'PRIMARY': INSERT INTO      [error]
{registry} (name, type, filename, module, weight) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3,
:db_insert_placeholder_4), (:db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9),
(:db_insert_placeholder_10, :db_insert_placeholder_11, :db_insert_placeholder_12, :db_insert_placeholder_13, :db_insert_placeholder_14), (:db_insert_placeholder_15,
:db_insert_placeholder_16, :db_insert_placeholder_17, :db_insert_placeholder_18, :db_insert_placeholder_19); Array
(
    [:db_insert_placeholder_0] => FeaturesUserTestCase
    [:db_insert_placeholder_1] => class
    [:db_insert_placeholder_2] => profiles/concern/modules/contrib/features/tests/features.test
    [:db_insert_placeholder_3] => features
    [:db_insert_placeholder_4] => 0
    [:db_insert_placeholder_5] => FeaturesEnableTestCase
    [:db_insert_placeholder_6] => class
    [:db_insert_placeholder_7] => profiles/concern/modules/contrib/features/tests/features.test
    [:db_insert_placeholder_8] => features
    [:db_insert_placeholder_9] => 0
    [:db_insert_placeholder_10] => FeaturesCtoolsIntegrationTest
    [:db_insert_placeholder_11] => class
    [:db_insert_placeholder_12] => profiles/concern/modules/contrib/features/tests/features.test
    [:db_insert_placeholder_13] => features
    [:db_insert_placeholder_14] => 0
    [:db_insert_placeholder_15] => FeaturesEnableTestCase
    [:db_insert_placeholder_16] => class
    [:db_insert_placeholder_17] => profiles/concern/modules/contrib/features/tests/features.test
    [:db_insert_placeholder_18] => features
    [:db_insert_placeholder_19] => 0
)
 in _registry_parse_file() (line 179 of /Users/tom/workspace/concern7/includes/registry.inc).

I actually get this printed 3 times in a row.

@mrfelton: you probably applied the patch twice and ended up with two (or more) FeaturesEnableTestCase classes in tests/features.test. Just remove the unwelcome duplicates.

Bump, any chance to this committed?

Best reg.
Stein

Commited to a2e030d.