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

Emit core 7.1 grid child placement instead of carrying grid and positioned layout as CSS

Abierto
  • ¿Algo no está bien?
#2,139 0 comentarios 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
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
45/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
css, php
Área
backend, web-dev

Línea de trabajo

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.

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

Descripción

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.

  1. Source-authored grid placement. When a display: grid container's children declare grid-column / grid-row / grid-area with resolvable integer lines or spans, write them to the child block's style.layout and drop the equivalent carrier declarations. Media-query variants that map onto the destination's @tablet / @mobile viewports go to style[<viewport>].layout. Unresolvable forms (named lines, grid-template-areas without a line mapping, auto-fill interactions, subgrid) stay on carriers with a typed diagnostic.
  2. Positioned compositions to grid placement. For containers already classified as positioned/freeform (absolute children, overlap, z-index stacking; the Figma path's StackingContextPolicy reasons 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 needs z-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-row spans, grid-area with 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.viewport breakpoints; 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.
Lenguaje dominante
PHP
Estrellas
20
Forks
2
Merge medio
5 h 1 min
PR fusionados (30 d)
702

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 Automattic/blocks-engine

Todos los issues de Automattic/blocks-engine

Issues similares

Más issues de PHP

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.