Allow using other entity widgets and also contrib widgets on entity_reference (Tagify, Entity Browser, ...)

This has been implemented in the 1.0.x branch.

What was done

• Added a Widget settings section to the admin form at
  Configuration > Content authoring > Canvas Entity
  Reference.
• Site builders can now choose the default single-value widget:
  Autocomplete (entity_reference_autocomplete) or
  Autocomplete (tags)
  (entity_reference_autocomplete_tags).
• Multi-value props (type: array in the component schema)
  always use the tags autocomplete regardless of this setting — only
  single-value props are affected.
• The selected widget is stored in
  canvas_entity_reference.settings under the widget
  key and defaults to entity_reference_autocomplete.
• Added widget: type: string to the config schema and a
  default value to
  config/install/canvas_entity_reference.settings.yml.

The taxonomy-specific settings (target vocabularies, auto-create) have been
moved into a separate collapsible fieldset on the same form to keep the UI
clean as more entity types are supported.

@anybody - I have added new release with all the changes 1.0.1

(Note: All changes live in dev release).

Added x-entity-widget annotation support. Component authors can now overridethe widget per-prop directly in the component YAML:

# Single-value prop — override the global widget setting
term_ref:
type: ['string', 'null']
x-entity-type: taxonomy_term
x-entity-widget: entity_reference_autocomplete

# Array prop — explicitly declare the widget
terms:
type: array
x-entity-widget: entity_reference_autocomplete_tags
items:
type: ['string', 'null']
x-entity-type: taxonomy_term

When omitted, the prop falls back to the global widget setting (single-value) or tags autocomplete (array). One important constraint: the tags widget (entity_reference_autocomplete_tags) requires an array-type prop — using it on a single string prop will only retain one value since the transform produces an array.

Support for contrib widgets like Tagify or Entity Browser is possible as long as the contrib module registers Canvas transform metadata for its widget plugin. That is outside the scope of this module.

Regarding version management — noted. Going forward, breaking changes will go through alpha/beta/rc before a stable tag.

PS: For contrib module integration I think giving a clear example in the README would make sense? - correct
But this module already includes 7 demo components adding extra lines in Readme doesn't make sense to me but I am open for suggestions.

Thank you for helping in making the module better thanks a ton!

Thanks for the feedback.

On the naming — x-entity-widget is intentional and consistent with the existing annotation pattern (x-entity-type, x-entity-field, x-entity-type-bundles). In Drupal, "widget" already unambiguously refers to a form input widget, so adding "form" would be redundant. I'd like to keep x-entity-widget unless there is a specific reason the shorter name would cause confusion.

On logging — the module already logs a warning for unrecognised $ref URIs. Widget validation is harder to do at shape-matching time because the field widget plugin system is only fully initialised during form build. If an incompatible or missing widget ID is passed, Drupal's own field widget manager will throw or fall back and log at that point. I can add a note to the README making this explicit so site builders know what to look for.

On the README contrib integration example — good suggestion. I will add a short section covering what a contrib module needs to do (register Canvas transform metadata via hook_field_widget_info_alter) with Tagify as an illustrative example.

Does that sound right, or do you want to reconsider the name before I update the README and commit?

Haha! (my module) its not like that, its our module you have as much rights as I do on the decisions
PR - https://git.drupalcode.org/project/canvas_entity_reference/-/merge_reque...