This is caused by this core bug: #2906113: Select element's #emtpy_value logic doesn't work for configured plugin forms.

The problem in an IEF is that if there's only a single item in the plugin selection field, the configuration subform won't appear because you can't change the value of the select element.

Workaround patch coming.

CommentFileSizeAuthor
#11 Screen Shot 2018-02-13 at 13.29.58.png56.52 KBjoachim
#6 2910611-6.commerce.plugin-reference-fields-dont-get-a-select-option-when-they-are-required-field-with-single-item-wont-work-within-an-IEF.patch725 bytesjoachim
#2 2910611-2.commerce.plugin-reference-fields-dont-get-a-select-option-when-they-are-required-field-with-single-item-wont-work-within-an-IEF.patch704 bytesjoachim
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

joachim created an issue. See original summary.

joachim’s picture

joachim CreditAttribution: joachim at Torchbox commented
Status: Active » Needs review
FileSize
2910611-2.commerce.plugin-reference-fields-dont-get-a-select-option-when-they-are-required-field-with-single-item-wont-work-within-an-IEF.patch704 bytes
joachim’s picture

joachim CreditAttribution: joachim at Torchbox commented
Priority: Normal » Major

Upping this. It's in fact arguably critical, as there is no workaround that is obvious to the average user.

(For someone who knows how FormAPI works - try to submit the form and then the failed validation will have the plugin configuration form elements for the selected plugin type.)

mglaman’s picture

mglaman
Primary language English
Location WI, USA
CreditAttribution: mglaman at Centarro commented

joachim is there _any way possible_ to easily reproduce this in tests? Does it only occur within IEF?

We do have \Drupal\Tests\commerce\FunctionalJavascript\PluginSelectTest which tests the widget. However it tests against commerce_condition.

Since this widget is provided by the Commerce module we need to replicate this bug in a test, I believe. Especially since our contrib ecosystem depends on it (shipping, etc.)

joachim’s picture

joachim CreditAttribution: joachim as a volunteer commented

> is there _any way possible_ to easily reproduce this in tests? Does it only occur within IEF?

You could simply create a form that shows a plugin form element that has one value, and check that it shows a ' -- select one -- ' option as the first option. Having that fixes the problem in any context.

Alternatively, AFAIK IEF can be run without JS, and if the plugin field item also works without JS, you can create an IEF where the inner entity has a plugin item field, and initially, the ' -- select one -- ' option should show, and making a choice and submitting the plugin field item with a value should then show you the plugin configuration form.

joachim’s picture

joachim CreditAttribution: joachim at Torchbox commented
FileSize
2910611-6.commerce.plugin-reference-fields-dont-get-a-select-option-when-they-are-required-field-with-single-item-wont-work-within-an-IEF.patch725 bytes

Reroll.

bojanz’s picture

bojanz CreditAttribution: bojanz at Centarro commented

I assume that this bug can be reproduced with License.
Tried to install License to confirm, but the latest beta blew up my test site (#2943829: Error: Call to a member function addConstraint() on null in commerce_license_entity_bundle_field_info_alter() ).

At a glance, I don't understand why the lack of an empty option prevents the configuration form from being shown.
We pass the same $target_plugin_id to both target_plugin_id and target_plugin_configuration in PluginSelectWidget.
So I'd expect the configuration form to work even with a single available plugin option. If it doesn't, then there's a deeper issue at play, and one that we're missing tests for.

bojanz’s picture

bojanz CreditAttribution: bojanz at Centarro commented
Status: Needs review » Postponed (maintainer needs more info)
joachim’s picture

joachim CreditAttribution: joachim at Torchbox commented
Status: Postponed (maintainer needs more info) » Active

> At a glance, I don't understand why the lack of an empty option prevents the configuration form from being shown.

IIRC, it's because when you open the form, the browser automatically selects the first option in the plugin ID dropdown. But the form hasn't *reacted* to that being selected, so the AJAX does not fire, and the configuration subform for that plugin ID is not loaded.

So if the available IDs are Alpha and Beta, and you want to pick Alpha, you have to do this:

1. select Beta
2. wait for AJAX to show you the beta form
3. select Alpha
4. wait for AJAX to show you alpha form
5. now you can configure it.

If there is only one plugin ID listed, then you're screwed, as you can't change the widget to make it notice you've changed it.

bojanz’s picture

bojanz CreditAttribution: bojanz at Centarro commented

But it's not the browser that's supposed to be selecting anything. We explicitly select the first available plugin via '#default_value' => $target_plugin_id. So the case you're explaining should not be possible with the current code, indicating a deeper problem.

joachim’s picture

joachim CreditAttribution: joachim at Torchbox commented
FileSize
Screen Shot 2018-02-13 at 13.29.58.png56.52 KB

Here's a screenshot showing the problem.

This is the 'add product' form for a product whose PV is set to limit to the role license (or the same effect -- don't enable any other license type modules).

The role license provides a configuration form which shows radios with the site's roles, but it's not showing here.

If there were other license types available in the select element, I would have to select another one, then go back to 'role' to get the role config form elements to AJAX in.

With only one option in the select, I am stuck at this point - there is no way to get it to show.

> But it's not the browser that's supposed to be selecting anything. We explicitly select the first available plugin via '#default_value' => $target_plugin_id.

It's good UX to have a neutral option initially selected -- there is even a comment somewhere in FormAPI code that says so, though sadly FormAPI doesn't provide that by default :/