There should be no problem with the Button Bar icons as long as the 'jbcore' folder is intact and the 'juicebox.js' file is successfully loaded into the web page. The location of the files should not make a difference (as long as all the paths are correct).

There is clearly no problem with the Juicebox font files or server MIME types as the Button Bar icons displayed fine in your original configuration.

This leads me to think that the problem might be a caching issue (either browser or server side) as the problem seems to happen after you move a file and change a path.

I can't quite figure out exactly what's happening but try the following:

(1) After moving the file and changing the path, try completely clearing your browser's cache before reloading your web page to see if this helps. If browser caching is the cause of your problem, then it is very unlikely that visitors to your website will experience the problem as browsers tend to check for newer versions of files on each browser session.

(2) After moving the file and changing the path, try (temporarily) renaming your 'projext x' folder (this should not break the gallery as long as the path to the 'juicebox.js' file from within the 'index.html' page is relative) and then reload your web page. This will create a completely new unique path to your web page that neither your browser nor your server will have seen before so there should be no strange caching going on. If you find that server caching is the cause of your problem, then ask your web host if they could turn off server caching on your web hosting account.

I hope this helps and points you in the right direction.

If you continue to experience difficulties, please post the link to your web page so that I can see the problem for myself and hopefully help further.

You're welcome!

Temporarily turning off Bitdefender whilst installing JuiceboxBuilder-Pro (or making an exception in Bitdefender for the 'JuiceboxBuilder-Pro.air' installation file) would be the first thing I'd try.
Hopefully this will resolve your problem and allow you to successfully install JuiceboxBuilder-Pro.

You're welcome!
I hope you get on OK.
If you run into any difficulties, please let me know and I'll do my best to help you out.

You're welcome!

If you want to build a new website around Juicebox galleries, then you might like to take a look an another one of our products, Showkase, which allows you to create a complete HTML 5 portfolio website.

Showkase is a PHP web application which in installed on your web server and whose interface is accessed via a web browser.
Showkase has full support for Juicebox-Pro and the galleries can be created within the application itself via its interface (or created with JuiceboxBuilder-Pro and imported).

You can create Gallery Index pages and have as many galleries listed on each Gallery Index page as you wish.
Each gallery is represented by a thumbnail image with the gallery title displayed below and the gallery is opened when the user clicks on the image.
Demo sites created with Showkase can be found here and a sample Gallery Index page can be found here.

Showkase can also create non-gallery pages (About, Basic and Contact pages) where you can add information about yourself (or any other content you like).
All of this is done automatically within the Showkase interface without the need for any manual coding at all.
You can take a look around the Showkase interface by logging into the Live Demo Admin.

Showkase can be purchased as Showkase-Standard (which comes with Juicebox-Lite) or Showkase-Pro (which comes with Juicebox-Pro).
The only difference between Showkase-Standard and Showkase-Pro is the bundled viewer (Juicebox-Lite vs Juicebox-Pro).

Alternatively, as you have already mentioned WordPress, you might like to try using WordPress to create your website.
There is a dedicated Juicebox plugin for WordPress, WP-Juicebox, which allows you to create and embed Juicebox galleries in WordPress pages and posts without any manual coding.
WordPress can quite easily be used to create a complete website (it is no longer just the blogging platform it started out as) although it it by no means as Juicebox-centric as Showkase.

Under the HTML 4.01 Transitional Doctype, there are certainly fewer errors and warnings for your web page than under the HTML 5 Doctype (which makes sense, knowing that your code is quite old). As before, many of the errors are trivial and will not actually cause any problems when your web page is viewed in browsers.
For example, just add an alt="image" attribute to all the <img> tags on your page and a type="text/javascript" attribute to all the <script> tags on your page and that will fix 7 of the errors straight away.

No problem. I'm glad my suggestions worked.

Both your images have exactly the same aspect ratio so they will both be scaled similarly for the Splash Page.
When the image is displayed in the gallery, it is dynamically scaled down to fit within the image area, respecting its aspect ratio and without any cropping (so the top and bottom of the image are flush with the top and bottom of the gallery and there is space to the left and right of the image which cannot be seen as you have a transparent background).
When the image is used for the Splash Page, Juicebox scales the image to ensure that there is no empty space (so the left and right sides of the image are flush with the left and right sides of the gallery and the top and bottom of the image are cropped as it is vertically centered).
You'll need to provide an image which has the same aspect ratio as your gallery (270:400 -> 1:1.48) if you do not want the Splash Page image to be cropped.
You could either reduce your image's height (by cropping the bottom of your image yourself), or increase your image's width (padding the left and right sides with blank space by increasing the canvas area).

I hope my notes above are helpful.

Thank you for the update.

Just for clarification, the sourcePath is used only internally by JuiceboxBuilder-Pro (when editing a gallery). It is not used by Juicebox when the gallery is displayed.
JuiceboxBuilder-Pro stores the original paths of the source images (as sourcePath entries) in case it needs to re-process the source images (for example to remove watermarks).
The images displayed in the gallery are the imageURL and thumbURL.

The %20 indicates that the image has (at one point or another) had a space in the filename (%20 is the percent encoding for a space).
As an image filename forms part of a URL when uploaded to a web server, it would be wise to use only web-safe characters within image filenames. Please see section 2.3 of this document for details.

JuiceboxBuilder-Pro can handle all images whose filenames use any or all of these unreserved characters.

This sounds more and more like there's a lock on certain gallery files preventing JuiceboxBuilder from re-saving the entire gallery. Unfortunately, I still do not know what might be causing this although it's certainly not a widespread problem as you are the first person to report it (as far as I can remember) which suggests that there may be something unique to your own computer which might be at the root of the problem.

Try using only files with web-safe filenames to see if the problem continues to occur.

I really do not know why Juicebox is unable to display your gallery images after you edit a gallery.

It is not something that I have been able to replicate. I have never seen this before and, as far as I can recall, no-one else has reported such a problem so the cause might be something unique to your system or setup.

As I suggested a couple of posts ago, maybe you could provide me with a couple of sample zip files: one of your gallery folder before editing and another of your gallery folder after editing. Once I'm able to compare the two versions of your gallery folder, I might have a better understanding of why you are unable to see your gallery images after editing.

The file-lock/auto-backup scenario might still be playing a part in the problem.
Try temporarily turning off your auto-backup program (or at least make an exception for the location of your gallery folder so that your auto-backup program does not interfere with it) to see if this makes a difference.
Also, make sure that the location you use for your gallery folder is not synced to a cloud backup service (such as Dropbox or Google Drive).

To clarify, after editing an existing gallery, JuiceboxBuilder-Pro will resave the entire gallery but, if all you do is change some configuration options (and do not add or remove any images), then the only file you need to reupload to your web server is the gallery's 'config.xml' file.

That's great! Thank you for letting me know.

I've taken a look at the validation errors from your web page.
Many are trivial (for example, missing 'alt' attributes from <img> tags) and won't actually cause any problems.
However, with so many 'obsolete' errors under the HTML 5 Doctype, your web page might actually be better suited to the HTML 4.01 Transitional Doctype (unless you plan to tackle the errors and replace your web page's table layout with CSS instead).
Try replacing:

<!DOCTYPE HTML>

... with:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
   "http://www.w3.org/TR/html4/loose.dtd">

... to see if your web page validates under this Doctyle with fewer errors. (Run your web page's URL through the W3C Markup Validation Service again after changing your web page's Doctype.)

Please see this FAQ:
How do I allow or prevent users from saving gallery images?
As noted in the FAQ, it is not possible to right-click on a Juicebox gallery so visitors to your website will not be able to right-click an image as select 'Save Image As...'. If you set showOpenButton="FALSE" (in JuiceboxBuilder-Pro's 'Customize -> Lite' section) and showDownloadButton="FALSE" ('Customize -> Button Bar'), then the Open Image and Download buttons will  not be displayed on the gallery's Button Bar. Also, you might like to watermark your images (to deter visitors from taking screenshots of your gallery). Please see the short Adding Watermarks support section for details.

No. The Juicebox branding (the Juicebox badge/link in the lower-right corner) is present only in Juicebox-Lite galleries.

Your 'stylesheet1.css' file has an invalid CSS 'color' property (assigned to the wrong element).
Remove:

color:eecc00;

... from line 30, in this section:

#toolbar {
    font:normal 17px palitoy;
    color:eecc00;
    margin:0;
    padding:0;
}

... and add the following to your 'stylesheet1.css' file (just below the section above would be fine):

#toolbar a {
    color: #eecc00;
}

This should fix your link color problem.

What you are describing is the caption area (with a gradient background and displaying the image number).
You can disable to entire caption area by setting captionPosition="NONE" ('Customize -> Caption').
Configuration options which can be used to customize the caption area can be found in the Color and Caption sections.

What you are describing is the Splash Page.
The Splash Page is a placeholder for the gallery which is displayed by default on small screen devices when the gallery is embedded in a web page alongside other content (rather than displayed on a page of its own with dimensions of 100% x 100%, filling the browser window) and may may too small to be usable.
The Splash Page is essentially an image link for the gallery which displays an image (by default, the first image in the gallery) and some text.
When the user clicks or taps the Splash Page, the gallery is expanded to fill the browser window (giving the images more space to be displayed).
When the gallery is expanded in Small Screen Mode, the user is presented with a page of thumbnails from which a main image can be selected. When a thumbnail is clicked, the thumbnail page is replaced with the chosen image. (In Small Screen Mode, the thumbnails and main images are displayed on different pages to maximize the area available for the images on small screen devices.) The user can return to the thumbnail page via the Thumbnail Button on the gallery's Button Bar.
More information about the Splash Page can be found in the Screen Modes section of the Gallery Tour.

By default, the Splash Page uses the first image in the gallery and scales the image to fill (rather than fit within) the Splash Page (which uses the gallery dimensions). If the image does not have the same aspect ratio as the gallery/Splash Page, then cropping will occur (as you have discovered).
There is no way to change the scaling behavior for the Splash Page image but you can choose an image to be used for the Splash Page via the splashImageUrl configuration option.
The splashImageUrl can be an absolute path or a relative path (relative to the web page containing the gallery's embedding code).
The splashImageUrl does not need to be a gallery image so you could perhaps prepare an image that represents your gallery and looks better at the gallery/Splash Page dimensions.

You can choose to not use the Splash Page by setting showSplashPage="NEVER" ('Customize -> Splash Page' section). Using this setting, the thumbnail page would initially be displayed instead of the Splash Page on small screen devices.
Alternatively, you could force the gallery to be displayed in Large Screen Mode (which, by default, does not use the Splash Page) on all devices and in all browsers by setting screenMode="LARGE" ('Customize -> General').

For reference, all the Splash Page configuration options can be found here.

Just to clarify, imageScaleMode changes only the scaling of the main image within the gallery's image area.

I hope these notes help.

@cwnicholls

Many thanks for all your suggestions.

Here's a little feedback on some of your most recent posts which might be of interest to other users reading this thread.

It is true that there is no progress bar or indication of when the saving process has finished but, when saving a gallery on the 'Publish' tab, the process should not take long at all.
The procedure that takes the longest time to complete is the resizing of the images and this is done when the images are added to the gallery on the 'Images' tab. (There is a progress bar for this, letting you know how many images have been processed and how many there are in total.) All that remains when the 'Save' button is clicked is to write the 'config.xml' file, add the custom embedding code to the 'index.html' file and move the resized images (and copy the 'jbcore' folder) to the specified folder.
You can always click the 'View in Browser' checkbox on the 'Publish' tab and JuiceboxBuilder-Pro will display the gallery (from the gallery folder) when the gallery is ready.

This is, indeed, a bug (thank you again for reporting it).
I have notified the developers and they will certainly investigate further (and hopefully fix the issue for a future version).
In the meantime, as I mentioned in this thread, the only workaround I've found is to rotate images (if necessary) in a third-party imaging program (such as Adobe Photoshop) before feeding them to JuiceboxBuilder-Pro.

Some programs use the EXIF orientation tag (and display the image in the orientation specified) and other programs do not.
JuiceboxBuilder-Pro is one such program that does not use the EXIF orientation tag, so, if anyone experiences difficulties with image orientation in JuiceboxBuilder-Pro, one possible workaround would be to re-save the image in an imaging program (such as Adobe Photoshop) stripping out the EXIF data and, then, if necessary, rotate the image so that it is visually oriented correctly (inverting the actual aspect ratio rather than introducing a new EXIF orientation flag) before feeding it to JuiceboxBuilder-Pro. I realise that this will add a few steps to an existing workflow but it might help.

We very much appreciate your suggestions and feedback.
I'm sure the developers will consider all your ideas and the points that you make.
My notes above are really intended for other users reading through this thread and experiencing similar issues (but who have not read through the individual forum topics that you have created.) They might help to clarify things for some people.

Thanks again for the suggestions.
I hope you're able to resolve your file-lock problem (it certainly sounds like it might be connected to your USB backup procedure).

Thank you for reporting this problem. I've been able to replicate it with one of my own images and I've notified the developers who will investigate further.
At the moment, the only workaround I've found is to rotate images (if necessary) in a third-party imaging program (such as Adobe Photoshop) before feeding them to JuiceboxBuilder-Pro.
Hopefully the developers will be able to fix this issue in a future version.
Thank you, once again, for reporting it.

Unfortunately, I cannot explain what might have happened.
You should certainly be able to edit a gallery without losing any gallery images. I've not encountered this problem before (and I don't recall any other users reporting such a problem).

It certainly sounds like the image entries were removed from the gallery's 'config.xml' file. If you upload a modified gallery folder to your website, then existing images will not be deleted (but if the image entries are no longer in the 'config.xml' file, then the images will no longer be displayed in the gallery).

If the problem happens again, check your gallery's 'config.xml' file (you can open it in a plain text editor) to see if the <image> tags for all your images are present.
Also, before saving your gallery on the 'Publish' tab, double-check that all the images are present on the 'Images' tab.

This is also very strange (although, as you say, if the 'images' folder permissions are too restrictive, then the browser will not have access to the image files).

Re-uploading images to your website should not change their permissions.
I do not know how you are uploading your gallery files but, in case it helps, I use Filezilla (a free dedicated FTP program) which I've used for many years without issue.

If you find that re-uploading a file (or folder) to your web server changes its permissions, then you might like to try a different FTP program to see if this makes a difference. An alternative FTP program for Windows is WinSCP (also free).

I'm not sure if these notes will help but if you can replicate the problem consistently, please post back with a set of steps that I can follow to try to reproduce the problem myself and hopefully help further. Thank you.

As you have discovered, JuiceboxBuilder-Pro does not use the EXIF orientation flag embedded within images. When images are added to a gallery, the EXIF orientation flag is not read and, when images are resized for galleries, all metadata is removed from the images.

If you need metadata to be retained in gallery images, you could resize your images in an imaging program such as Adobe Photoshop (retaining metadata during the resizing process) before feeding them to JuiceboxBuilder-Pro and deselect the 'Resize Images' checkbox so that JuiceboxBuilder-Pro does not process the images further.

However, this still might not be enough to solve orientation issues. It can be difficult to know exactly how a certain program will display an image with an EXIF orientation flag and there seems to be little consistency across different programs (and web browsers).

For example, try viewing this image directly in different browsers.
http://7stripes.esy.es/sample/image001.jpg

In Edge and IE11, the image is displayed in landscape orientation (the EXIF tag not being read).
However, in Chrome, Firefox and Opera, the image is displayed in portrait orientation (correct according to the EXIF orientation tag which I changed by rotating the image in Windows File Explorer).

When the image is displayed by an HTML <img> tag (just as Juicebox does in a gallery's web page), all browsers (at least the ones I listed above) do not seem to respect the EXIF orientation tag and just display the image as it is.
http://7stripes.esy.es/sample/index.html

You could try including the image-orientation: from-image; CSS rule in your gallery's web page (applied to all 'img' tags) but browser support is currently limited (to Firefox 26 and later) and Juicebox itself would not know that the image had been rotated by the browser which may result in the image being displayed in the gallery with unexpected dimensions (the drop-shadow around the image may be in an incorrect position).

With all this in mind, perhaps the best way to ensure that your images are displayed as expected in your gallery would be to re-save your images in an imaging program (such as Adobe Photoshop), stripping out the metadata during the resizing process and then rotate your images so that they are visually oriented correctly (inverting their actual aspect ratios rather than introducing new EXIF orientation flags) before feeding them to JuiceboxBuilder-Pro.

EXIF orientation can be a minefield at times and, as can be seen above, it is not always easy to predict how an image will be displayed in any given program.
This article, whilst a little out-of-date, makes for interesting reading.

Knowing how JuiceboxBuilder-Pro works should at least allow you to adjust your workflow to obtain a gallery with correctly orientated images.

If you do not have Adobe Photoshop, then there are other imaging programs you could use to batch process (re-save with or without metadata, rotate, etc.) your images, such as Irfanview. (This is just a personal suggestion rather than an official recommendation.)

I hope this goes some way towards explaining things.

I do not know how likely it is that JuiceboxBuilder-Pro's behavior will be changed in the future but, if you like, please feel free to make suggestions for future versions in the Feature Requests forum thread.
This keeps all the ideas together and ensures that they are not overlooked by the developers.
Thank you.