Drupalwoo ☉

How To Use Drupal Entity References For Content Relationships

Drupal websites rarely consist of isolated pages. A university website connects courses with campuses, a property site links listings with suburbs, and a publisher relates articles to authors, topics, and series. Entity reference fields provide a structured way to create those connections without duplicating content or relying on manually maintained links.

This approach is useful for both developers and editors. Editors can select existing records from an autocomplete field, while developers can build filtered listings, reusable components, and relationship-aware templates. The following workflow applies to modern Drupal installations and can be adapted to content, taxonomy terms, users, media, commerce products, and custom entities.

Understanding Entity Reference Fields

An entity reference field stores a relationship between one entity and another. For example, an Article content type might contain an Author field that points to a User entity, or a Related events field that points to Event nodes. Drupal stores the target entity ID rather than copying the target’s title or body into the source item.

This distinction matters when content changes. If an editor updates an event title, every article, landing page, or listing that references the event can display the new title automatically. The relationship remains stable because it is based on the entity’s identifier.

Drupal supports several common relationship targets:

Entity reference is also different from a plain link field. A link field stores a URL and optional link text, while an entity reference understands Drupal’s entity system. That means it can use access checks, view modes, translations, revisions, and Views relationships.

For a practical overview of Drupal development and site administration, the Drupalwoo background provides useful context for this kind of implementation. The important principle is to model meaningful content relationships as data rather than hiding them inside formatted text.

Creating A Reference Field

Begin by identifying which entity should own the relationship. If articles belong to one primary author, add an entity reference field to the Article content type. If an article can mention several events, create a multi-value field such as field_related_events.

In the administration interface, go to Structure, select the relevant entity type and bundle, and open its Manage fields screen. Choose Add field, select Entity reference, and then choose the target type. The label should describe the relationship clearly, such as “Related locations”, “Course coordinator”, or “Recommended products”.

The field settings determine what editors can select. Set the allowed target bundles when Drupal offers that option. A Related content field should usually allow only Article, Basic page, or Event bundles that make sense for the editorial model. Restricting the list prevents accidental references to internal records, draft-only content types, or unrelated administrative entities.

Choose the reference method according to the expected number of records. An autocomplete widget is usually the safest option for a large content library. A select list can work for a small, stable set of choices, such as four office locations. For more specialised filtering, use an entity reference view so that Drupal presents only records matching particular criteria.

Configure cardinality carefully. A single-value field communicates a primary relationship, while unlimited values support related items or multiple categories. Add a validation rule if the field must always contain a value. For example, an event might require one venue, but an article’s related content field can remain optional.

Improving The Editorial Workflow

Good field configuration makes relationship management predictable for editors. Use descriptive help text to explain what belongs in the field, especially when several similar entity reference fields exist. “Select events directly related to this article; choose no more than four” is more useful than a generic label.

Autocomplete results should expose enough information to distinguish records with similar titles. If possible, include a date, suburb, content type, or status in the result display. This is valuable for Australian organisations with repeated names across Melbourne, Brisbane, Sydney, and regional areas. An editor selecting “Community consultation” should be able to identify the correct year and location.

Avoid creating circular relationships unless the design requires them. For instance, an Article can reference a Topic, but a Topic usually does not need a manually maintained list of Articles if that list can be generated with Views. Automatic reverse listings reduce editorial work and prevent one side of a relationship becoming outdated.

Access permissions also affect the selection process. Editors may see only entities they are allowed to view, and unpublished targets may behave differently depending on permissions and configuration. Establish a clear publishing workflow so that a published article does not unexpectedly point to a restricted or unpublished related item.

Australian privacy requirements deserve attention when user entities are referenced. A public author profile should expose only approved fields, and personal information should not be rendered merely because a user was selected in an entity reference field. Review the site’s handling of personal information against the Privacy Act 1988 and the Australian Privacy Principles, particularly when a relationship points to staff, customers, or community participants.

Rendering Referenced Content

The simplest display method is the field formatter. On the content type’s Manage display screen, configure the entity reference field and select an appropriate view mode for the target entity. A compact view mode might show a title and summary, while a card view mode could include an image, date, category, and link.

View modes keep presentation consistent. If the same Event entity appears in an article, a homepage promotion, and a search result, each context can use a different formatter without changing the stored relationship. Avoid placing raw entity IDs or hard-coded links in Twig templates when a field formatter can handle the output.

For custom markup, Twig can render the referenced entities through the field’s render array. A basic field output might look like this:

{% if content.field_related_events %}
  <section class="related-events">
    <h2>Related events</h2>
    {{ content.field_related_events }}
  </section>
{% endif %}

This approach preserves Drupal’s cacheability metadata and access handling. If you need a custom list, preprocess the field or create a dedicated view mode rather than loading entities directly inside a template. Direct entity loading in Twig can produce slow pages and makes caching harder to reason about.

When a reference points to a media entity, check the media view mode and image style. When it points to a taxonomy term, decide whether the output should be a linked term name, a description, or a visual label. For user references, use a carefully limited view mode that excludes private account fields.

Multilingual sites should enable translation for the reference field when the relationship itself can vary by language. The target entity must also have suitable translations. A reference to a bilingual page does not automatically guarantee that the correct language version will be rendered; language negotiation, entity translation, and fallback settings all influence the result.

Building Dynamic Listings With Views

Entity references become especially powerful when combined with Views. Instead of manually selecting every article related to a venue, create a view that filters content by the current venue or by a selected relationship. This produces reverse relationships: the venue page can automatically list all events that reference it.

In Views, add a relationship based on the reference field, commonly exposed as something similar to “Content referenced from field_related_events”. The exact label depends on the entity type and field name. Add filters for publication status, content type, date, language, or taxonomy. Always filter by published status for public displays unless the site has a deliberate preview requirement.

For a page showing related content, an entity reference view can also control the options available in an autocomplete widget. This is useful when editors should select only current events, products in a particular category, or locations belonging to a specific state. A view can expose title, ID, and other values required by the reference selection plugin.

Contextual filters allow the listing to respond to the current entity. A venue route can pass the venue ID into a view, which then returns events whose reference field contains that ID. This is more maintainable than creating a separate field on the venue that editors must update every time an event is added.

Check performance before adding several relationship-heavy views to one page. Add sensible filters, use pagination where appropriate, and avoid loading hundreds of full rendered entities. Cache the view output and use compact view modes. For a large Australian property, government, or retail site, these decisions become important as the content catalogue grows across multiple offices and regions.

Choosing The Right Relationship Pattern

Entity references are a strong default, but they are not suitable for every connection. A simple external URL belongs in a link field. A fixed label such as “Monday to Friday” belongs in a text or fielded value. A relationship that needs filtering, permissions, translation, or reusable rendering is usually better represented by an entity reference.

The direction of the relationship should reflect editorial ownership. If an Event belongs to one Venue, store the venue reference on Event. If a Venue page needs to show its events, generate that reverse view rather than maintaining a second manual field. Two-way manual references can drift apart when editors update one side and forget the other.

Reference revisions deserve special care. In moderated sites, a content item may reference a draft revision of another entity. Confirm how the chosen field, formatter, and contributed modules handle revisions. This is particularly important for legal notices, health information, public transport updates, and other content where the published page must display an approved version.

The following patterns help select an appropriate implementation:

Relationship Pattern Suitable Drupal Approach Main Benefit Key Consideration
One article has one author Single-value entity reference to User Clear ownership and reusable profiles Limit public user fields
An event has one venue Entity reference to a Venue content type Centralised venue details Define publishing and access rules
An article has several topics Multi-value reference to Taxonomy terms Consistent classification Avoid uncontrolled term creation
A venue displays all related events Views relationship and contextual filter No duplicate editorial maintenance Configure caching and status filters
Editors choose current products Entity reference view Filtered, relevant selection list Keep view results performant
A page contains flexible promotional blocks Paragraphs with entity reference fields Reusable structured components Manage nesting and editorial complexity
A record links to an external website Link field Stores URL and link text directly Does not provide entity-aware behaviour

Test the complete workflow with realistic roles before publishing the feature. Create, revise, translate, unpublish, and delete referenced entities while logged in as an administrator, editor, and anonymous visitor. Confirm that broken references are prevented or handled gracefully, that access restrictions are respected, and that cache clears or invalidates when related content changes.

A well-designed Drupal content relationship remains understandable months after it is created. Editors know what to select, developers can query the connection through Views or APIs, and visitors receive current information without duplicated maintenance. Entity reference fields provide the underlying structure; careful field settings, view modes, permissions, and relationship-aware listings turn that structure into a dependable publishing system.