This module is great, thanks for doing this. I've run into the following problem, though:

An autocomplete (tagging) term reference editable field gets displayed with the default widget (autocomplete/tagging) even when select list or check boxes/radio buttons is configured.

The sample HTML below shows the table cell for an editable tagging field (relevant bits in uppercase text). The parent Views div class contains field-widget-options-select as expected, but the input tag has classes form-text form-autocomplete and is of type text:

<td class="views-field views-field-field-model-tags-editable">
    <div class="views-row-edit-static">
        <a href="/model-tags/123" class="views-ajax-processed-processed">123</a>, <a href="/model-tags/moose" class="views-ajax-processed-processed">moose</a>, <a href="/model-tags/deer" class="views-ajax-processed-processed">deer</a>
    </div>

    <div class="views-row-edit-edit">
        <DIV class="field-type-taxonomy-term-reference field-name-field-model-tags FIELD-WIDGET-OPTIONS-SELECT FORM-WRAPPER" id="edit-node-1-field-model-tags">
            <div class="form-item form-type-textfield form-item-node-1-field-model-tags-und form-group" role="application">
                <INPUT class="form-control FORM-TEXT FORM-AUTOCOMPLETE viewsImplicitFormSubmission-processed" type="TEXT" id="edit-node-1-field-model-tags-und" name="node[1][field_model_tags][und]" value="123, moose, deer" size="60" maxlength="1024" autocomplete="OFF" aria-autocomplete="list"><input type="hidden" id="edit-node-1-field-model-tags-und-autocomplete" value="https://firesheet.local/taxonomy/autocomplete/field_model_tags" disabled="disabled" class="autocomplete autocomplete-processed"> <span class="element-invisible" aria-live="assertive" id="edit-node-1-field-model-tags-und-autocomplete-aria-live"></span>
            </div>
        </div>
    </div>
</td>

Looking at handlers/editableviews_handler_field_field_edit.inc , I see this @ line 122:

    // Only doctor the widget type if the option is set; otherwise the widget
    // type set for the entity's bundle will be used.
    if (!empty($this->options['widget_type'])) {
      $field_instance['widget']['type'] = $this->options['widget_type'];
    }

When I dsm() the value of $this->options['widget_type') in my field, it holds options_select as expected. Had a look at editableviews_plugin_style_row_edit_table.inc but I'm not familiar enough with views handlers and plugins to interpret it very well. Let me know if I can provide more information.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

joachim’s picture

Title: Autocomplete (tagging) field widget ignored » Setting a different widget doesn't work if it's from a different module
Version: 7.x-1.0-beta9 » 7.x-1.x-dev
Status: Active » Needs review
FileSize
1.03 KB

Thanks for reporting this.

The problem is that Field module uses the 'module' property of the widget settings first, and the widget type second:

    $function = $instance['widget']['module'] . '_field_widget_form';

So it turns out that this will happen anytime that the widget set in the views handler settings and the widget set in the field settings are supplied by different modules.

To fix this, we'd need the code that doctors the widget type to also look up to find out which module supplies the required widget and set that in the field instance widget array too.

Can you try this patch please?

thekenshow’s picture

Thanks! Applied and tested the patch - the tagging field now renders and functions as multiple select.

I noticed that this editable field (image attached) lists just the tags that have been applied to this node (as links above the select list) but the select list contains every tag in the vocabulary, with the applied ones selected. Is this the expected behaviour? If so, I'll need to work out how to filter the select to display only those tags that are applied.

joachim’s picture

Yes, that's normal behaviour. Try changing the widget at the field level and look at the entity form.

zmove’s picture

Status: Needs review » Reviewed & tested by the community

I can confirm the original issue and that the provided patch resolve it.

joachim’s picture

Status: Reviewed & tested by the community » Fixed

Thanks for testing! Committed.

  • joachim committed 28f7e24 on 7.x-1.x
    Issue #2356573 by joachim: Fixed widgets from a different module to the...

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.