Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[5.x]: Link fields can't be eager-loaded, and each linked element costs a query

Abierto
  • ¿Algo no está bien?
#20,150 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
php
Área
backend, database

Línea de trabajo

Read BaseElementLinkType::element(), Link, and LinkData to trace how linked elements are fetched and how eager loading changes the field value. The issue describes regression tests and proposed changes for both 5.12 and 6.x; review those tests and the eager-loading map handling. Done means links load in batches with and without with(), preserve LinkData, and the 6.x worker case does not reuse elements from earlier jobs.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

bug repo:cms
What happened?
Description

Link fields fetch each linked element with its own query, and they can't be eager-loaded. Adding a Link field to with() makes things worse: the field's value becomes an empty ElementCollection instead of a LinkData object.

The cause is that BaseElementLinkType::element() runs $query->one() once per distinct link value. Results are memoised, but never batched. Link doesn't implement EagerLoadingFieldInterface, so there is no way to batch them.

On a content site, every entry or asset link in a Matrix or Content Block field (buttons, teasers, steps) adds one element query per page. On the Craft 6 site where we found this, that was one extra query per distinct link. A page with 20 entry links runs 20 single-row element queries, which nothing can batch.

The Craft 5 docs say that "it is not currently possible to eager-load link field relationships, as their element type is not known until the field data is loaded" (link.md). Since Craft 5, though, the field data is loaded with the source elements. An EagerLoadingFieldInterface map can also return one set per element type, so the element type is known when the map is built.

Craft 6 has the same per-link query. It also gained LinkElementLoader / BaseElementLinkType::preloadElements() for Table link cells in #19998, but Link fields don't use them.

Steps to reproduce
  1. Add a Link field linkField that allows entry links to an entry type.
  2. Create three entries that each link to a different entry.
  3. Run Entry::find()->id($ids)->all() and read $entry->linkField->getElement() (or getUrl() / getLabel()) on each of them. That runs one element query per entry.
  4. Run Entry::find()->id($ids)->with(['linkField'])->all() and read $entry->linkField. It is an empty ElementCollection, not a LinkData.
Expected behavior
  • with(['linkField']), including nested paths such as linkField.image, eager-loads the linked elements, and the field value stays a LinkData.
  • Without with(), reading the first link loads the linked elements of every element from the same query together. Entry authors (Entry::getAuthors()) and Content Block fields already work this way.
Actual behavior
  • Each getElement(), getUrl() or getLabel() call on a link to an element runs its own element query (one per distinct link value).
  • With with(['linkField']), $entry->linkField is an empty ElementCollection instead of a LinkData.
Proposed fix (PRs ready)
  • Link implements EagerLoadingFieldInterface. The map is built from the field values that are already loaded, with one map per link type and site. It uses the same criteria as BaseElementLinkType::element() (status(null), drafts(null), revisions(null), and either siteId or site('*')->unique()->preferSites()), so the resolved elements don't change.
  • The eager-loaded elements are handed to the LinkData objects through the existing SetEagerLoadedElements event, with handled set, so getFieldValue() keeps returning links.
  • LinkData falls back to Elements::eagerLoadElements() across elementQueryResult when no with() was given, the same way as Entry::getAuthors().
  • Links to different sites or link types each need their own map, which uncovered a separate bug: normalizeEagerLoadingMaps() merges a list of maps with +=, so only the first map is used. The PRs append them instead.
  • On 6.x, a separate small fix: BaseElementLinkType::$fetchedElements is a static array that outlives the request. Queue workers and Octane return elements fetched by earlier jobs, and TestCase resets it with reflection. It moves to a #[Scoped] holder.

I've prepared PRs against 5.12 and 6.x, with regression tests that fail without the change, and will open them once you're OK with the approach. Let me know if you'd prefer different target branches.

Craft CMS version

5.12 (branch 5.12) and 6.x (branch 6.x, and 6.0.0-alpha.20)

PHP version

8.5

Operating system and version

Linux (Docker)

Database type and version

PostgreSQL 16 (also reproduced with SQLite in the 6.x test suite)

Image driver and version

n/a

Installed plugins and versions
Lenguaje dominante
PHP
Estrellas
3.6k
Forks
710
Merge medio
11 h 26 min
PR fusionados (30 d)
324

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de craftcms/cms

Todos los issues de craftcms/cms

Issues similares

Más issues de PHP

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.