ICT:D Linking Assets to Person
Drupal: Linking Assets to Persons (MM Relationship Without Custom Code)
Purpose
This page documents the step‑by‑step implementation of a **many‑to‑many–style relationship between Person and Asset entities** in Drupal 11.x.
The objective is to allow editors to:
- link existing Assets to a Person,
- manage these links in a table‑based UI,
- search and select Assets via a modal browser,
- avoid custom modules and custom database tables.
This solution uses **standard Drupal mechanisms** and is upgrade‑safe.
---
Design Principles
- Prefer configuration over code
- Avoid custom schema and join tables
- Use Drupal’s entity reference system
- Use contrib modules for UX, not data modeling
- Ensure maintainability and handover safety
---
Conceptual Model
| Entity | Role |
|---|---|
| Person | Main entity (e.g. historical person) |
| Asset | Reusable referenced entity (documents, images, objects, etc.) |
Relationship:
- One Person → many Assets
- One Asset → many Persons (implicit)
Drupal handles this naturally via **entity references**.
---
Required Modules
Ensure the following modules are enabled:
- Core:
- Field
- Views
- Contrib:
- Inline Entity Form (IEF)
- Entity Browser
No custom module is required.
---
Step 1: Create the Entity Reference Field
On the **Person** entity:
1. Go to:
Structure → Content types → Person → Manage fields
2. Add a new field:
* Field type: Entity reference * Label:Assets* Machine name:field_assets
3. Reference settings:
* Target type: Asset
* Allowed bundles: select relevant Asset bundles
* Cardinality: Unlimited
Save the field.
---
Step 2: Configure the Form Widget (Critical Step)
1. Go to:
Manage form display
2. For field_assets, select widget:
* Inline Entity Form – Complex
3. Open the widget settings (gear icon):
* ✅ Allow users to add existing entities * ❌ Allow users to add new entities * Entity Browser: select the Asset browser (configured in Step 3)
4. Save the form display.
Important: Do NOT select “Entity Browser” as the field widget itself. That widget does not provide a table‑based UI.
---
Step 3: Create the Entity Browser for Assets
1. Go to:
Configuration → Content authoring → Entity Browser
2. Create a new browser:
* Name: asset_browser
* Display: Modal
* Selection mode: Multi‑select
3. Add a widget:
* Widget type: View
4. Create or select a View:
* Base table: Asset
* Display type: Entity Browser
* Pagination: 10–25 items per page
* Exposed filters:
- Title
- Type / taxonomy (as needed)
* Fields:
- Thumbnail (image style)
- Title
- Optional metadata
5. Save the Entity Browser.
---
Step 4: Resulting Editor UX
On the Person edit form:
- Assets are displayed in a table
- Editors can:
- Add existing Assets - Remove Assets - Reorder Assets
- Clicking “Add existing Asset” opens a modal browser
- Assets are searched and selected visually
This provides a historian‑friendly workflow.
---
Step 5: UX Cleanup – Hide the Misleading “Add node” Button
Inline Entity Form displays an intermediate chooser containing an “Add node” button, which is misleading when creation is disabled.
This is hidden via Gin admin CSS.
CSS Location
sites/default/files/gin-custom.css
CSS Rule
/* Hide misleading "Add node" button in Inline Entity Form chooser */
input.ief-entity-submit[data-drupal-selector*="ief-reference-save"][value="Add node"] {
display: none !important;
}
This solution:
- requires no JavaScript
- survives AJAX rendering
- is upgrade‑safe
- does not depend on dialog wrappers
---
Why No Join Table Was Used
An experimental approach using a “real” join table was evaluated and rejected because:
- it required a custom module
- it required schema lifecycle management
- UI construction required many hooks
- upgrades would require maintenance work
Drupal’s entity reference system already models the relationship correctly.
---
Performance Notes
- 1000+ Assets are handled without issue
- Only referenced Assets are rendered on the Person form
- Entity Browser uses pagination and indexed Views
- Thumbnails should always use image styles
---
Summary
This implementation achieves:
- ✅ Many‑to‑many relationship semantics
- ✅ Clean table‑based UI
- ✅ Visual asset selection
- ✅ No custom code
- ✅ No custom schema
- ✅ Upgrade‑safe architecture
This is the recommended approach for modern Drupal (11.x).
---
Key Lesson
If a solution requires:
- custom join tables
- extensive hook usage
- complex UI overrides
…it is often a sign that Drupal already offers a better abstraction.