Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#20,150 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
25/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
php
Lĩnh vực
backend, database

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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
Ngôn ngữ chính
PHP
Star
3.6k
Fork
710
Merge trung bình
11 giờ 26 phút
Pull request đã merge (30 ngày)
324

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của craftcms/cms

Tất cả issue của craftcms/cms

Issue tương tự

Thêm issue về PHP

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.