Emit core 7.1 grid child placement instead of carrying grid and positioned layout as CSS
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 45/100
調査の方向性
Start by reading the core layout handling in wp-includes/block-supports/layout.php and wp_get_layout_child_values(). Examine the transformer's InlineGeometry classification in the php-transformer/src directory to understand current carrier CSS logic. The goal is to modify the transformer to emit style.layout attributes for grid children and remove corresponding CSS carriers. Test with explicit grid placements and responsive overrides, ensuring output passes Gutenberg block validation.
索引モデルが issue の本文から書いたものです。
説明
Problem
WordPress 7.1 core stores grid-item placement natively on any block: style.layout.{columnStart,columnSpan,rowStart,rowSpan} on children of a layout.type: grid container, with per-viewport overrides under style["@tablet"].layout / style["@mobile"].layout (see wp_get_layout_child_values() and the viewport child-layout loop in wp-includes/block-supports/layout.php; breakpoints come from settings.viewport via WP_Theme_JSON::get_viewport_media_queries()).
The PHP transformer does not emit any of these fields. InlineGeometry still classifies grid-area, grid-column* and grid-row* as geometry that "converted native blocks cannot retain in their saved markup", so source grid placement travels through positioning/geometry carriers (generated CSS) instead of editor-owned block attributes. columnStart/rowStart appear nowhere in php-transformer/src.
Consequences:
- Explicitly placed grid items are only faithful while carrier CSS wins; the editor's grid controls show unplaced children and the first user edit can collapse the composition.
- Responsive re-placement (different spans/rows per breakpoint) is not representable as native data.
- Positioned compositions (collages, overlapping hero art, offset cards) have no native target at all and fall back to carriers or lose geometry (#668).
Proposal
Emit core 7.1 grid child placement as the native target, in two scoped steps.
- Source-authored grid placement. When a
display: gridcontainer's children declaregrid-column/grid-row/grid-areawith resolvable integer lines or spans, write them to the child block'sstyle.layoutand drop the equivalent carrier declarations. Media-query variants that map onto the destination's@tablet/@mobileviewports go tostyle[<viewport>].layout. Unresolvable forms (named lines,grid-template-areaswithout a line mapping,auto-fillinteractions, subgrid) stay on carriers with a typed diagnostic. - Positioned compositions to grid placement. For containers already classified as positioned/freeform (absolute children, overlap, z-index stacking; the Figma path's
StackingContextPolicyreasons are the model), project child boxes onto an explicit grid with per-viewport placement when every child snaps within tolerance. Overlap is legal in CSS grid with explicit placement. Anything that still needsz-index, rotation, or sub-cell offsets stays on carriers and is reported, so the remaining gap is measured rather than assumed.
Acceptance
- Contract coverage: explicit
grid-column/grid-rowspans,grid-areawith numeric lines, one responsive override, and an unresolvable named-line case that keeps its carrier plus diagnostic. - Output passes Gutenberg block validation with no invalid-content warnings; placements are visible and editable in the core grid UI after save/reload.
- Carrier CSS for converted placement properties is removed, not duplicated.
- Visual parity on 2–3 positioned/collage fixtures (including the #668 collage) is no worse than the current carrier baseline, and the positioned-composition step reports how many children it could not place natively.
- Viewport overrides are emitted only when the destination declares matching
settings.viewportbreakpoints; otherwise the base placement stands and a diagnostic records the dropped variant.
Why this matters
It turns layout that is currently CSS-carried into data the WordPress editor owns, for every block type, with no plugin dependency. It also creates a single interoperable placement format that visual layout editors building on core grid (for example Automattic/canvas) could read directly.
Related: #668, #1743, #733.
AI assistance
- AI assistance: Yes
- Model: Claude (Anthropic)
- Tool: OpenCode
- Contribution: Investigated core 7.1 layout support and the transformer's current grid/positioning handling, and drafted this issue; reviewed by the requester before filing.
- 主要言語
- PHP
- スター
- 21
- フォーク
- 2
- 平均マージ
- 7時間 22分
- マージ済み PR（30日）
- 731
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
Automattic/blocks-engine のほかの issue
-
Solved site promotion gate fails on runner PHP patch drift (expects 8.2.33, runner installs 8.2.34)オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
Automattic/blocks-engine#2161 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
Automattic/blocks-engine#2061 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
Automattic/blocks-engine#1701 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
Automattic/blocks-engine#775 ·
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 45/100
Automattic/blocks-engine#2764 ·
メンテナーはふだん 1 日以内に返信
Automattic/blocks-engine の issue をすべて見る
似ている issue
-
sync-en
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
メンテナーはふだん 1 日以内に返信
-
sync-en
難易度 2/5 1〜3時間 初心者へのやさしさ 66/100
メンテナーはふだん 4 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
scanaislop/aislop#482 ·
メンテナーはふだん 1 日以内に返信
-
bug UI
難易度 2/5 1〜3時間 初心者へのやさしさ 66/100
メンテナーはふだん 1 日以内に返信