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

Carousel block: derive slide-dependent values and move source replay out of attributes

Abierto
  • ¿Algo no está bien?
#2,965 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
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
15/100
Tipo de issue
Refactorización
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
javascript, php, wordpress
Área
tooling

Línea de trabajo

Start with the attribute definitions in AuthoredCarouselBlockGenerator, then trace the editor, save and view script that read them, plus safeControlTopologyMarkup in PHP. Build the attribute inventory the acceptance list asks for, classifying each of the 46 attributes as editor-facing, derived or fidelity carry. Done means that inventory exists and the fixtures/websites/ carousel imports still hold parity, with any regression listed. The design choices (native supports, structural controls) need maintainer agreement before code changes.

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

Descripción

Summary

The generated carousel block (AuthoredCarouselBlockGenerator) declares 46 attributes. Only a handful describe the carousel a user would edit. Most of the rest replay the source page's markup and geometry, and two of them hold raw HTML. As a result, the block is hard to edit, and editing it can leave the saved markup out of step with its slides.

This issue proposes auditing the attributes against what an editor needs, and moving source fidelity out of block attributes.

Related: #220 (rebuild interactive behaviors with WordPress-native primitives).

What the attributes are today

Carousel settings a user would recognize. The block's sidebar exposes only the five marked with *:

  • transitionStyle*, transitionDuration*, autoplayInterval*, showPlayControl*, playControlPosition*
  • wrap, itemsPerView, initialSlide, showDots, showStatus
  • thumbnailPosition, fullBleed, ariaLabel

Source replay, which nobody can see or edit in the editor:

  • sourceRootGeometry, sourceCustomProperties, sourceIdentityAttributes
  • sourcePresentationClasses, sourceControlClasses, sourceControlAttributes
  • stageWrappers, stageTrackClassName, stageMinHeight, stageAspectRatio, stageMaxWidth, viewportHeight
  • controlPresentation, previousControlPresentation, nextControlPresentation
  • previousControlClasses, nextControlClasses, previousControlVisual, nextControlVisual
  • sourceControlArtwork, playControlInset

Raw HTML stored in attributes:

  • sourceControlTopology is injected with dangerouslySetInnerHTML in save and passed through safeControlTopologyMarkup in PHP.
  • srcSwapMarkup is split on a sentinel comment and written into the slide sequence.

Values derived from content but stored separately:

  • slideCount determines how many dots save renders.
  • thumbnails stores a URL list that save renders as the thumbnail rail.

Problems

  1. Saved markup drifts out of step with the slides. The editor lets users add or remove slides (InnerBlocks with an appender), but slideCount and thumbnails don't follow:
    • The saved dots and thumbnails keep the count and images from import time.
    • The view script counts the slides from the DOM, so the controls and the slides can disagree.
  2. Editing is mostly invisible. Only 5 of 46 attributes are shown in the sidebar. Geometry, control artwork and wrappers can only be changed by hand-editing the block comment.
  3. Raw HTML in attributes. Control markup and slide sequences stored as HTML strings get none of the block editor's editing, validation or sanitizing. They also tie the block to the source page's DOM.
  4. Per-site generated code. Every import ships its own copy of this block under the site's namespace. The more source detail the attributes carry, the more each site's content depends on that generated copy.

Proposal

  1. Derive values from the content.
    • Count the dots from the inner blocks at save time, or render them in the view script.
    • Read the thumbnails from the slides' images.
    • Remove slideCount and thumbnails.
  2. Use native block supports for presentation. Map geometry and spacing to the block's style attribute (dimensions, spacing, color, border) so it is editable like any other block. Move the source-specific classes and custom properties to className and theme or global styles, which is where the rest of an imported site's styles already live.
  3. Make controls structural. Replace sourceControlTopology and srcSwapMarkup with:
    • a small, enumerated set of control layouts (attributes such as dot or arrow placement), or
    • inner blocks for the controls,
      so that no HTML is stored in attributes.
  4. Expose what remains. Every attribute left after the audit should either appear in the sidebar or be derived. Document anything that can't be either as an intentional fidelity carry.

Acceptance

  • An attribute inventory classifies each attribute as editor-facing, derived or fidelity carry, with the reason for each.
  • After adding or removing a slide in the editor and saving, the dots, thumbnails and slides agree on the front end, and the block validates on reload.
  • No attribute holds HTML.
  • The carousel fixtures in fixtures/websites/ still import at their current parity. Any regression is listed, with its cause.

Drafted with AI assistance (Claude, running in the Pi coding agent). The agent read the carousel generator's attribute definitions, editor, save and view script on trunk, and counted the exposed controls. The author reviewed it before posting.

Lenguaje dominante
PHP
Estrellas
22
Forks
2
Merge medio
7 h 50 min
PR fusionados (30 d)
686

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.