The widely used Apache web server maps http://[host]/~[user]/[path] to a root in user's home directory, e.g., ~[user]/public_html/[path] (the Mac uses "Sites" rather than "public_html"). This is typical for a multiuser installation such as a university or a PC potentially shared by several users. It circumvents the problem that you can't give everybody access to the web server's own file structure and you don't want to explicitly upload using something like FTP.

My "localhost" is a Mac which keeps a user's web pages in ~/Sites. I tried the download button of JB 1.5 to download from my own site and got a file IMG_3130.jpg.html with a PHP error message:

Warning: readfile(/Library/WebServer/Documents/~axel/at/2016/01/images/IMG_3130.jpg): failed to open stream: No such file or directory in /Users/axel/Sites/at/2016/jbcore/juicebox.php on line 21

The script ought to have looked in /Users/axel/Sites/at/2016/01/images/IMG_3130.jpg, i.e., in the user's tree, not in the web server's tree.

The error disappeared.

I created a test with an embedded gallery and essentially no scripting. I evolved that into the code which failed (served from Google Drive) before, but checked at each step that the code wasn't failing on iOS (or elsewhere, for that matter).

Since this is a boilerplate for several galleries, finally, I copied the boilerplate into the two directories (2014 and 2015) which failed before. Both are now happy in iOS and elsewhere.

I did tweak the code here and there; however, positively the only interaction between my embedding code and jbcore is the configuration options hash. Previously, the hash contained only entries which differed from your default. However, since I want this hash to be the default for all embedded galleries together, I now set ALL entries, either to the default value, or to to the values for which I want to set my own default. (No, I'm not going to take the defaults out again for more testing...)

Thanks for your help!

I traced things a bit (hard to do because your code is obfuscated):

The error 400 happens in response to your code loading jbcore/full.html once the button on the splash page is pressed.

If I use the relevant URL directly, I get a complaint that there is no config.xml (and indeed, there is not).

Which means that your code loads full.html and config.xml relative to two different base directories.

Once the error 400 has happened, Safari appears to cache the response and the error appears all over.

I'll simplify my code but I can't see how my code can corrupt a URL generated by your code.

<http://schreiner-family.net/at/2014/index.html> switches between several embedded galleries. This works just fine if there is no splash page, or with a splash page if it is NOT hosted on Google Drive.

However, the site is actually hosted on Google Drive, i.e., the URLs are quite lengthy.

If there is a splash page (e.g., when the site is viewed from an iPhone, or if ALWAYS is set for displaying the splash page) and the splash button is clicked, Google (i.e., the web host) responds with error 400 and complains about an ill-formed request.

I'm afraid the request originates in JuiceBox's code...

I tried once more. Here is what seems to work:

(a) use the plugin to create a gallery with the 'large' picture size 2048x1536 (in Output Settings in Lightroom's Web mode).

(b) use JBB and open this gallery.

(c) use the Change Sizes... panel in JBB and check large and small sizes. [I also changed the small size to 640x480 and thumb quality to 80.]

(d) finally, do a Save in JBB to write the gallery back into the same location.

This moves the original images in the gallery (from step (a)) to a 'large' subdirectory and populates the 'images' directory with 1024x768 images and the 'small' subdirectory with 640x480 images.

---

It turns out that if you do the exact same thing with the gallery on a network volume (i.e., the Sites folder of a server Mac connected as Shared) all images are simply destroyed. (No error message...)

If you save it to a new directory on the network volume everything gets created.

Sigh...

It's not documented -- but now it is. Thanks!

Ok, so the problem seems to be that first the 'Change Sizes' panel inserts something into presets, but is a preset is loaded afterwards (through the next JBB screen) it silently kills off the change made earlier. Probably not good?

But it is worse: I opened a gallery made by the plugin (i.e., without sizes). I loaded the preset without the sizes. I went back to the size panel and changed the sizes. I saved the preset:

    thumbWidth="64"
    thumbHeight="64"
    thumbQuality="80"
    useLargeImages="true"
    useSmallImages="true"
    smallImageWidth="640"
    smallImageHeight="480"/>

And I asked to publish the gallery to a new folder. Unfortunately, the images were copied unchanged from the old to the new gallery and no larger/smaller folders even appeared. And config.xml is a bit confusing:

    thumbWidth="64"
    thumbHeight="64"
    thumbQuality="80"
    useLargeImages="true"
    useSmallImages="true"
    smallImageWidth="640"
    smallImageHeight="480"

>
  <image imageURL="images/IMG_1990.jpg"
    thumbURL="thumbs/IMG_1990.jpg"
    linkURL="images/IMG_1990.jpg"
    linkTarget="_blank"
    sourcePath="/Volumes/ats/Sites/NZ/etc/01_start/images/IMG_1990.jpg">
    <title><![CDATA[]]></title>
    <caption><![CDATA[Early at JFK]]></caption>
  </image>

At least the browser won't ask for images which do not exist...

Seems to me that the problem is that you do not write the default to config.xml:

If the background color is set to 'transparent' in the constructor call

          box = new juicebox({ backgroundColor: 'transparent', ... });

and there is no expandedBackgroundColor in config.xml you are at the mercy of the browser as to full screen.

Actually, even if the images are used in a totally new gallery (by dragging them into JBB) 'large' and 'small' are still not populated.

I'm trying to get multiple image sizes and I'd like to use Lightroom to manage my galleries.

Unfortunately, the plugin doesn't support the multiple sizes. Therefore, I export my gallery using the plugin, open it in JBB (in order to preserve the order of images, independent of the file names), and export again to a different place to get the multiple sizes.

In the process, JBB will apply sizes and perhaps configurations.

There is no preset for the sizes (duh! the plugin does not know about them) and editing all the numbers each time is no fun if you have several galleries.

To add insult to injury, when I change sizes and apply a configuration preset, JBB displays that it does some 'processing' but in the end during Publish simply copies the images from the old to the new gallery, adding folders large and small but not populating them.

If I load a preset for the configuration, I have issues with expandedBackgroundColor -- the plugin exports black/1 whereas (as reported in another post) JBB does not.

Seriously?

The defaults for backgroundColor and expandedBackgroundColor are black with opacity 1. JBB does not write the defaults into config.xml.

The real backgroundColor and expandedBackgroundColor seem to result from the backgroundColor and expandedBackgroundColor components of the constructor call -- in your case it is something like #222222, i.e., very dark.

If I set the component to be 'transparent' to defer to CSS for the (embedded) gallery I get, e.g., a white background in embedding.

I'd like my fullscreen version to use a black background and therefore assume that if expandedBackgroundColor is set to black and 1 I will get just that.

Unfortunately, the default is not in config.xml and the fullscreen expansion ends up white, apparently taken from the embedded gallery.