Swiper Slider Blocks for Gutenberg

What the plugin provides

The plugin adds two complementary slider building blocks to Gutenberg:

1) Slides / Slide blocks (manual slider)

A fully custom slider built from individual Slide blocks.

• Each Slide can contain any Gutenberg blocks
• Ideal for hero sections, feature sliders, testimonials, or custom layouts
• Editor productivity features:
  • slide numbering
  • copy / delete slide actions
• All layout, spacing, typography, and color controls use native Gutenberg supports

2) Query Slider block

A slider container designed to wrap Query-based content.

• Uses InnerBlocks to embed a core/query block
• Turns standard query layouts into responsive Swiper sliders
• Keeps Query rendering intact while adding slider behavior

Modern Swiper integration (key difference)

This plugin uses Swiper Web Components, not legacy JS initialization.

That means:

• No manual JS slider setup per instance
• No jQuery dependency
• Native custom elements:
  • <swiper-container>
  • <swiper-slide>
• Configuration is stored as HTML attributes, not inline scripts
• Fully compatible with modern frontend build pipelines and future Swiper updates

This makes the sliders more maintainable, more portable, and more future-proof than classic slider implementations.

Responsive and motion controls

All sliders support:

• Responsive slides per view for desktop / tablet / mobile
• Spacing derived from Gutenberg blockGap
  (including preset and clamp() values)
• Optional features:
  • Prev / Next navigation
  • Pagination (clickable)
  • Autoplay with configurable delay
  • Fade transition
  • Focus / on-slide behavior via data attributes

All options are controlled from the block Inspector and saved directly into the markup.

Output philosophy

• Outputs clean HTML using Swiper’s native custom elements
• No inline styles for layout logic
• No editor-only artifacts saved to content
• Frontend behavior is driven entirely by attributes and Swiper’s runtime

Editor and frontend parity

• What you configure in the editor is exactly what is rendered on the frontend
• Spacing, breakpoints, and behavior stay consistent
• No separate “preview mode” logic