It's a long shot but it could be due to corrupt or missing Microsoft Visual C++ Redistributable files.

Try downloading and installing the latest Microsoft Visual C++ Redistributable files from here: https://learn.microsoft.com/en-us/cpp/w … le-version

Pick both the x86 and x64 versions (JuiceboxBuilder-Pro is an x86 application).

Thank you for posting the Event Viewer logs.

Looking solely at the logs, I'd try uninstalling and reinstalling Adobe AIR (making sure to use v33.1.1.744).
The weird thing is that you say JuiceboxBuilder-Lite runs OK (which suggests that your AIR installation is OK).
I'd still try uninstalling and reinstalling Adobe AIR, though.

Just so I can be clear on what you've already tried:

(1) Do you use any anti-virus software and were you able to completely disable it when trying to run JuiceboxBuilder-Pro?

(2) Were you able to locate and manually delete all of the following folders between uninstalling and reinstaiing JuiceboxBuilder-Pro?

• C:\Program Files (x86)\JuiceboxBuilder-Pro

• C:\Users\Username\AppData\Roaming\Adobe\AIR\ELS\JuiceboxBuilder-Pro

• C:\Users\Username\AppData\Roaming\JuiceboxBuilder-Pro

• C:\Users\Username\Documents\JuiceboxBuilder-Pro

Also, is there anything odd going on with your system's Documents folder? Have you renamed it or moved it from it's default location? Is it actively being synced by an online backup of file-sharing service (such as Dropbox, Google Drive or OneDrive)? If so, try temporarily disabling the service to see if this helps.
Any problem with the Documents folder might prevent JuiceboxBuilder-Pro from initializing it's own temporary work folder.

This is certainly unusual (especially as JuiceboxBuilder-Lite continues to function correctly) and, unfortunately, I'm not sure what might be causing it.

The first thing I should mention is that JuiceboxBuilder-Lite and JuiceboxBuilder-Pro can be installed and run side-by-side on the same computer without any problem, so JuiceboxBuilder-Lite should not be interfering with JuiceboxBuilder-Pro in any way.

JuiceboxBuilder-Lite and JuiceboxBuilder-Pro also share a lot of the same code so it's strange that one would work while the other does not.

I'd try a complete uninstall and reinstall of JuiceboxBuilder-Pro to see if this helps.
Follow the uninstall procedure noted as #11 in this forum post: https://juicebox.net/forum/viewtopic.ph … 453#p17453
If JuiceboxBuilder-Lite runs OK, you can skip steps 3, 4 and 5 (uninstalling and reinstalling JuiceboxBuilder-Lite and Adobe AIR) but be sure to manually delete any and all folders corresponding to JuiceboxBuilder-Pro after running the uninstaller (details in link above).

If this does not help, then you might need to dig a little deeper to figure out why JuiceboxBuilder-Pro is crashing.

Do you have any anti-virus or security software installed? If so, try temporarily disabling it to see if this helps. (Microsoft's own virus and threat protection should be fine but other third-party programs can be very aggressive with their detection sometimes resulting in false positives.)

Also, check the Windows Event Viewer immediately after the crash to see if anything is logged in the 'Windows Logs -> Applications' or 'Windows Logs -> System' sections which might point you in the right direction.
(Check the exact time of the crash and look for entries in the Windows Event Viewer with the same timestamp.)

I hope this helps.

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.

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.

I see the filename in both Firefox and Chrome.
If you are not seeing the same thing in both browsers, then try clearing your browsers' caches and reload your web page.

The filename is the image's 'Title' rather than its 'Caption' (Juicebox terminology) and, as the gallery is a NextGEN gallery, the 'Title' is being pulled from the NextGEN 'Alt Text' rather than the NextGEN 'Description' (which is used for the 'Caption').

If you don't want the image filenames to appear, edit the images in your NextGEN gallery and remove the 'Alt Text' entries.
You might need to clear your browsers' caches after making any changes.

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 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.

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

I'm glad to hear you've managed to resolve your problem.
Thank you for posting back to let me know. It's most appreciated.
Best wishes!

Maybe you're just seeing the Splash Page (see here for details and scroll down).
The Splash Page is an image placeholder for the gallery which, when clicked, will expand the gallery to fill the browser viewport (to give the gallery as much room as possible).
By default, the Splash Page will be displayed on mobile devices when a gallery is embedded in a web page alongside other content (where the gallery might be too small to use). By default, Juicebox uses the first image in the gallery as the Splash Page image (and crops if necessary). You can change this if you like via the splashImageUrl option (in JuiceboxBuilder-Pro's 'Customize -> Splash Page' section).
You could also choose to not use the Splash Page at all by setting showSplashPage="NEVER".
Please note that these are Pro options (not available in Juicebox-Lite).

Also, if you are using a fixed value for your galleryWidth, try using a percentage instead (e.g. 100%).
However, please be sure to set widths for all parent containers using CSS so that your browser knows what the gallery's width should be 100% of.

Unfortunately, WordPress changed some of their internal code which now prevents the 'Add Juicebox Gallery' button from appearing in the Gutenberg editor.
With an update to WP-Juicebox unlikely, the best solution would be to create the gallery on the 'WP-Juicebox -> Manage Galleries' page and then copy the shortcode (provided on the 'Manage Galleries' page after creating a new gallery) into your page or post.
This should still work fine.