Is this module still needed? If so who will build and maintain it?

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.

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.

... I can even see discussion of renaming the contact module to form module in https://www.drupal.org/node/2582955

Seems like retirement of eform is on the cards.

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.

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.

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.

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.

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.

Thoughts?

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?

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.

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?

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?!)

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 https://www.drupal.org/project/viewfield .

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.

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.

For my site using Drupal7 I have been using the Webform module. That was a module I originally waited for to setup Drupal8. Now that the Webform module has reached beta for version 8, I am starting to doubt I can accept it. The project seem hit by refactoring/feature creep as the D8 version is more than 15X the D7 version, and the module in fact alone is larger than the entire Drupal 7. Of the 12MB uncompressed data, about half is in the "tests" sub-folder. To me it seem like the module will become a security and maintenance nightmare even if it some day should complete initial security audit and QA testing.

I for one would like a light-weight Webform alternative, if the eForm module was maintained, I probably would be using that instead regardless of a stable Webform module gets released. As is however, I likely wait to see what happen with the core "Contact" module.

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.

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

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...:-)

I'd say yes, this module is still useful. The Contact module development seems stalled, at a really basic "why should we do this?" level. Hardly something to count on. Eform is the only actually existing Field API based solution.

Did I miss something? I looked at Contact Storage and it's nothing like entity forms. I've used Entityforms on 30+ sites and it's very disappointing that it's going away. As of today Contact Storage still forces you to email a user and has hard coded fields. I used Entityforms for a data collection and not a contact someone form.

This module is extremely needed!

Contact module from core is very limited. It allows to create forms only at the /contact page. It does not support tokens.
But users should to be able to place forms anywhere on the website in blocks.

Webform builder was replaced with a yaml editor.

@a.milkovsky The webform module for D8 includes a full UI but you need to enable the webform_ui.module to see it.

I hope this module can have an official version of Drupal 8.
Do we make a donation for @tedbow?

So that he can continue on this project.

I started on a replacement for this a while back (but lost the need to complete at the time) with the idea of changing this into two things:

1) a basic entity with revisions enabled that could be used as the basis for a form -and-
2) all eForm specific functionality would be pulled out so that it could be applied to any entity, since, why not?

I have already pulled out draft and conditional field functionality into modules (entity_draft, controlled_fields, filter_form_values) which can be applied to any entity (e.g. node) for starters. What is missing now is the redirect, resubmit, permission handling mainly.

I could potentially put in enough effort to get the above over the line but my question is should it go in this module (maybe 8.x-3.x) or somewhere else? I was thinking something like "entity form tools" could make more sense since it is based around extending the built in Drupal entity form display handling. Or even splitting up all the functionality into separate modules e.g. entity_form_redirect, entity_form_resubmit etc.

Thoughts?

Hi,

I am in the process of starting a new drupal 7 website which will be heavily based on collecting data from user and for such requirement, i will be using Entityform or Wefborm module.

I, personally, prefer Entityform module for several reason; However:

1) is Entityform module is stable for D7 ?

2) What about the D8 version, the development of the module will continue ?

Clarification about the life of Entityform module is required !

Thank you for you support,

@C.E.A.

Why Drupal 7 instead of Drupal 8? My suggestion would be to forget Drupal 7 to save you the pain of upgrading later. Drupal 8 is very stable and has many good features. If you avoid starting with Drupal 8 now you'll still have to learn a whole new way of doing things for D8, D9 and above.

For collecting data use the D8 version of Webform. It is scalable to hundred of fields over hundreds of forms, well supported and very easy to use.

@imclean

Thank you for your kind reply,

I am planning to build the website using drupal 7 since lots of modules which i am planning to use they don't have yet a stable d8 release.

One of them is the rules modules which my entire website will be heavily based on: Webform(or Entityform), views and rules the most.

So i was thinking to start the development with D7 and 2-3 years later i will migrate to D8.

When changing from one major version of Drupal to another (except maybe D8 and above) you generally need to rethink how you do things. Rather than trying to find the exact mix of modules you used previously, find out what can be built with D8 and the available modules. Start small then add features.

Also, Rules is available for Drupal 8.

@imclean

I will take your advise into consideration and i will review again my website needs to see if it will fit within D8.

And as for my first question about webform or Entityforn, i will stick with the Webform module as it is widely supported.

Thanks again for your kind help,

@C.E.A

I have been using Entityform on my Drupal website for 3 years and I guarantee that it is very stable with the necessary patches.
@tedbow and all Drupal community is the best.

I hope this module will have a version in Drupal 8. Unfortunately I am a small programmer and I can't help developing it, but I will try to do my best because I will start using it in a new DRUPAL8 project.

In webform Drupal8 is more complicate for me insert "entity reference field, fieldcollection field, etc... ", and take actions on them with RULES, VIEWS, etc ...
Entityform is simple great, you can use any Drupal Field.

@imclean
I suggest you, also, try Business Rules for DRUPAL 8 which is an alternative to the Rules module, which is not in a stable version yet and is much more complicated (in my opinion) to use than the version for Drupal 7.

@Kris77 thanks for the suggestion. I tend to avoid using the Rules module as it is quite large, has an impact on performance and is fiddly to configure correctly. Our approach with Drupal 8 is to listen for events in a custom module.

However, it looks like Business Rules supports events so that could be a good alternative.

Can someone please point me to a discussion with the Contact Storage maintainers about the expected roadmap regarding entityform-like behavior of the Contact Storage module? I think that is the first step to take. It appears we are on a dead end otherwise?

I am closing this issue, since the main questions have been already answered.