Add support for Fieldable Panels Panes

Here's an update to the #2 patch to add support for file fields on FPP export/import (and an interdiff.txt that just has the changes between patch 2 and 3).

Here is an update to #2 which includes file field support from #3. This provides a helper function to discover other modules which create FPP bundles. This way those modules can be marked as a dependency automatically.

This way there are not any missing bundles when enabling a Feature.

Updated to provide better context when adding an FPP through Features UI. Not all FPP's have a title, or one that is unique. Updated patch to display Admin title or UUID if admin title empty.

I applied the last patch here and this is the error that I am receiving when in the Create Features page.

Notice: Undefined property: stdClass::$admin_title in uuid_fpp_features_export_options() (line 18 of/sites/all/modules/contrib/uuid_features/includes/uuid_fpp.features.inc).

if this patch needs to be applied after other patches then it would be helpful to merge all the patches into one.

Sorry. #5 I forgot to actually add f.admin_title to the query :/

@kclarkson each patch is a build off of the other.

Awesome !

I have applied the patch in #7, it applied cleanly, no errors and my FPP's have been exported with my features.

Thanks a bunch

Marking as Tested

Tested patch and everything works great. This is quite an important patch due to the use of Panopoly. Going to link Panopoly to this issue so the FPP are exportbale.

kclarkson: Did you need to apply #2246893: Does not properly set pane subtype on content edit form submit. in order for it to work?

@DamienMcKenna: This patch does not require #2246893: Does not properly set pane subtype on content edit form submit.. With this patch a new features.uuid_fpp.com is properly created.

The FPP patch fixes panes on page manager and mini panel export so it can properly set UUID and reference a FPP exported via uuid_features.

FPP's are exported with the user `uid` which created them, causing panes to appear overridden due to value being unset or set to 0 when feature enabled.

Here is updated patch to remove export of UID.

I am getting fatal errors trying to export FPPs. It's always an "unsupported operator" error.

I am getting it for the Media module in

media/modules/media_wysiwyg_view_modes/media_wysiwyg_view_modes.module in this code

  $entity_info['file']['view modes'] += array(
    'wysiwyg' => array(
      'label' => t('WYSIWYG'),
      'custom settings' => TRUE,
    ),
  );

If I add a check and make sure that $entity_info['file']['view modes'] is an array, the error goes away, but then shows up again in the message_notify module at this code, again an array union operator

    $entity_info['message']['view modes'] += $view_modes;

If I disable the message_notify module, then it works.

function fieldable_panels_panes_entity_info() should be returning an array for view modes, but the code does contain this comment

 'view modes' => array(
      // @todo we should support view modes.
      'full' => array(
        'label'  => t('Full'),
        'custom settings' => FALSE,
      ),

So somehow the += operator on view modes seems to create issues for FPP exports with features.

Patch #13 sends an empty array to hook_entity_info_alter() but module writers who invoke this hook expect proper output from hook_entity_info().

The API docs for hook_entity_info_alter() say that "All properties that are available in hook_entity_info() can be altered here" but they are vague on which array elements are absolutely required (some have default values and some are optional, but others are not - are they all required?).

In any case, module creators seem to reasonably expect that the &$entity_info param will be a properly formed hook_entity_info() array and therefore that an array union on the standard elements would be safe, so the empty array used here creates a fatal error and you need the full entity_info array.

At least in my tests, you can achieve this by simply calling fieldable_panels_panes_entity_info() and getting the info and then passing it to the hook calls.

I haven't tested it much, but it seems to work for me.

Make sense @ergophobe! Tested and patch applies smooth.

Glad to hear. Have you tried an export/import cycle yet?

It's working so far for me without errors.

It of course still doesn't handle Media fields (e.g. image field using media widget) but that's a totally separate issue.

So I haven't had notices, warnings or fatal errors with this patch, but it's not necessarily a total solution since in I think Node Export is the only thing that handles export of media, but of course it only handles nodes. So there are still some limitations on export of entities like FPPs

We've been using this for import/export on our product without issue. Only problem we ran into is Features doesn't do components check. So if you have your fields featurized in with your FPPs you'll have to rebuild on enable. For some reason UUID_* triggers before other feature components.

Rebuild or revert? To rebuild you should just have to view the Features listing page right?

Anyway.... there is a hook_features_post_enable (or something like that; I need to doublecheck the Features API) so it would be possible to call a rebuild on various components. I only have a vague knowledge of how that would work though.

Revert, sorry. Basically the FPPs were created before field_base was called, borking it to hell. So our profile calls a revert of uuid_fpps on enable.

Okay... I think that's pretty standard to need to revert in situations like that.

Re-rolled patch after I committed #1973770: Integration with users, entityreference, taxonomy term references, field collections and nodequeue items
After re-rolling I made some adjustments too (see interdiff):
Most important change: uuid_features_features_pipe_alter() replaced by uuid_features_features_pipe_uuid_fpp_alter()
However, I didn't test it(!) - I don't have a scenario ready in which I can test this.
Please test if the patch still works with the changes. If so, I don't see other reasons why this should wait any longer :)

Another re-roll to make it apply after a coding standards cleanup of the module.

Hey das-peter! I'll re-test it all and give it a whirl to make sure it works as we planned!

25: uuid-features-fpp-support-2222727-25.patch queued for re-testing.

Re-recreated patch. No code changes.

Manually tampered with the patch. Let's see what the bot says.

Hey das-peter, not sure what's happening but when I try to apply uuid-features-fpp-support-2222727-31.patch against 7.x-1.x I get...

Checking patch includes/uuid_fpp.features.inc...
Checking patch uuid_features.module...
error: while searching for:

    case 'field_collection_item':
      $export_bundle = $export->field_name;
  }
  $fields = field_info_instances($entity_type, $export_bundle);
  $supported_fields = array_map('trim', explode(',', variable_get('uuid_features_file_supported_fields', 'file, image')));

error: patch failed: uuid_features.module:276
error: uuid_features.module: patch does not apply

Oh, I guess it needs another re-roll. I'm pretty active right now and changed quite some code.
I'll try to do a re-roll asap.

Here we go. Another re-roll.

The original patch was calling "uuid_features_load_module_includes();" which apparently doesn't exist anymore! So here is re-roll that's been verified. Marking RTBC since we know it works and just needed to catch up with latest dev :)

There is one note: We discovered #2246893: Does not properly set pane subtype on content edit form submit.. FPP's aren't proper initializing their subtype with UUID on edit/submit for ctools export. If we can get that RTBC and committed there's no issue. So may want to make note & link.

I've just committed the patch :)
Thanks all for the work!

I applied the add_support_for-2222727-39.patch patch but i got an "Cannot access empty property" fatal error when i tried to export a fieldable panel pane bundle. After some investigation some investigation i fixed the issue. The attachment contains the original patch and my modifications as well.

Hi kovacsaba - you don't have an interdiff by any chance do you?

If anyone is struggling with this issue and needs a version that works.

git clone --branch 7.x-1.x http://git.drupal.org/project/uuid_features.git
git checkout f0e01172040c6bcc3a464c31a28eb0dd0b02a630

Then apply the attached patch if you need anything from hook_uuid_entity_features_export_render_alter() for fieldable panels pane.

The patch/commit in #45 works for me. The latest dev release seems to do two things differently when exporting than what the patch/commit mentioned in #45 does...

it stores 'user_uuid' => '16d98c34-30ac-4fc1-ab2b-6fa6d9ca3556', causing the feature to show as overridden any time you revert..

and adds this as a dependency __drupal_alter_by_ref[pipe][][fieldable_panels_pane][gnus_menu] = gnus_menu (notice the [pipe])

I am getting the same problem with user_uuid and overridden features (latest dev version).
Also when I create a new fpp sometimes the class is pane-current-185 (or whatever number)
other times I get a class of pane-uuid-(uuid#) which is what I use to get the uuid for export.
Anyone know why sometimes the class is pane-current-xxx and what can be done to prevent that?

I'm experiencing the user_uuid problem as well. I originally was thinking that the uuids were not actually unique across envrionments. I get into a state in one envirnment where everything is default after reversion, but reverting in another environment, the user_uuids wont revert. I assumed it was because it couldn't find a match and just ignored it and worked around the issue. Deployments were working fine and authorship was not an issue in my case.

Perhaps this is not really associated with what this issue is trying to do, so maybe we need a new issue for the user_uuid problem.

FYI for anyone looking at this thread, the patch in #45 already exists in the current release.