Proper way to define module defaults.

Bumping this issue. Coming from media and file_entity issues trying to work around this. Did non of the feature maintainers come back to you on this?

Tried this patch on 2.10. Default file types (image, video etc.) showed up in the components available for export, but after exporting the feature I don't see any code being generated.

Confirmed. Tried to export features with the media image preview settings, and there was no code exported after applying this patch.

@torotil something the testers missed or does this needs work?

Tried patch, it might work, but I'm getting a slew of messages on admin pages :( I even updated from features 7.x-2.10 to -2.x-dev, but the messages still happen. Here's a sampling:

Notice: Undefined index: api in features_ctools_plugin_api_alter() (line 1108 of /home/alison/workspace/d7/itc-sitedata/sites/all/modules/contrib/features/features.module).
Warning: in_array() expects parameter 2 to be array, string given in _features_export_build() (line 615 of /home/alison/workspace/d7/itc-sitedata/sites/all/modules/contrib/features/features.admin.inc).

(they repeat a zillion times on the screen)

(when I'm on a page to recreate a feature, I get both of the above messages -- when I'm on the create-new-feature form, I just get the Undefined index message a whole bunch of times; I also get the Undefined index message on other admin pages, though just once; the errors did not change when I switched Features module version, other than the slight line number differences)

About my env:

• Drupal 7.51
• Features 7.x-2.10 or 7.x-2.x-dev (I was using 2.10 but then tried -dev)
• Ctools 7.x-1.12

I couldn't get this to work with the media module (Related issue #2104193: Default file entities are not exportable by features (Media File Entity Overridden)). The file displays would not export.

I updated the patch to address the Warning in #27 by checking for both strings and arrays. For me, the warnings appeared with module dependencies which were always strings instead of arrays. That could possibly be fixed elsewhere though.

Thanks, all! Unfortunately I'm still getting an error repeated a whole bunch on my "recreate" screen :(
Warning: Illegal offset type in ctools_component_features_export() (line 167 of /home/alison/workspace/d7/itc-sitedata/sites/all/modules/contrib/features/includes/features.ctools.inc).

(I did go up to -dev again, like the last time I tried it out.)

Is there anything I can do or any info I can share to help troubleshoot? Thank you!

It's working for me, file entities are exporting correctly now with the -dev version + the patch in #31. I'm not seeing the issue reported in #32.

...Hesitantly changing to RTBC, but I think this still needs more testing.

I think it's close, but the problem in #32 is still there, and it's definitely not just a harmless warning - it's actually affecting the logic. In line 167 of features.ctools.inc the $other_feature variable is an array, but is being treated like a string. I can also recreate the warnings on the command line by doing something like a "drush features-diff my_feature", and it causes the features-diff to think things had changed that hadn't.

I'm not familiar enough with the code to know what $other_feature should be reasonably expected to be, but this could be maybe fixed by either doing an array_shift() on $other_feature to get the first element, or using a foreach to loop through the array.

Looks better, but this time running a "drush fd my_feature" it's failing with: Fatal error: Function name must be a string in /var/www/drupalvm/sites/all/modules/contrib/features/features.export.inc on line 868

Sure thing, that solved all the PHP issues. I ended up with strange behavior though - I tested it on a random Features module on my site, and when I did a "drush fd" it gave output implying that a lot of new variable (strongarm) components needed to be added to the Feature. They were all variables related to random node types, such as these variables for the "book" type:

* field_bundle_settings_node__book
* language_content_type_book
* menu_options_book
* menu_parent_book
* node_options_book
* node_preview_book
* node_submitted_book

And I do have a separate Feature related to the book type that does already have those variables exported to it. When I did a "drush fu" for first Features module, it did actually add all of the book variables to the Feature. So the end result is I've got 2 enabled Features with the some of the same strongarm components exported to them both.

I should mention I'm testing with Features 2.10.

With #41 I was able to export a file type to a Feature, which is something I haven't been able to do before. I tested the drush commands: fl, fu, fr, and fe, and all worked as expected. So nice work, one successful test here. I hope some other folks can test also.

An update after a bit more testing: I've had to remove this patch because of some issues, though I'm not totally sure what in the patch might cause them. @torotil, hopefully this makes sense to you. Here's what I do to recreate the problem:
* Use drush to do a full cache clear, "drush cc all"
* Visit a page that renders a file entity
This results in fatal PHP errors, because the file entity does not have a "type" property. The best I can tell is that drupal_get_schema is running at a point early in the bootstrap, before file_entity_schema_alter has added "type" to the file_managed schema. This causes a database query to load the file entity without the "type" column, which results in a file entity without a type, which triggers the PHP error.
Once drupal_get_schema is properly cached, it's not a problem. So the first page load after a full cache clear is really where the problem occurs.
Again though, I have no idea why this patch would cause something like that. But sure enough, if I remove the patch, the problem goes away.

Anyone else using this patch?

I'm still using the patch in #41 on Features 7.x-2.11

Attached is a re-roll of the patch in #41 against the latest features-7.x-2.x-dev 2019-10-20

Hi
I have not studied this issue until now, and need some help to get started with it.

A starting point could be to improve the docs:
- Improve the issue summary, by adding an example.
- Improve the docs in the patch!

/**
 * Get a map of components to their providing features.
 *
 * @param string $component_type
 *   Get the conflict map for all components of this type.
 *
 * @return string[][]
 *   An associative keyed by $component names. Each value is an array of
 *   enabled modules that define this component.
 */
function features_get_conflict_map($component_type) {

The doc might already have the info I need, but it looks a bit awkward.
Why does a @param doc start with "Get the ..."?
"An associative keyed by" probably should be "An associative array keyed by".

I get the impression that this function behaves equally to features_get_component_map(), except:
- Always a specific component, the parameter cannot be NULL.
- Only return enabled modules.

This should be reflected in the doc comment and in the function name.

Btw the doc on features_get_component_map() contains an interesting @return doc. We could do something similar here, e.g.:

 * @return string[][]
 *   Format: $[$identifier][] = $module,
 *   where $identifier is the machine name of a single exportable for the given component.
 *   Note that there can be more than one module defining the same exportable. This would be a "conflict".

Not sure if people other than me like this.

      if ($modules = array_filter($modules, 'module_exists')) {

It would be faster to fetch module_list() only once, and then use array_intersect().
The list from module_list() has the format $[$module] = $module, so we can use keys or values likewise.

function features_get_conflict_map($component_type) {

I never really liked the naming patterns in features.
What is a "$component", "$component_type" or just "$type"?
One could think that the names should be used like $component_type = 'field_instance'; $component = 'body';.
But in most places, they are used like $component = 'field_instance'; $identifier = 'body';, or sometimes $name = 'body';.
We should follow the most common conventions for variable names that we find elsewhere in features.

I can confirm with patch from #57 I am able to export and take ownership of "file_type" and "file_display" components, with default hooks in place i.e. without needing file_entity patch in #2192391-83: Default file entities are not exportable by features (Sibling Issue) or media patch #2104193-113: Default file entities are not exportable by features (Media File Entity Overridden).

We are exclusively using drush to manage features so I have not tested UI.

One quirk to note is that if there is an alter hook that appends data (e.g. hook_file_default_types_alter() is used to append a mime type to the array), it will be added again on each feature export so you'll end up with duplicate entries. I've noticed this before in features so I don't think it is caused by the patch in #57 just something to watch out for.

Another minor weirdness is when running drush fda -y it will sometimes list our custom feature with media exports in it but just says it's in the default state; the expected behavior is that if there is no diff the custom feature would not be listed at all.

I have not had time to uncover the cause of either if these minor issues, and do not consider them release blockers.

Pushed this into dev , this also permits closing of an issue for file_entity
#2192391: Default file entities are not exportable by features (Sibling Issue)

Hi! Thanks for taking the time to merge the patch. I hope it is still of use to some even though the Drupal 7 end-of-life is now only months away. At least it’s a nice gesture.

Sorry I did not follow up on this since the messages from 2020.
And thanks to @joseph.olstad for picking it up again.

Drupal 7 end-of-life is now only months away.

For the record, this got pushed to Jan 2025.
https://www.drupal.org/about/drupal-7/end-of-life

EDIT: I think I was waiting for a 3rd party to rtbc, and then did not check on it again.

https://www.drupal.org/project/features/releases/7.x-2.15