Adapting ShortcodeCarousel for homepage - or using bxSlider instead


I tried updating an earlier post about putting a slider/carousel on default page - but when I went to submit, it said the topic is closed (not sure whether due to a forum/blackout issue, or an etiquette issue - as it does not appear closed).

Anyway - the following logical extension of the suggested code works when inserted just before the Homepage Text in index.php of Berlin theme:
<p><?php echo $this->shortcodes('[featured_carousel autoscroll=true]'); ?></p>

So it does seem feasible that we could clone/extend/customise that plugin to cater for some extra requirements - such as using 'fullsize' instead of 'square_thumbnail', and displaying images that are either not defined in Items, or require special selection criteria beyond the carousel/featured/recent possibilities. Which leads to the following questions:

1) If we want our customised version of ShortcodeCarousel to co-exist with the original (which we might still use untouched on Simple Pages), can we simply clone and rename it - eg. change string "ShortcodeCarousel" to "ShortcodeCarouselMac1" wherever we find it?

2) Seeing that the Posters plugin appears to use "bxSlider", while ShortcodeCarousel uses "jCarousel", are you able to recommend which one might be better suited for a larger style slider/carousel on a homepage?

Thanks in advance for any suggestions...

For 1), it would mostly be just changing the names, as you describe. Of course, you'd also need to change the names of the shortcodes themselves when the plugin does add_shortcode(). But with just the name changes they should be able to coexist.

Then again, it might be worth suggesting pull requests to the original plugin's code that add the features you need:

Fullsize vs square_thumbnail would be an easy addition. It's hardcoded to square_thumbnails now because it's so easy to produce an ugly carousel without the consistency of the square thumbnail size.

Make sure you double-check the documentation of selection criteria, especially noting that all the options for the item shortcode are available for the carousel. If selection criteria beyond that are needed, that could also be a pull request.

Displaying images that aren't part of Items seems trickier, and might make more sense as a completely different shortcode, but one that might also make just as much sense as an addition to the plugin.

Note, too, that your theme should be able to override the carousel.php script that displays the carousel, if that's an approach that'd have some affordances you need.

For 2) I don't think that we have a specific recommendation -- it probably just came from which was easier to make work and look okay with the different kinds of content being displayed and what we were familiar with. Which one looks better will likely vary a bit with the details of what's being displayed (especially if you add in additional features)

Thanks very much for the prompt reply!
Agreed the carousel will not look great if the pictures are mismatched - but we would be aiming to prepare/crop around 6-7 pictures to be identical in size - so hoping that will work.

I did try collection= and tags= as selection criteria, placing the homepage pics into their own hidden collection. I had found that my preferred option (collection=) did not work, and looking now at ShortcodeCarouselPlugin.php it appears to not be catered for.
I will retry with tags=, and also see if ids= might be do-able (presumably item numbers are fairly static).

I will also try your idea of having a theme version of carousel.php which will override the supplied plugin version. Can you advise if that strategy should work more generally - ie. CSS and JS as well as PHP? We are very new to Omeka (and PHP!) here, and when wanting to change the look of the carousel we went to the plugin's CSS. It would be so much cleaner to make all our customisations in our theme.
With this "theme overrides plugin" approach we could also potentially cater for collections=, in which case most of our original concerns are handled.

PS: could you advise how to apply the markup in these forum entries? Is it just like html? I guess if this is bold then I will know...

Hmm....if by a 'hidden' collection, you mean that the collection and/or items are not public, then that might be part of the issue. If items are not public, then the usual access restrictions will apply. That is, if a user (or no user) can view the item, they won't be able to access the files for that item. Same will apply whatever strategy you try (tags, ids, etc).

Good question about the theme version. I don't think I've come across trying to override the CSS and JS, as well as the PHP. I'll experiment.

The theme override wouldn't be able to handle the collections= option passed in to the shortcode -- the item lookup happens before it gets to the theming (but check if the first paragraph above sheds light on how things work.)

Code can either follow HTML markup for what's allowed, but usually backticks work better.

I have a backtick before and after me!

Yep, looks like CSS overriding in the theme works, too. Just add a css file called carousel.css to your theme's css folder.

I got it to work using tags= rather than collections. Previously I was using featured_carousel so probably had them tagged but not featured which would lead to the empty slider.

Thanks for the warning about private/hidden items - I will be mindful of this now, as I tend to be changing and testing with super user still signed in - so need to check other access levels too.

So I will proceed with trying to get the homepage carousel looking how we want via theme code only.

Lastly - when you mentioned "suggesting pull requests" earlIer - were you meaning Git (which we are also using for the first time this semester)? As in we code and test our desired feature and propose it (via pull request?) for the core/Omeka repo?

Yep, the featured_carousel vs tags would make that difference.

And, I still sometimes mess up being signed in as super vs being anonymous user! Running two browsers often helps (and spots browser differences in CSS).

Yes, with the pull requests was suggesting Git and GitHub. Making a fork of the existing plugin and building desired feature, then propose it via pull request sounds like a good route. When doing pull requests, making them very concise and well-defined around single features will help us to decide whether it should be merged in, and make that merging easier.