Drupalwoo ☉

Build a Slick Carousel in Drupal with Views

Implementing a Slick Carousel in Drupal with Views gives editors a visual way to publish a sequence of featured items while developers keep markup and behaviour under version control. Views supplies each slide as a row; the Slick integration converts those rows into a responsive slider; and Drupal libraries load the JavaScript and CSS. That division suits Australian small-business sites, community organisations and lean agency teams, where a marketing coordinator may change campaign content without waiting for a developer.

This walk-through assumes Drupal 10 or 11, Views, a maintained Slick contrib integration and the Libraries module. Module names and supported Drupal branches can change, so check the project pages and security advisories before pinning packages. The aim is a working editorial workflow with sensible caching, responsive images and keyboard access, rather than merely adding slides that move across the screen.

Compare the available approaches

The practical first decision is whether the carousel should remain a View, become a custom display plugin, or be assembled from a theme component. Editor-led publishing usually benefits from a maintained Views style, while unusual layouts may justify custom development.

Approach Best fit Main advantage Main drawback
Maintained Views style Editorial teams needing configurable sliders Familiar Views workflow and quick setup Depends on upstream support for the Drupal version
Custom Views display plugin Highly bespoke designs Precise control of markup and behaviour More development, testing and upgrade work
Theme block or paragraph Small, fixed promotional features Simple implementation Content and ordering sit outside Views

For most Drupal teams, the maintained integration is the safest starting point because its formatters, settings and Views style share the same maintenance cycle. Check that its latest stable release supports your exact Drupal version, has recent security releases and provides the field options you need. If no compatible release exists, a custom Views display can be cleaner than forcing an old contrib module into a newer core release.

Model slides as structured content

Create a dedicated content type for slides, with fields for an image, alternative text, heading, summary, optional link and link label. A Media image field gives editors reusable assets and useful metadata, while ordinary text fields keep captions searchable. If cards need body copy, use a trimmed summary rather than copying the entire node into every slide.

Keep alternative text on the Media entity and let the template output it; do not duplicate the same phrase in both fields. Cropping and responsive source sets should preserve the subject of an image. For image-heavy inspiration, the Just Baby Cake gallery can provide a useful visual test when checking portrait, close-up and landscape assets at mobile sizes. Use descriptive link text so users know where a slide leads.

Use Views sorting to define the sequence rather than storing an arbitrary position on every node. A weighted date, promotion flag or editorial relationship can drive the result, while an exposed filter lets campaign pages target a specific audience. For Australian event content, dates commonly read as day, month and year, and the relevant state time zone should be displayed, including daylight-saving changes where they apply. Interface labels should also use Australian English, such as “Colour” and “Favourite”.

Attach the slider through Drupal libraries

A Slick package is a third-party front-end library, so declare it through Drupal’s asset system rather than inserting a script tag into a template. The contrib integration often includes a compatible Slick build. A common Composer starting point is composer require drupal/slick drupal/libraries, although package names vary by release and companion Slick modules may also be required. Enable Views and the modules listed by the selected project rather than installing similarly named packages by guesswork.

If assets are managed manually, place the minified files in the agreed library directory and describe them in a libraries.yml definition. The paths below assume the library contains the following structure:

slick:
  version: 1.8.1
  js:
    js/slick.min.js: { minified: true }
  css:
    component:
      css/slick.css: { minified: true }
      css/slick-theme.css: { minified: true }

Keep the paths relative to the library root, and copy any font files required by the theme stylesheet. If the contrib module already declares the same library, do not add a competing definition. Run drush cache:rebuild after changing library metadata or file locations, then inspect the rendered page to confirm that each asset is requested only once.

A maintained integration normally registers its own JavaScript behaviour and exposes slider options through its configuration UI. For a custom implementation, attach a compatible jQuery library, read options from drupalSettings, and initialise the slider inside a Drupal behaviour attached to the relevant context. This prevents the carousel from being initialised twice when Views content is replaced through AJAX.

Configure the Views display

Create a View with the slide content type as its data source. Add the image, heading, summary and link as separate fields, then arrange them in the desired display order. Use a field formatter for the image that supports responsive image styles, and check the rendered output for unwanted wrappers such as duplicate links. A slider should normally contain one primary link rather than placing the same destination around both an image and a heading.

In the display’s style settings, select the Slick or Views Slick option supplied by the integration and configure the number of slides to show. Set sensible defaults for the responsive breakpoint, arrows, dots and swipe behaviour. Avoid placing essential information only in the first visible slide, since users may arrive from a shared deep link and later slides may remain hidden to assistive technology.

Separate displays can serve different editorial needs without duplicating content. A full-width display might show four slides on desktop, while a compact promotional display shows one at a time. Use contextual filters to restrict slides to a campaign, service region or audience segment. Cache the View where content changes infrequently, but avoid caching personalised or highly dynamic results.

Tune responsive and accessible behaviour

Treat desktop responsiveness as only one part of the experience. A one-slide mobile layout, two-slide tablet layout and three- or four-slide desktop layout generally provide a clear hierarchy without making captions unreadable. This matters for train commuters in Sydney and Melbourne and for users on variable mobile connections in regional Queensland. Serve appropriately sized images, define image dimensions to reduce layout movement, and avoid loading large media for slides the user may never reach.

Slick can support keyboard users, but its generated controls still need testing within the page. Confirm that previous and next buttons have meaningful labels, that focus does not disappear after a slide change, and that every slide link can be reached with the keyboard. Alternative text should describe the image’s purpose in context; decorative images should use empty alternative text. Team members serving Australian government clients commonly benchmark accessibility against WCAG 2.2 AA, including contrast, focus visibility and meaningful page structure.

Avoid automatic movement by default, particularly when slides contain essential information. If autoplay is enabled, provide a visible pause control and do not let a slide advance while a visitor is reading or interacting with its content. Honour the operating system’s reduced-motion preference by removing transition effects where appropriate. Test the complete experience with keyboard navigation, a screen reader, browser zoom at 200 per cent and JavaScript disabled so that content remains available when the slider cannot start.

Ship with reliable safeguards

Before deployment, exercise the View as an editor would: create several slides, publish them in sequence, open the target page and verify that the intended items appear. Test both anonymous and authenticated sessions so access restrictions and preview behaviour are visible. Deployment scripts should update Composer dependencies, compile any custom theme assets and clear Drupal’s caches as one controlled operation.

Ownership then sits with the Drupal administrator for dependencies, security updates and library maintenance, while the Views editor controls slide selection, ordering and campaign-specific filtering. This separation keeps routine publishing accessible to content teams without turning the carousel into an isolated piece of custom front-end code.