Problem/Motivation

Currently each of several Debut feature modules provides its own media field. Since all fields instance properties should be synchronized, and since these properties are in flux as new functionality is added, it's cumbersome to have them dispersed. Instread, Debut media should provide the field, enabling other features to register content types to receive it.

Proposed resolution

Follow the basic approach used in Debut social.

  • A feature can include the following in its .info file (using 'article' as a sample content type): debut[media][node_types][article] = article
  • Put the field definition in debut_media. This will need to be manually updated in future, but can be done so via features, e.g.: add an existing media field instance to a dummy feature, generate the feature, copy and adapt the generated code for the field into the corresponding function in debut_media.module.
  • Use hook_field_default_fields_alter() to add the field to registered content types.
CommentFileSizeAuthor
#5 claim-media-fields-1316514-5.patch2.59 KBnedjo

Comments

nedjo’s picture

nedjo
he/him/his
Primary language English
commented

Done in http://drupalcode.org/project/debut_media.git/commit/b698d11.

Still need to remove from other features.

nedjo’s picture

nedjo
he/him/his
Primary language English
commented
Status: Active » Fixed

Adapted other features.

ao2’s picture

ao2 commented

@nedjo, does the line

debut[media][node_types][my_content_type] = my_content_type

need to be added to the "destination" feature, the same one witch defines my_content_type? If so you are still adding a "soft dependency" on the media module in those features, they have to know that "debut_media" exists, not that this is a big deal tho.

I was wondering: can this mechanism be pushed a little further to make debut_media enhance (all, or chosen on debut_media installation) content types automatically?

I also do not know if it is possible to generalize the hook_field_default_fields_alter() implementation, put it into the base debut feature and make it called at the right time.

Last question: can't the structure of feature be generated by "Features" and debut_media_media_field() return it taking in from debut_media.features.field.inc.

I am still a newbie on features, so forgive if I write something inaccurate.

Thanks for working on this BTW.

Regards,
Antonio

nedjo’s picture

nedjo
he/him/his
Primary language English
commented

need to be added to the "destination" feature, the same one witch defines my_content_type?

Yes. This is by design. What I'm looking for is a way to allow programmatically adding fields to specific content types--not all will need a media field.

I was wondering: can this mechanism be pushed a little further to make debut_media enhance (all, or chosen on debut_media installation) content types automatically?

I considered making this configurable, but that's not the primary use case. It's possible to manually add a field as it is, so that use case is covered.

I also do not know if it is possible to generalize the hook_field_default_fields_alter() implementation, put it into the base debut feature and make it called at the right time.

I'd like to avoid a dependency on the base debut feature. So, while it means some repeated code, I'd like to stick with distinct implementations in each feature.

Last question: can't the structure of feature be generated by "Features" and debut_media_media_field() return it taking in from debut_media.features.field.inc.

Yes, it could, if debut_media provided a specific field. But it doesn't, because it doesn't provide any content types. If a feature both provided its own content type and field and also provided a generic field to other features, then yes, it could use this approach, and it would be cleaner than what I've done here, since it wouldn't require manual export of the 'master' field.

Overall, what I've done here is a quick, hacked approach to enabling generic or abstract fields. I'm okay with it for now, though there is a lot of improvement that could be done. I've opened #1321176: Enable export of generic or abstract compontents (e.g., fields) that can be applied to multiple entity bundles to look at if/how this could be incorporated into Features.

nedjo’s picture

nedjo
he/him/his
Primary language English
commented
StatusFileSize
new claim-media-fields-1316514-5.patch2.59 KB

Hmm, I was thinking we should claim the media fields via hook_system_info_alter(), see attached patch, but it appears that isn't called for data loaded with features_get_features().

ao2’s picture

ao2 commented

@nedjo thanks for answering so precisely.

I still can't put the deserved time to look at this properly, just a quick thought about installation order: with your design should debut_media be installed after the “destination” features? If this is the case maybe you could use something like #981248: Allow a feature to execute a secondary install function after features components are created to postpone the media field addition to the content types to when all features have been installed and remove the ordering issue.

Regards,
Antonio

nedjo’s picture

nedjo
he/him/his
Primary language English
commented

It should work in either order. We're acting through a drupal_alter() call, which is invoked each time a new feature module is enabled.

Status: Fixed » Closed (fixed)

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

Anonymous’s picture

(not verified) commented
Issue summary: View changes

Updated issue summary.