@support+juicebox
Thanks for the update! It's most appreciated.
You are not logged in. Please login or register.
Juicebox Support Forum → Posts by Steven @ Juicebox
@support+juicebox
Thanks for the update! It's most appreciated.
@support+juicebox
Many thanks for the additional information!
Incidentally, while new information is being added to this thread, support for purchase URLs (which I mentioned in my post above) was added to Juicebox-Pro in v1.4.0. Please see the Version History for a list of changes between versions and the Using Custom Purchase URLs support section for more information on the use of purchase URLs.
Can juicebox be adapted to tell the browser to load the images sequentially (by name)?
No, unfortunately not. The only control you have over the preloading of images is the imagePreloading configuration option (in JuiceboxBuilder-Pro's 'Customize -> Main Image' section).
I think your issue is a direct consequence of setting enableLooping="TRUE".
Normally, Juicebox-Pro will preload both the previous and next images in the gallery (both images adjacent to the current image) so that they are ready to be displayed should the user click the 'previous' or 'next' navigation button.
If enableLooping="TRUE", then the previous image will be the last image in the gallery (in your case No. 9) and Juicebox just seems to preload this before No. 2, No. 3, etc.
As you are aware, large file sizes and a slow connection are also contributing factors.
As an example, if you were to create a gallery using JuiceboxBuilder-Pro with all default values, then the resulting image sizes would be around 120KB. With even just an 'average' connection speed, this would probably not be an issue.
However, real-life constraints (such as a slow connection speed) will certainly make a difference and you might need to counteract such factors by doing thing like reducing your image sizes (especially if you know that your gallery's target audience is likely to have a slow connection).
The other option would be to set enableLooping="FALSE". Perhaps not something you'd like to do in an ideal scenario but a compromise that would help to resolve your problem.
Please also see my notes regarding Muti-Size Image galleries in your other thread. They might be of interest to you.
If you'd like to suggest an idea for a future version, please feel free to post in the Feature Requests forum thread.
This keeps all the ideas together and ensures that they are not overlooked by the developers.
I do not know the likelihood of any suggestions being implemented but this is certainly the best place for all ideas.
Thank you.
I might try setTimeout if necessary.
It looks like this might be the best course of action (other than changing the filesize of your images).
I have also resorted to smaller images already. This just is the No.1 performance parameter...
As a side note, you might like to look into having a Multi-Size Image gallery. Please see the Multi-Size Image Support section for details.
In a Multi-Size Image gallery, up to 3 different sizes of images can be used and Juicebox-Pro chooses the most appropriate image size depending on factors such as the device, screen size and pixel density being used to view the gallery. The speed of the connection is not a factor in deciding which image size to use but at least you should be able to feed smaller images to mobile devices to minimize the problem as much as you can.
Basically my problem is starting to go off topic and therefore I will start another thread for this.
OK. No problem.
Thank you for reporting this. It certainly looks like a bug (thumbnails do not AutoHide when showInfoButton="TRUE" and overlay is toggled off). I've notified the developers.
It looks like the problem is directly related to the Info Button so a workaround might be to set showInfoButton="FALSE".
...I don't want the Info Bar to be constantly overlaying and therefore obscuring the image.
If you still want to display the Button Bar but just don't want it to be overlaid on top of your images, you can set buttonBarPosition="TOP" (in JuiceboxBuilder-Pro's 'Customize -> Button Bar' section). The Button Bar will then always be positioned at the top of the gallery above the images (not on top of them). You can set the topAreaHeight (in JuiceboxBuilder-Pro's 'Customize -> General' section) if you like.
If you don't want the Button Bar to be displayed at all, then you can set buttonBarPosition="NONE" (in JuiceboxBuilder-Pro's 'Customize -> Button Bar' section).
Thanks again for reporting the problem.
Set useFullscreenExpand="TRUE" (in JuiceboxBuilder-Pro's 'Customize -> Lite' options) and the Expand Button will be displayed on the Button Bar (even in a 100% x 100% gallery) and the gallery will be expanded fullscreen as long as the browser supports the Fullscreen API.
Here's a demo with a 100% x 100% gallery with useFullscreenExpand="TRUE" and the Expand Button displayed on the Button Bar (third icon from the left): https://www.juicebox.net/demos/pro/full/
I hope this helps.
If you have a gallery that you're having trouble with, please let me know (and provide a link so that I can see the problem for myself) and I'll move your query to a new thread of its own.
Thank you.
I think GODaddy puts them into a folder...
If your web host is GoDaddy, then they provide your web space but where files and folders are uploaded to within your web space (and ultimately located) is up to you.
If you are not already using an FTP program to transfer your files from your computer to your web space, then I'd recommend trying one (such as Filezilla). Once you're logged into your hosting account, you'll be able to drag and drop files and folders from your computer into the FTP interface to upload them to wherever you like within your web space.
I think GODaddy puts them into a folder with the location:
http://adriannelugo.com/public_html/images rather than directly in the root folder.
'public_html' is the name of the directory on your web server that represents your web root. ('public_html' does not form part of a URL.)
For example, if you upload a file named 'main.html' to your 'public_html' directory, then it will be accessible at http://adriannelugo.com/main.html.
So I just need to figure out how to move them where they need to be.
As you seem to have followed the regular embedding instructions here, all you should need to do to have your http://adriannelugo.com/juicebox_portfolio.html gallery work correctly is upload the contents of your gallery folder to your web root directory (the 'public_html' directory). The gallery's 'images' folder should reside directly inside the 'public_html' directory (alongside the gallery's 'thumbs' folder).
Why can't I just change the path in the embed code? Wouldn't that be easier?
As long as you follow the embedding instructions correctly, then there should be no need to change any paths in the embedding code (or elsewhere).
If you changed the structure of your gallery, then you could (if you wanted to):
(1) Use a configUrl in your embedding code to point towards a specific XML configuration file (if you have moved or renamed the gallery's 'config.xml' file).
(2) Use a baseUrl in your embedding code to point towards a complete gallery folder (if you have uploaded a complete gallery folder to your web server rather than just the contents of a gallery folder). The baseUrl method of embedding is documented here.
Short descriptions of configUrl and baseUrl can be found in the Embed Options section of the Config Options page.
The paths to the images themselves can be found inside the XML configuration file. (You can open a gallery's XML configuration file in a plain text editor and change the imageURL and thumbURL paths if you like.)
Relative paths are relative to the web page containing the gallery's embedding code (or a baseUrl if one is used).
(imageURL and thumbURL entries can be absolute as well as relative.)
All you should need to do though, is make sure that your gallery's 'images' folder is directly inside your 'public_html' directory, alongside your gallery's 'thumbs' folder. If it is already there, then check its permissions (as I suggested in my post above).
This should hopefully solve your problem.
According to your gallery's 'config.xml' file, the first image in your gallery should be located here: http://adriannelugo.com/images/2_n.jpg
... but going directly to that location in a browser results in an error 404 (file not found).
It looks like your gallery's images have not been uploaded to your web server (or at least not to the correct location, your http://adriannelugo.com/images/ directory).
Please check that your image files have been uploaded to the correct location on your web server and that their permissions (and the permissions of the 'images' folder itself) are not too restrictive.
Default permissions of 755 for folders and 644 for files should be fine.
You can check and change permissions with an FTP program such as Filezilla or via your web hosting account's online file manager.
Also, please see this FAQ which may help:
My images show locally, but not when I upload them to my website. Why?
The only other thing I can think of would be to start AutoPlay when the Juicebox-Pro API determines that the first image has been displayed for the first time (using the onImageChange event).
Try the following:
<!--START JUICEBOX EMBED-->
<script src="jbcore/juicebox.js"></script>
<script>
var jb = new juicebox({
containerId: "juicebox-container",
autoPlayOnLoad: "FALSE",
enableAutoPlay: "TRUE",
goNextOnAutoPlay: "FALSE"
});
var flag = false;
jb.onImageChange = function(e) {
if (flag === false && e.id === 1) {
jb.toggleAutoPlay();
flag = true;
}
};
</script>
<div id="juicebox-container"></div>
<!--END JUICEBOX EMBED-->
If this still does not help, then you might need to use a setTimeout() delay (as I noted in my post above) or tweak your gallery's imagePreloading value and/or your image sizes (although I understand that you do not want to do this).
One more thing I'm not sure about, is the use of the config.xml file. As it contains the same statements...do I have to change anything in this file?
You can set configuration options in the gallery's XML file, in the embedding code or via a query string in the URL.
Please see the Setting Config Options support section for details.
If you have a certain configuration option set in both the embedding code and the XML file, then the value from the embedding code will take precedence. (Options set via the query string will override both embedding code and XML file options.)
I chose to add the configuration options required for my code to function correctly to the gallery's embedding code simply to keep my suggestion to a single chunk of code. You can set all your configuration options in your gallery's 'config.xml' file without any problem.
Rather than setting autoPlayOnLoad="TRUE", use autoPlayOnLoad="FALSE" (the default value) and start the AutoPlay via the Juicebox-Pro API toggleAutoPlay() method when the onInitComplete event is fired (once the gallery is ready).
At the moment, you'll need to also set enableAutoPlay="TRUE" for this to work. This should not be necessary: the toggleAutoPlay() API method should not have the enableAutoPlay configuration option as a dependency. However, the developers are aware of this issue and it should hopefully be fixed in the next version.
Also, be sure to set goNextOnAutoPlay="FALSE" (default value), otherwise, when AutoPlay is started, the image will change immediately instead of waiting the allotted displayTime before moving on.
Try the following:
<!--START JUICEBOX EMBED-->
<script src="jbcore/juicebox.js"></script>
<script>
var jb = new juicebox({
containerId: "juicebox-container",
autoPlayOnLoad: "FALSE",
enableAutoPlay: "TRUE",
goNextOnAutoPlay: "FALSE"
});
jb.onInitComplete = function() {
jb.toggleAutoPlay();
};
</script>
<div id="juicebox-container"></div>
<!--END JUICEBOX EMBED-->
Hopefully this will help.
If not, then you could introduce a short delay using the JavaScript setTimeout() function.
For example:
<!--START JUICEBOX EMBED-->
<script src="jbcore/juicebox.js"></script>
<script>
var jb = new juicebox({
containerId: "juicebox-container",
autoPlayOnLoad: "FALSE",
enableAutoPlay: "TRUE",
goNextOnAutoPlay: "FALSE"
});
jb.onInitComplete = function() {
window.setTimeout(function() {
jb.toggleAutoPlay();
}, 500);
};
</script>
<div id="juicebox-container"></div>
<!--END JUICEBOX EMBED-->
The '500' entry in the code above is the delay in milliseconds. You can change this to a different value if you like.
Yes. You can use whatever valid units you like in your custom CSS.
The reason that only px and % are accepted as galleryWidth and galleryHeight in the gallery's embedding code (as noted in your query here) is that Juicebox sanitizes the values (turning anything that is not a % into a px value) before using them internally as CSS.
Any custom CSS will be used by the browser as is.
For anyone looking to change the font size of gallery text, the following CSS may help. (Just change the values as necessary.)
/* IMAGE TITLE */
.jb-caption .jb-caption-title {
font-size: 20px !important;
}
/* IMAGE CAPTION */
.jb-caption .jb-caption-desc {
font-size: 18px !important;
}
/* IMAGE NUMBER */
.jb-cap-frame .jbac-number {
font-size: 12px !important;
}
You could add this CSS to the end of your gallery's 'jbcore/classic/theme.css' file or wrap it in <style type="text/css"> ... </style> tags and add it to the end of your gallery web page's <head> section (to avoid the need to modify your gallery's 'theme.css' file).
If you do modify your gallery's 'theme.css' file, please remember to make a backup copy of your modified file as it may be overwritten if you upgrade your gallery when a new version of Juicebox is released.
Please, drop this request
OK. No problem. I've moved this query into its own thread (rather than the Feature Requests forum) as it's a known bug.
I have turned off Enable Direct Links in all my galleries. But it is still working when there is a hashnumber in the URL. I understand from you that this is a bug.
That is correct. Currently, a hash identifier in the URL will display the specified image, even with enableDirectLinks="FALSE".
As I mentioned, this has been logged as a bug and should hopefully be fixed in a future version.
I'm glad you've found a workaround. Thank you for letting me know.
Another possible workaround (if you need to specify a number in the URL but don't want Juicebox to use it) would be to use a query string (e.g. ?number=2) instead of a hash (e.g. #2) for your own custom function.
I realise that you have already implemented your own custom function using the hash identifier and would need to rewrite the function to make use of the query string instead but it might help others who are still working on their site and have not yet implemented their own 'number in URL' functionality.
[Query moved from Feature Requests forum to new thread.]
@arachnid
The hash will only appear in the URL automatically (when loading a gallery or selecting a new image) if enableDirectLinks="TRUE".
However, at the moment, you will still be able to manually enter a hash value in a URL (to directly access an image) even if enableDirectLinks="FALSE". This has been logged as a bug and should hopefully be addressed in a future version.
I've just set up 9 different test galleries (all setting screenMode="LARGE"), using all combinations of showPagingText (not set, TRUE and FALSE) and showSmallPagingText (not set, TRUE and FALSE).
I then viewed all 9 galleries in Mobile Safari, Chrome 56 and Firefox 6.0 on an iPod Touch 6 running iOS 10.2.1.
All results were as expected: the thumbnail paging text displayed only in those galleries which set showPagingText="TRUE".
The value of showSmallPagingText (or its existance as a configuration option at all) did not make a difference to any of the galleries (which is expected as screenMode="LARGE").
I've tried but I really can't replicate the problem you're describing.
Maybe what you were seeing was a result of a caching issue (either client or server-side) and your browser was using an older cached version of your gallery's 'config.xml' file (with different settings).
If you do find a gallery which displays the thumbnail paging text unexpectedly (or does not show it when it should), please post a link to the gallery in question and let me know what device and browser you see the problem in.
Thank you.
The default value for showSmallPagingText is TRUE (noted on the Config Options page).
If, when you first open JuiceboxBuilder-Pro, you do not change a configuration option, JuiceboxBuilder-Pro will not write the option's default value to the gallery's 'config.xml' file (to save cluttering up the file with hundreds of entries) and Juicebox-Pro will use the default value when the gallery is displayed.
If there is no entry for showSmallPagingText in the gallery's 'config.xml' file, then Juicebox will use this option's default value of TRUE and you'll see the thumbnail paging text when the gallery is displayed in Small Screen Mode.
I think this might be what you are experiencing.
I have checked that JuiceboxBuilder-Pro is writing correct values to the 'config.xml' file and cannot find an error.
Correct values (corresponding to the interface input fields) are written to the file (but default values are not always entered).
I hope this helps somewhat.
If you have a gallery which does not behave as expected, then please post a link so that I can investigate further.
Likewise, if you have a set of steps that I can use to reproduce an error with JuiceboxBuilder-Pro, please let me know.
To summarize...
showPagingText="TRUE" will always show the thumbnail paging text when the gallery is displayed in Large Screen Mode. The default value for showPagingText is FALSE.
showSmallPagingText="TRUE" will always show the thumbnail paging text when the gallery is displayed in Small Screen Mode. The default value for showSmallPagingText is TRUE.
If a configuration option is not explicitly written to a gallery's 'config.xml' file, then Juicebox will use the default value for that option.
Also, just to clarify, you mention "LargeScreen Mode in mobile browser" and "LargeScreen Mode on mobile devices with screens smaller than 1024px". The only way that Juicebox will be displayed in Large Screen Mode on mobile devices with small screens is if you set screenMode="LARGE". If the gallery is truly in Large Screen Mode, then showPagingText will be active (and showSmallPagingText will be ignored), regardless of the device or browser window size.
All my galleries are by default set in Large Mode. I notice that what ever I set for Show Small Paging Text (False or true) Small Paging Text is visible in screens smaller then 1024 px.
If all your galleries set screenMode="LARGE" (always being displayed in Large Screen Mode), then showSmallPagingText will never have any effect. showSmallPagingText refers to Small Screen Mode only.
showSmallPagingText will display the thumbnail paging text only if screenMode="SMALL" or screenMode="AUTO" and Juicebox decides to use Small Screen Mode (due to the device and screen size being used to view the gallery).
In Large Screen Mode, the thumbnail paging text can be selected using showPagingText.
If screenMode="LARGE" and showPagingText="TRUE", then the thumbnail paging text will always be displayed, no matter what size the user's browser window is.
If you want to hide the thumbnail paging text in browser windows of less than 1024px width when screenMode="LARGE" and showPagingText="TRUE", then you'd need to introduce custom CSS and JavaScript.
Something like the following should work:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8" />
<style type="text/css">
body {
margin: 0px;
}
/* Initially hide thumbnail paging text until we know whether or not it should be visible */
.jb-idx-thb-list-page-number {
display: none;
}
</style>
<script type="text/javascript" src="jbcore/juicebox.js"></script>
<script type="text/javascript">
function pagingText() {
var windowWidth = parseInt(window.innerWidth ? window.innerWidth : $(window).width(), 10);
if (windowWidth > 1024) {
$('.jb-idx-thb-list-page-number').show(); // Show thumbnail paging text if necessary
} else {
$('.jb-idx-thb-list-page-number').hide(); // Hide thumbnail paging text
}
}
var jb = new juicebox({
containerId: "juicebox-container",
screenMode: "LARGE",
showPagingText: "TRUE"
});
// Wait until gallery is ready before using thumbnail paging text class
jb.onInitComplete = function() {
pagingText();
$(window).resize(pagingText);
};
</script>
<title>Test</title>
</head>
<body>
<div id="juicebox-container"></div>
</body>
</html>
Please note that the suggestion above will hide the thumbnail paging text in Large Screen Mode for browser window widths of less than 1024px but space will still be reserved for it by Juicebox (as showPagingText="TRUE" and, as far as Juicebox is concerned, the paging text should be there).
You'll need to use an http:// absolute path (not ftp://) to your gallery's 'index.html' file as the 'src' attribute of your iframe.
Once you've uploaded your gallery folder to your web server, find out the URL that you need to use to view the gallery's 'index.html' page in your browser. This is what you should use for the 'src' attribute of your iframe. If you are not sure what this URL is, your web host should be able to help you out.
It looks like it might be something like http://madagascar14.byethost7.com/Little Manor/Galleries/index.html but this doesn't work. (I don't know what domain and subdomain your account uses but your web host should be able to tell you if you don't know.)
Your iframe should look something like this:
<iframe src="http://www.example.com/Little Manor/Galleries/index.html" width="1200" height="660" frameborder="0" scrolling="no"></iframe>
You're welcome!
I'm glad it turned out to be an easy fix. Thanks for letting me know.
If you allowed JuiceboxBuilder-Pro to create all image sizes for a Multi-Size Image gallery, then (as you are aware), no gallery images would contain metadata unless any of the source images are already within the maximum bounds of an image size and do not need to be resized (in which case they would be copied across to the gallery folder unmodified with their metadata intact).
Perhaps the easiest thing to do would be to create a Multi-Size Image gallery with JuiceboxBuilder-Pro so that all the smallImageUrl and largeImageUrl entries are present in the gallery's 'config.xml' file.
All you'd then need to do is create your own Small, Medium and Large images (in an imaging program such as Adobe Photoshop) and then replace the images in the 'images' (Medium), 'images/small/' (Small) and 'images/large/' (Large) folders.
(Images for each size should have the same filename. Each image size is stored in a different folder to avoid file name collisions.)
At least all the smallImageUrl and largeImageUrl entries would be generated for you.
This would be a step in the right direction over having to create a Multi-Size Image gallery from scratch manually.
I have checked, and all of the galleries with audio have the same configuration - only the gallery title and the audioUrl entries are different.
There is really no reason why galleries with the same configurations should function differently (as I'm sure you're aware).
One of these galleries however does not display the audio play button in the Firefox browser on my iphone.
I've just checked the gallery you claim does not work as expected ('WebMuir-js') in Firefox 6.0 (2) on an iPod Touch 6 running iOS 10.2.1 and the Audio Button displays fine and the audio track plays OK.
Maybe the problem is a browser caching issue.
Try completely clearing your Firefox browser's cache ('Firefox Menu -> Settings -> Privacy -> Clear Private Data' - clear everything) to see if this makes a difference.
Killing or updating the app and rebooting your iPhone may not affect the browser's cache and the browser may be displaying your gallery with an older cached version of the configuration file.
I hope this helps.
If you resize your images prior to using JuiceboxBuilder, just deselect the 'Resize Images' checkbox (on the 'Images' tab) and drag and drop the images into the 'Add Images' box as normal.
When you 'Save' the gallery on the 'Publish' tab, Juicebox will copy the images (without modification) to the gallery's 'images' folder (and will still create thumbnails from them in the gallery's 'thumbs' folder) and will populate the 'config.xml' configuration file with the correct paths (to the images and thumbnails in their respective folders).
@Reti33
If a gallery does not display on a web page, then the most likely probably causes are:
(1) Incorrect paths (or missing files), perhaps the 'juicebox.js' file or the 'config.xml' file.
(2) Custom CSS code which is affecting the visibility of the gallery. Check any custom CSS to make sure that the gallery's parent containers are visible (e.g. do not have zero height or have been removed from the DOM).
Please also see this FAQ for another possible cause (incorrect formatting for the gallery's embedding code).
When I view my gallery, I see a blank area. Why?
If you like, you could post the URL to your gallery's web page and I'll take a look to see if I can determine the cause of your problem. (I'll move your query into a new thread of its own.) Thank you.
Only the one gallery fails on the iphone - the other three work as expected.
Please double-check that the configuration options for all your galleries are exactly the same as each other.
It sounds like there might be a difference between your galleries which is causing your problem.
If you continue to experience difficulties, please post back with the URL to your gallery's web page so that I can take a look at the problem for myself and hopefully help further. Thank you.
I see the problem in IE11 (the gallery not visible) but I do not see the content of the <noscript> tags (which would be a vertical list of images) so the problem does not seem to be a JavaScript related issue.
It looks like the gallery is probably working OK but the problem is that it is not visible on your web page (perhaps due to custom CSS or HTML errors on your web page).
I have checked your web page with the W3C Markup Validation Service and there are several HTML errors.
For example, your web page has 3 separate containers with id="menu-hoofdmenu". All ids on a web page should be unique. IE11 may not know which of these containers to apply #menu-hoofdmenu CSS rules to. You might expect it to apply #menu-hoofdmenu CSS rules to one (or all) of these containers but there is no telling how IE11 (or any other browser) will react to this.
Some browsers can be more tolerant towards HTML errors than others which might explain why your web page appears to be OK in some browsers but not others.
If you can fix the HTML errors on your web page, then it should be rendered with greater predictability and consistency across different browsers.
I do not know how much code on your web page is generated manually (or automatically by a theme) but trying a different theme might help.
I hope this points you in the right direction.
I'm still not sure what the root of the problem is but as neither of us can replicate the problem in a standalone gallery or stripped back test case, I can't help but think that the surrounding code on your web page must somehow be contributing to the problem.
I'm glad you've found a workaround. Thanks for sharing.
It's interesting that I only ever saw the problem (occassionally) in Chrome and IE11 and that you've never seen the problem on any mobile device. Maybe we can keep an eye on browser updates to see if this somehow solves the problem in the future without any further action.
Once again, I appreciate you keeping this thread up to date with your progress.
If I can reproduce the problem and create a bug report that the developers can work with, I'll certainly do so but, at the moment, the problem seems to be present only in your web site (no other users have reported this issue) and only in certain desktop browsers. It's a tricky one to troubleshoot for sure.
The best way to tackle it would probably be to copy your web page (to create a test environment) and then remove elements (external CSS and JavaScript) one by one until the problem no longer occurs and you find the cause of the problem. However, as you've found a workaround, I would understand if you'd rather just leave things as they are.
Juicebox Support Forum → Posts by Steven @ Juicebox
Powered by PunBB, supported by Informer Technologies, Inc.