Fix editor slide layout wrappers, harden loop initialization, and add Slides per view (v0.1.2)

[Copilot]

This addresses the v0.1.1 regressions where editor slides still stacked vertically and loop mode produced Swiper warnings/unreliable behavior. It also adds a configurable Slides per view control wired from block settings to frontend runtime.

• Editor UX: horizontal slide strip in Gutenberg wrappers

  • Updated editor selectors to match real editor DOM nesting (.swiper-wrapper → .block-editor-inner-blocks / .block-editor-block-list__layout).
  • Made .slider-press .swiper the horizontal scroll container.
  • Forced horizontal non-wrapping flex layout through wrapper layers.
  • Ensured slide blocks render side-by-side with fixed-ish width (flex: 0 0 auto), without relying on brittle direct-child selectors.

• Frontend reliability: loop safety + grouping

  • Count slides from .swiper-slide.
  • Auto-disable loop when requested loop constraints are not satisfiable for current content.
  • Explicitly set slidesPerGroup: 1 and keep config stable for loop/non-loop operation.

• New setting: Slides per view

  • Added block attribute slidesPerView (default 1).
  • Added InspectorControls RangeControl (1–6), labeled Slides per view.
  • Persisted to markup via data-slides-per-view.
  • Consumed in frontend Swiper config (slidesPerView), integrated with loop safety checks.

• Versioning + artifacts

  • Bumped plugin/package/readme versions to 0.1.2.
  • Rebuilt and committed updated build/ assets.

const slidesPerView = Math.max(1, parseInt(el.dataset.slidesPerView || '1', 10) || 1);
const slidesPerGroup = 1;
const slideCount = el.querySelectorAll('.swiper-slide').length;
const minSlidesForLoop = Math.max(2, slidesPerView + slidesPerGroup);
const loop = (el.dataset.loop === '1') && slideCount >= minSlidesForLoop;

Editor horizontal layout screenshot:
https://github.com/user-attachments/assets/8c56f356-acce-4a42-af4b-ed7759453c15

Frontend behavior screenshot:
https://github.com/user-attachments/assets/5ac5b7ec-ce76-40b9-a104-3ba26489464c

Original prompt

Fix SliderPress issues in repo bradhogan/sliderpress and add Slides Per View.

Context / bugs:

• Release v0.1.1: editor slides are still stacked vertically instead of horizontal scroll UX.
• Swiper loop warnings show when loop is enabled and slider may not function reliably.
• Need to adjust editor CSS selectors based on actual editor DOM structure: .swiper-wrapper contains .block-editor-inner-blocks / .block-editor-block-list__layout wrappers and slide blocks have class block-editor-block-list__block ... swiper-slide ....

Tasks:

1. Editor horizontal UX

• Update src/editor.css so the slide list in editor lays out horizontally with scrollbar.
• Ensure correct selectors for Gutenberg wrappers:
  • Make .slider-press .swiper the horizontal scroll container.
  • Make .slider-press .swiper-wrapper (and possibly the .block-editor-block-list__layout inside it) display:flex; flex-direction:row; flex-wrap:nowrap.
  • Ensure child blocks (the slide groups) are flex: 0 0 auto with a fixed-ish width so they appear side-by-side.
  • Remove or avoid > selector that misses wrapped children.
  • Keep frontend unaffected.

2. Frontend slider reliability & loop

• In src/frontend.js, make loop safe:
  • Count slides via .swiper-slide.
  • If loop enabled but slides are insufficient, automatically disable loop (and avoid warning).
  • Explicitly set slidesPerGroup to 1 (or match slidesPerView) and ensure config supports loop.
• Ensure slider functions with and without loop.

3. Add Slides Per View option

• Add block attribute slidesPerView (number) default 1.
• Add InspectorControls RangeControl (e.g., 1-6) labeled "Slides per view".
• Save the value as data-slides-per-view on frontend markup.
• In src/frontend.js, read it and pass to Swiper config.
• Adjust loop safety logic considering slidesPerView + slidesPerGroup requirements.

4. Version bump + build

• Bump version to 0.1.2 (plugin header, package.json, readme/readme.txt if present).
• Rebuild build/ assets and commit.

Deliverable: PR with these fixes and updated build artifacts.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: @copilot Accepted Confirmation: Confirm agent session

Assistant: I’ve started working on the updates (rename to SliderPress, add a proper release ZIP that unzips to a sliderpress/ folder, and improve the horizontal slide editing UX in the editor). You can track progress at the task link below.

data:
  - title: "[WIP] Update branding to SliderPress and improve ZIP build process"
    repository: bradhogan/Slider-Press
    url: https://github.com/copilot/tasks/pull/PR_kwDOSBjs6s7StvPg?session_id=93ca3464-3622-485a-90ed-e20a90c084f4
    state: queued

User: once you're done with those changes, can you move the contents of this repo to this repo instead to better match the plugin name > @bradhogan/sliderpress

Assistant: Yes—I can move/duplicate the plugin into bradhogan/sliderpress, but I need one decision from you because there are two “correct” ways to do this on GitHub:

Choose how you want to “move” it

A) GitHub rename (best, keeps history, issues/PRs):
Rename the repo bradhogan/Slider-Press → bradhogan/sliderpress in GitHub settings. This preserves commits, PRs, stars, etc., and GitHub will redirect the old URL.

B) Copy contents (new repo history):
I’ll copy the plugin files into the new repo bradhogan/sliderpress. This won’t preserve PR history from Slider-Press (it becomes a separate project history unless we do a full git history migration, which is more involved).

Given you already created bradhogan/sliderpress, option B is likely what you mean—but I want to confirm.

One more question

Should the old repo bradhogan/Slider-Press be:

1. left as-is,
2. archived, or
3. replaced with a README that points people to the new repo?

Reply with:

• A or B, and
• 1, 2, or 3.

Once you answer, I’ll proceed accordingly after the current change set finishes.

User: let's go with (A) and then we can completely archive or remove the Slider-Press repo

Assistant: I can’t perform repo rename/archive/delete operations from here (my tools can write files and open PRs, but they don’t have admin control over repository settings). You’ll need to do the rename + archive/remove in GitHub’s UI, and I’ll adjust anything in the codebase that depends on the repo name if needed.

Do this (recommended sequence)

1) Rename the repo

GitHub → bradhogan/Slider-Press → Settings → General → Repository name
Rename to: sliderpress

GitHub will automatically create redirects from:

• bradhogan/Slider-Press → bradhogan/sliderpress

2) Confirm the default branch stays main

It usually will, but just verify under Settings.

3) After rename: tell me the new canonical repo URL

Reply with just: bradhogan/sliderpress once the rename is complete....

This pull request was created from Copilot chat.