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.

YAML Form

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.

Comments

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 https://www.drupal.org/node/2582955

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