My latest commit:
http://drupalcode.org/project/inline_entity_form.git/commitdiff/c6d28dd?...
attempts to make the table (listing the already referenced entities, and providing the edit / delete links) more flexible.
The table is now auto generated, and the entity type implementation just has a "default fields" callback that returns which fields should be displayed, and in which order. If the fields are provided by Field API, the formatter can be selected and configured as well (so you can say "show the base price" instead of "show the calculated price" for price fields, for example).

If someone wants to modify the logic (add his own field, for example), there are two ways to do that:
1) Implement hook_inline_entity_type_info_alter(), swap out the "default fields" callback for a custom one. (The custom one can then call the original one and override certain values, or just start from scratch).
2) Provide the settings in the same way when creating a field (or update the instance from code).
So if $widget['settings']['field'] has a fields structure, it will be used instead of the one provided by the "default fields" callback.
This allows install profiles to easy configure the look of the table.

Is this enough?
I've also been thinking of providing a custom UI, a "Inline Entity Form" tab shown when editing the reference field, that would have a table similar to the one from "Manage Display" (drag & drop, formatter settings), showing properties added through hook_field_extra_fields() such as Title and SKU, and also showing all fields that are common to all selected bundles. So for line items you could add (and configure) the total field, etc.
Does that sound desirable?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

joachim’s picture

> Implement hook_inline_entity_type_info_alter(),

AFAICT this has gone, presumably as part of the refactoring to use a controller.

Should we replace it with a hook_inline_entity_form_fields_alter()?

> Provide the settings in the same way when creating a field (or update the instance from code).

That seems a bit fiddly for site builders. I guess you can hack the settings into your Feature by hand...

> I've also been thinking of providing a custom UI, a "Inline Entity Form" tab shown when editing the reference field, that would have a table similar to the one from "Manage Display" (

Could that be done within the field admin page? EntityRef module has a UI within that for choosing entity properties for labelling and sorting.

bojanz’s picture

AFAICT this has gone, presumably as part of the refactoring to use a controller.

Yep, so the solution now is to inherit the controller and replace it through hook_entity_info_alter(), just like with any other controller.

Could that be done within the field admin page? EntityRef module has a UI within that for choosing entity properties for labelling and sorting.

Yeah, I was thinking of a tab when editing the reference field.
The whole approach has many edge cases and adds a ton of complexity, so I'm not rushing to do it. Might just prove unnecessary, we'll see if more people request it.

joachim’s picture

> Yep, so the solution now is to inherit the controller and replace it through hook_entity_info_alter(),

But what if you want to tweak the fields for an entity that's not yours?

Say, for example, commerce products. I've seen the impressive screenshots of this used for Commerce Kickstart 2, with the product images shown in the IEF table. How are you achieving those? Subclassing the controller for that seems a bit wrong to me.

bojanz’s picture

Say, for example, commerce products. I've seen the impressive screenshots of this used for Commerce Kickstart 2, with the product images shown in the IEF table. How are you achieving those? Subclassing the controller for that seems a bit wrong to me.

That's done by IEF by default (CommerceProductInlineEntityFormController::defaultFields()).

It's not wrong, but it is cumbersome.
The main complexity with adding the new UI is the fact that multiple bundles might be supported, so you need to add fields belonging to each one...
So it's basically a copy of the existing "Manage display" code, but saving to IEF settings, and supporting multiple bundles.

rcross’s picture

I have 2 thoughts on this:

1) Define a render/display mode for entities, and then you could just use the drag/drop ui of the "manage display fields". This could potentially allow for the use of Display Suite to configure the display in a more general sense.

2) Use views to define the table. Then adding or reordering fields would just be a matter of overriding a default view.

I think either of these options also have the possibility of reducing the complexity and need for a controller for each entity.

I haven't dug into the code yet to see which of these options might be the most feasible, but conceptually I don't see a strong reason we couldn't use one of these approaches even if they might require a few workarounds.

bojanz’s picture

1) Keep in mind that IEF might be showing entities of multiple bundles at the same time. So if you have a view mode for each bundle, what happens
if the fields aren't the same? Plus, changing the IEF table in that case means you need to go to the "Manage Display" form for each bundle.
That's why my idea in this issue was to provide a custom "Manage Display"-like form that works for all allowed bundles for that IEF field.

2) Using a View in a form context is hard and makes the code almost unmaintainable. I've been done that road with Entityreference View Widget, and have had only bad experience.

rcross’s picture

I'm not sure how common the case will be that multiple types of entities will be referenced, so I"m not sure we should optimise/cater for it.

One work around would be to group by different types of entities, so that you can have multiple tables with different fields. Alternatively, you could just leave the cells blank for the columns/fields that the entity doesn't have. We could also have an configurable option to show only common fields or show all fields with empty cells.

If we use the entity render approach, you could just have a simple list of the rendered entities instead of using tables and a row for each entity. If we use the views-based approach, views already has code to handle different entities with different fields.

Some thing else to think about is that people might prefer to have something else besides a table-based layout. For example, maybe someone might want a simple grid layout of product images with edit/delete links under each image.

2) I'm aware that views in forms is not very nice. I would probably expect that the form editing space would be separate to the rendered view space to help with this, but obviously you would have more experience in this.

It might also be worth looking at http://drupal.org/project/editablefields (D7) and http://drupal.org/project/editview (D6 only)

rcross’s picture

@bojanz - have you thought about this any more?

bojanz’s picture

My points in #6 still stand.

Supporting entities of multiple bundles is vital for use cases such as line items (product line items, shipping line items, etc).
We already optimize & cater for it.

m42’s picture

@bojanz:
Thank you so much for this module, I was trying to implement something equivalent before I found yours !

If someone wants to modify the logic (add his own field, for example), there are two ways to do that:
1) Implement hook_inline_entity_type_info_alter(), swap out the "default fields" callback for a custom one. (The custom one can then call the original one and override certain values, or just start from scratch).

Yep, so the solution now is to inherit the controller and replace it through hook_entity_info_alter(), just like with any other controller.

As I'm very new to entities, I don't understand your solution to add an existing field to the array. Can you please provide any piece of code about how to do that ?

Thank you in advance !

kirie’s picture

@hwold - did you figure it out?

m@rtijn’s picture

I would love to see this functionality added to the Inline Entity Form module.

m42’s picture

@kirie: I finally found the trick (the solution was 75% in the module's files, I just had to copy/paste then adjust to my needs). But I didn't try to filter the columns as I needed them all.

If someone is interested by the way I did it (which is, I repeat ot, definetely not THE way), just ask ! ;)

eme’s picture

Indeed, you can post it here, and maybe it'll help coding the functionality cleanly.

kirie’s picture

@hwold - thanks for replying back! I haven't gotten around to looking through the relevant files yet, but, as @eme said, a little code pasted here would be much appreciated!

m42’s picture

So, here is what I did :

1. Create your custom module, then a folder named "includes" (or whatever you want) intended to contain your classes.

2. In this folder, place the following into a file named NodeCustomController.php


class NodeCustomController extends NodeInlineEntityFormController {

    /**
   * Returns an array of fields (which can be either Field API fields or
   * properties defined through hook_entity_property_info()) that should be
   * used to represent a selected entity in the IEF table.
   *
   * The IEF widget can have its own fields specified in the widget settings,
   * in which case the output of this function is ignored.
   *
   * @param $bundles
   *   An array of allowed $bundles for this widget.
   *
   * @return
   *   An array of field information, keyed by field name. Allowed keys:
   *   - type: 'field' or 'property',
   *   - label: Human readable name of the field, shown to the user.
   *   - weight: The position of the field relative to other fields.
   *   - visible: Whether the field should be displayed.
   *   Special keys for type 'field':
   *   - formatter: The formatter used to display the field, or "hidden".
   *   - settings: An array passed to the formatter. If empty, defaults are used.
   *   - delta: If provided, limits the field to just the specified delta.
   */
  public function defaultFields($bundles) {
    $info = entity_get_info($this->entityType);
    $metadata = entity_get_property_info($this->entityType);

    $fields = array();
    if (!empty($info['entity keys']['label'])) {
      $label_key = $info['entity keys']['label'];
      $fields[$label_key] = array(
        'type' => 'property',
        'label' => $metadata ? $metadata['properties'][$label_key]['label'] : t('Label'),
        'visible' => TRUE,
        'weight' => 1,
      );
    }
    else {
      $id_key = $info['entity keys']['id'];
      $fields[$id_key] = array(
        'type' => 'property',
        'label' => $metadata ? $metadata['properties'][$id_key]['label'] : t('ID'),
        'visible' => TRUE,
        'weight' => 1,
      );
    }
    
    if (count($bundles) > 1) {
      $bundle_key = $info['entity keys']['bundle'];
      $fields[$bundle_key] = array(
        'type' => 'property',
        'label' => $metadata ? $metadata['properties'][$bundle_key]['label'] : t('Type'),
        'visible' => TRUE,
        'weight' => 2,
      );
    }
    
    // There, we add every single "CCK"-field the content type has
    $w = 3;
    foreach($metadata['bundles'][$bundles[0]]['properties'] as $key => $property){
        $fields[$key] = array(
            'type' => 'property',
            'label' => $property['label'],
            'visible' => TRUE,
            'weight' => $w++,
          );
    }

    return $fields;
  }
}

3. Add this on top of your .module
module_load_include('inc', 'your_module_name', 'includes/NodeCustomController');

4. Still in your .module, add the following :

/** Implements hook_entity_info_alter() **/
function your_module_name_entity_info_alter(&$entity_info) {
    $entity_info['node']['inline entity form'] = array(
        'controller' => 'NodeCustomController',
    );
}

This will make every content type referenced through an EntityReference field use your custom class to decide which fields are printed.

Hoping this helps.

kirie’s picture

@hwold - woha - thank you very much - that piece of code got me up and running in almost no time - thank you!

Just some additional info - there are probably someone else struggling with this :)

I am using the module to manage Commerce products with the Product Display node type - and as such, my use case was a bit different. Instead of extending the NodeInlineEntityFormController class, I did the CommerceProductInlineEntityFormController (I only implemented the defaultFields($bundles) function).

My module file thus contains this code:


/**
  * Implements hook_entity_info_alter().
  */
function MY_MODULE_entity_info_alter(&$entity_info) {
  if (isset($entity_info['commerce_product'])) {
    $entity_info['commerce_product']['inline entity form'] = array(
      'controller' => 'MY_MODULE_CommerceProductInlineEntityFormController',
    );
  }
}

Also, at first I had the problem that my controller would not be loaded - and it turned out to be a module weight issue (i.e. my module's hook_entity_info_alter was called before the hook in inline_entity_form - this the module altered my alter) - the solution was to add a couple of lines to my module's install file to increase the weight of my module (i.e. making the system call my hook_entity_info_alter after the inline_entity_form's hook):

/**
 * Implements hook_install().
 */
function MY_MODULE_install() {
  $weight = db_select('system', 's')
    ->fields('s', array('weight'))
    ->condition('name', 'inline_entity_form', '=')
    ->execute()
    ->fetchField();

  db_update('system')
    ->fields(array('weight' => $weight + 1))
    ->condition('name', 'MY_MODULE', '=')
    ->execute();
}

Nitpicks:
- It might be a better practice to include the controller file in the module info file instead of inside the module itself, just add this line to the info file: files[] = includes/MY_MODULE_commerce_product.inline_entity_form.inc
- I generally like to keep the naming scheme of the inc file begin overridden/extended - i.e. MY_MODULE_commerce_product.inline_entity_form.inc - but thats a purely personal taste :) You could also leave it the same as the original (no, there won't be a naming conflict - as long as your class name is not the same, of course)

Hope this helps anybody :)

temkin’s picture

@bojanz, First of all thanks a lot for the efforts you've put on this!

Regarding your question:

I've also been thinking of providing a custom UI, a "Inline Entity Form" tab shown when editing the reference field, that would have a table similar to the one from "Manage Display" (drag & drop, formatter settings), showing properties added through hook_field_extra_fields() such as Title and SKU, and also showing all fields that are common to all selected bundles. So for line items you could add (and configure) the total field, etc.
Does that sound desirable?

That will be very helpful. Let me know if it's still on your list and if I can help somehow with that. Thanks!

- Artem

agileadam’s picture

When I implemented #16 my "Image" (image) and "Caption" (long text) columns appeared, but they didn't show any data. So, I made a few changes:

    $weight = 1;                                                                                     
    foreach ($metadata['bundles'][$bundles[0]]['properties'] as $key => $property) {                   
      $field = field_info_field($key);                                                               
      $field_type = field_info_field_types($field['type']);                                          
                                                                                                     
      $fields[$key] = array(                                                                         
        'type' => 'field',                                                                           
        'label' => $property['label'],                                                               
        'formatter' => $field_type['default_formatter'],                                             
        'settings' => array(),                                                                       
        'visible' => TRUE,                                                                           
        'weight' => $weight++,                                                                       
      );                                                                                             
                                                                                                     
      if ($field['type'] == 'image') {                                                               
        $fields[$key]['settings'] = array('image_style' => 'thumbnail');                             
        $fields[$key]['delta'] = 0;                                                                  
        $fields[$key]['weight'] = -10;                                                               
      }                                                                                              
    }

Also, like kirie says in #17, I renamed the .inc file and added it to mymodule.info. When I added this code to a Feature I had to implement hook_install() to fix module weights too. Thanks Kirie!

Thanks a lot hwold for showing your code.

For anyone else looking to implement defaultFiles() overrides like this, have a look at inline_entity_form README file.

m42’s picture

You may have noticed that, using our approach, the columns and their values do appear, but in some random order.
To restablish the appropriate one (the order you set in your content type definition), you just need a few changes.
Starting from agileadam's code :

       foreach ($metadata['bundles'][$bundles[0]]['properties'] as $key => $property) {
            $field = field_info_field($key);
            $field_type = field_info_field_types($field['type']);
            $field_instance = field_info_instance($this->entityType, $key , $bundles[0]);
            
            $fields[$key] = array(
                'type' => 'field',
                'label' => $property['label'],
                'formatter' => $field_type['default_formatter'],
                'settings' => array(),
                'visible' => TRUE,
                'weight' => $field_instance['widget']['weight'],
            );

            if ($field['type'] == 'image') {
                $fields[$key]['settings'] = array('image_style' => 'thumbnail');
                $fields[$key]['delta'] = 0;
            }
        }

Thus, pay attention to the fact that the controller sets title field's weight to 1, which might not be the real value. So you just can set the appropriate weights in your content type (the easiest solution), or you can try to write (yet another) patch that will always be welcome ! :)

pzerimars’s picture

Hey guys, I was just working on this was really bugging me.

I'm using IEF for products. In a custom module, I define:

// @file mymodule.info
files[] = includes/commerce_product.mymodule.inc
<?php
// @file mymodule.module
/**
 * Implements hook_entity_info_alter().
 */
function mymodule_entity_info_alter(&$entity_info) {
  // we'll use our custom contoller
  if (isset($entity_info['commerce_product'])) {
    $entity_info['commerce_product']['inline entity form'] = array(
      'controller' => 'MyModuleCommerceProductInlineEntityFormController',
    );

    // We'll define a custom view mode for this entity
    $entity_info['commerce_product']['view modes']['inline_entity_form'] = array(
      'label' => t('Inline Entity Form'),
      'custom settings' => TRUE,
    );
  }
}

/**
 * implement hook_install()
 */
function mymodule_install() {
  $weight = db_select('system', 's')
    ->fields('s', array('weight'))
    ->condition('name', 'inline_entity_form', '=')
    ->execute()
    ->fetchField();

  db_update('system')
    ->fields(array('weight' => $weight + 1))
    ->condition('name', 'MY_MODULE', '=')
    ->execute();
}
?>

And finally the controller. This controller makes the table appear exactly as defined in (Entity Type) -> Manage Display -> Inline Entity Form. Weights and visibility are accounted for.

<?php

class MyModuleCommerceProductInlineEntityFormController extends CommerceProductInlineEntityFormController {


  public function defaultFields($bundles) {
    // Let our parent do what it does
    $fields = parent::defaultFields($bundles);

    if (count($bundles) > 1) {
      return $fields;
    }

    // Get the bundle
    $bundle = reset($bundles);

    // Use the inline_entity_form view mode
    $view_mode = $this->settings['ief_view_mode'];

    // let's attempt to use the order set by "Manage Display (Inline Entity Form)"
    $entity_fields = array();

    // Get field instances for the given bundle
    $instances = field_info_instances($this->entityType, $bundle);
    $extra_fields = field_info_extra_fields($this->entityType, $bundle, 'display');
    $all_fields = $instances + $extra_fields;

    // Loop through the entity's Fields
    foreach ($all_fields as $field_name => $instance) {
      $field = field_info_field($field_name);
      $display_settings = $instance['display']['inline_entity_form'];

      $is_visible = TRUE;
      if (isset($display_settings['visible'])) {
        $is_visible = $display_settings['visible'];
      }


      // Populate the fields array with the managed display settings
      $fields[$field_name] = array(
        'type' => 'property',
        'label' => $instance['label'],
        'visible' => $is_visible,
        'weight' => $display_settings['weight']
      );

      // Some of our values are not properties and have their own formatters
      if (isset($display_settings['type'])) {

        // Hidden fields should stay hidden
        if ($display_settings['type'] == 'hidden') {
          $is_visible = FALSE;
        }

        // Modify the fields array to account for the field's formatter
        $fields[$field_name] = array(
          'type' => 'field',
          'settings' => array(),
          'visible' => $is_visible,
          'formatter' => $display_settings['type'],
        ) + $fields[$field_name];
      }
    }

    return $fields;
  }

  /**
  * Overrides EntityInlineEntityFormController::settingsForm().
  *
  *
  * Returns the settings form for the current entity type.
  *
  * The settings form is embedded into the IEF widget settings form.
  * Settings are later injected into the controller through $this->settings.
  *
  * @param $field
  *   The definition of the reference field used by IEF.
  * @param $instance
  *   The definition of the reference field instance.
  */
  public function settingsForm($field, $instance) {
    $form = parent::settingsForm($field, $instance);

    // Which View mode do we want to apply to this entity?
    $entity_info = entity_get_info($this->entityType());
    $view_modes = array();

    foreach ($entity_info['view modes'] as $machine_name => $view_mode) {
      $view_modes[$machine_name] = $view_mode['label'];
    }

    $form['ief_view_mode'] = array(
      '#type' => 'select',
      '#title' => t("View Mode"),
      '#description' => t('This view mode will be used to by IEF to display an existing @entity.', array('@entity' => $instance['entity_type'])),
      '#options' => $view_modes,
      '#default_value' => $this->settings['ief_view_mode'],
    );

    return $form;
  }
 
  
  public function defaultSettings() {
    $defaults = parent::defaultSettings();
    $defaults['ief_view_mode'] = 'inline_entity_form';

    return $defaults;
  }
}
?>

I'll write up a generic patch later

pzerimars’s picture

weird dup post. Sorry about that.

rogical’s picture

As this isn't available right now, I created a module for showing referenced entities http://drupal.org/sandbox/rogical/1880826 References Thumbnail.

philipz’s picture

Thank you very much @kirie and @hwold! The weight of my custom module did matter a lot in my case and now it's working perfectly :)

ruben_vreeken’s picture

@pzerimars, thanx for the code, it works great on my nodes too!

In case it helps anyone, to apply pzerimars's solution to nodes, just modify the hook_entity_info_alter implemenation to something like this:

/**
 * Implements hook_entity_info_alter().
 */
function MY_MODULE_entity_info_alter(&$entity_info) {
  // Set the controller class for nodes to an alternate implementation of the
  // DrupalEntityController interface.
  // we'll use our custom contoller
  if (isset($entity_info['node'])) {
    $entity_info['node']['inline entity form'] = array(
        'controller' => 'NodeCustomInlineEntityFormController',
    );

    // We'll define a custom view mode for this entity
    $entity_info['node']['view modes']['inline_entity_form'] = array(
      'label' => t('Inline Entity Form'),
      'custom settings' => TRUE,
    );
  }
}
Summit’s picture

Hi, I am not a programmer, but is with these solutions also possible to filter a producttype before the exisiting producs are shown? It seems they show a table, but already after the product autocomplete field? Sorry If this issue is completely different from this usecase, but I thought they where related and I can't find a way to get this working. Greetings, Martijn

dmiric’s picture

pzerimars solution works great only problem I have is with ECK entites it dosent accept formater settings. For example I can use Image formater for image field but it dosent accept thumbnail setting.

Anyone got around to solove this problem ?

Never mind it was easy to solove for anyone else having this problem find in controler and add last line

$fields[$field_name] = array(
'type' => 'field',
'settings' => array(),
'visible' => $is_visible,
'formatter' => $display_settings['type'],
'settings' => $display_settings['settings'],

dmiric’s picture

Category: feature » support

I'm trying to use pzerimars controler from #21 to extend EntityInlineEntityFormController and it works perfectly exept that it somehow looses title property on the entity form. So the title shows in table where you choose which row you want to edit but on form it self it dosent. Can someone point me in the right direction how to add ECK title property to the form.

derjochenmeyer’s picture

#7 by rcross

I'm not sure how common the case will be that multiple types of entities will be referenced, so I"m not sure we should optimise/cater for it.

Outside of Drupal Commerce this could become a very common usecase. Our customers often ask for an intuitive way to create pages and articles with: text, images, galleries, media elements. Right now there are lots of different approaches with WYSIWYG, Insert, Insert video, Image Resize Filter, Image Assist, ...

A different approach are "content elements" like in TYPO3. Site builders could create "content elements" of different types all with different sets of fields like text, text with image (float left or right), image, image gallery, video, audio, advertisement, related articles, etc... Entity Construction Kit (ECK) makes it easy to create and customize such "content elements".

There is a sandbox project by Dave Reid: Inline entity form rendered.

I think the most flexible way is to let users chose which view mode should be used per type. Here is an example how this could look like (modified the "Inline entity form - Multiple values" widget settings page:

This is how an article form could look like

And here how it could look like with rendered entity types

Created with sandbox project by Dave Reid: Inline entity form rendered

bojanz’s picture

Status: Active » Fixed

A lot of time has passed and a lot of feedback was gathered.

I have decided not to implement any kind of UI, because all options have been confusing (we'd basically need a "Manage fields" UI that supports field instances from multiple bundles).
I am adding an alter hook in #2032155: Rename the defaultFields() controller method to tableFields(), introduce an alter hook. which will make it easy for developers to change the fields returned (so commerce_stock can always add a stock field, and users can tweak what they want as well).

I also like Dave Reid's approach of showing an entity in a specific view mode.
I can't do that in the existing widgets because it would be too big of a change, but I think it makes a lot of sense to have that either as a separate module or inside IEF itself as a new widget.

Status: Fixed » Closed (fixed)

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

_vid’s picture

Hi bonjanz,
Would it be more appropriate to change the status to "closed (won't fix)"

msh2050’s picture

FileSize
64.12 KB
88.39 KB
2.38 KB

I try pzerimars's module in #21
and I delete the commerce code witch is :

 * Implements hook_entity_info_alter().
*/
function mymodule_entity_info_alter(&$entity_info) {
  // we'll use our custom contoller
  if (isset($entity_info['commerce_product'])) {
    $entity_info['commerce_product']['inline entity form'] = array(
      'controller' => 'MyModuleCommerceProductInlineEntityFormController',
    );

    // We'll define a custom view mode for this entity
    $entity_info['commerce_product']['view modes']['inline_entity_form'] = array(
      'label' => t('Inline Entity Form'),
      'custom settings' => TRUE,
    );
  }
}

then I replace the code of ruben_vreeken "in post #25 "to use it for all of content type...witch is:

<?php
/**
* Implements hook_entity_info_alter().
*/
function MY_MODULE_entity_info_alter(&$entity_info) {
  // Set the controller class for nodes to an alternate implementation of the
  // DrupalEntityController interface.
  // we'll use our custom contoller
  if (isset($entity_info['node'])) {
    $entity_info['node']['inline entity form'] = array(
        'controller' => 'NodeCustomInlineEntityFormController',
    );

    // We'll define a custom view mode for this entity
    $entity_info['node']['view modes']['inline_entity_form'] = array(
      'label' => t('Inline Entity Form'),
      'custom settings' => TRUE,
    );
  }
}
?>

(I have tender content that have an Entity Reference to tender_detail content type .... the mymodule folder is attached ...)
I add new tab in display manager but unfortunately I can not add or edit any content that use inline entity form

I see that the development is done before 6-7 months why they did not include this in module releases as stable or development release so it will be easier to setup and use??(Just download and extract)

I open an issue(modifying the Inline entity form listed fields and I try many solution witch is did not work to modify the list or title of the fields even it did not hide the title...

hope I can find easy solution.. or we can see an update for the inline entity form or other module that will add new features..

regards..

update:-
I try with fresh installation(to check if it cause be in compatibility with some patches that I apply) of api and inline entity form with application of pzerimars's module in #21 only...
but I get the same issue and if I disable the new custom module it will be Ok but as the stock module ...

bryancasler’s picture

FileSize
212.42 KB

In the interim I used the Entity Connect module and modified it a little to look like this...
Screenshot

bojanz’s picture

@animelion
That looks really nice, seriously.

bryancasler’s picture

Thanks Bojanz, it was basically this and a lot of jquery. If anyone is interested in making a proper patch, I'd be more than happy to help with what I can.

bryanmanalo’s picture

After much fiddling around I was able to make it work.

#16 is very helpful. But there were things that I changed to make it work:
(I am not using drupal commerce but just inline entity form)

1.) #17, the module weight is very important make sure that your module is loaded after inline_entity_form
2.) module_load_include('inc', 'your_module_name', 'includes/NodeCustomController'); the controller class should be .inc (instead of .php) for this line of code to work.
3.) Inside NodeCustomController, defaultFields method is not existing in the parent class, you need to override tableFields method instead.

Hope this helps someone.

Let us build the community

bendiy’s picture

I've created a patch to Dave Reid's sandbox for Inline Entity Form Render module that adds support for #29 and #34 to that module. Please check it out.
#2119791: Rerolled and Updated module code

OnkelTem’s picture

@bojanz

I have decided not to implement any kind of UI, because all options have been confusing (we'd basically need a "Manage fields" UI that supports field instances from multiple bundles).

Unfortunately, the situation is not appropriate yet: Dave's module was not promoted to a full project, it doesn't work out from the box and you need to apply a patch. Also emerged a module https://www.drupal.org/project/inline_entity_form_preview which makes pretty much the same. But still, there is no way to just allow IEF to add fields to the table!

I haven't read the whole discussion and maybe missing some important issue but let me quickly explain what UI would be just fine and not confusing from my point of view.

1) On the widget settings form could be a fieldset with ALL fields from ALL the bundles checked out.
2) The list could be provided as a sortable table so you can reorder fileds
3) Near the table could be a dropdown list of available view modes.

That's all. Now, when you build a list of table columns in EntityInlineEntityFormController::tableFields(), you just add configured fields in the proper order with proper settings from their display view modes.
Profit!
Or I'm missing something?

mnico’s picture

Hi @OnkelTem, I created a module that could help you. Still in development version but is a full project. There is https://www.drupal.org/project/ief_table_view_mode . This allow you to add fields to the table using Field UI.
Regards