Add other field types

Hello andrimont,

Yes, i plan to add other field types. For now, i have limited the possible content type fields (possible types: 'boolean', 'email', 'decimal', 'float', 'integer', 'text', 'text_long', 'text_with_summary', 'string', 'string_long') because i need to test and assure the compatibility between the most complex webform and node field values.
But for sure i plan to add the most complex field types as soon as possible.
Moreover, i only added the 'custom' fields in configurations (with prefix 'field_') and because of this the body is not appearing yet, but i plan to add it to the Webform Content Creator configurations also.

Thank you very much for testing!

Best regards.

I tested datetime and entity_reference. Seems to work.

It would be nice if daterange would be possible. You might have to code a custom mapping, so that you can map 2 datetime fields from the Webform to the daterange field (beginning and end).

Hello andrimont and Corn696,

I removed the limitation in content type fields and i added "body" to Webform Content Creator configurations.
Besides that, i have tested dates and images and it worked well.
In the specific case of dateranges and other complex types, i will look for the best solutions to have the most compatible mappings between webform submission values and node fields.

Thank you very much.
João Marques

Do link field types work already, or is it in progress?

Hi, with this quick fix patch link fields start to work. Webform link field value comes ['url'] and entity link field needs to be ['uri'].

And another quick fix to date field dateformat.

I had a need for some more complex field types to be supported, so I took a stab at coming at coming up with a more generalized solution to this problem. I think the most scalable way to approach this is to introduce a plugin system for field types, so that additional fields can be easily added and any special logic to handle those fields can be done at the plugin level instead of being tacked onto the main mapNodeField function. I think we also need a way to handle field types that don't have a specific webform element equivalent. This patch attempts to solve these issues the following way:

1. Introduce an Annotated plugin for field mappings.
2. Allow the plugin to control what entity fields it's applicable for, what webform elements it supports, and whether it supports the custom value functionality.
3. Move any field type specific logic (Timestamp conversion, max length check, etc) to its applicable plugin.
4. Allow for the plugin to define 'component fields'. With this approach, a plugin can map many different to form fields to one entity field, to allow complex field types to be broken up among more basic form elements.

For the component fields, one example of a use case is the Social Media Links field. It doesn't have a webform element and the actual allowed fields depend on what social networks are enabled. With this plugin approach you can add basic text fields to the webform and then map each one to a different social network:

I think I added plugins for all the basic fields already supported, but if I missed a field type that worked I'm happy to add it. I didn't apply the two patches already in this thread; it looked like the datetime patch had already been added via another thread and the link field patch in my testing didn't appear to be needed. I have a webform URL field mapped to a Link field and it was working without any patches.

Some updates to allow this patch to support the nested form values, as well as some bug fixes.

Hello João,

Hope I'm posting this in the right place, rather than opening a new issue. Since it concerns other field types.

Is there a way to support Dynamic entity references (taxonomy term selection)?

The browser gets a "website encountered an unexpected error" whenever I enable any Dynamic entity reference.

Error log: Uncaught PHP Exception Drupal\\Core\\Entity\\EntityStorageException: "Value is not a valid entity." at /var/www/ispa/drupal/web/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php line 846, referer: https://skills.ispa.org.za/form/skills-registry

Thank you for your time and effort.

Hi @wildcoast,
This is as good a spot as any I think :) I think the approach we're taking here could support Dynamic Entity Reference fields. When I get a free moment I'll see about adding that as a plugin to this patch.

Thanks for all the work with this module. It is a really helpful feature to add to webform.

I can't get the patch in #8 or #9 to apply.

The test for #9 fails too - not sure what has changed since patch was created and I tried to apply.

I've not done much with patches in the past - so it may be a user error and not a patch error. I have left status as "Needs Review".

Hi @thomasfowles, some updates were made to the module that were preventing the patch from applying. I've rerolled it for the latest dev release, so this one should work for you.

Hello,

Thank you very much for your contribution jacobbell84!

I think that your idea to introduce a plugin system for field types is excellent , as it will improve scalability and it will be easier to add support for complex field types, which require additional code to work. I plan to use this in a new release of this module (2.0.0).

Best regards!

Hello jacobbell84,

I released a new version (3.x) with the plugin system, using some things of your patch and another things from here: https://www.drupal.org/project/webform_content_creator/issues/3163207.

By now we have just a simple version of the plugin system in order to allow any person to map any field type, but in the future we would like to have the component fields concept that you have in your patch also.

Thanks for your contribution on this plugin system.

Best regards.

I also am interested in seeing this extended - for example, our site requires body with summary also required. There is no way to do that with the unpatched module. I can match a textarea to the description, but there are no options to populate the summary.

Likewise on images that require alternate text (very common for accessibility requirements), no way to map alternate text.

Hello all,

Considering the new plugin system, it can be extended to create the plugins for any type of complex field. Please feel free to provide new generic plugin for the common used fields, creating new issues with the patches for each field.

Best regards.

Sorry, I got it :)