Support all entity types

Thanks for pointing this out — that’s a fair observation.

Currently, the module supports taxonomy term entity references only, as that was the initial use case for integrating with the Canvas component props system.

However, the module is designed with extensibility in mind, and support for additional entity types (e.g., nodes, media, custom entities) is definitely planned for future iterations.

The current naming reflects the broader goal,

Thanks, really appreciate the feedback 🙂

Yes — I completely agree. The goal is not to add support for entity types one by one, but to move toward a more generic approach based on Drupal’s entity API.

The current taxonomy term support is just the first step, but the plan is to leverage the abstraction around EntityInterface / EntityTypeManager so this can work across different entity types in a consistent way — similar in spirit to what entity_reference and dynamic_entity_reference provide.

I’m currently exploring how best to generalize the data transformation layer for Canvas props without introducing too much complexity.

Thanks again for the suggestion — it definitely aligns with the direction I want to take this module.

Yes, thanks for pointing this out.

This module explores similar ideas around passing entity references into component-based rendering (via Canvas/SDC), especially for composing structured outputs from multiple sources.

While it doesn’t implement that proposal directly, there’s clear overlap in goals and approach. Linking it as related work on the module page makes sense and could help provide useful context for where this pattern is heading.

Happy to add a reference there.

@zeeshan_khan Do you have a rough timeline in mind? Sorry, I don't mean to rush you, but this is just such an important feature for Canvas that we really miss 😩

@thomas.frobieter - I'm thinking to work on it this weekend if that works?
I'll try to wrap it up asap you'll get the updated release by next week.

@zeeshan_khan Thats awesome! Thank you :)

This has been implemented in the 1.0.x branch.

What was done

• Added a new x-entity-type JSON Schema annotation. Component
  authors can now declare any entity type instead of being locked to taxonomy
  terms.
• Added four built-in $ref definitions to
  schema.json: taxonomy-term-reference,
  node-reference, user-reference, and
  media-reference. These can be used directly via $ref
  or matched automatically from x-entity-type.
• Updated EntityReferenceShapeMatcher to recognise all entity
  types via both the legacy $ref URI and the new
  x-entity-type annotation, including array props (

  type:
    array

  with items.x-entity-type).

• The correct entity handler (default:{entity_type}) and prop
  expression are now built dynamically for each entity type.
• Removed the hardcoded drupal:taxonomy module dependency —
  the module now works with any installed entity type.

Usage examples

Single node reference (returns the node title):

                                                     
  my_article:                                                                   
    type: string                                            
    x-entity-type: node
  

Single user reference using the built-in $ref:

                                                     
  author:                                                                       
    $ref:                                                   
  'json-schema-definitions://canvas_entity_reference.module/user-reference'
  

Multi-value media reference:

                                                                         
  gallery:                                                  
    type: array
    items:
      type: string
      x-entity-type: media
  

Bundle restrictions and auto-create remain supported for
taxonomy_term. All other entity types use the default handler
with no bundle restrictions.

Additionally, a

entity_render(entity_type, entity_id,                
  view_mode)

Twig function is provided so component templates can render
the full entity output (e.g. a media image) when needed.

Also added 5 new Test SDCs for each

1. Test: Media Reference
2. Test: Multi-value & Taxonomy Term (x-entity-type)
4. Test: Node Reference (numeric ID)
5. Test: Node Reference (title)
6. Test: User Reference

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

Thanks for quick response and feedbacks
I'll double check on your latest comment questions!

(Note: all the changes currently lives in dev release)

Completed a security review of the implementation. Three issues were found and fixed:

1. entity_render() — missing access check The Twig function was loading and rendering entities without checking if the current user has permission to view them. This could expose unpublished nodes or private media. Fixed by adding an access('view') check before rendering.
2. Auto-create endpoint — GET used for state mutation The /api/canvas-entity-reference/create-term endpoint was a GET request that created taxonomy terms. GET requests are not CSRF-protected in Drupal, making it possible for a third-party page to silently trigger term creation via an img tag or similar. Fixed by changing the route to POST with _csrf_token: 'TRUE' enforcement and updating the JavaScript to send X-CSRF-Token headers using a cached token from /session/token.
3. Missing input validation and insufficient access control Term name was not validated for length (now capped at 255 characters). The endpoint now also checks that the user holds administer taxonomy or edit terms in {vocabulary} before allowing term creation — access content alone is no longer sufficient.

   No other security concerns were found in the current implementation. The schema annotations (x-entity-type, x-entity-field, etc.) are defined in component YAML files which require file system access to modify, so those are not an attack surface.

MR https://git.drupalcode.org/project/canvas_entity_reference/-/merge_reque...

#19
Yes, the autocomplete suggestions are already access-controlled by Drupal core. This module sets handler: "default:{entity_type}" for all entity types, which uses Drupal's built-in DefaultSelection handler. That handler runs entity queries with access checks enabled, so users will only see entities they are allowed to view in the autocomplete results — unpublished nodes, restricted media, or private terms will not appear for users without the appropriate permissions.

#20
Good point — going forward all commits will reference the relevant issue number in the format Issue #XXXXXXX by zeeshan_khan: description for proper contribution record tracking. The existing commits on this branch predate that, but new work will follow the convention. An MR is already open for this branch at !4.