- Issue created by @robbt
- πΊπΈUnited States robbt
So I'm just providing an update, there appears to be an error in the way that the twig cache is interacting with swiper_formatter module.
Essentially these issues existed only in the render cache, by disabling Disables render cache, dynamic page cache, and page cache. on /admin/config/development/settings the issue is fixed.
Sometimes clearing the cache for the whole site fixes it as well but other errors seem to be introduced, so it seems like there is a bug here where the render array isn't always being generated with the right markup but it's still intermittent and I'm not sure what the exact cause is or where to dive deeper in order to troubleshoot it.
- πΊπΈUnited States robbt
Ok, I'm no longer sure that this is a problem with the swiper_formatter or a problem with how Drupal caches full content nodes in the views cache. I realized that essentially the "cards" which are being rendered as a full node are getting wrapped in the slider or not wrapped in the slider based upon whether they have been rendered on a page. So far this is happening with different displays under the same view using different formatters.
Say view_1 which is a list of cards has A B C D rendered with the bootstrap_views_grid formatter - if I then load a page that has
a view with swiper_formatter (displayed with the cards) E D F G - D will be rendered without the swiper_slider as it was cached without it.If I then loaded a grid which should be rendered without a swiper_slider after this that has C D E F G - E, F & G will still have the swiper_slider div included in their rendered values.
I'm going to see if I separate the displays using different formatters into different views if I still have the problem or if this is a workaround. Otherwise it seems like this might require digging deeper into drupal render caching than I had planned.
- πΊπΈUnited States robbt
The work around for this was to create a new view mode for the content and then select that view mode for the ones that weren't swipers. I'm not sure if this is caused by a bug in Drupal View's caching or if it's in swiper formatter at this point.
- π·π΄Romania bbu23
Hey,
Thank you so much for posting this issue. I was having the same problem. I knew it was cache, and of course it cannot be core, but my problem is that I was not managing to reproduce because I couldn't find the exact rule. Your comments helped me realise immediately what the problem was and where to look to instantly reproduce.
The issue is in the module in my opinion. No processor should alter the render array of an entity view mode. I was using slick before this (raw library) and slick was generating the slide wrapper automatically. Now, because this module changes the #theme of the render array that was originally created by Drupal core, the cache keys stay the same. If you have the same view mode in another page that does not use swiper, and you hit that first, and then hit the page with the same or at least a few items displayed as a swiper with the same view mode, then the cached one will be displayed, since they use the same keys.
I need a fix fast, so I'm not going to go into the deep code of this whole logic, but for now I'll add a cache key to differentiate between swiper and non-swiper item. It's up to the maintainer to decide on improvements. The downside of this is that the view mode will have two keys stored for the same view mode in order to store the output with the slide in it. My opinion is that the slide should not be inside the item content, and rather act as a wrapper or something.
I'll provide MR.
- Merge request !3Issue #3395406. Add extra cache key to avoid conflict with original view mode. β (Closed) created by bbu23
- Status changed to Needs review
10 months ago 4:41am 29 February 2024 - Status changed to Fixed
9 months ago 4:51pm 19 March 2024 - π³π±Netherlands nk_
Thank you all! It was finally committed in the new release β , the last one supporting Drupal 8.8 and 9. A brand new branch 2.0.x β with quite some new features is there and recommended for a future use.
Automatically closed - issue fixed for 2 weeks with no activity.