Embed an Entityform in a Block

IMO, Bean is definitely the say forward when it comes to blocks in Drupal 7, and a lot of modulers are starting to provide integration. Perhaps an entityform_bean module to bridge the gap would be a nice addition, which would may even just need mimic what you did with your custom bean and entityreference field to some extent.

Yes I have been using a combination Bean and Entity Reference for the embedding Entityforms in blocks in testing.

@Arrow to get it to display you have to set it to "rendered entity" in the manage display and then click the setting icon to set it to "Rendered as Full content". I was able to use it is this manner.

@mrfelton, I think entityform_bean is good idea but don't plan to make it a submodule, at least not for 1.x. It would be good as another contrib module. Though even if it wasn't module it is pretty easy to set up. Could just be exported Feature. It wouldn't need any coding.

Yeah, so following in the vain of other bean plugins, probably bean_entityform as opposed to entityform_bean, and as ou say - probably just a basic feature module.

I've written a module that can create a block out of any entity form type (similar to webform block). If anyone is interested, I'll post it as a project.

@drush fan I think that would interesting to look at. At least post it as a sandbox project. Thanks. Ted

Ok, I've opened a sandbox project with the code I've got for now.

Sorry to be lazy (unknowing) about getting git going, but can you upload the zip file?

I am going to close this issue. @hellomobe if you need help with the sandbox project you can create an issue in that project.

Thanks

@hellomobe I have also created a sandbox project that uses the Bean/Entity Reference method

http://drupal.org/sandbox/tedbow/1774070

To get the tar file of a sandbox project(without dealing git)

1. Click the "Repository Viewer" link on the project page
2. Click the first "snapshot" link on the page.

Using bean with entity reference or this sandox project works great, but there still undesired effect, the entity_form_wrapper callback override every page title where block with an entityform is shown, solution is simply to comment drupal_set_title() function on entityform.admin.inc line 206
But this title is used on admin page, so i'm not sure it's the best solution.

Regards.
Jean

@mogtofu33, thanks for reporting issue could you make new issue for the drupal_set_title problem.

Basically this is going to effect any entityform that you have embedded via block, panel, or entity reference. So I will make it a priority to solve.

Thanks,
Tedbow

@mogtofu33 I create an issue and a patch. #1820020: Embedded entityforms(panels,entityreference, etc) overrides page title

Please review if you get chance

I also did experience this problem while embedding entityform as a mini panel. Applying this patch solved the problem for me too.

I've created a simple patch that creates block for each entityform type.
I think it is important to provide such kind of functionality out-of-the-box instead of using additional module (I mean Entityform Block). It becomes a useful feature to ease migration from Webform.
Please review.

Sorry, here is the patch.

Tweak that deals with the problem described in #1820020: Embedded entityforms(panels,entityreference, etc) overrides page title: avoids page title overriding.

@Staratel thanks for the patch. But I think I would prefer this to be a separate module. Or at lease a sub module.

In any case I think there should at least be a checkbox on the entityform type edit form to ask "expose as block?". If a site has tons of entityforms this would fill up the block admin page as it is now.

Also does the method work with multi-page forms created using Field Group. I don't think it would or at least might have some unexpected results.

I am marking as a possible feature for 2.x(as a submodule) to get feedback

Well, there is a way to make it work with views:

• Create a new view
• On the "Add new view" page choose "Show: Entityform Type"
• Check "Create a block" and under "Display format" choose "Fields" (not "Rendered Entity")
• In your view settings be sure to add the field "Entityform Type: Rendered Entityform Type"
• The important settings for the field are "Display: Show Complete Entity" and in the appearing dropdown select "Full content"
• You should also add a filter "Entityform Type: Internal, numeric entityform type ID" and give it the value/ID of the form or what I find more elegant is the filter "Entityform Type: Machine-readable name" and give it the machine name of the entity form.

Entities are awesome, right? :)

I haven't tested this with multipage forms as of #18, but for simple forms it works just great.

Anyway, thanks for the great module! Having a module that takes advantage of the build in Field API in Drupal and the magic that entity aware modules supply to such approach is great.

One more thing to keep in mind though!

In the entityform module settings you can setup which roles should be able to submit the forms.

When you create a block as in #19 these settings are being overriden by views and even if you dissallow the anonymous user to submit the form in the module settings, having the view being visible by "View published content" would make the form appear.

So you have to apply the same access settings to your view.

Thanks to mrupal in #19, that worked just fine!

Removing entityform-2.x feature tag because I don't see this as part of 2.x.

I think could easily be put into another module.

I've applied patch from #17 and I can expose the entity form in an block which is great! After some testing i've noticed that validation and submission messages dosen't work. Could the patch be related to this issue or am I missing something here?

> I think could easily be put into another module.

I am inclined to agree.

However, there are a few problems with another module modifying the entityform type form:

- The use of _entityform_type_setttings_elements() means that form alterations to entityform_type_form won't show up in the defaults.
- _entityform_remove_fieldsets_from_tree() forces #parents on all the settings that are serialized, so you end up with a flat array in the entityform_type entity, rather than things placed under, say, 'draft_set'. This is run in the base form. That means that form alterations won't benefit from it. That can be worked around by the form_alter form elements each setting their #parent... but this really needs documenting in the entityform_type_form, so developers extending this can figure it out.

I needed this for a project, so I've used the patch above as the basis for a module: https://drupal.org/sandbox/joachim/2045865

I'd be happy to promote it to full project -- though if anyone wants to offer to maintain it, I'm very happy to hand over ownership :)

@joachim thanks for making the sandbox module available.

I set up _entityform_type_setttings_elements() so that the defaults and the Entityform Type forms themselves could use the same elements and they would only have to added in 1 place. But maybe I over thought it.

That means that form alterations won't benefit from it. That can be worked around by the form_alter form elements each setting their #parent... but this really needs documenting in the entityform_type_form, so developers extending this can figure it out.

Yes, how I got around this in Entityform Notifications for the 7.x-1.x version of the module was to call _entityform_remove_fieldsets_from_tree() from the alter.

function entityform_notifications_form_entityform_type_form_alter(&$form, &$form_state, $form_id) {
  $entityform_type = $form['#entityform_type'];
  _entityform_notifications_type_settings($form['data']['notifications_set'], $entityform_type);
  //$form['data'] ['notifications_set'] = $notifications_set;
  _entityform_remove_fieldsets_from_tree($form['data'], array('data'));
}

But yes, either way it should be documented.

UPDATE:
Another thought is that maybe I just replace _entityform_remove_fieldsets_from_tree() with something that happens on the #submit side to remove the "*_set" level from the submitted values.

> Another thought is that maybe I just replace _entityform_remove_fieldsets_from_tree() with something that happens on the #submit side to remove the "*_set" level from the submitted values.

That would be a possibility too.

I do sort of like the #parents technique; it's neat.
I wonder whether _entityform_remove_fieldsets_from_tree() could be set as either a #process or an #after_build on the $form['data'].

I wonder whether _entityform_remove_fieldsets_from_tree() could be set as either a #process or an #after_build on the $form['data'].

Yeah, I think I will try those.

The plot thickens: I just found this project already exists: https://drupal.org/project/entityform_block

I haven't time to look at it right now (just moved house!!!) -- does it do the same thing as the sandbox I posted? Would there be work needed to merge the two sets of code?

It doesn't have any releases, or any commits in nearly a year, so maybe its maintainer would want to hand it over to someone?

Yeah, this looks like a very similar module to the sandbox with potentially extra features, but it definitely doesn't look like there has been much activity on the project / any desire to push it live.

I'll check in with the maintainer and see what his/her thoughts are.

I have now become a co-maintainer on this module. We'll be releasing a dev version shortly.

Test it out and let us know what you think.

Cool! Feel free to plunder any code you like from my sandbox (which in turn I'd plundered most of from the patch here... :D )

Just to weigh in here.

I currently like @joachim's sandbox module: https://drupal.org/sandbox/joachim/2045865

I just seems to have a lot less code than the other Entityform Block module.

@timodwhit or others working on that project does you project do other things that the sandbox project?

If we can use something as simple as the sandbox then I would be in favor of making it a sub module in this project(maybe starting with 2.x).

Thoughts?

Yeah, our project adds a checkbox to each entity form and allows the block creation to be decided on a form-by-dorm basis, and then it adds a helper message to say "This form is now a block" or "this block has been disabled".

Does that help?

> our project adds a checkbox to each entity form and allows the block creation to be decided on a form-by-dorm basis

I've got that too, in entityform_block_form_entityform_type_form_alter().

I'm not sure those messages are needed -- presumably you're having to check if the state has changed, which is quite fiddly.

Oh nice. I would say go ahead with the lesser code version, and create a submodule. Nice work @Joachim

I've made a few small fixes to my sandbox.

Also spotted this: #2090199: can't have more than one entityform submission form on one page

I don't know if it's a bug in my sandbox code, or to do with the way Entforms uses forms.

Added #19 to the handbook pages. Thanks @drupov!

Issue is six months old, open if still needed.

Thanks, Drupov! Your solution (#19, 20) is just what I needed.