March 18, 2026 · 3 min read

Building block-based carousels in Gutenberg

Most WordPress carousel plugins still pull you out of the block editor. You paste a shortcode, fill out a settings screen, or manage slides in a separate UI that does not behave like the rest of Gutenberg.

Carousel Slider Block takes the opposite approach. Each slide is a native block area inside the editor, so the same workflow you use for normal content also works for slides.

Why that matters

When slides are built with native blocks, you can mix content types without changing tools. A simple image slider works, but so does a carousel made from Cover blocks, pull quotes, buttons, embeds, WooCommerce blocks, or anything else already available in the editor.

That also means normal WordPress extension points still fit the workflow. If your stack relies on block supports, filters, theme styles, or custom blocks, the carousel does not need a parallel content system.

A cleaner editing workflow

The editor stays closer to normal Gutenberg because the plugin uses inner blocks for each slide. You can add, move, duplicate, and remove slides with the same block controls people already understand.

For agencies and content teams, that usually makes the editor easier to work with. If someone already knows Gutenberg, they can start building slides without learning a separate workflow.

Frontend behavior still matters

On the frontend, the plugin uses Swiper.js for responsive behavior, touch support, pagination, navigation, autoplay, and looped tracks. That keeps the editing model native without giving up a modern slider engine.

The result is a better split of responsibilities: Gutenberg for content structure, Swiper for carousel behavior.