Problem/Motivation

Building #options using YAML is not intuitive for most users and the current interface requires YAML for option groups.

Proposed resolution

Extend the completed UI for editing options to allow for option groups.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

scott_euser created an issue. See original summary.

scott_euser’s picture

I have taken a first stab and this and it seems to work well for existing YAML with optgroups. There is currently no way to 'upgrade' the options to allow for optgroups. Was thinking a button or link like 'Enable option groups' perhaps?

Also there is a bug in the way the value callback is, so when you add options or optgroups more than once it doesn't remember what type the previously added rows are until saving.

Thought it anyway best to let you have a look at my progress on this and let me know if it's completely off the mark, etc.

Thanks!
Scott

jrockowitz’s picture

@scott_euser You are moving in the right direction but this is going to be a very challenging task. Just setting up the options element was exhausting for me. I am procrastinating on building the #states UI

Some immediate thoughts...

  • An #optgroups boolean property should be added to yamlform_options elements that should support optgroups.
  • I think the "Add [X] more options" should stay AS-IS with an "Add Option Group" button next to it. Users should only add one optgroup at a time.
  • I am not sure why weight, depth, and optgroup need to be grouped into a settings array. Even if an element is nested you can use the #parents property to manipulate the FormState's getValues() hierarchy.
  • Use the test form (/form/test-element-options) to get this working. Currently, there is an error, "Recoverable fatal error: Argument 1 passed to Drupal\yamlform\Element\YamlFormOptions::hasOptGroup() must be of the type array, null given"
  • I think preserving the 'state' and having the element remember which row is an optgroup is going to be difficult. I am not sure how you would do it.
  • Make sure to get the element working without any AJAX before enabling the AJAX callback.
scott_euser’s picture

@jrockowitz Thanks, yeah it's not a simple thing, agreed!

Thanks for all your points, all make sense and I'll keep progressing on it. Yeah I've been using the test-element-options but I deleted the non-optgroup ones for easier debugging which is why I missed the fatal errors, I'll be sure to add those back in to make sure it doesn't break those.

jrockowitz’s picture

Title: Create UI for editing options with optgroups » Add OptGroup support to options element
jrockowitz’s picture

Based on the work I did for the #state conditional logic element, there is probably any opportunity to rework and significantly improve this element.

fenstrat’s picture

Project: YAML Form » Webform
Version: 8.x-1.x-dev » 8.x-5.x-dev
jrockowitz’s picture

Status: Active » Closed (won't fix)

I am closing this ticket for now. If someone wants to supply an update patch, please reopen this ticket.

code-brighton’s picture

If anyone gets here and is stumped at how to edit the yaml to add option groups manually. It's like this:

  '#options':
    'Group One':
      option1: 'Option One'
      option2: 'Option Two'
    'Group Two':
      option3: 'Option Three'
      option4: 'Option Four'

etc...

Would be cool to have it working in the interface though...if I get some time I'll have a look at your patch guys...thanks for the great work on this module!

jrockowitz’s picture

@code-brighton The patch is now outdated.

OptGroup support is going to very difficult to add the UI. We would have to build a completely custom widget/element to manage it.

code-brighton’s picture

@jrockowitz thanks for getting back so quickly! When I made the change in the source I returned to edit the individual select field and was pleasantly surprised to see the edit area was now forced to be the source input. My main concern was an edit wiping my option groups. This isn't a problem so thanks :)

code-brighton’s picture

@jrockowitz All working well...However sadly this doesn't play with translations. All the rest of my form translates, but with the OptGroup select list for some reason the translation always reverts to English (or whatever the master language is) when I save.
Any ideas why this might be the case?

jrockowitz’s picture

@code-brighton Please create a new issue and document if OptGroups are not being translated via the global options (/admin/structure/webform/config/options/manage) or webform specific options.