I'm not sure if you are referring to the "Config file not found." message appearing in your Chrome browser or Lightroom's live preview window (or both).

If the error message appears in your Chrome browser, then please see this FAQ which refers to the error message and might help.
When I view my gallery I see the message 'Config file not found'. How do I fix this?

Also, if possible, please upload the gallery to your web server and post a link so that I can take a look at the problem for myself and hopefully help further. Once I am able to see your gallery and its code, I should be able to determine the cause of the problem and propose a solution.

If the error message appears in Lightroom's live preview window then the try forcing a refresh of the page (by pressing Cmd+R (Mac), Ctrl+R (Windows) or by selecting 'Web -> Reload' from the drop-down menu at the top) to see if this clears the problem without having to move away from the Juicebox web engine and lose your settings.

Over the course of a year and a half, only three other users have reported the "Config file not found." message appearing in Lightroom's live preview window. Two of these users are known to be using a Mac (the third user's system is unconfirmed) but I've never been able to replicate the problem myself on a Windows PC. From the limited information I have, it seems that the problem may affect only a limited number of Mac users.

Maybe my notes in these forum threads will at least help to explain this issue in greater detail:
https://juicebox.net/forum/viewtopic.php?id=2115
https://juicebox.net/forum/viewtopic.php?id=2249

As I mentioned in the forum threads above, the problem could be some kind of timing problem with the way that Lightroom generates the files for the preview (perhaps the 'config.xml' file is sometimes not ready in time for the gallery to be displayed by the 'index.html' file).
In the plugin's manifest file, the plugin requests that the 'config.xml' template be processed before the 'index.html' template so, unless there is some kind of threading issue or asynchronous activity (which, as far as I am aware, the plugin has no control over), I'm really not sure what might be causing the problem.

Please let me know if refreshing the live preview window when the error message appears (Cmd+R (Mac), Ctrl+R (Windows), 'Web -> Reload') helps.

You're welcome!

I'm glad you've found the cause of your problem, although deselecting the "Include xmp metadata in generated images" checkbox should not prevent an image from being processed and placed into the 'hi-res' output folder.
As the relevant post is already in jAlbum's 'Bug reports' sub-forum and the problem you reported is clearly the same as that of the original poster, I would normally suggest that you bump the post (it's not that old) and add your own notes to make your voice heard and to let the jAlbum developers know that there is at least one other user who is affected by the problem.
However, as the jAlbum team are removing the ability to generate 'hi-res' images in the next version of their program, I think it is highly unlikely that they will spend time and resources fixing a bug relating to a feature that will not be around for very much longer so there's probably very little you can do other than deselecting the "Include xmp metadata in generated images" checkbox (or adding you PNG files manually to the 'hi-res' folder after album creation).

Deselecting the "Include xmp metadata in generated images" checkbox just means that there will be no embedded data (at least not in XMP format) in the album images.
If all you want to do is display your images in a gallery, then there will be no functional problems at all.
However, some people might prefer their images to contain metadata (such as a copyright message and/or information about the image) but this has no effect on the visual quality of the images in the gallery or the functionality of the gallery itself.

I notice you use a galleryHeight of 50%.
This suggests that the gallery's actual height should be only 50% of the height of its parent container (and this would likely result in unwanted space).

Also, when using a percentage height, you'll need to make sure that all the gallery's parent containers have heights assigned via CSS, otherwise the browser may not be able to determine what the gallery's actual height should be. (The browser needs to know what the gallery's height should be 50% of.)

Additionally, you might need to take into account this note regarding Using Percentage Heights.

You might like to try setting your galleryHeight to 100% (so that you know that the gallery will always fill the height of its parent container) and then adjust the height of your gallery's parent container(s) as necessary.

Otherwise, to avoid the potential problems associated with using a percentage height, I'd recommend setting your galleryHeight to a fixed pixel value (such as 600px).
In doing so, you will have total control over the height of your gallery (you always know how high it will be), and being that your web page has a lot of vertical scrolling content, your gallery would not benefit from being responsive in the vertical dimension.
At the moment, the height of your gallery (and the amount of space above and below the main images) changes depending on the height of the browser window. I expect you probably do not want this to happen and a fixed height gallery would be the solution. (A vertically responsive gallery would really only be useful if your web page's content filled the browser window without any vertical scrollbars.)

Try using something like the following (adjusting it if necessary) and hopefully you'll be able to reduce the space surrounding your images.

galleryHeight: "600",

Facebook uses the data from Open Graph meta tags to populate the sharing window.

The thumbnail image displayed in the Facebook sharing window is determined by the og:image tag.
This specified image is displayed when any image in your gallery is shared.
You can think of the og:image as being representative of the gallery as a whole so you could use an image which best represents your gallery. (The og:image does not need to be an image from the gallery itself.)

When you create a Juicebox-Pro gallery with JuiceboxBuilder-Pro, Open Graph tags are included in the gallery's 'index.html' file (and the first image in the gallery is used as the og:image Facebook thumbnail).
The tags will looks something like this.

<!-- START OPEN GRAPH TAGS-->
<meta property="og:title" content="This is the Gallery Title." />
<meta property="og:type" content="website" />
<meta property="og:url" content="http://www.example.com" />
<meta property="og:image" content="http://www.example.com/images/IMG_0001.jpg" />
<meta property="og:description" content="This is the Gallery Description." />
<!-- END OPEN GRAPH TAGS-->

og:title uses the Gallery Title ('Customize -> Lite').
og:url uses the Share Url ('Customize -> Sharing').
og:image uses the Share Url and appends the relative path to the first image in the gallery.
og:description uses the Gallery Description ('Customize -> General').

If you embed your gallery into a custom web page (and do not use the 'index.html' file generated by JuiceboxBuilder-Pro), then you'll need to manually add an og:image meta tag to your web page. Please make sure that the content is in the form of an absolute URL (such as http://www/example.com/images/image.jpg) and not a relative URL.

If, after adding an og:image meta tag to your web page, you do not see the specified image displayed in the Facebook share window, then you might need to use one or more of the following online tools that Facebook provides.

(1) Facebook's Sharing Debugger: https://developers.facebook.com/tools/debug/sharing/
(2) Facebook's Batch Invalidator: https://developers.facebook.com/tools/d … ing/batch/
(3) Facebook's Open Graph Object Debugger: https://developers.facebook.com/tools/debug/og/object/
(Click the 'Fetch new scrape information' button.)

Running your web page's URL through these online tools should clear Facebook's cache of your web pages and fetch new scrape information from your gallery's web page.

Hopefully this will help.

I should also note that, unfortunately, there is a known issue whereby the error can be generated if the resize image dimensions are too large. This might be the reason for your problem.

The developers are aware of the problem and it has been logged as a bug so it should hopefully be addressed for a future version.
In the meantime, the only workaround is to reduce the resize dimensions until the error is no longer displayed.
I realise that this is not an ideal solution but, until the bug is fixed, there is no way around it (at least using JuiceboxBuilder-Pro).

I do not know the exact nature of the problem (why large resize image dimensions cause the error message to be displayed), but, having experimented with large images myself, the error seems to be triggered when the Max Width and Max Height both exceed a threshold value somewhere in the range of between 2364 and 2504.

If you need to create a gallery with images of a size that triggers the error, then the best course of action might be to do the following:
(1) Create a gallery with JuiceboxBuilder-Pro, using resize image dimensions that do not generate the error. This will at least generate a 'config.xml' file containing the imageURL entries.
(2) Create a set of images in a separate imaging program (such as Adobe Photoshop) at the required size and then copy them into the 'images' folder inside the gallery folder (overwriting the images originally generated by JuiceboxBuilder-Pro). Just make sure that the image filenames match the imageURL entries in the gallery's 'config.xml' file.

I understand that this adds extra steps to your workflow (and should not be necessary) but, until the bug is fixed, it might be the best option.

I hope this this at least helps to explain what you are seeing and provides you with a workaround.

OK, thanks.
If you still have problems, just post the link to your gallery and I'll take a look at it for you.

thumbsPosition is in the 'Thumbnails' section of the 'Customize' tab.
You need to be on the 'Images' tab (to the left of 'Customize') and then click the 'Change Sizes...' button in the 'Image Size' control panel (on the left side of the window). See the image attached.

If your have a full page gallery (i.e. it has dimensions of 100% x 100% and there is no other content on the web page), then the Expand Button will only be visible if you set useFullscreenExpand="TRUE" in JuiceboxBuilder-Pro's 'Customize -> Lite' section (for the gallery to expand to fill the user's entire screen). If useFullscreenExpand="FALSE" (the default value), then the gallery would expand to fill only the user's browser window (not the entire screen) and, as the full page gallery already fills the browser window, it would not be able to be expanded any larger so Juicebox hides the Expand Button.

If this does not explain what you are seeing, then please post the link to your gallery's web page so that I can see the problem for myself and hopefully help further. Thank you.

You can change the thumbnail dimensions using the thumbWidth and thumbHeight configuration options.
For reference, a list of all Thumbnail Options can be found here.

When creating a gallery with JuiceboxBuilder-Pro, you can set the thumbnail dimensions on the 'Images' tab. (Just click the 'Change Sizes...' button in the 'Image Size' control panel to reveal the input boxes.)
Thumbnails will be generated at the specified dimensions and the thumbWidth and thumbHeight options will automatically be set in the gallery's 'config.xml' file accordingly.

Alternatively, just set the thumbWidth and thumbHeight options in your gallery's 'config.xml' file to whatever values you like (instructions on how to set configuration options can be found here) and, when the gallery is displayed, Juicebox-Pro will dynamically scale the thumbURL images to fill the chosen dimensions. (Please note that if your thumbURL images do not have the same aspect ratio as that set by the thumbWidth and thumbHeight options, cropping will occur.)

I'm glad that clearing you browser's cache solved your problem.
Thank you for letting me know.

When I view your gallery's web page in a desktop browser, I see the thumbnail paging arrows being displayed (to the left and right of the thumbnails, centered vertically).
If you do not see this yourself, then try clearing your browser's cache before reloading the web page.
If you have made any changes to your gallery recently, your browser may still be using an older, cached version of your gallery's 'config.xml' file instead of the latest version from your web server.

@gfs

The issue reported above was addressed by the developers, confirmed as fixed (via email) by the original poster (robertcoldwell) and the bugfix was included in Juicebox v1.5.0 (which was released on 24 May 2016).

It certainly seems strange (though not impossible) that the problem would crop up again over a year later in a different version.

One thing I notice which could be causing layout problems is that there are several HTML errors on your web pages, including stray and unclosed <p> and <span> tags (and extra double-quotes alongside certain <div> attributes). Also, your gallery <div> containers are inside <p> tags. (A <p> element should not contain another block-level element such as a <div>.)

Try validating your gallery web pages with the W3C Markup Validation Service and fix the errors reported.
Once the code on your web pages validates correctly, the web pages should be rendered with greater consistency and predictability across different browsers and devices.

Unfortunately, I do not have access to an iPad Pro so cannot check your web pages in such a device myself.
If, after fixing the HTML errors on your web pages, you still see the problem, then I'll happily compile a report for the developers who will investigate further but it would help to have as much information about the problem as possible so please let me know the following (if you can).

(1) What version of iOS was the iPad Pro running?
(2) What browser or browsers (Mobile Safari, Mobile Chrome or any others) did you see the problem in?
(3) If you can gain access to the iPad Pro again, please provide a screenshot of the problem (and let me know which of your galleries it is from) so that we can see exactly what you are seeing.
(4) Also, if possible, please let me know if the problem occurs in any of our demo galleries here.

Thank you.