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

@nflowers1228 thanks, thats a great list - would you be interested in creating feature requests (where they don't already exist) in contact_storage for all of those?

Recapping on the features requested in #17

• Ability to turn the form on/off. Currently appears you can only edit/delete the contact form. - #2724499: Allow disabling forms to prevent new submissions
• Maximum submissions setting (total, per user) - #2724507: Add a maximum submission limit for forms
• Permissions at the form level (who can submit the form by role) - #2724503: Per form based access permissions
• 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?) - #2693281: Add bulk operations support for views
• 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? #2723893: Merge Webforms "OptionEmailtem" feature into Contact Storage
• 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. You can do this with csv_serialization module and views
• Ability to change form button text easily ("send message" not ideal) #2669794: Add ability to change the "Send message" button text and hide preview button
• Multi-page forms This should be something that works generically for Field UI - eg field_group
• Form validation: some is built-in to contact form/fields, but some of what we had with webform validation module does not existThis should be something that works generically for Field UI - eg Field validation
• Conditional form fields: again, some of this was added to webform via webform conditional moduleThis should be something that works generically for Field UI - eg Conditional fields
• Save form as draft to finish later

The latest beta of YAML Form looks like it could be a viable alternative for Webform in Drupal 8.

I concur with @mandclu - I've been trying out YAML Form, and it checks off almost all the main features of Webform, yet feels even simpler in practice. There are few things that will still need improvement, but it's already satisfied need for a generic form builder in D8 on all the sites I've been working on.

YAML form looks promising. I presume that there are important architectural changes comparing to Webform, but, I was wondering if there will be a viable solution to build an automatic migration strategy from D6 or D7 old webforms? /cc @jrockowitz

I have done a custom D6 webform to a custom D8 YAML form migration for MSKCC. MSKCC is using an early version of YAML form that is a completely different architecture, so their migration code is not exactly compatible with the current version of YAML forms on D.O.

Basically, the migration consisted of building a D6 export module that converted a D6 webform's outputted render array to a YAML form compatible render array that is serialized to YAML and then migrated to D8. It is worth noting that this is not generally how the migrate module works. Converting Webform submissions to YAML form submissions was easier because the table schema for both modules is very similar.

I still need to make some final tweaks to the YAML submission data table schema to help starting addressing #2792583: Use Field API.

Feel free to create a ticket in the YAML form's issue queue.

It would be nice if someone helps build (or sponsors) the migration path.

@jrockowitz Great! My little contribution to the cause! #2803269: Build a migration path from D6 and D7 Webform to YAML Form

Thanks!

We should better port webform that is and was a long term project. No idea why a module is named yaml forms/blocks if the user only sees a Drupal interface. Stupid name for a module that nobody understands. You should rename it to something meaningful regarding the feature and not how it saves it's configuration under the hood. We all know that drupal saves it's configuration in yml files, but Drupal is not named "YML Drupal Core".

Actually the original and first feature of the module was the ability to edit an entire form as YAML.

Feel free to open a ticket about renaming the module. I am open to suggestions.

++@jrockowitz for filling the void of complex webforms in Drupal 8.

YAML Form + YAML Form UI checks all the boxes. Development is steady and updates are frequent. It's functionally superior. It's easier to use. It looks and works great.

That year of re-development Webform needed to be ported? As best I can tell, it's all @jrockowitz has been doing for the past year.

I know this will be controversial for many, but at this point (at least for me), YAML Form is the defacto replacement for Webform in Drupal 8.

The King is dead. Long live the King.

@jrockowitz - (sorry for hijacking this issue a bit), but what about Forms / forms? It seems to not be used by any active module: https://www.drupal.org/project/forms

(And it doesn't conflict with the form namespace used by FAPI.)

The Contact Storage Initiative has been discussing using the Forms namespace so I can't occupy such a global and potentially core namespace.

Here is a ticket to discuss the YAML form module's namespace.

#2805097: Should the YAML form module change its name?

Similar to what @larowlan started in #26.

I created the below ticket to help move any additional discussions over to the YAML form module's issue queue.

#2807571: [meta] Webform 4.x features currently missing from the YAML Form module

Unfortunately I cannot dedicate any serious time to the Webform D8 port. The major project we had which was driving our need for the D8 port has come to an end.

However with the great work @jrockowitz is putting into yamlform it seems Webform may well have reached the end of the road (though it may well live on in Backdrop). I think the progress of #2807571: [meta] Webform 4.x features currently missing from the YAML Form module will be key to helping it's adoption for more complex use cases in D8.

I'm tempted to mark this as Closed (won't fix).

A migration path from Webform 7.x-4.x to YAML Form would be very helpful.

I have posted a sandbox D6 Webform to D8 YAML form migration at YAML Form migrate.

Hey so a lot has happened on this thread in the last year, including some recent thoughts about maybe scrapping a Webform port and just moving to YAML Form. As someone looking for D8 stuff to contribute to, should I just forget about Webform and look at how I can help with YAML Form, then? Where's this at?

@mausolos that's correct, YAML Form will become Webform. It's still early days in the transition but it will happen.

I just tagged a usable 8.x-5.0-beta1 release of the Webform module.

How would we go about removing or updating the blue message from the Webform's project page?

For now, I am going to change the status of this ticket to 'Needs review'

Hmmm, since I updated the status of this ticket, the blue message has changed to say "This module has a pre-release version for Drupal 8. To find out more, follow this issue or download below."

I am fine with this new message and will assume that the blue message will go away once we close this ticket.

Please see #2805097: Should the YAML form module change its name? for more information about the status of porting the Webform module to Drupal 8.

Jake you've done fantastic work, the video is a really nice overview of what the module is capable of, very powerful. Great stuff mate!

With an RC, Status should RTBC.

In Webform 8.x-5.0-rc4 in ready form client can't see Markup element inputting text (Advanced HTML/Text).

@Susis Please see #2952809: Markup elements (Advanced HTML/Text, Basic HTML, Horizontal rule, and Message) not rendered

Please refrain from posting support requests here. This issue is about the port to D8. For support requests use the project issue queue itself.

Fixed due to Stable released.