Closed (fixed)
Project:
Features
Version:
7.x-2.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
19 Sep 2014 at 22:35 UTC
Updated:
12 Feb 2016 at 22:50 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
dave reidComment #2
chx commentedI think system_features_export always returns an empty array.
Comment #3
dave reid@chx: It's exported using the $data array. It doesn't need to pipe any additional information through. It's an odd return structure for that hook, but that's what it expects: http://drupalcontrib.org/api/drupal/contributions!features!features.api....
Comment #4
chx commentedOMG you mean the &$export array. I missed that. Oh well. Features :)
Comment #5
frankcarey commentedNice :) I don't see any options for it though. Should this show up in the UI?
Comment #6
frankcarey commentedfeatures.system.inc was placed in the root and not features/includes. This patch *should* fix that, but was hand-edited, so cross your fingers :)
Also, here is a snapshot of the new option in the UI for those looking for it. It's under "System", and it doesn't have a setting per module as I expected, but I can imagine that is so newly enabled modules can be identified automatically?
Comment #8
dave reidThe original patch definitely had the correct location for the include?
Comment #9
dave reidIt's definitely intended to not be per-module since it's an export of the 'currently enabled modules' state.
Comment #10
frankcarey commentedYou are correct, not sure why my patch command didn't place it there, I should have checked the patch more closely. That said, this still wasn't working for me until I changed system_features_export() to just output 'modules' and not all of the actual modules. The code seemed to be exporting all of the modules in 2 places for some reason resulting in the if statement failing.
I also removed system_features_rebuild() (and moved the code to system_features_revert()) since it meant that every cache clear and visits to the modules page or features pages caused the enabled modules to all be reverted. I could see that being useful in production, but it was a PITA in development when you have modules like devel enabled.
I'm still trying to think how this could work where the enabled modules were individual items... Maybe one "all" option as the first, followed by individual modules as well? Then you could do things like exclude dev modules... Just added this contrib module which allows you to "banish" features components from showing up anywhere. https://www.drupal.org/project/features_banish and it would be useful to "banish" dev and ui modules from being reverted while working locally.
Comment #11
frankcarey commentedComment #12
frankcarey commentedLooks like hook_features_system_defaults_alter(&components) can be used for what I'm looking to do (add or remove defaults based on environment, like with dev modules.
This code will disable the dev modules if they were exported for instance:
Comment #13
hefox commentedTo quickly summerize, you want to have modules enabled, but not list them as dependencies to the feature?
So, if I recall correctly, what I did for that in d6 (private) install profile was have a recommends[] key that enable by default but not dependencies. I remember there was a contrib module or maybe a core issue queue along those lines, but don;t recall details.
Comment #14
frankcarey commentedFYI, I just turned this into it's own module. https://www.drupal.org/project/features_master
Feedback very welcome :)
Comment #15
digitgopher commentedAssuming the spin off module takes care of this issue.