Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#20,150 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
25/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
php
領域
backend, database

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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
主要言語
PHP
スター
3.6k
フォーク
710
平均マージ
12時間 44分
マージ済み PR（30日）
335

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

craftcms/cms のほかの issue

craftcms/cms の issue をすべて見る

似ている issue

PHP の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。