Integration with Inline Entity Form

Neat Idea. I'm working on this in the inline_ref_field branch.

Cheers,
Neil

I wrote a patch quick last night for the entity boxes module that adds integration with inline entity module if its any help.

http://drupal.org/node/1846998#comment-6761150

I needed to get a demo done for it so I could show a client today but just been shown Bean by a colleague which looks like an overall better solution so would be good to get support for this added :)

FYI as a temporary solution it works really well with References_Dialog (-dev version) to provide a popup dialog rather than an inline form.

Couldn't find this as the issue didn't reference inline_entity_form, so I've closed #1911214: Support for inline_entity_form as a duplicate.

+++ b/bean.info
@@ -6,6 +6,7 @@ files[] = includes/bean.info.inc
+files[] = includes/bean.inline_entity_form.inc

I think you forgot to include this file in the diff

Thanks for working on this. I think it will be a great feature. A few comments from the code.

1. +++ b/includes/bean.inline_entity_form.inc
   @@ -0,0 +1,160 @@
   +  public function entityForm($entity_form, &$form_state) {
   

   Can we just use the current code in bean_form? It would be nice to not have to worry about keeping the form updated in two different places

2. +++ b/includes/bean.inline_entity_form.inc
   @@ -0,0 +1,160 @@
   +  /**
   +   * Overrides EntityInlineEntityFormController::entityFormSubmit().
   +   */
   +  public function entityFormSubmit(&$entity_form, &$form_state) {
   +    parent::entityFormSubmit($entity_form, $form_state);
   +  }
   

   Is this needed? You are just calling the parent class

3. WIthout having looked at the EntityInlineEntityFormController class, is there any validation? There is quite a bit of code in bean_form_validate and bean_form_submit which is missing. It's very possible that code is not needed I just want to make sure it's caught.

Thank you for this patch. I've been working on an implementation of bean+entityreference+inline_entity_form to add basic block placement functionality to nodes. The results are pretty awesome.

I think all of indytechcook's comments in #9 are legitimate. I think we can find a way to reuse the form code. I haven't yet dug in to the comment regarding validation, but it's definitely something to look into as well.

The one issue I've been banging my head around is with regards to labels and titles.

This particular patch overrides EntityInlineEntityFormController::tableFields() to add label and title to the table of entities. The problem here is that if a bean has a title, the label column will display the title instead of the label.

From what I can tell, this comes from bean's defaultLabel function: http://drupalcode.org/project/bean.git/blob/refs/heads/7.x-1.x:/includes... The code here will return the title if provided, otherwise return the label. I'm still not entirely sure why inline_entity_form is doing this, but figured I'd post a comment indicating that I'm looking in to it.

There is some history and reason to the $entity->label madness.

We mocked the block configure form where you are allowed to have an "block title which can be blank and a "block description" which is required. The problem is that we beans are entities which have pages, are in listing, in views, etc. We needed a way to create a title that will always be there. So we used the logic that if there is a title then use it, otherwise use the label.

Different modules integrate into the entity api differently so we've done our best to adjust.

The patch works sweetly for me. Thanks a lot!

Is there a provision for it to be committed to the 7.x-1.x branch?

Nested Box is a module quite similar to Bean and already allows creating items from Inline Entity Form. Plus its code is following Drupal 8 standards with PSR-0 and PSR-4 stuff. Might be a good idea to have a look at its code for this feature?

Also the Paragraphs module is doing the same, although it also recreates Entity Reference + Inline Entity Form in its own way so code might be more complex to get into.

Looking forward to using these kind of stuff in future projects!

See also #2283019: Beans for non-block purposes

every bean shows up on the blocks config page, which will really bloat the list.

But having two entity types [..] you cannot share bundles definitions.

It would be great being able to tell a bean instance to not be available as a block.
And if you create it from inline_entity_form, the default setting should be "do not expose as a block", and this option should be hidden.

If you have defined a custom Bean Type in your module using hook_bean_types(), and written a custom handler class, the patch in #8 will not display your form fields defined in public function form($bean, $form, &$form_state) {...}

The patch in #8 is missing a crucial line in method public function entityForm():

+++ b/includes/bean.inline_entity_form.inc
@@ -0,0 +1,160 @@
+  public function entityForm($entity_form, &$form_state) {

In order to get your custom form fields defined in public function form($bean, $form, &$form_state) {...}, add following line above the return statement in entityForm() method:

// Get the Bean type form.
$entity_form += $bean->getForm($entity_form, $form_state);

As indytechcook mentioned in #9 (bullet point 1), it would be better to use bean_form instead of duplicating functionality. Then we wouldn't need to worry about such issues. I have yet to figure out how to do that. I n the mean time, you can use my suggestion.

Attaching a revised patch to include missing piece of code.

The patch in #15 isn't applying cleanly for me:

[mac:kristenpol:bean]$ patch -p1 < bean-inline-entity-form-integration-1821136-15.patch 
(Stripping trailing CRs from patch.)
patching file bean.info
Hunk #1 FAILED at 6.
1 out of 1 hunk FAILED -- saving rejects to file bean.info.rej
(Stripping trailing CRs from patch.)
patching file bean.module
(Stripping trailing CRs from patch.)
patching file includes/bean.inline_entity_form.inc
patch unexpectedly ends in middle of line

Reroll.

Hi,

I have tested the patch and it looks very good so far. There is one small thing though. Instead of function labels() could you please use function defaultLabels() so the labels can be configured trough the admin ui if needed. This way if it is only 1 block type then can rewrite the label with the block type instead of just saying add block.

Kind Regards,
Dobromir

Adding updated patch from #17 with my changes.

adding path file with proper name this time

Just found this issue. This seems like it would be a great addition to Bean.

I have found a couple problems with this patch. It may work well for more generic but it acts differently then saving a Bean in the regular so modules extending Beans will have problems. Here are the problems I have found so far:

1. Bean::setValues() is not called. This is called when a Bean saved via the regular form.
2. hook_bean_submit is not called

I have feeling this section will have to be changed:

  public function entityFormSubmit(&$entity_form, &$form_state) {
    parent::entityFormSubmit($entity_form, $form_state);
  }

It will probably need to be changed to include the logic in "bean_form_submit" or call it directly and remove the redirect.

I found these problem because I was trying to make the patch work with my new module Views Beans but it would cause problems with any Bean related module that relies on setValues or hook_bean_submit.

doesn't seem to work with entity translation: no blocks are returned in the autocomplete field when choosing an existing block

Implements the suggestion from #21

Hiding #23 which contained an error

The label is not shown in the table list. Instead, the title is shown twice in a row.

@vectorbross may be this issue's problem to fix. #1995770: Issue with Automatic Entity Label

I can confirm the patch is working.

The patch was tested on GetPantheon's servers, with a Panoply Distribution installation.

I don't know how stable this patch is, but I am rolling out a website with DIY drag-and-drop functions for 100+ users and this was a core solution for making that process simple. Hopefully it's ready to be put through the ringer :)

kamescg, I've been using this patch in production for many many months across hundreds of websites without any signs of issues.

Great to hear! So what is happening with design on this patch? It seems like it opens up a great stepping-stone to transition into a drag and drop interface, like Panels, but without the limitations and overhead of that module, by using a nice little dashboard fixed at the bottom of every page, which contains blocks and their current placement in the theme's regions.

With this patch applied, I was initially getting an undefined function error at line 156 of entityFormSubmit where it was attempting to call bean_form_submit. I was able to resolve it by adding

module_load_include('inc', 'bean', 'includes/bean.pages');

right before than line. However, problems persist. When I click on "create block" I get a EntityMalformedException on line 7766 of common.inc. It seems that there's no $entity parameter being passed into entity_extract_ids. I've tracked the issue back as far as bean_form_submit, where it seems like there's no bean in the form_state array. The form state array actually seems the form_state for the entire form, rather than just the inline entity form. It contains the node object, but not the bean.

I don't have any problems creating new blocks via the regular UI at block/add.

The code I'm using this patch for is available in a sandbox project: https://www.drupal.org/sandbox/ultimateboy/2221701

This sandbox project contains field base entity reference field exports via features. To use, first select which content types "block selector" should be enabled on. Behind the scenes, field instances are pragmatically created on the selected content types. Once selected, a new "blocks" tab appears on nodes revealing the new entity reference + inline entity form fields to allow content editors to quickly place beans on to individual nodes.

Anyways, thought I'd pass along how I'm personally using this patch. Definitely a powerful combination.

I took a look at your sandbox code - it looks like it's using a patch other than the most recent (#24). Seems like it works generally, but not if you have fields on your block types. Or rather, it works in that it will create blocks, but there's no way to enter data in any custom fields.

Going to keep working on this.

Here's a statically coded version of something that works for fielded block types -

  public function entityFormSubmit(&$entity_form, &$form_state) {
    if (isset($form_state['redirect'])) {
      $before = $form_state['redirect'];
    }

    $ief_form_state['bean'] = $entity_form['#entity'];
    $ief_form_state['values'] = $form_state['values']['field_sections']['und']['entities'][1]['form'];

    module_load_include('inc', 'bean', 'includes/bean.pages');
    bean_form_submit($entity_form, $ief_form_state);
    // Undo the redirect set by bean_form_submit().
    if (isset($form_state['redirect'])) {
      if (isset($before)) {
        $form_state['redirect'] = $before;
      }
      else {
        unset($form_state['redirect']);
      }
    }
  }

Instead of passing $form_state directly into bean_form_submit, it seems necessary to get the subsection of $form_state values that actually pertains to the field we're using (in this case, field_sections).

So what this code needs in order to be a usable solution is a way to replace 'field_sections', 'und', and '1' in $ief_form_state['values'] with appropriate values.

Delzhand is there anything I can do to help assist in solving this? You seem to be knowledgeable about Bean Module inner-workings.

Okay, it was pretty trivial to figure out how to resolve that last bit - the entity form helpfully gives you exactly what you need. This patch should work.

@kamescg - I actually have never worked with Bean before Wednesday! If you want to help, you could test out this patch - it should work for both creating and editing fielded block types. So far I've only tested it with a block containing a node reference.

This patch removes the title field from the table and form. Due to the way bean's core handling of labels works, it simply isn't good UX to have both fields present. If only the label form is present, then whatever you enter is what shows up in the table. If you want to add a title, you can do it through the regular block edit (although it seems that the default bean template file never outputs the title anyway, so even that seems unnecessary).

Update the patch with the following:
* Added back the title to the form since this is actually used for the block titles. Implementing hook_inline_entity_form_entity_form_alter() allows customizations to hide or show as needed.
* Added auto generated title and label settings similar to Commerce Products title auto generation. If the enabled, then the label and/or title are automatically set to the parent entity's label, ie node title.

Pushed to 7.x.

Bean title issue are being handled in another issue

Really? I dont see the commit. https://www.drupal.org/node/1149602/commits

Your right sorry. I held off because it was related to a later issue around titles.

So what still needs to happen for this patch to be committed?

This issue shows up in Release notes for 7.x-1.9 (https://www.drupal.org/node/2445527)

Confused.

I just applied patch from #40 with joy. Elsewhere I'm using 1.9 and the patch was not necessary to create beans with inline entity form. Not sure what the status of this issue should be since release notes mention it, but the commits page doesn't list it... at least rtbc, eh? though seemingly fixed...

The problem with two missing commits is being handled via #2623456: 7.x-1.9 release not merged on the 7.x-1.x branch.

The commit has been recovered, the 7.x-1.x branch is now up-to-date.