When opening image in a new window it needs to refresh to appear

Hummm, I'm not able to replicate that behavior in my test environment, so there may be something specific about your setup going on. Do you have a link to an example gallery that exhibits this behavior?

There is a chance that this could be related to the way Drupal handles image styles, and the related URL structures. This has led to some bugs in the past, but I'm not aware of any pending issues in that regard. Either way, seeing a specific example, if possible, would shed a lot of light on things.

Can you cut-and-paste an example of what appears in your browser bar when the new tab (with just the image) opens up? The URL structure there can provide some clues.

Also, if you can access the XML config code for a gallery that does this, and post that here, that could help too. If you need info about how to access that XML, just let me know.

It looks like that URL is not generated by Drupal's image style methods, so I think that can be ruled out.

You mentioned that you are using tokens for the image path, which I assume is how you are adding those dynamic date paths. What tools are you using for this? Is another contrib module involved in some way (like "File Aliases")?

I should note that this module does not actually build that page that appears when you view the full image, it just sets a URL value that will be opened when you click the correct button. As long as this URL is valid (e.g. it points to a real file or an image style derivative), Drupal will serve-up the image as needed in a totally separate request (that's unrelated to Juicebox). Because this module only deals in URLs, and does not build/create/display any images on its own, it'll be important to investigate exactly what tools/processes are responsible for getting your images to the correct location, and associating working URLs with them.

You said you get a white screen on the first request to the full image. This often means there was a fatal error before any content could be returned. My suggestion would be to re-trigger this situation (so you get the white screen) and then immediately check your logs (admin/reports/dblog). With any luck there will be some useful error(s) reported there that might help identify what process is causing problems.

Also, it would be worth checking to see if the URL value changes at all between the white screen request and the sequential request that works. If it does change, there may be some form of redirect at work.

Let's start with the log check as described above. If that does not yield any useful info then we can look more that your Juicebox XML specifics. I'm thinking less-and-less that those XML details will be related, but let's just wait and see.

Since there are reasons external contrib tools may affect this, and because it's not clear yet if the problem is linked specifically to this module, I should probably adjust the status. If we can isolate the issue to the module, and replicate it in dev, then we'll certainly flag it as a bug.

Just let me know if anything useful comes up in your logs, etc.

Hummm, I'm still confused about how you are assigning those image files to those custom dynamic paths (with tokens). Somehow you must be programmatically uploading images into those date-based paths, but I'm not aware of anyway to do that without a helper module, like filefield_paths or file_aliases. Maybe you are using a special kind of widget for the image/file field that stores your images?

Now I suppose it would not hurt to see your Juicebox XML. Each gallery is described in XML, and you can access this XML for any given gallery by enabling a special "debug" option. Simply go to the Juicebox global settings at admin/config/media/juicebox, and check the "Show links to debug info" option. Then go back to the page with a gallery and just above it you'll now see a link that says "debug info". Click this to reveal some useful tech info about the gallery. I'd suggest sharing the XML URL, as well as the contents at the XML URL (just click the link to bring up the actual XML in your browser).

Ok, I think I see now. You are just using native token replacement on the "File directory" setting for the field. I was confused about how you split out the individual tokens for the date, which made me think you had a helper module. Setting-up a date format with slashes like that (such that they double as directory separators when inserted as a token) is pretty clever.

It looks like the XML didn't get added to your comment. It was probably filtered out by the comment text filters. It should work if you edit you comment above and add <code> just above the XML snippet and </code> just below it. That should escape the special characters so they can be displayed in the comment body.

From a look at the XML I don't see anything particularity strange about your setup that could indicate problems. You have things configured in a common way such that the Juicebox linkURL value (which is what's opened when you click the "open image" button) is the same as the imageURL value. In this regard the Juicebox javascript is just requesting the same image URL for display in the actual galley as it does when you click the open image button.

Also, based on your explanation of how you assign custom file paths from tokens, these linkURL values should represent real file paths. So no image derivative processing should be involved, and you're likely dealing with just direct requests to the files. This would seem to mean that not only is this module not involved in the handling of the image after the "open image" button is clicked, but neither is any other part of Drupal.

So I'm sort-of at a loss, and figure there must be something about the problem that has not come out yet...

• When you click the "open image" button does a new window/tab always get opened? Is it the contents of this new windows/tab that are blank?
• Does the URL in the browser bar stay exactly the same between the first "bad" request (the white page) and the refresh (when it works)?
• Does this problem happen for all images, or just specific ones?
• Does this problem repeat for the same image (e.g. forest-light-900.jpg always shows this problem when clicking the "open image" button, or only the first time after the node it's uploaded to has been edited)?
• What happens if you just open a new tab and browse directly to one of your images (e.g. manually enter the URL http://localhost/cars-copy/sites/default/files/2014/03/26/forest-light-9... into your browser)?

Ok, thanks. By process of elimination I'm starting to think this must have something to do with the Juicebox javascript. When you click the open image button it's the Juicebox javascript that actually opens a new tab and sets the target URL to be the image's linkURL address. Since you have checked that the target URL is valid, that this module is correctly configuring the library to use that URL, and that Drupal is correctly setting an image at that URL, I'm not sure what else it could be.

You may want to see if there is some kind of javascript or jquery conflict in your setup. Are you able to replicate this issue with a variety of different browsers (Firefox, Chrome, Safari, IE)? Do you have any Drupal modules that make major alterations or additions to the native javascript included with Drupal (things like jquery_update or other tools/libraries that add special javascript to your site pages)?

I would also suggest checking any browser-based logs that you have for errors, like the firefox console (that you can easily view with a tool like firebug). Often these logs will catch javascript errors.

Also, myself and others will be able to provide ever grater assistance if you can host the site at a public URL (even temporarily), so they can see this problem in action.

Ok. Because this is most likely an issue with the Juicebox javascript library I highly suggest you open-up an issue here:

http://juicebox.net/support/

The people there will be able to help you much more than I can as they officially develop and support the actual Juicebox javascript. In fact, they are the only ones who know the code of that javascript (it's not open source).

Feel free to share the link to this Drupal issue with them. They may immediately suspect that this is a Drupal problem (since the Drupal integration adds a layer of complexity that they may think is involved). Showing that we have been quite exhaustive about trying to eliminate Drupal-specific variables will probably help focus their support.

Having a public URL to show them will also help greatly.

As best I can tell at this point it looks like this issue in unrelated to this module, so I'll update the status accordingly.