I can see why your gallery is blank but I do not know what caused it.

If you check out the XML configuration file for gallery #191: https://inmagicland.com/wordpress/wp-co … ery_id=191
... you'll see that it has no image information at all (just gallery configuration options).

The 'juicebox.js' JavaScript file is being loaded in your page OK, the gallery's embedding code is present and correct in your page and the gallery's XML configuration file is being generated OK but the images are not being picked up.

WP-Juicebox uses another XML file (where the image source is stored) to generate the actual XML configuration file that Juicebox uses to display the gallery.
You can find the corresponding XML file for gallery #191 here: https://inmagicland.com/wordpress/wp-co … ox/191.xml
(The fact that the file exists is the reason why the gallery listing shows up in the Manage Galleries page.)

You'll see the entries e_library="nextgen" and e_nextgenGalleryId="215", telling WP-Juicebox to create a XML configuration file containing all the images from NextGEN gallery #215.
I'm guessing that there's a problem with either:
(1) WP-Juicebox being unable (for some reason) to fetch the images from NextGEN gallery #215.
... or:
(2) NextGEN gallery #215 contains no images (for whatever reason).

WP-Juicebox seems to at least be creating and embedding all the files the gallery needs. The problem seems to be that it can't fetch or find the images from your NextGEN galleries.

Gallery #192 seems to be suffering from the same problem as gallery #191; all the required files are there but there is no image information in the XML configuration file.

I know this does not directly resolve your problem but I hope it's at least a first step in the right direction towards finding the cause (and it should hopefully let you eliminate some potential problems).

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 (?).

Yes, I was actually already using 3.59.12, not sure why I wrote 3.9 - that was just from memory. I tried upgrading to 4.1.3, adding a new Juicebox gallery and then using it in a post and still it shows as not found.

I don't know why it's happening but there is no WP-Juicebox XML settings file for gallery #201: https://inmagicland.com/wordpress/wp-co … ox/201.xml
... which results in a completely empty gallery XML configuration file: https://inmagicland.com/wordpress/wp-co … ery_id=201

Unfortunately, I'm no further forward in figuring out what is going on.
All I can say with any certainty is that new galleries are displaying as expected in my own setup so the combination of WP-Juicebox 1.5.1.4 and NextGEN 4.1.3 ought to work in your own setup, too.

If I can think of anything else that might help (or anything else that you could check that might point us in the right direction), I'll be sure to post back here.

It was blank when I checked it. I guess you must have deleted the gallery by then.

Where exactly are you seeing "Juicebox Gallery Id 202 cannot be found."? Is it in the admin section or the gallery's page? If it's the gallery's page, could you please provide a link to it so that I can see the problem for myself? I'm not sure it will help but it might.

Thank you.
Here's what I can deduce from this:

(1) The shortcode itself is fine, otherwise WP-Juicebox wouldn't recognize it and go looking for a gallery.

(2) The shortcode handler can extract the gallery ID fine (as it forms part of the error message).

(3) The problem seems to be with the shortcode handler creating the full path to the '202.xml' file and confirming that it is an actual file. Why this happens sporadically and not consistently across all galleries is a mystery to me at the moment (as the '202.xml' file is present and correct on your web server and the 'config.php' file finds the '202.xml' file without any problems and dynamically generates the gallery's XML data fine).

One thing I noticed in my investigations was that you seem to be using WP-Juicebox v1.5.1.1 and not the current version v1.5.1.4.
I don't know if it will resolve your problem but I'd certainly recommend upgrading.
WP-Juicebox is not in the official WordPress repository so you'll not be able to upgrade it on the 'Plugins' page.
Instead, you'll need to download it from here: https://juicebox.net/support/wp-juicebox/
... and follow the installation instructions (overwriting your existing WP-Juicebox plugin files).

I'll keep my fingers crossed that this helps.

I don't see any obvious problem with the code and I cannot replicate the problem which makes troubleshooting difficult.

The next step would be check where your setup is looking for the gallery #203 file.
This would confirm whether or not the internal path is correct.
If the path is OK, then the next step would be to figure out why the file check is failing.

Some modifications to the 'wp-juicebox.php' file will be required.

Open 'wp-juicebox.php' (from 'plugins/wp-juicebox/') and change the error message on line 375 from:

return '<div><p>Juicebox Gallery Id ' . $clean_gallery_id . ' cannot be found.</p></div>' . PHP_EOL;

... to:

return '<div><p>Juicebox Gallery path ' . $gallery_filename. ' cannot be found.</p></div>' . PHP_EOL;

This will print the full path to the gallery XML file rather than just the gallery ID in the error message.
We can then see if the path is correct.
Please let me know what the error message now says with this modification in place.

If the path looks correct, then the only other reason for the shortcode handler to fail would be if the path fails the PHP is_file() check. (There are many instances of this function throughout the source code so if your PHP installation has any problem with this function, I would expect the plugin to fail in other areas, too.)

N.B. The line number refers to WP-Juicebox v1.5.1.4.

I also verified that if I download 203.xml and upload it to public_html/wp-content/uploads/juicebox/ then the new gallery 203 works. So, if I could just get new juicebox galleries to route their xmls to the latter folder, I suppose I could just keep going with wp-juicebox in the non-standard location, and all galleries would work. I would have thought that with juicebox active in the non-standard location, it would create gallery xmls in that location, especially since that is where it goes looking for them...?

I've just noticed that going to:

https://inmagicland.com/wordpress/2024/02/whistler-spankys-ladder

... redirects to:

https://inmagicland.com/2024/02/whistler-spankys-ladder/

... i.e. there's a redirect from one WordPress account (the one with /wordpress/ in the path) to the other.

If you remove the redirect (which might be in a .htaccess file or a setting in your web hosting account's control panel), this might help to disentangle your two WordPress installations.

I can't think of any other reason why one WordPress installation would save files to the uploads folder in another WordPress installation which, by all accounts, it should not even know about.

I think the root of the problem could either be that both WordPress installations are sharing the same database or that the redirect is causing problems in the admin sections of your sites.

If you think a migration might have gone awry, then maybe your web how would be best suited to help you resolve this.
If you don't remember installing WortdPress twice (in two different locations), then it's quite possibly a migration problem.

You certainly seem to have two different login URLs:

• https://inmagicland.com/wp-login.php

• https://inmagicland.com/wordpress/wp-login.php

... which suggests to me that you have two different installations.

Your current redirect ensures that the site seen by the public is always the root directory site (not the /wordpress/ one).
This suggests that it's the root site that you should be using but I don't know which one you've recently been logging into.

Unfortunately, I have no knowledge of the history of your site (whether a second installation was intentional or a migration ever took place) or access to your web server.
With this in mind, I think your web host would be better placed to help you untangle things.

Here are a couple of things you could check to see if things make sense:

(1) Check /wp-config.php and /wordpress/wp-config.php to see if both installations are using the same database and/or table prefix. Look for:

define('DB_NAME', ...);
$table_prefix = 'wp_...';

(2) Check /wp-config.php and /wordpress/wp-config.php to see if the path to the content directory (the parent directory for the uploads directory where Juicebox stores its XML files) is explicitly defined. Look for:

WP_CONTENT_DIR

In a regular installation, this constant will not be present (and WordPress will just use the default value of ABSPATH . '/wp-content'). However, the path can be overridden with WP_CONTENT_DIR so it might be interesting to see if one installation has an explicit entry for WP_CONTENT_DIR.

You might be able to 'fix' your problem by setting a WP_CONTENT_DIR in the wp-config.php file in one of your installations to force a certain content directory to be used.
e.g.

define('WP_CONTENT_DIR', $_SERVER['DOCUMENT_ROOT'] . '/wp-content');

... or:

define('WP_CONTENT_DIR', $_SERVER['DOCUMENT_ROOT'] . '/wordpress/wp-content');

However, with your two installations seemingly intertwined, I don't know which installation you should target for this 'fix' or which path to use.
(Also, I put 'fix' in quotes as this is more of a potential workaround than a true fix as, under normal circumstances, you shouldn't need to define a WP-CONTENT_DIR and you'll still be left with two installations on your server.)

Maybe you'd get more specialized help from a WordPress forum or more knowledgeable support from your web host (as they will have access to everything and might have been involved in the installation and/or migration). These are avenues I'd certainly explore.

Incidentally, there won't be a queue. There will be one content directory specified per installation and either it will be used or saving content will simply fail. As noted above, the default path will be used unless WP_CONTENT_DIR is specified.