Edit field instance display settings across bundles

I love this idea.

Writing on it cause I'm looking for something like this.

You can already do this if you go to admin/reports/fields/tools

Does this need to be added to the docs so it's easier to find?

It can sync the display setup?

No, it's just the instance settings form.

I'll take a patch for the display settings though :)

Ummmm, ok :D hehehe let me see what can I do.

Maybe I just add an extra MENU_LOCAL_TASK and try to do the same but with the display settings.

Idk if create like a setup or something ... like the "image style" like.

1 - Chose name (and machine name)
2 - The wizard start and you pick a master bundle / entity display
3 - Then you chose from a list (of the same bundle / entity) display to sync
4 - a hook or something handle the request to keep it sync when you're editing the *main bundle* to the others.

Or you have a better idea?

I would add another link in the table at admin/reports/fields/tools to edit display settings. It's not ideal, but it's the simplest thing :)

There, see if you can grab just the part of the display form for a single field. Given it's ajaxy, that may be tricky.

Entity bundle display modes across bundles ... or in simple word cloning display mode into others bundles.

- What do we want?
- Replay easily the display settings to others bundles (content types)

- When do we want it?
- .....

And the answer comes ... when you apply this patch.

How you can use this new feature?

go to. admin/structure/types/manage/you-bundle/display-clone this will be your source settings to clone into others content type (bundles)

You can select which display mode you want, like admin/structure/types/manage/you-bundle/display-clone/full and then select the others content type you want to replay this settings.

This patch support display suite and field groups.

So I believe that cover the 80% of the case of use.

This also works for others entities like product (commerce) and works fine.

Ok some changes I did.

Still review ... someone?

1. +++ b/field_tools.admin.inc
   @@ -738,3 +738,278 @@ function field_tools_field_instances_list($field) {
   + * Retrive all the bundle and the displays.
   

   Typo: 'Retrieve'

   Also, please add documentation for all the params and the return, if any.

   Also, what does 'prnt' mean? Avoid abbrevs in variable names.

2. +++ b/field_tools.admin.inc
   @@ -738,3 +738,278 @@ function field_tools_field_instances_list($field) {
   +      if ($bundle_type === $bundle_name->type) {
   

   This is why we need @param docs, as I am already confused.

   $bundle_name sounds like it's a string. But you're accessing it as an object.

   Also, where was it defined? I don't see anything about it!

3. +++ b/field_tools.admin.inc
   @@ -738,3 +738,278 @@ function field_tools_field_instances_list($field) {
   +        $bundles_displays[$entity_type . ':' . $bundle_type]['relation'] = $prnt_entity_type === $entity_type ? 1 : 0;
   

   This should be broken up into more lines so it's clearer. There are no awards for managing to fit something on a single line ;)

4. +++ b/field_tools.admin.inc
   @@ -738,3 +738,278 @@ function field_tools_field_instances_list($field) {
   +  // Adding support for ds and field_group.
   +  if (module_exists('ds') || module_exists('field_group')) {
   +    // Prepare storage with ctools.
   +    ctools_include('export');
   +  }
   

   There's quite a lot to do for both of these modules, so I am wondering whether we should split this off into either helper functions, or just invent a hook and then implement it on their behalf.

   Would it make code more convoluted, or easier to read? Trying to keep functions short is definitely a good thing, so I am leaning towards splitting.

I'm confused about the related/non-related fields bit. Does this create new field instances? I'm not sure it should.

> I'm confused about the related/non-related fields bit

Actually I think I can see the use case.

I was thinking this would only let you copy the display settings for one instance of field_foo to other instances of field_foo.

But I can see that you might want to copy display settings from taxonomy term ref field_foo to taxo term ref field_bar. Which certainly makes things more complicated...

Updating the coding to the last dev code.

Hope you like it more. I add some @param description and correct other coding process.

I applied your patch to the latest dev and you're missing a closing '}'.

Also, I can't for the life of me find the feature you added. There are no new tabs or buttons anywhere.

Lastly, how hard would it be to add the ability to modify all the widget types at the same time?

Poieo I'll try a new one later ...

Hi
@ killua99
There is an issue on how to List all discounted products? (using commerce discount)
See https://www.drupal.org/node/2149777.
I think that the field tools module and your patch can be used in attempt to solve this issue if it's possible to use the same fields on products entity and discount.
What do you think?

Updated patch.
Now currently selected/active display mode is used as 'source display'. That means, settings could be synchronized to different display mode.

Thank you for your help gatis, here are some tweaks for the patch:

This can be removed, there is no reason for this check. It just produces notices:
field_tools.admin.inc - Line 1349

if ($bundle_type === $bundle_name->type) {
  continue;
}

To improve the workflow, we should use checkboxes to clone into multiple displays. I tried to change the form element, but this is not working out of the box :/

Looks like this is making good progress, but needs some more cleaning up.

1. +++ b/field_tools.admin.inc
   @@ -1185,3 +1185,316 @@ function field_tools_textarea($label, $value = NULL) {
   + * Internal use to retrieve all the bundle and their displays.
   ...
   + * Internal clone or add a single display instance into multiple bundles.
   

   Function docs first lines should be a verb in the 3rd person, eg "Retrieves yada yada". If you want to say it's internal only, you can do so in the next line.

2. +++ b/field_tools.admin.inc
   @@ -1185,3 +1185,316 @@ function field_tools_textarea($label, $value = NULL) {
   + * @param string $parent_entity_type
   + *   The parent entity type.
   + * @param string $parent_bundle_name
   + *   The parent bundle name.
   + * @param string $parent_view_mode
   + *   The parent view mode.
   

   What's a 'parent' in this context?

3. +++ b/field_tools.admin.inc
   @@ -1185,3 +1185,316 @@ function field_tools_textarea($label, $value = NULL) {
   + * @return array
   + *   The bundles and displays.
   

   This needs to document the structure of the returned array.

4. +++ b/field_tools.admin.inc
   @@ -1185,3 +1185,316 @@ function field_tools_textarea($label, $value = NULL) {
   + * This function don't return anything.
   

   There's no need to say this, we can see that from the lack of @return.

5. +++ b/field_tools.admin.inc
   @@ -1185,3 +1185,316 @@ function field_tools_textarea($label, $value = NULL) {
   + * @param array $source_instances
   + *   The instance source.
   

   Is this singular or plural?

6. +++ b/field_tools.admin.inc
   @@ -1185,3 +1185,316 @@ function field_tools_textarea($label, $value = NULL) {
   +    // This means same entity node === node.
   

   I don't understand this comment.

Also, I would seriously consider breaking up that big function that has the module_exists() with a hook pattern. Invent a hook_field_tools_instance_clone() (or whatever it is we're doing that that point) and then implement it on behalf of ds and field_group modules. That would make it a lot easier to read and keep it to a more manageable length.

How can i copy the all display settings from one entity type into another? Which patches should i use from here? Cos the "display-clone" path is not in the latest display-settings-across-bundles-2032735-15.patch. Thx

@mibfire, you are right, ...-15.patch lacks menu item definition.
Here is updated patch, which also includes modifications based on @joachim suggestions.

rudins, THX!

I have tryed to clone the default display of "erzekelok" product entity type to "fuvokak" product entity type but i got severel php errors:

PHP Warning: Missing argument 5 for field_tools_bundle_display_clone_from_form() in field_tools.admin.inc on line 1389, referer: /admin/commerce/config/product-variation-types/erzekelok

PHP Notice: Undefined variable: view_mode in field_tools.admin.inc on line 1397, referer: /admin/commerce/config/product-variation-types/erzekelok

PHP Notice: Undefined variable: view_mode in field_tools.admin.inc on line 1401, referer: /admin/commerce/config/product-variation-types/erzekelok

PHP Notice: Undefined index: in field_tools.admin.inc on line 1266, referer: /commerce/config/product-variation-types/erzekelok/display-clone

PHP Fatal error: Unsupported operand types in drupal/modules/field/field.crud.inc on line 630, referer: /admin/commerce/config/product-variation-types/erzekelok/display-clone

Now, display modes are radio boxes, but in this case only one can be copied. I think this should be a select list for multiple display modes copy.

Errors are shown if Default display mode is selected. There was missing argument for view_mode in menu item callback.
I`ll check on multiple display clone option later.

Thx the quick fix!

I applied this patch but i am still getting those errors.:(

Did you cleared caches?

Didnt, but i dont think it is needed.

It is needed, menu item definition is changed.

You were right. It is working, but the default display hasnt been changed.

Rudins, can you clone the commerce product entity display?

I had a look at this and did a bit of further work on it:

- tidied up the message and added the bundle admin URL to it
- fields that are only in a destination bundle were set to visible on the view mode, which is not what I expected. I've changed that so they are hidden.

There's something weird going on with the call to _field_tools_clone_add_display_to_bundles() -- I've left a TODO in the code for now.

Oh and another thing that needs to be changed: this should be moved under the Tools tab, and the source view mode should be taken from a form element, not from the current tab location. It's rather wasteful of tabs to use them in this way.