The select2widget has it's own autocomplete path. There is a patch to select2widget to support og_vocab: #2503787: Add support for OG Vocab. This requires passing the $vid in the autocomplete URL so og_vocab can fetch the $og_vocab object and collect the custom widget settings.

Currently og_vocab has specific autocomplete support for entityreference_autocomplete and entityreference_autocomplete_tags. We just need another simple case for the select2widgetajax widget.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

mpotter’s picture

mpotter’s picture

Status: Active » Needs review
amitaibu’s picture

I'd prefer not to add integration with other modules -- but allow other modules to alter this. Can't this be done via hook_form_alter()?

mpotter’s picture

Good question. A hook mechanism would be useful here. But seems like if we use a hook for select2widgetajax then we should use that same hook for the existing code in og_vocab that handles entityreference_autocomplete and entityreference_autocomplete_tags. Those cases are a lot more complex than what select2widget needs so I'd probably defer to you on how such a hook would be implemented.

Then og_vocab could implement this new hook itself to provide the existing entityreference functionality if you don't want to push this to the entityreference module.

But my point is that you are already hardcoding integration with another module (entityreference).

mpotter’s picture

Also, as you can see from the related patch mentioned in the OP, this is a complex case where both the behavior (og vocab) and the widget (select2widget) both implement their own autocomplete logic. Which should win? To make it work, both sides currently need to be patched. The patch to select2widget is needed because of how og_vocab implements the fake field and instance. The patch to og_vocab is needed because of how select2widget needs to be passed the $vid.

Maybe somebody knows of a cleaner way to handle this that wouldn't require both modules to have special cases like this. We would need to decide who is responsible for implementing the autocomplete path (the widget or the behavior). Not sure entityreference even has the hooks that would be needed to handle this cleanly.