how to fix vertically stacked repeats of content type images

Hello,

The module supports two display modes:
Hero Slide Mode – This requires a specific field type, and the image field must be limited to one image only.
View Mode Integration – This allows you to use any defined view mode.

Please note: the module includes its own Twig template. If any other module or theme overrides this default template, the slideshow will not function correctly.

To verify which template is being used, follow these steps:

Enable Twig debugging.
Inspect the page source and look for the template suggestions in the HTML comments.
Ensure no other template is overriding the one provided by this module.

<!-- BEGIN OUTPUT from 'modules/contrib/vvjs/templates/views-view-vvjs.html.twig' -->
<!-- BEGIN OUTPUT from 'modules/contrib/vvjs/templates/views-view-vvjs-fields.html.twig' -->

You can see examples of both display types on the demo site:
https://unitedstarsofamerica.com/vanilla-views/views-vanilla-javascript-...

By default, you should see a working version similar to the examples shown there.

Best regards,
Alaa

Thanks for suggestions, Alaa. But sorry, I am not understanding exactly how to inspect the twig inspection thing. Can you provide a Mac Terminal command for twig debugging and to reveal other relevant factors? The site theme in use is DXPR Theme 6.0.5. Does that tell you anything about a possible conflict? BTW, the link provided as demo site is not working, and generates a Page Not Found.

Hello,

You can enable the twig debug through the Drupal UI

Go to: https://your-site.com/admin/config/development/settings
Under Twig Development Mode, check the following boxes:
☑️ Twig debug mode
☑️ Disable Twig cache
☑️ Do not cache markup
Click Save configuration and clear caches.
Then open your site in a browser → Right-click → "View Page Source" → Search for

.
You'll see detailed comments showing:

Important Note for DXPR and Layout Builder Themes
The vvjs module provides its own templates to ensure correct rendering of the slideshow.

However, some themes like DXPR may override or suppress default Views template suggestions, particularly when using their own layout builder or dynamic block region system.

If your theme still overrides the rendering or you want to customize the slideshow:
Copy these two files from the module:

modules/contrib/vvjs/templates/vvjs-internal.html.twig
modules/contrib/vvjs/templates/vvjs-fields-internal.html.twig

Rename them to match your view name using standard Views suggestions:

views-view--yourviewname.html.twig
views-view-fields--yourviewname.html.twig

Place them in your theme at: themes/custom/YOUR_THEME/templates/views/
then clear caches.

BTW, the link provided as demo site is not working, and generates a Page Not Found. m not sure why it's not working for you. I just clicked the link and it's working on my end.
You can also access the demo by visiting https://unitedstarsofamerica.com and navigating to the Views Vanilla section; the demo link is available there.

Best wishes,
Alaa

Alaa, I have enabled the options
☑️ Twig debug mode
☑️ Disable Twig cache
☑️ Do not cache markup
and see code matching the example you provide (excepting that I don't currently have the Hero option enabled).
But it's not clear to me how this can be used to resolve the issue. I assume the DXPR theme is disrupting the VVJS template, as suggested. In regard to the changes that followed, involving modifed .twig files, the instructions seem incomplete but maybe I'm just not getting it. Do you mean to make a full duplicate of the DXPR theme fileset, rename it and put in a themes/custom folder, and replace the 2 modified .twig files there? Then enable this theme as the default?
It seems like a lot of extra steps to get the slideshow working properly. Would this be avoided if using a different theme, not DXPR?

Hello,

To confirm if the issue is theme-related, try switching to the Olivero theme (included with Drupal). If the slideshow works there, it means the current theme is interfering with the VVJS templates.

You do not need to copy the entire theme. If you're using a custom theme in the themes/custom folder, you can place the two template files directly there and rename them according to your view.

If your theme is in themes/contrib, then it's best to create a sub-theme and place the renamed templates inside it.

Theming Views: https://drupalize.me/tutorial/overview-theming-views
How to Create Sub-Theme: https://www.drupal.org/docs/extending-drupal/themes/contributed-themes/s... →

Best,
Alaa

Getting back about the suggestions: I switched the theme to Olivero. The vertically stacked repeats of images, below the actual (and working) slideshow display, is still happening. The only difference is, in Olivero theme the extraneous items below the desired display are all just titles of images, not titles plus actual image, as happens in DXPR theme. Since it's also happening there, should I assume the suggested creation of those filename-modified .twig files would probably not help because the problem is coming from some other issue?
--Thanks--

Adding a note to this, and requesting suggestions for resolving the problem: Here's a screen capture of the display I am getting. The slideshow at top is cycling as configured, with the timing and transition type selected. But the 17 images involved are repeated below in a column. The slideshow setup is using a content type set up for this purpose, with one image in each instance of that content type. What could be going wrong?

Hello,

Unfortunately, I can’t determine much just from the image. If you can share a URL, I’ll be able to provide more specific help.

In general, for the slideshow to function correctly, make sure it's using the correct Twig template as shown in the screenshot I shared. Also, check the browser’s developer console for any JavaScript errors that might be preventing it from working properly.

If you've already debugged that and it's still not working, try disabling any custom or contrib modules that could be interfering. It can also help to test the slideshow while logged out (as an anonymous user) to rule out permissions or caching issues.

The module includes an example View (vvjs_example) that works with the default Article content type. If you don't have that content type, you can edit the View and switch it to a different one. If the example doesn’t work after adjusting it, then something else on the site is likely causing the problem.

Let me know if you can provide a URL, that will help me assist you more effectively.

Best wishes,
Alaa

Alaa, Sorry to bother you again about this, but you are the likely best expert to comment on it. I can't provide a URL because this Drupal 11 site is in local development on my Mac, with Docker Desktop running.

Here are other observations about this, which to me are making it a bigger mystery:
-- It doesn't matter which theme is set as default, the cycling slideshow is working but repeats of individual images below it continue to appear. I tried Olivero and Stark, instead of the desired default of DXPR.
-- I tried substituting the VVJS Example view instead of the view I had built with desired preferences. It displays differently because of settings for VVJS Slideshow, but the repeats below it are the same.
-- (This seems odd) - The slideshow view is set as the block occupying the Hero region of the theme. If I disable the view, the slideshow display no longer shows, as expected. But despite a full cache flush, those repeats of images in vertical order continue to appear.

If I use the browser Inspect function and get the code from one of these 'extraneous' images, could that tell you something useful?

I have just resolved some issues limiting my participation and am experimenting again. This issue is very relevant me and I've posted similar "support" issues before.

I'm trying to understand the relationship between the "parent" module paragraphs and the "child" module vvjs. ON my ddev based system I just did a drush uninstall of "paragaphs_bundle_slideshow" and ran a slideshow that I had working when both paragraph bundle slideshow and VVJS were installed and running. I was able to replicate the vertical layout of images you (opstao) posted here in #8. Running the same content with BOTH paragraphs_bundle_slideshow and vvjs running I get the cycling slideshow running properly with no vertical display of the images below.

I posted a similar issue https://www.drupal.org/project/vvjs/issues/3528979 💬 Dependencies Active titled "Dependencies" (at least it seems related to me) but have never worked out exactly what is happening there. I am using a content type called gshow which has a single field in it named "Entity reference revisions" with Reference type: Paragraph. That seems to produce a cycling type of slideshow rather than a vertical one. Then I can go into the VVJS example view provided with the VVJS module and change the filter criteria there to access different "intances" of the gshow content type.

My goal is to be able to set up multiple instances of a content type pointing to individual galleries and to have one view accessing them all. Then have a menu listing the galleries and have the users able to use the menu to access whichever gallery they want to see. I realize that you can use a view to expose a filter to users but that seems to impractical and error prone for true end users.

Just to follow on my rushed post from yesterday. Here are four files illustrating the process I am trying to use with VVJS to create and present galleries.

Basically I am relying on a custom content type, (a simple one), that I am naming gshow. I want to isolate the gallery creation process from the rest of the "stuff" in Drupal to better control it (and for me to better understand and maintain it). So my content type definition has a single field named slideshow with a machine name "field para" that is a entity reference revision with a reference type Paragraph.

I added one additional screen capture, with file name china_slideshow_section4.png that is the fourth slide in what we are calling here the cycling slideshow. It corresponds to the fourth slideshow section in the file "one_content_item.png uploaded pervious. Each section "cycles" through the slideshow, as we would hope/expect. There is no vertical display of items as initially posted in this issue.

So, just to confirm previous findings. This morning I brought up my ddev based system locally. I did a " drush pm:uninstall paragraph_bundle_slideshow" which is the slideshow associated with the parent paragraphs module. I added a file upload named scrolled without_paragraphs that replicates the problems opstao showed in the initial post in this issue. Then, I did a drush pm:install paragraph_bundle_slideshow and the problem with vertical scrolling continued. ARghh. Then did a drush cr and the problem went away.

Only @Alaa understands how these modules work together, but I'd recommend that opstao verify whether he has the paragaphs/paragraphs_bundle_slideshow module working.

fkelly12054, thank you for all the investigation and testing you have done. This may provide a useful guide at some point. But I have since learned of what seems to be a very simple solution, suggested in the r/drupal section of Reddit where I had also posted this issue:

Sounds like you are still using the default front page of the drupal installation?

To disable the standard front page in Drupal 11, navigate to admin/config/system/site-information and either set the "Default front page" to a custom path (like a newly created page) or disable the checkbox "Retain /node as an active url?" if you've already changed the front page from "/node".

Indeed, I had been (stupidly?) attempting to do all this slideshow setup in the default front page of a new Drupal installation. But I had no idea and had never read any comment advising not to do that. So, upon creating a new page and defining it as the front page, this whole issue has vanished. I didn't find the exact options this person suggested, but in general the methodology did work.

Hello,

@fkelly12054 thanks for the detailed testing. I’ve added two working examples on Simplytest that you can visit to see VVJS in action.
This setup can get complex; if it feels heavy, I recommend grabbing some one-on-one help (Drupal Slack/support channels) so you can get guided, hands-on troubleshooting while you experiment.

@opstao glad you tracked it down!

This demo may only be temporary, please check it soon.
https://master-4th1wcocxbnaaysibtmhqd2gjel9bh1u.tugboatqa.com/
username: admin
pass: admin

Best wishes,
Alaa

I can't find opstoa 's post on reddit. I can't find anything on tugboat. I don't know where demo.png is coming from or what it's supposed to show.

Is there supposed to be some secret way to install the vvjs module? What does "the setup can get quite heavy" mean?

The way I have vvjs working and using a dedicated content type together with one copy of the vvjs example view works okay for me. With some fine tuning, I can see vvjs being a reasonable substitute for the hundreds of galleries and thousands of jpg files I'm using with the old Juicebox module. I'm a maintainer on the juicebox contrib project and there are thousands of sites supposedly using juicebox. All of them are going to need a replacement approach to galleries on drupal because the fundamental product (juicebox javascript) is not open source and not supported. VVJS looks to me like a great possibility, but we need some more thud thud clank clank instructions (a.k.a. step by step) instructions. First you do x then y then z.

@opstao ... can you provide me with a link to the reddit discussion you mentioned? It is beyond me why you would want or need to change the default front page as part of installing vvjs.

When I disable the paragraphs version of slideshow I get the same problem (vertical slides) you alluded to. When I re-enable it the problem goes away.

I look at Slack frequently. The ddev folks have been very helpful to me there. I'm skeptical that I'll find vvjs help there unless Alaa himself visits that space.

@fkelly12054, here's the Reddit discussion you were asking about - I think this is the link but not sure it reveals all comments in the thread:
https://www.reddit.com/r/drupal/comments/1mqmfs7/why_is_image_content_di...

Thanks for the link to reddit. I was able to put one of my galleries as the front page on my dev site using config/system/basic site settings. The gallery now shows on the front page. I have no reason to use this approach. And I have no insight into why this fouls up your site. The gallery using vvsj with the content type (I use the name gshow but that's not required, but I think devoting a content type to it is a good idea) ... at any rate it works just fine with no vertical items below the "cycling" display.

I'm still puzzling over the comment about the "setup can get heavy". Besides using composer install (and update when required) for the vvjs module and having all dependencies installed, I'm not seeing that. I'm using multiple instances of a dedicated gallery content type and just one copy of the view and it works just fine.

I'll just mention that I'm also using the relatively new media folders contrib module. That's because I have a large volume of plain old jpg files in my sites/default/files directory and they need to get converted to media items. Other conversion solutions are not particularly friendly if you don't have alt tags for your jpgs and I don't time to be entering 20k alt tags for files that already have separate captions.

@fkelly12054, thanks for additional insight. I have been using a unique content type set up for the slideshow only, but not sure I've created it in the best way. Can you explain exactly how you created the content type? Does it use field_image, and set to display only field_image? In the content type setup is "type of item to reference" set as "Media"? (Just double-checking as many details as I can.)

The list of content items that I am working with is in the file content-type.png that I uploaded. The definition of the content type (structure / content type) is in the file definition of content item.png and consists of

label: Slideshow
machine name: field_para
field type: Entity reference revisions and Reference type: Paragraph

the "guts of it" are in the file one_content_item.png that was posted in #13. Flipping between all these is driving me to distraction. The issue queue arrangement is not friendly for this type of communication. Pulling these together is the key to making VVJS work. You also have to set up the display part of the one_content_item.png type file to layout the slideshow sections.

The more I work with this, the more I think that you just want to have ONE view (using the Example view Alaa provides) and just change or expose the filters and have the filters pointing at individual instance of the content item: one per gallery. The filters would be exposed and encapsulated by the site admin in menu items that would link to filter criteria in the view. On my site I would NOT want to expose the filters to users' discretion ... each menu item will point to a particular gallery that will be, from the user's perspective, hard-coded.

In the nitty gritty of the slideshow section within the content item I have something like:

"Slideshow Body Section
Image
Toggle Actions
Content
(active tab)
Display
Image Title
Image title for section 1, 152.jpg

Image
alt for 152
152 Caption
152.jpg
The maximum number of media items have been selected."

Where I have set the images up ahead of time as media items. I think that I am evolving to using media folders to better organize a large number of media items. I am also moving towards using image (PB) items rather than plain images because it gives added fields for putting in ancillary information such as captions alt text and titles that can be carried over to the gallery display.

I hit a bit of a road block in moving from sites/default/file/ ... many jpg files ... because my initial jpg files did not have alt text. Drupal wizards are very concerned (as they should be) about accessibility and don't make it easy to create media items without alt tags. Using the PB item types at least makes it possible to type in an alt tag as you go through the conversion.

Automatically closed - issue fixed for 2 weeks with no activity.