We can not cache included components per component. This works well if a single feature is enabled per request, but when we enable multiple features in one go, if those two features have the same component, only the first one's included will be rebuilt.

This happens when doing automatic deployments with drush.

Patch attached in comment.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

kotnik’s picture

There's hardly any reason to cache includes at all, since require_once's are cheap.

hefox’s picture

Status: Active » Closed (duplicate)

It sounds like the *bug* you're having is the same as #1537838: Upgrading to 7.x-1.0-rc2 (from rc1) breaks taxonomy creation (confusing bug report considering it's actually one potential solution); please offer your alternate solution in that issue.

kotnik’s picture

Status: Closed (duplicate) » Needs review

Sounds like it, but it isn't. It is caching issue like that, but in another function.

#1537838: Upgrading to 7.x-1.0-rc2 (from rc1) breaks taxonomy creation fixed issues w/ taxonomy, which is one of the modules features provides integration for. This bug is related to features that depend on ctools, ie. Strongarm.

I have the same issue after using solution provided there, and my bug fix wouldn't help that issue either.

hefox’s picture

Can someone update the title/body to describe what the bug is/how to reproduce/etc.?

mpotter’s picture

Status: Needs review » Closed (won't fix)

Re-open this if it's still an issue in the latest 2.x and provide the requested details on what problem is occurring.

Ogredude’s picture

Version: 7.x-1.0-rc2 » 7.x-2.x-dev
Status: Closed (won't fix) » Needs review
FileSize
1.07 KB

The fix provided by this patch is not in the 2.x tree.

When I create a site with Aegir, several fields on my content types do not have the specified display settings until I rebuild the feature.

I ended up fixing it with this patch and the patch from https://drupal.org/node/1572578#comment-7839439

Attached is the patch re-rolled for Features 2.x

redndahead’s picture

Status: Needs review » Reviewed & tested by the community

This fixes an issue I have where defaultconfig files weren't being included. This issue didn't appear until rc2. The patch here: #1959076: Features does not remove the several known deprecated files caused it to start showing up. This is because before that issue all files would be included if they were in components or not. Thus caching didn't apply. While I'm not sure if this is the best approach I will say it fixed my issues. You can test by doing a drush make/si of panopoly while using rc2 or rc3 of features.

helmo’s picture

dsnopek’s picture

Both Features 2.0-rc2 and Features 2.0-rc3 break Panopoly install: #2062377: Update features to 2.0

I tested both the patch here and the patch in #1572578: Rethink the way features are enabled / disabled.

It was the patch here that fixes the problem! The other patch on #1572578 doesn't hurt anything (when they are both applied), but on it's own it doesn't fix the problem.

+1 for committing the patch here on comment #7!

mpotter’s picture

Status: Reviewed & tested by the community » Fixed

Confirmed this fixes issues in OA2 and Panopoly. Committed to afa9133.

dsnopek’s picture

Great! Thanks, Mike. :-)

Status: Fixed » Closed (fixed)

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

donquixote’s picture

Issue summary: View changes

I found this issue because commit afa91335ebc88a7fb04b05d578f9d74cdea453d1 is labeled with this issue number.

The commit contains some changes in includes/features.menu.inc, which seem unrelated and are not mentioned in this issue or in #1572578: Rethink the way features are enabled / disabled.

E.g. menu_links_features_identifier() gets a new parameter $old which changes the way that menu link identifiers are constructed. Was this discussed anywhere?

I am trying to document this file, and want to give accurate information :)

donquixote’s picture

The commit contains changes from another issue.
See #927566-74: Add link title to menu link identifiers to make them more unique..

Thanks to @ciss for pointing this out in #3075693-3: Menu link identifier logic is confusing!