PhotoSwipe renderer — CSS conflict + unnecessary jQuery dependency when combined with another PhotoSwipe integration

Hi Lefteris,

We're using Showtime Image Gallery (v1.10.1) on a Joomla 6 site that also has its own separate PhotoSwipe-based lightbox for regular article images (a custom system plugin, unrelated to Showtime). When a Showtime gallery (renderer: PhotoSwipe, layout: Wall) and one of our own popup images appear on the same page, we run into two issues:

1. CSS/icon conflict between two PhotoSwipe versions

Showtime's PhotoSwipe renderer bundles PhotoSwipe 4.1.2 (media/showtime/vendor/photoswipe/), while our own integration uses the current PhotoSwipe 5.x (ESM build). Both use the same .pswp/.pswp__* class names — that's expected, since it's PhotoSwipe's own convention — but the CSS rules and DOM structure differ significantly between the two major versions (e.g. v4's sprite-based icons via default-skin.css/png/svg vs. v5's inline SVG icons). When both stylesheets load on the same page, they visibly clash: broken/duplicated icons in both the Showtime modal and our own modal.

Would you consider updating the bundled PhotoSwipe renderer to the current PhotoSwipe 5.x release? That would align it with the version most sites are standardizing on now, and would remove the version-mismatch as a source of conflicts for anyone running a second PhotoSwipe integration alongside Showtime.

2. jQuery is loaded even though it isn't needed

We noticed plugins/showtime/photoswipe/photoswipe.php (initialize(), around line 24) unconditionally calls HTMLHelper::_('jquery.framework'), even though PhotoSwipe itself doesn't require jQuery. We checked all seven bundled renderers — they all make this same call, presumably copied across from the renderers that genuinely need it (Fancybox, Magnific, Swipebox). We also confirmed the "Wall" layout itself (macy.js) has no jQuery dependency at all.

For sites that have deliberately removed jQuery elsewhere, this means enabling the Showtime module reintroduces it — solely because of this one line, not because PhotoSwipe or the Wall layout actually need it. Would it be possible to drop the jquery.framework call from the PhotoSwipe (and lightGallery, which has the same situation) renderer specifically? That alone would let sites use Showtime with the PhotoSwipe renderer without pulling in jQuery.

Happy to provide more detail or test a patch if useful. Thanks for considering these!

Best regards,
Jip Jonker

Hi Lefteris,

Thanks for the quick and thoughtful response!

On the PhotoSwipe 4 vs. 5 question: I'd lean toward introducing v5 as a separate renderer rather than replacing v4 in place. The two versions are quite different in structure — v5 uses an ESM build with inline SVG icons and a different DOM layout, while v4 relies on a sprite-based skin and a jQuery-style initialization. Any Showtime user who has written custom CSS targeting the v4 DOM (e.g. .pswp__button--arrow--left + custom backgrounds) or custom JS that hooks into PhotoSwipe's v4 API would silently break on a direct upgrade.

A separate "PhotoSwipe 5" renderer entry keeps v4 working for existing installations, lets new users opt into v5 directly, and gives you a clean deprecation path for v4 when the timing is right.

The one thing worth noting for a v5 renderer: PhotoSwipe 5 expects to own the .pswp container and its CSS globally. If you bundle the v5 CSS inside Showtime's own stylesheet scope, it'll still conflict with any other v5 integration on the same page (including ours). Loading it as a separate asset that the browser deduplicates — ideally registered via Joomla's Web Asset Manager so $document->getWebAssetManager()->useStyle('photoswipe') prevents double-loading — would solve that cleanly.

Happy to test a dev build if that's useful.

Best regards,
Jip

Hi Lefteris,

Thanks for the update — good to hear you're already underway.

One thought on the Crop-vs-zoom issue: I'm not 100% sure this applies to your implementation, so take it as a suggestion rather than a fix, but PhotoSwipe 5 has a thumbCropped option that tells it the thumbnail is center-cropped (like object-fit: cover), and it adjusts the opening/closing animation to start from the correct visible sub-area instead of assuming the thumbnail matches the full image.

If that works as I understand it, it might let you keep the zoom animation for Crop thumbnails too, rather than falling back to fade across the board. Worth a quick look before you finalize the approach — but if you've already considered it and fade is simpler/more reliable, no strong opinion from my side.

Best, Jip

Hi Lefteris,

Thanks for the update — I tested v1.11.0 on our site (Showtime gallery combined with our own PhotoSwipe 5 lightbox plugin on the same page) and can confirm the original CSS conflict is resolved.

With the renderer set to PhotoSwipe 5, the gallery now loads only PhotoSwipe 5.4.4 assets — no v4.1.2 files, and no jQuery at all. I also tested a page with both a Showtime Wall gallery and a separately-triggered PhotoSwipe 5 lightbox (our own plugin, unrelated to Showtime) — both work cleanly side by side, no broken/duplicate icons, no console errors.

One small note, not a bug on your end: on our test page the gallery was rendered through a Joomla module instance, which turned out to have its own separate "Renderer" setting, independent from both the item-level display setting and the extension's global default. Took me a moment to find — worth keeping in mind if other users report "I changed the renderer but nothing happens." ;-)

Thanks again for the quick turnaround on this.

Best,
Jip