Features integration

Anyone looked into what we actually are missing in the feature export? #2 indicate at least the field type is empty or the field.info is never exported.

FYI: http://drupalcode.org/project/multifield.git/commit/4e7a90e removed necessary info for features, no idea why

Here is a working patch (tested by creating a feature and enabling it on a fresh drupal install).
As @attiks said, I had to add the ctools exportable info that was removed from multifield_schema in order to get features to work.
With this patch dependencies and subfields are auto-detected.

For example:
Add a multifield to a content type.
Create a new feature and select the content type with the multifield.
The features will auto-detect & auto-select the multifield with its subfields to be exported with this feature.

*sigh*
This time without the newline error.

Seems there is still a problem.
The fields & instances exist, but are not shown on the edit form

Strange, now I can't reproduce my own error.

Everything seems to work as expected now.

I removed the exportable hooks because it was clear there was a lot more needed to actually make Features integration work. So I'd rather remove it than encourage people to export their multifields and have it not work. Once this is ready I'll consider it to be re-added. I'll take a look.

New patch: Fixes the case where the multifield config object was not yet loaded in the ctools cache and features attempted to create the multifield field base anyway, which resulted in a FieldException.

Ok there was one last problem that if the multifield existed but had no subfields yet (meaning the field type does not exist), a FieldException would be thrown. New patch attached.

Sorry, the previous patch didn't include the multifield.features.inc file. New patch attached.

AFAIK this is RTBC ;-)

FYI: Patch in #13 + latest 7.x-1.x code works for me.

Multifields are exported and imported as expected.

+1 this fixes features integration.. RTBC

Information is captured but multifield not added to it's content type on a site install, you need to revert feature after the site install for the multifield field to be on it's content type.

#18 Isn't this a more general feature problem?

A site install should come out clean without the need of a revert. That is in my world though :)

In my world as welk, but features is some times a different universe

Related, with #2234769: Should multifield types be represented as separate field types, or just one 'Multifield' field type? and the new 'Multifield' field type, it becomes *way* easier to export a multifield to features since it works more like the Field Collection way: the 'bundles' of multifields are all the field names that have $field['type'] = 'multifield';. I'm half tempted to officially deprecate the old field types since this seems to work sooooooo much better.

Deprecating the old one sounds reasonable, but will you provide an upgrade?

I'm not sure it will be possible to provide an upgrade path, especially since the module is in an unstable state and we would have to mess with people's existing fields too much. Right now deprecating means 'you cannot create new field instances of those field types'

Makes sense

@Dave I assume we go with the new field types? Just asking because we are about to launch a site depending heavily on multifield, so we rather switch now?

Has any work from this issue been committed? I'm having some issues with features on the latest -dev and I'm wondering if they're related to this work:

• I have a site with exported multifields running multifield 7.x-1.0-unstable9, and when I update it to multifield 7.x-1.0-alpha1 or 7.x-1.x, my multifields are available on node edit forms but not on node view or in the multifield admin listing
• Exporting multifields using multifield 7.x-1.x results in a malformed feature that seems to have most of the information but some of the wiring is messed up, ie, features[ctools][] = multifield:: in the feature's .info file

I know that -unstable implies there might not be an upgrade path, but I'm trying to figure out where exactly my issues are coming from before trying to fix the 16 multifields on my site.

It looks like my issues are caused by #2234769: Should multifield types be represented as separate field types, or just one 'Multifield' field type?, but they definitely relate to features exports.

This patch will prevent a feature from showing as overridden, but shouldn't break when subfields haven't been created yet e.g. on a site installation.
Note that I only exported using the native field exports and ignored the "Multifield" option, which I think is going to be removed (see #2355777: Multifield is trying to export [feature-name]..inc ).

Rerolled against 7.x-1.x. Notable conflicts happend in multified.features.inc and are listed below.

In multifield_field_default_field_bases_alter():

7.x-1.x:

function multifield_field_default_field_bases_alter(&$fields) {
 foreach ($fields as $field_name => $field) {
   if ($field['module'] == 'multifield') {
     // Prevent errors if a multifield is exported via features but its
     // subfields have not yet been created. Ideally core should not be
     // storing the schema indexes and foreign keys in the field definition
     // since these are both fetched from hook_field_schema().
     $fields[$field_name]['indexes'] = array();
     $fields[$field_name]['foreign keys'] = array();
   }
 }
}

Patch (picked):

function multifield_field_default_field_bases_alter(&$field_bases) {
 features_include_defaults('multifield');
 multifield_cache_clear();
 $field_bases_copy = $field_bases;
 foreach ($field_bases_copy as $key => $field_base) {
   // Do not create multifields if they don't exist yet.
   if ($field_base['module'] == 'multifield' && (!multifield_load($field_base['type']) || !field_info_field_types($field_base['type']))) {
     unset($field_bases[$key]);
   }
 }
}

In multifield_features_pipe_field_base_alter():

7.x-1.x (picked):

function multifield_features_pipe_field_base_alter(&$pipe, $data, $export) {
 foreach ($data as $field_name) {
   // Export a multifield's subfields along with the field base.
   if ($field = field_info_field($field_name)) {
     if ($machine_name = multifield_extract_multifield_machine_name($field)) {
       foreach (multifield_type_get_subfields($machine_name) as $subfield_name) {
         $pipe['field_instance'][] = "multifield-{$machine_name}-{$subfield_name}";
       }
     }
   }
 }
}

Patch:

function multifield_features_pipe_field_base_alter(&$pipe, $data, $export) {
 foreach ($data as $field_name) {
   $info = field_info_field($field_name);
   if ($info && multifield_load($info['type'])) {
     $pipe['multifield'][] = $info['type'];
   }
 }
}

In both cases I had to make a guess as to what might integrate better.

Patch caused Strongarm components that where unrelated to multifield to not get exported, even though they had been added via the features UI. Can't dig deeper for now.

Adding a minor portion of the patch that fixes notices regarding missing current_version / api keys, and that should also fix incomplete files names ("..inc"). Clear your cache after applying.

@ciss your last patch fails because the code was already included in the previous patch, perhaps you didn't clear cached.

Features has been working since #2234769: Should multifield types be represented as separate field types, or just one 'Multifield' field type? was committed.

#32 fixes the undesirable notices that pollute the log messages, I think this is all that's needed.

Okay multifield_field_default_field_bases_alter() is apparently needed to prevent errors if subfields don't exist, but if they do exist it will cause features to mark the multifields as overridden if though they aren't, so I think the empty arrays should only be added if there is nothing there already.

I used the below modifications in conjunction with #32.

function multifield_field_default_field_bases_alter(&$fields) {
...
-      $fields[$field_name]['indexes'] = array();
+      if (empty($fields[$field_name]['indexes'])) {
+        $fields[$field_name]['indexes'] = array();
+      }
-      $fields[$field_name]['foreign keys'] = array();
+      if (empty($fields[$field_name]['foreign keys'])) {
+        $fields[$field_name]['foreign keys'] = array();
+      }
...
}

Adds the feedback from #35 into a patch.

Patch in #32 is what we should use (if tests come back as a pass). The comments in #35 have to be fixed upstream in features. See #2506877: Remove 'indexes' from field base.

Marking #32 RTBC.

I concur with heddn, my suggestion worked for reverting but not creating features, now it works with both.

Error with features integration #2451011: Recoverable fatal error: Argument 1 passed to multifield_extract_multifield_machine_name() must be of the type array, null given

Patch in #32 works well together with patch from #2506877: Remove 'indexes' from field base (for comment #35).

#32 is RTBC

#32 works well here too.

I'm confused why we need the exportable definition here again. Is it to support the older multifields that are stored in the multifield table (and is no longer possible to create new ones)?

Hi there,

I believe the reason is that the ctools standards say we should have a "exportable definition". See "Defining the configuration data":
https://www.drupal.org/docs/7/creating-custom-modules/howtos/how-to-make...
Additionally, It may stop the multifield fields from being exported/imported properly via features.

On my machine, if you navigate to a exported multifield inside a features in the features UI -> recreate, there are errors from features module:

Notice: Undefined index: api in _ctools_features_get_info() (line 277 of [..]\features\includes\features.ctools.inc).
Notice: Undefined index: current_version in _ctools_features_get_info() (line 277 of  [..]\features\includes\features.ctools.inc).
Notice: Undefined index: api in ctools_features_export() (line 66 of  [..]\features\includes\features.ctools.inc).
Notice: Undefined index: current_version in ctools_features_export() (line 66 of  [..]\features\includes\features.ctools.inc).

So the change in #32 fixes this (if you create brand new feature)

#32 is RTBC from me as well. Thanks for all the work on this!

Subscribed to follow up applied #13 and #32 patch for CG
Thumbs up also !

We stepped out of multifield in favour for paragraphs module for the following reason :
Once multifield and its subfields are used in content, it seems impossible to change the display settings (eg. adding a grouping div field).

After disabling and uninstalling from our site, a lot of (via #50) created features were not cleaned up properly.

See attached screenshot from our gitlab commit where we manually removed the feature leftovers in code (inaccessible via Features UI) :

Notice the files that have the suffix ..inc (double dot) -> eg. feature.job.posting..inc

Looks like there's still some work to do.