Current Status

Determining if this module is needed for Drupal 8.

Current alternatives

Contact Storage( +Core Contact)

This module adds much of Drupal 7 EntityForm functionality to the core Contact module. Many of it's features are likely going to be moved into Drupal Core.

There is a roadmap issue for getting features into Drupal core: #2582955: Contact module roadmap: 80% usecase of webforms in core
Phase 1 of the roadmap has been done. Phase 2 has an issue to get approval: #2807777: Formal approval for Phase 2 of 80% usecase of webforms in core

Contact Storage has over 4500 installs(rising fast) and is at 8.x-1.0-beta7.


This module does not use the Field API. It has form creation user experience that is more similar to Webform than Entityform or Contact Storage.
YAML Form has over 2000 installs(rising fast too) and is at 8.x-1.0-beta19.

Is this module needed?

Given the 2 options above is this module still needed? Would it make more sense to join force with Contact Storage?

Developing this module well would be a substantial, ongoing commitment. I, as the maintainer, don't have the time for this.

I would be willing to help facilitate further development continue if it is determined that it is still needed considering the 2 options above.


tedbow created an issue. See original summary.

mikejw’s picture

My current thought is "Yes" but perhaps with some changes.

Having a look at the current contact module here are my thoughts with respect to it as a replacement (YAML module is completely different conceptually and not a replacement):
- I think that the base fields such as recipient (which is required), subject, message are not useful and are specific to contact forms. If you don't want those for a custom form then too bad.
- It doesn't have any permissions around who can edit submissions
- It doesn't currently have a mechanism for submissions to easily edit their submission (re-edit old submission function)
- I think that the name of it is a bit unfortunate as a replacement ("contact" - what about surveys? or other uses?)

Another option is ECK for general entity form creation (without the contact form cruft) but that is completely functionless (as expected).

What I would like to see from eform (based on my projects):
- (perhaps this could happen in 8.x-2.x)
- get revisions working
- remove the draft thing, I have a module for generally doing drafts that I will put up soon, makes sense for it to be more generic
- possibly add in some of the form code in a way so that it can show up on any entity which would be very useful to add into an eform block functionality
- clean up permissions and also a bit of an all around code clean up

I also have created a bunch of modules for making the form creation process a lot nicer (more like webform) which I am also looking to release.

I also believe I have the time to do this and maintain it to a reasonable degree.

tedbow’s picture

Issue summary: View changes

@mikejw thanks for the feedback

Having a look at the current contact module here are my thoughts with respect to it as a replacement

Were you looking at core Contact alone or with the contrib Contact Storage enabled? A couple of these are fixed by that module and a couple have issues in the queue.

I have linked the 2 core roadmap issues for adding functionality to the core Contact form and added them to the summary.

I think they address all the issue you address with core forms
Here are some individual issues. Many of the test are
#2753255: Make adding email recipients optional
#2753253: Don't hardcode Sender name, Sender email, Subject and Message fields
#2325799: Add per contact-form permissions for contact module.
#2750627: Add Edit and Delete forms for contact module Message entity

I think when deciding if the module is necessary we should look at where core Contact is likely to be in 8.3 or 8.4. Not what core has right now because obviously eForm is also not ready now and will take a good of work to get it ready.

YAML module is completely different conceptually and not a replacement

I agree that YAML module is not a replacement but it but others may be using eForm because Webform is not ready and they just want a flexible form. YAML Form is much more the Webform use case where forms are content and are passed onto clients to make and edit.

I also have created a bunch of modules for making the form creation process a lot nicer (more like webform) which I am also looking to release.

I looked at your profile and a couple these projects look interesting. I know that the developers of Contact Storage are also planning to work on a more client friendly Form building experience through another module. It might make sense to join forces with them for a general Form building Field API module.

mikejw’s picture

Hi @tedbow.

Yes - you are doing a good job of swaying me towards contact module et al. as the longer term solution. I am still not enamoured with it's "contact" form angle but from looking at the roadmaps it seems like it is heading back to be a more general eform alternative. Any more specific functionality will hopefully be able to be added in a sub-module of sorts.

The other modules that I don't have in the sandbox yet (about 7 of them) are all entity agnostic so they should plug right into contact/contact_storage anyway.

I will start contacting some of the contact storage people and make some inroads there. Cheers.

mikejw’s picture

... I can even see discussion of renaming the contact module to form module in

Seems like retirement of eform is on the cards.

dougmorin0’s picture

Has development on the eform module stopped? The main reason in adopting entityforms over webforms in Drupal 7 was because that was supposed to be the direction of forms in D8. Now, while in the middle of fully adopting D8 and having around 10 sites in D8 using eforms I now find out the forms I have created will need to be converted to using another module because dev has stopped or slowed down.

Even with adopting Drupal's built-in contact forms, all features are not there yet and therefore not easily adoptable for me. My company runs a lot of sweepstakes for our clients and that's proving difficult.

tedbow’s picture

Now, while in the middle of fully adopting D8 and having around 10 sites in D8 using eforms I now find out the forms I have created will need to be converted to using another module because dev has stopped or slowed down.

I am sorry if these were production sites but it is never recommended to put dev release modules on production.

Have you checked out ?
What features does eForm have that this does not offer?

nielsaers’s picture

Contact storage + core contact is not a viable option at this time in my opinion.
Contact still has those base fields that you don't actually need every time (temporarily patching core is not an option)

Maybe in a year or year and half core might have changed the contact module to be more generic, but in the mean time eform is good alternative if you need the field api.

This also is the policy we've taken in our company for forms. As long as core doesn't get rid of the base fields we wont use the contact module and we'll keep using eform.

tedbow’s picture

@nielsaers re "(temporarily patching core is not an option)"

Having you looked at various hooks in core that would help you deal with this?

Also from the issue summary

Developing this module well would be a substantial, ongoing commitment. I, as the maintainer, don't have the time for this.

Related to this issue we would have to figure out who would support module long term. If nobody is going to support the module it doesn't seems like a good idea to use it.

scottsawyer’s picture

I am not sure if it is still up for debate as to whether or not this module is "needed", but in my mind eform ( and entityform ) fill a pretty specific ( and important ) role, at least for me.

I tend to use these for quickly collecting user input to do something with later. For instance, a membership application, where the information is stored in an entityform ( eform ) submission until it is approved by a privileged user, recording RSVPs. Little chunks of information that don't warrant their own entity type, but where the information benefits from being it's own entity. And I don't have to build a module or new entity every time I need to collect some new "chunk" of information.

Additionally, the fact that eform exposes so much of what it does to the front-end, it's an easy tool for a site builder to use, especially in conjunction with Views and Rules, it becomes quite powerful.

I realize though, that finishing a release of eform and maintaining it is a huge proposition, and while I am willing to help where I can, I am certainly not in a position to be a maintainer. I appreciate all of the work you've done on the module and hope others are willing to contribute.

frob’s picture

I also consider this module to be essential.

It would be nice if there was a general purpose form builder that created full fledged entities as form submissions, but currently there isn't and I cannot find anywhere that it is being discussed.

mikejw’s picture

I have been thinking about this a bit more - I feel like most (all?) of the functionality encapsulated in eform could be put into a module so that *any* entity with bundles could effectively provide an 'eform'. So you would create an entity using eck or drupal console and then you would enable this new module which would then give you all the rest of the eform functionality.


frob’s picture

I am not opposed to the idea. It would more mirror the way webform has worked except on the entity level. Or do you expect this to work on the bundle level?

mikejw’s picture

Hmmm, yeah it would probably show up on the bundle edit page (so in the vertical tabs that for a node bundle have things like publishing options) where you would basically just enable it and when you enable that it would add a horizontal tab, perhaps 'Extended form settings' which would have the meat of it i.e. all the current eform functionality that shows up on the eform bundle edit page.

frob’s picture

What about making eform work more or less like the paragraphs module. Instead of having to fuss about displaying things on other entities/bundles the module could just use an entity revision reference field to the entity form. I have not looked to far into the existing implementation, are the eforms implemented as content entities or config entities?

mikejw’s picture

The current implementation has both config and content. There is the eform_type config entity and eform_submission content entity. Quite similar to, say, node and article.

Your idea is interesting, however, I am not sure where you would put configuration for any form settings such as to do with the submission page, resubmission, access etc. that is currently in eform submission or similarly in something like the contact form module (which I am hoping my module could also do - why not?!)

frob’s picture

The paragraphs module has a route for entity configuration /admin/structure/paragraphs which basically matches that of eform. The change is more of a supporting use-case. This is actually how I used to use entityform nearly every time I used it. Create the forms, then add an entity reference field to a node that includes a select form for the page.

If we wanted to have the form submission options as a part of the field instance instead of the base field we would have to create a custom field. We could probably base it on the entity reference field. A similar thing was done with the viewfield module .

mikejw’s picture

Ok, I think I understand what you are saying.

That sounds totally do-able but where would the submission options show up? On the form display field settings on the entity reference field (that shows up when you hit the cog)? I kind of feel like that could be too much to throw in there and I was thinking of exposing the submission options using plugins so potentially you could add all sorts of things if you wanted. I guess it could be cool to pick the bundle and then the form display (usually default) from the entity reference field and then there is a link through to 'submission settings' or whatever that could should in a modal or just another page somewhere.

Either way that's really just UI etc. and as you say a supporting use-case. I kind of like this idea either way and so I think I will try and create a sandbox module first as a proof of concept. It could potentially become, maybe, eform 2.x or a completely different module etc. Thanks for your input.

chaloum’s picture

Yes, this module is definitely needed. This module was vital for the D7 projects I did. the other form builders out there are very constrained or some strange drupal hybrid or promote a type of usage, workflow or field limitations. Also, the lack of reusability particularly with Webform is hopeless.

tedbow’s picture

@chaloum are saying this after reading the summary of alternatives in D8? what does entity form offer that others don't?

dougmorin0’s picture

I just recently switched to the D8 version of webform after support for this ended. It's fully flushed out and does everything I need. I used the d7 entityforms version, and the new version of webform has everything the d7 entityforms version had and then some.

I would suggest that anybody still concerned with this module's support being dropped check it out and switch.

frob’s picture

@dougmorin0, @tedbow; Last I saw webform didn't have entity level operations for forms and submissions.

tedbow’s picture

@frob yes but Contact Storage would handle that

Kris77’s picture

Hi @tedbow,
I'm trying to replicate my site in Drupal 8 but I realize it's still too early because of too many uncompleted modules or conflicts in general.

I use your fantastic module in DRUPAL 7 and I explain to you my reasons. With EntityForm, in my scenario, i can:

  • Use any type of field(entity reference, field collection, term reference, and all those that exist in drupal
  • EntityForm is completely customizable: Draft settings, Buttons, Message to show, etc...
  • Is full integrated with rules module and entity rules module(I use the rules module very much)
  • Is full integrated with Views
  • With DRAFT my users can send entityform, i check their submission and then they confirm
  • With last translation support i can use it with multilingual site.

These are all things I've been able to do in Drupal 7 only with EntityForm. With webform you can not enter a field collection field, for example ...

Sorry for my english...:-)