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

Captured gallery frames with responsive capture classes lose their frame attributes

Open
  • Is something wrong?
#2,903 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
50/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
php, wordpress
Domain
backend

Research direction

Start where responsive capture classes cause a layout-shell wrapper to keep only class, and check why the data-blocks-engine-capture-gallery-* attributes are dropped there, while the homepage slideshow without those classes keeps them. Add a neutral two-frame captured gallery fixture whose frame 0 has responsive classes, then confirm data-blocks-engine-capture-gallery-frame="0" survives on the emitted wrapper. Done when next/previous steps through both frames with the gallery runtime kept.

Written by the indexing model from the issue text.

Description

Problem

When a captured gallery's visible frame carries responsive capture classes, its frame wrapper is lowered to a layout-shell that keeps only class; the capture gallery attributes on that wrapper are dropped:

<div class="slides" data-blocks-engine-capture-gallery-stage data-blocks-engine-capture-gallery-initial="0">
  <div class="slide data-blocks-engine-capture-responsive-…" data-blocks-engine-capture-gallery-frame="0" data-blocks-engine-capture-gallery-image="/media/a.jpg" data-blocks-engine-capture-gallery-display="block" data-blocks-engine-capture-gallery-text="[]">…<img src="/media/a.jpg">…</div>
  <div class="slide data-blocks-engine-capture-responsive-…" data-blocks-engine-capture-gallery-frame="1" … hidden>…<img src="/media/b.jpg">…</div>
</div>

In a Studio import of a captured site built on a hosted site builder, one blog post's two-frame slideshow is emitted with frame 1 still carrying data-blocks-engine-capture-gallery-frame="1", but frame 0's wrapper is now <div class="wp-block-group slide data-blocks-engine-capture-responsive-… blocks-engine-attribute-…"> with no data-blocks-engine-capture-gallery-* attributes.

Effect at 1440: the kept capture gallery runtime sees only one frame. The gallery root is 13px tall with no visible frame on load, and clicking Next shows frame 1 and then stays there. Previous does not step back. The homepage slideshow on the same site, whose frames carry no responsive classes, keeps every frame attribute and steps correctly.

This happens with php-transformer v0.41.19 and current trunk. It is independent of #2883, which concerns the direction controls.

Expected

Every captured gallery frame keeps the gallery frame contract (…-gallery-frame, …-gallery-image, …-gallery-display, …-gallery-text, hidden) on the block that owns the frame, whatever presentation classes the frame carries. The kept runtime should then step through all captured frames.

Acceptance

  • A neutral fixture of a two-frame captured gallery where frame 0 carries responsive capture classes keeps data-blocks-engine-capture-gallery-frame="0" on its emitted wrapper.
  • With the gallery runtime kept, next/previous cycles through both frames.

AI disclosure: Claude (Anthropic) via Claude Code investigated and drafted this under Chris Huber's direction; operator-authorized direct fallback outside Homeboy.

Dominant language
PHP
Stars
21
Forks
2
Avg merge
8h 50m
Merged PRs (30d)
609

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.