Contrib.social

Display as "Swiper Entity" shows the same image in all slider elements

Open on Drupal.org →
Created on 18 November 2024, 4 days ago

Problem/Motivation

By using the Display Mode "Swiper Entity", all slides in a slider show the first image rendered.

Context:

  • fresh installed Drupal 10.3.8
  • php 8.3
  • Swiper Formatter: 2.0.x-dev
  • No other modules are installed apart of the usual installed during the installation.

Steps to reproduce

These are my steps, but maybe it can be reproduced with another steps.
I'm using Layout Builder to build the pages using Custom Blocks (both inline as normal blocks)

1. Create a Swiper template to apply to the formatter.
2. Create a custom Block "Gallery"
3. Add a Media Field ans select Image as Reference type and set it to be multiple.
4. In Manage Display, set Swiper Entity as a formatter.
5. Configure the formatter to use the swiper template you created in the Step 1 and the view mode "Media Library" as a renderer for the slides (see Image 1)
6. Create a Block in "Content > Blocks" with name gallery_thumbnails
7. Add some images to to the block.
8. Create content type which uses Layout builder
9. Create a node of this content type and add the custom Block "Gallery" you created in the step 2.

Now you should see a gallery with all slides showing the same image. Also, the first one.

Proposed resolution

As far as I can find the problem is in the service "Swiper.php" in the line 337:

   // Add an extra cache key to avoid conflict with
    // an original view mode cached version as a workaround to the current
    // implementation until the main logic is reworked.
    // Just in case it's not an entity, we add a check.
    $keys = $item['#cache']['keys'] ?? [];
    if (in_array('entity_view', $keys)) {
      $slide['#cache']['keys'][] = 'swiper-slide';
    }

Apparently this new key is causes a hit in the cache each time Drupal starts rendering a slider element.
(see Image3)

As soon as you randomize or make different the key for each element, all works, obviously, again as expected.
For example:
$slide['#cache']['keys'][] = 'swiper-slide-' . rand(0, 100);
(see Image 4)

I'm not really sure how it can be addressed because I don't know what is exactly the purpose of this key.
Isn't the element enough identified whit the keys found in $item['#cache']['keys'] ?

Remaining tasks

N/A

User interface changes

N/A

API changes

N/A

Data model changes

N/A

🐛 Bug report
Status

Active

Version

2.0

Component

Code

Created by

🇨🇭Switzerland juagarc4

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @juagarc4
  • Comment 4 days ago →
    🇨🇭Switzerland juagarc4
  • Comment 4 days ago →
    🇨🇭Switzerland juagarc4
  • Comment 3 days ago →
    🇷🇴Romania bbu23

    Hi,

    Thanks for reporting this issue, I'll try to reproduce it when I get the chance.

    The cache keys is an array of parts. In the case of node, a example is "['node', 5, 'teaser']". This means that the teaser representation of the node will be cached, but in Swiper's case it was a conflict because swiper is altering the representation. By adding the "swiper-slide" key we are creating two different "cache keys" depending on the scenario. And in theory, they are supposed to be unique. Randomising is not an option, so I first need to try to reproduce your scenario and investigate what happens to understand better.

    More information about the original issue here: https://www.drupal.org/project/swiper_formatter/issues/3395406 🐛 Swiper formatter fails to wrap row in swiper-slide div intermittently Active

  • Comment 3 days ago →
    🇷🇴Romania bbu23

    Though from your screenshots it might look like the keys are empty, so yes, in that particular case, the cache keys array will only contain the same key for all which is incorrect. Makes sense, I'll investigate.

  • Comment 3 days ago →
    🇷🇴Romania bbu23
  • Merge request !16Issue #3488101: Display as "Swiper Entity" shows the same image in all slider elements → (Open) created by bbu23
  • Comment 1 day ago →
    🇷🇴Romania bbu23

    I have provided a fix for this, thanks again for reporting this issue.

    We made a small typo mistake when porting from version 1 to version 2. Please try out the patch and let us know if everything okay now.

    Regarding the Proposed steps, 8 & 9 are not necessary, but of course can be tested. This bug can be reproduced for any entity reference, and in this particular example after step 7 the block can be added directly to the block layout and will have the same behaviour.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024