Thanks - I don't know why I would have two Wordpress installations... How would I check if that's actually the case? Or is the presence of the files enough to show that that is the case? I'm wondering if it was just a migration went awry that ended up copying some files into the wrong location, which are now being picked up since that location is higher in the queue (i.e., it checks public_html/ first, then public_html/wordpress/).

I think I just stumbled on the key to this puzzle... My Wordpress lives in the public_html/wordress folder, and so my plugins are in the public_html/wordpress/wp-content/plugins/ folder, including the newly upgraded wp-juicebox v1.5.1.4 (which is the version I see on my dashboard under Plugins). However, recently I was surprised to find out that I also have a public_html/wp-content/plugins/ folder with some plugins in it - I don't know why... Maybe it happened in the recent (automatic) migration? There are copies of some or all of my plugins there. I might have done this mistakenly myself? I don't know. There is an older wp-juicebox there v1.5.1.1.

Either way, when I made the change you asked for (in the former, more normal directory), nothing happened initially. Then I removed the wp-juicebox plugin from the latter mysterious folder and then... all galleries disappeared and instead of the galleries and not found error I just could see the shortcode as is - i.e., the plugin stopped working completely. Then I put the folder back, and went back to the situation I had before, where the old galleries work and the new ones give a not found error. So, I believe that the shortcodes are going to the oddly placed older wp-juicebox.

Once I determined that, I upgraded the mysteriously located wp-juicebox and uploaded the Pro jbcore folder. Then I edited the file as you suggested, and get this:
Juicebox Gallery path /home/u860466953/domains/inmagicland.com/public_html/wp-content/uploads/juicebox/203.xml cannot be found. BUT, that folder doesn't go via the wordpress/ parent folder, since that plugin is in wp-content/ and not in wordpress/wp-content/ (so it makes sense for that plugin I guess). As posted before, it should be going to the file that actually exists, at:
https://inmagicland.com/wordpress/wp-co … ox/203.xml

Then I tried deactivating wp-juicebox and uploading the new version zip with the pro jbcore by choosing "Add plugin" and uploading the zip. Now I have two v1.5.1.4 wp-juicebox plugins on my dashboard. If I activate the new one (in the more standard location), nothing works (I just see the shortcodes printed). I know it's the one in the odd location since this one doesn't have the edited code (your edit), whereas the other one does - and when I activate the "old" one, I see the not found message with the path (due to the new edit).

I also looked in my wp-content/uploads/juicebox/ folder and I see xmls going up to 192.xml. Whereas in my wordpress/wp-content/uploads/juicebox/ folder I see the new 203.xml as well. So, it seems that when I create a new Juicebox gallery, it puts the xml in the latter folder, but the plugin is looking in the former folder!

The question is, what to do now to make Juicebox work with both old and new galleries- ideally I would remove the wrongly placed one and then maybe everything would work via the correctly placed one. But as above - if I remove it, things break, since I guess something, somewhere, refers to that oddly placed plugin folder.

I was seeing it in the preview of a new post. In order for you to be able to see it, I've added that same shortcode to an existing post: https://inmagicland.com/2024/02/whistle … s-ladder/. At the end of the post you should see a working gallery (existing = old = was blank before but working now), and below it the message: "Juicebox Gallery Id 202 cannot be found."

I tried a few different things - including deleting the NextGEN plugin and reinstalling the same 3.59.12 version, removing and adding Juicebox galleries, re-scaning the folder for new images in NextGEN, re-saving a couple of NextGEN galleries and mysteriously all the black blobs (my old galleries) are showing up now properly!

However, still when I add a new Juicebox gallery it shows up as not found... This seems to be a different problem. Here's an example of a gallery that shows up as "not found" but the xml file DOES contain the test image I added (which wasn't happening with the blank galleries before): https://inmagicland.com/wordpress/wp-co … ery_id=201

Somehow through all this meddling I did get a gallery to work again. That's gallery 192. I tried doing what I described above with another gallery that isn't working, but it failed. That's the only gallery that actually shows up, the others are all black. That tells me though that there is a way to fix this. I'm on PHP 8.2 by the way. Wondering if upgrading PHP could have caused an issue. But again, given that one gallery is working, that makes me think that it can't be a systemic issue (?).

Thanks for the quick response. That's rather unfortunate, since that CSS snippet you posted is part of Jetpack, a rather popular plugin. I tried switching to a vertical image, but that doesn't work well either - it doesn't show the image on the splash page then on my laptop. Is there a particular size I should crop an image to, for it to definitely fit? That would be a bit cumbersome, but could at least solve the problem. Is there perhaps another solution that is more elegant? Changing the CSS of the plugin manually isn't ideal, of course, since it could have unintended consequences (as you mentioned), but would also get overwritten the next time I update that plugin.

Looks like the offending CSS is part of the Mobile module in Jetpack. Therefore, switching to a theme that is already mobile-ready (i.e responsive) could allow me to disable it, at which point the splash screen would hopefully not show a cropped image. A bit roundabout though...

For now, I have had to switch the gallery back to Simpleviewer, since the splash screen with the cropped image does not look good. I will only be able to use Juicebox if there is a reasonable solution to this issue.

Thanks for the quick response! Yes, that worked great. Would you consider adding control over this directly in the interface? I'm concerned that I'll forget to re-make the changes when I update. This could potentially be useful to others - one might want to show just the title/alt, just the description, both, or none. Thoughts?

PS: In the meantime I purchased the Pro version.