Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
#2,965 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
15/100
Issue type
Refactor
Clarity
Mostly clear
Activity status
Active
Domain
tooling

Research direction

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.

Written by the indexing model from the issue text.

Description

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.

Dominant language
PHP
Stars
22
Forks
2
Avg merge
8h 22m
Merged PRs (30d)
659

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Automattic/blocks-engine

All issues in Automattic/blocks-engine

Similar issues

More PHP issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.