[webform] Webform

I'm a little torn on priority here. On the one hand it's a top 10 module. On the other, D8 contact module might render some uses unnecessary. On a third hand, the maintainers are actively seeking help.

Split the difference at major.

And while I was equivocating, updated the issue summary with my current knowledge of this project.

I know, that there are limited resources, but i think, this is a critical issue.

I experimented with the contact form in the last days. This is a very basic form. There is not much you can do with it. For example there is no way to add markup to give the user some hints how to use the form. The module gives the advice to add a custom block for additional text. That is not a good solution, the text will not be integrated in the form and it will clutter the block interface.

If the webform gets no priority, then the contact form needs the priority to add some of the functionality that webform has.

I'm already coding some forms myself, because we are planning to go live in the next few weeks. But i think when drupal 8 gets released there will be a lot of site builders in need for a working form module.

What should we do with Drupal 8, when we have no forms?

I agree with @k4.

At least we should add the upgrade path from webform to contact form. If there is not need on updating two similar projects.

re: #4: There is a migrate_webform project with a current focus on D6 => D7. Lumping an upgrade path into this issue should be focused on that project, not here.

Adding a pointer to Contact Storage module.

This should be a major priority. Real world example:

Developer is deciding whether to build a new site in D8 or D7.
Needs a few forms on the site.
Tries D8 contact.module, decides it doesn't do everything required (i.e. anything above a very simple form)
Looks at webform.module D8 status.
Ends up here.
Looks for D8 webform alternative.
Ponders if they should use form API to manually create forms.
Reverts to building site on D7

There are half a million plus sites using webform. Many of the people who built those sites will go through the above steps. This is a major roadblock for D8 adoption and unfortunately the contact.module is no replacement for webform.

@all If you have tried to build a form with contact form + contact storage in D8 and you are blocked, please post the missing functionality here.

This will help us either improve contact form or build the case to port webform.

@johnkennedy

For instance, with Webform you can browse form submissions and export them to Excel. I hope that with eForm module this could be done.

What's mostly missing IMHO is the fact that contact forms are entity_types. This means they actually get created in config with CMI. That makes a CMI deployment model very difficult, when you want to allow site-editors to create forms (set fields, conditionals, mail settings, ...).

This blog entry is very interisting. Also read the comment there from larowlan:

As a maintainer of contact in core and contact_storage in contrib I want to point out that there are some things that webform is better suited to - that contact module cannot do.

These are
* Forms with lots of fields. Each field is a config object and this can increase the size of your fieldmap, as well as the number of tables. Webform stores its data in a single table, Field API stores fields in one-table per field. There is obviously a storage and performance implication there (This is the same issue with entityform in D7).
* Multipage forms (although fieldgroup in contrib might power this for contact module)
* Lots and lots of forms. Each contact form is a new entity-type bundle so adding lots is equivalent to adding lots of content types. (This is the same issue with entityform in D7).

That said, we have plans to bring elements of contact_storage to core in an 8.x point release (e.g. 8.1, 8.2) - please join the conversation on https://www.drupal.org/node/25...

Also, to expose entity form as block you can user this module: https://www.drupal.org/project/entityform_block

#14 @rcodina, You do not need to use an extra module for that. You can add a field to a block and add the contact into a field.

Hi, I would like to throw my YAML form module into the ring as another approach for building survey forms and collecting submissions in D8. The YAML form module uses the Entity API for managing forms and submissions, but the actual form inputs are just FAPI render arrays serialized as YAML.

The module has an alpha release, with around 75% feature parity with the Webform module with a whole assortment of additional features like multilingual, access controls, entity references, prepopulation via query string parameters, devel generate support, starter examples and templates, etc…

Please take this module for a spin on simplytest.me or watch a screencast, and post any feedback, bugs, issues, and/or feature requests in the YAML form module's issue queue (not here).

Hello,

The D8 core contact form + contact storage solution does fill some of the webform use cases. The D8 contact form is a huge step forward, and the views integration in core helps a ton.

That said, as someone actively trying to migrate dozens of sites to D8, here are some of the functionality issues that I see as missing from the contact + contact storage solution:

• Ability to turn the form on/off. Currently appears you can only edit/delete the contact form.
• Maximum submissions setting (total, per user)
• Permissions at the form level (who can submit the form by role)
• Clearing out a form: Guessing you could use VBO to make this happen if not in contact form itself (alternative appears to be delete submissions one by one?)
• Emails: custom and multiple different emails to recipients (And ability to include data supplied in the submission). Might be able to use actions/rules to fill the gap?
• Download options: CSV, EXCEL export specifically missing. You can replicate the tables and submissions tabs in views. Contact Storage helps with the list tab, and ability to easily filter results per form, etc. Views integration helps with any other way you want to view submissions. REST core functionality gives you data export to XML, JSON, but not CSV/Excel. However, if views data export moves to D8 that solves the CSV/Excel issue.
• Ability to change form button text easily ("send message" not ideal)
• Multi-page forms
• Form validation: some is built-in to contact form/fields, but some of what we had with webform validation module does not exist
• Conditional form fields: again, some of this was added to webform via webform conditional module
• Save form as draft to finish later

Personally, I feel like contact form + contact storage is pretty close to a viable solution. If a few of these bullet points listed could get tacked on to contact form, and/or addressed via a few helper modules, it would address a majority of our concerns.

I'd also like to chime in that webform is recommended again and again by folks over at CiviCRM. Many people I know use https://www.drupal.org/project/webform_civicrm

The ability to download forms into CSV/Excel is hugely important to me. Almost everything I use webform for requires this.

The ability to do multi-page forms is very important. This helps to break up a long form, such as an application, into more manageable pieces.

I'm running a D8 site right now and was really hoping to do a simple order form with webform. Since it's not ready I guess I'll have to go look at other solutions.

Sorry to say but I agree with #9 and #12, the contact module just doesn't do it:
- not functionally due to a lot of missing features like export to excel, reporting, conditional elements, ... Have a look at the huge list on https://www.drupal.org/node/1526208
- not technically because of its architecture it doesn't scale like webform did

Webform was imo one of the best features (for webmasters, not developers) in Drupal 7, its importance should not be underestimated.
Willing to help port webform to D8 as it is a key module.

No need to panic folks, webform will be ported to D8, we could certainly use some help though!

The core contact and contact_storage (currently in contrib) are great for straight forward forms. However there are a number of use cases that it does not cover (ability to scale, client form creation, multi page forms, complex conditional forms, etc). So there's clearly a need for webform on D8.

Currently I am the only maintainer actively working on the D8 port. DanChadwick has stepped down from his role of leading the 7.x branch and quicksketch is again maintaining the 7.x branch. Which means I could very much use a hand on the D8 branch. My time to devote to this is limited, so any co-maintainers willing to step up or even just provide a patch or two would be much appreciated.

I wish I knew more about this type of coding to where I could help with that sort of thing. I'm happy to help with testing and such, but otherwise I'm fairly limited. I've been using my blog to test out a number of D8 modules so that I can help identify any issues, bugs, css problems, etc. Happy to do the same for webform.

I wanted to provide some input on functionality for Webform Module that I have not been able to replicate with the Contact Module. We at Yale University are in the process of building our YaleSites distribution (http://yalesites.yale.edu) in D8. The Webform Module is key to our platform as it is used by our admin staff to capture information from students and staff beyond simple registrations and surveys. I haveused the Contact Module for other projects outside of my work at Yale and have found it to be limited in many of the things that the Webform Module provides. Since the Webform is used mostly by non-technical people with no access to the backend, it is essential that we have a point and click configuration for the following:

* Easily create custom email notifications to the sender and admin staff.
* Export results in a csv file
* Total submissions limit
* Per user submission limit
* Conditional fields
* Setting the form to be Open or Closed
* Treating the form as a node so it can be easily added to a menu

These are the most commonly used features that are built into the Webform module that are difficult to replicate with the Contact Module.

@jsimonis Any help is appreciated, it's still early on in the port so there are many bugs and broken functionality. Simply reporting them one at a time is a valuable contribution.

@nflowers1228 Thanks for those use cases. I think the issue summary provides a brief overview of those use cases, but it's good to see a more comprehensive list. Any efforts you could add into the port to help out YaleSites would be appreciated.

I'll see about downloading it and putting it on my site to test out. : )