Slider Revolution


I would like to ask an advice regarding the following problem:

We are using Hugo (version v0.55.5/extended windows/amd64) for generating our static site

I am now looking for the most elegant solution how to include a Slider Revolution (https://sliderrevoluitoin……) generated slider into the homepage of our Hugo site.

Ideally we would like:

  1. Fully separate slider-generated code from our website code
  2. Be able to include generated sliders at will into parts of the website via partials
  3. We should be able to easily update/renew the generated sliders
  4. We need multilingual support but we can live with per-language generated slider

One idea is to keep the generated sliders in /static/sliders and read the main slider.html of each slider with readFile and modify it with replace

Can the Hugo gurus here share some insights if and how this can be done most elegantly?

Many thanks…

Have a look at Inline Shortcodes

By using these you can call a partial directly from content files.

Also by coupling the above with Page Resources and Page Bundles it is possible to write the slider code once store it in a partial and re-use it multiple times for different content.

This is an approach that meets all of the criteria that you mentioned, since you will be adding sliders with content in markdown files and not in templates.

1 Like

Hi @alexandros! Thanks for the reaction, let me clarify @LexSpeedKB question (we are from the same organisation):

There is no problem to bundle a slider as a page bundle and call it via a short-code, the real issue we are facing is how to cleanly integrate a rather dirtily generated Slider-Revolution sliders into our clean Hugo code :slight_smile:

So, the Slider Revolution plugin produces something like this for each slider:

β”œβ”€β”€ NOTICE.txt
β”œβ”€β”€ assets
β”‚   β”œβ”€β”€ burger-1.png
β”‚   β”œβ”€β”€ courgette.png
β”‚   β”œβ”€β”€ dummy.png
β”‚   β”œβ”€β”€ egg-1.png
β”‚   β”œβ”€β”€ fish.png
β”‚   β”œβ”€β”€ fork-1.png
β”‚   β”œβ”€β”€ iphone_cutout.png
β”‚   β”œβ”€β”€ knife.png
β”‚   β”œβ”€β”€ leaf-1.png
β”‚   β”œβ”€β”€ onion-1.png
β”‚   β”œβ”€β”€ paprika.png
β”‚   β”œβ”€β”€ screen.jpg
β”‚   β”œβ”€β”€ transparent.png
β”‚   └── wheat.png
β”œβ”€β”€ css
β”‚   └── settings.css
β”œβ”€β”€ fonts
β”‚   β”œβ”€β”€ font-awesome
β”‚   β”‚   β”œβ”€β”€ css
β”‚   β”‚   β”‚   └── font-awesome.css
β”‚   β”‚   └── fonts
β”‚   β”‚       β”œβ”€β”€ FontAwesome.otf
β”‚   β”‚       β”œβ”€β”€ fontawesome-webfont.eot
β”‚   β”‚       β”œβ”€β”€ fontawesome-webfont.svg
β”‚   β”‚       β”œβ”€β”€ fontawesome-webfont.ttf
β”‚   β”‚       └── fontawesome-webfont.woff
β”‚   β”œβ”€β”€ pe-icon-7-stroke
β”‚   β”‚   β”œβ”€β”€ css
β”‚   β”‚   β”‚   β”œβ”€β”€ helper.css
β”‚   β”‚   β”‚   └── pe-icon-7-stroke.css
β”‚   β”‚   └── fonts
β”‚   β”‚       β”œβ”€β”€ Pe-icon-7-stroke.eot
β”‚   β”‚       β”œβ”€β”€ Pe-icon-7-stroke.svg
β”‚   β”‚       β”œβ”€β”€ Pe-icon-7-stroke.ttf
β”‚   β”‚       └── Pe-icon-7-stroke.woff
β”‚   └── revicons
β”‚       β”œβ”€β”€ revicons.eot
β”‚       β”œβ”€β”€ revicons.svg
β”‚       β”œβ”€β”€ revicons.ttf
β”‚       └── revicons.woff
β”œβ”€β”€ js
β”‚   β”œβ”€β”€ extensions
β”‚   β”‚   β”œβ”€β”€ revolution.extension.actions.min.js
β”‚   β”‚   β”œβ”€β”€ revolution.extension.carousel.min.js
β”‚   β”‚   β”œβ”€β”€ revolution.extension.kenburn.min.js
β”‚   β”‚   β”œβ”€β”€ revolution.extension.layeranimation.min.js
β”‚   β”‚   β”œβ”€β”€ revolution.extension.migration.min.js
β”‚   β”‚   β”œβ”€β”€ revolution.extension.navigation.min.js
β”‚   β”‚   β”œβ”€β”€ revolution.extension.parallax.min.js
β”‚   β”‚   β”œβ”€β”€ revolution.extension.slideanims.min.js
β”‚   β”‚   └──
β”‚   β”œβ”€β”€ jquery.themepunch.enablelog.js
β”‚   β”œβ”€β”€ jquery.themepunch.revolution.min.js
β”‚   └──
└── slider.html

We don’t want to manipulate this generated output manually so that if we need to update/modify the generated slider we don’t have to do the manual re-integration again.

So the idea is to keep these generated sliders folders somewhere separately, like e.g. /static/sliders/homepage-cs/ and have a clever Hugo code (in a short-code or partial, doesn’t matter) that would read the slider name’s slider.html, parse it into blocks (head/style/js/body) and re-insert the relevant blocks of the relevant layout or content page.

I guess we are looking into writing a custom pipeline if we want to do it this way?

Or can you guys see some other elegant way to do it? Any other ideas at all?



The /static folder just presents those files as is, on the published site; no magic. Hugo does not manipulate them. To me your challenge seems possible to script though, running some script after you update the files from the vendor.

I agree with @RickCogley either use scripts on the frontend or experiment with Local File Templates to render slider.html with its assets from the /static/ folder. You may be able to render it by using a mix of what was already mentioned above.

But let me be honest here. Hope you don’t get it wrong but what is so special about some proprietary Wordpress plugin slider that is written with jQuery?

There are better alternatives out there that can be made to work with Hugo in a more elegant way such as the iDangerous swiper which I am using for some of my projects.

Also note that jQuery has become somewhat redundant these days and older versions have vulnerabilities.


@alexandros That’s exactly my thinking but the marketing girls just seem to love that particular Slider Revolution and we were not able to convince them otherwise this far. I will certainly check the iDangerous swiper and if you have any other alternative ideas - very welcome!

Thanks so far!


Slider Revolution code is sheer horror, but it does solve one purpose: creates beautiful responsive slides that look good on any device.

Any idea if there’s another plugin that can be combined with iDangerous swiper to achieve fully automated slide responsiveness?

To illustrate our problem, below two versions of our home page, first with slider revolution, second with our home-made js: (slider revolution) (homemade jquery)

And I do understand why our marketing prefers the first version. :slight_smile:

OK, perhaps we miss a duly qualified web-developer who would be able to make #2 look like #1 but we are a startup and that’s the constraints we have at the moment…

Have a good day!