1 Reply by ryan

(6 replies, posted in Juicebox-Pro Support)

Hi there,

I maintain the Drupal Juicebox module and frequently get questions about this kind of issue. In fact, some Drupal users have started to reference the suggestion in this juicebox.net post as a "fix" (that's how I learned of this thread).

There are conditions that can occur with a Drupal install where every page prints extra whitespace at the beginning of its markup, which then interferes with all XML that Drupal tries to generate. This is usually related to bad code in another Drupal module and almost always has nothing to do with Juicebox or the Drupal Juicebox module. The fix posted here provides a temporary workaround by simply masking a bigger underlying problem with a Drupal instance (again, independent of the Drupal module). In this regard I would not look at the code change above as a fix, but only a temporary workaround, or something that might help with troubleshooting.

Fixing the underlying whitespace issue properly might save future Drupal headaches for people encountering this, and is always recommended.

For anyone interested to know more, I suggest looking at: https://www.drupal.org/node/2312037

Go to forum: Juicebox-Pro Support

2 Reply by ryan

(10 replies, posted in Juicebox-Pro Support)

Ok, thanks for the clarification.

Whenever I see that the code/build has changed on a project, but the version number has not, I immediately assume that I've somehow got a "working" copy that's not yet tagged for stable/public use. This is why I was concerned, and suppose others could be as well. For whatever it's worth I'd encourage your developers to use a true semantic version scheme (http://semver.org/) as that might help avoid confusion in the long run... just my 2 cents.

I really appreciate the attentive response and quick turnaround on all this. Thanks very much!

Go to forum: Juicebox-Pro Support

3 Reply by ryan

(10 replies, posted in Juicebox-Pro Support)

I downloaded a copy of the most recent 1.4 and can confirm that the logic looks very good. The linkURL details appear to be handled just as before and the new smallImageURL and largeImageURL appear to be selected as expected. That's great! I'm one of this features biggest fans.

My only pending comment is that the new build, which is clearly a different public release, is still tagged as 1.4.0 as opposed to 1.4.1 (1.4.n or whatever the current patch number is). Was this an oversight? Users may reference this to confirm whether-or-not they are patched, and integration tools (like ours) may parse it to auto-detect if certain integration features should be enabled or not. It looks like you are using a semantic version scheme, but I just wanted to confirm.

Go to forum: Juicebox-Pro Support

4 Reply by ryan

(10 replies, posted in Juicebox-Pro Support)

That's great, thanks!

I'll grab a copy of that as soon as I can. At the moment it looks like I've used-up my 5 pro downloads, so I'll have to wait until someone responds to my request for a new link.

Anyone interested in the Drupal-side of things may also want to see these notes on the topic: https://drupal.org/node/2246851

Also, you may want to update the version history at http://juicebox.net/support/history/ as there does not appear to be a reference to 1.4.1 (or any new revision/build number) there yet.

Cheers

Go to forum: Juicebox-Pro Support

5 Reply by ryan

(10 replies, posted in Juicebox-Pro Support)

Currently, the largeImageURL does take precedence over the linkURL. This is a bug which we intend to fix as soon as possible.

Thanks, that certainly helps explain things. I think this means that my conceptual understanding of things is solid, and it'll just be a matter of digging into this further one that bug is fixed (maybe a 1.4.1 release?).

Cheers

Go to forum: Juicebox-Pro Support

6 Reply by ryan

(10 replies, posted in Juicebox-Pro Support)

Ok, thanks for the info. Will all this be officially documented somewhere at some point?

Also, the point that is still somewhat confusing to me is the handling of the linkURL attribute. Can you clarify how this will be used going forward?

I played around with things a bit and from what I can see the largeImageURL attribute seems to "take over" everything the linkURL attribute used to do in terms of custom "navigation" options. This means that when largeImageURL is define it's used for the "open image" button URL, for navigation when imageClickMode="OPEN_URL", etc. However, it does not appear to be used when the "expand" button is clicked (the imageURL appears to still be used in this case). This actually feels quite backwards to me as I would expect that "navigation" features would be strictly separated from image sizing features. I also know many users like to use Juicebox to display images, but also define non-image URLs for each image that can be linked to outside of Juicebox. For this they have been setting a non-image URL (e.g. a URL to a normal webpage) for the linkURL attribute and then using the "open image" button, or features like imageClickMode="OPEN_URL", to navigate users to these special webpages that are related each image. From what I can see this kind of setup will be broken when these users upgraded to 1.4 pro, unless of course they ensure they are not using this new multi-size feature (i.e. not defining largeImageURL).

We have built-in special features within the Drupal integration module to allow users to define custom URL patterns, or dedicated image derivatives, specifically for the imageURL value. We did this due to high demand from users who wanted to do things like what I described above (link each image to a non-image URL, or some special full-size derivative), so I want to be sure I understand how the linkURL value will be leveraged in the new version(s) of your library. On first glance it seems like there are some inconsistencies, but it's very possible that I don't understand all the details just yet. I'm thinking that linkURL and largeImageURL should always be set the same, but I'm not sure what to offer users who may expect to be able to configure them separately.

Please just let me know if I can provide more clarification on all this. I just want to fully understand these kinds of things as I now find myself in a role where I indirectly represent a few thousand of your users (who experience it via Drupal).

Also, it looks like 2 new attributes have been added to the <juicebox> tag in the XML, useLargeImages and useSmallImages. However, toggling these from TRUE to FALSE does not have any affect that I can see. Do these values also have to programmatically be set in a certain way for the multi-size features to work?

Go to forum: Juicebox-Pro Support

7 Topic by ryan

(10 replies, posted in Juicebox-Pro Support)

Hi,

I'm excited to see that you've added multi-size/adaptive image support (which was actually a feature request of mine - http://juicebox.net/forum/viewtopic.php?pid=4042#p4042), though it's a little disappointing that it's a Pro-only feature. Anyway, my question is in regard to the specifications for this feature when programmatically creating gallery XML. I'm interested in this as I maintain the Drupal integration project for Juicebox, and I know that our users will be asking about this.

Drupal, and other frameworks like it, have their own image processing tools for managing image derivatives, and the ability seamlessly tie these tools to this new multi-image feature is obviously very enticing.

I can see from you multi-size demo XML (http://juicebox.net/demos/pro/multisize/config.xml) that you've added support for new attributes to the image tag (smallImageURL and largeImageURL), which is exactly what I was hoping for. However, there does not appear to be any documentation for all this beyond the notes at http://juicebox.net/support/multisize/, which only reference your JuiceboxBuilder tool. Will you be adding formal documentation for this, from an XML-building perspective, at some point?

Some specific questions include:

  • If "small" and "large" mode are handled by smallImageURL and largeImageURL respective, what attribute is used to define the "medium" mode source, perhaps just imageURL?

  • You say "large" mode (which I presume uses the source defined in largeImageURL) is "used in Large Screen Mode when opening image in a new window or when gallery is expanded". I originally thought this is what the linkURL attribute is for. Would you be able to clarify the distinction between these going forward along with best practices for backwards compatibility with old (pre 1.4) XML?

  • Which source is used when generating a "splash" image in small screen mode? smallImageURL?

  • If XML generated for 1.4-PRO (using smallImageURL and largeImageURL attributes) is used in a pre-1.4 version of your javascript library, or 1.4-Lite, will there be any issues?

I'm hopeful that you'll be able to provide some official specs on all this so that we don't have to reverse-engineer the details.

Thanks again for prioritizing this feature. It may not be very "sexy" for most users, but it's very important from a practical perspective.

Go to forum: Juicebox-Pro Support

8 Reply by ryan

(7 replies, posted in Juicebox-Pro Support)

OK, thanks. I think that makes sense.

Given that jQuery is used within the internal Juicebox logic, I'm curious how it gets included. Manually including a jQuery library is not a dependency for Juicebox to work, and it does not look like Juicebox makes any external requests to fetch/include any version of jQuery from a remote server at runtime. Does this mean that a jQuery library of some sort is actually bundled inside of juicebox.js itself?

Just curious.

Ryan

Go to forum: Juicebox-Pro Support

9 Reply by ryan

(7 replies, posted in Juicebox-Pro Support)

Sure, here's a quick demonstrative example:

http://li321-141.members.linode.com/temp/index.html

The embed code there calls upon XML that's hosted in a different domain: http://www.ryan-jacobs.net/juicebox/xml … e_1/Nature ... When the XML is served up a "Access-Control-Allow-Origin: *" response header is included (which is obviously critical to allow CORS to work).

In that example everything works great on modern browsers, but fails on IE8 (and presumably 9), with the "XML Not Found" Juicebox grey screen of death. Direct requests to the XML work fine in all browsers. Given that IE8/9 require special considerations to implement CORS support (as noted in my comments above) I figured that must be the root of the issue.

Btw, I don't personally requite CORS support for any of my own projects, but I do maintain a Juicebox integration module project for Drupal which has become quite popular. I discovered this issue while testing various features and configurations for that project that other Drupal users are interested in.

Go to forum: Juicebox-Pro Support

10 Reply by ryan

(7 replies, posted in Juicebox-Pro Support)

Great, thanks. It's great to see that CORS concepts are already considered. Hopefully any missing IE 8 and 9 support would be a simple adjustment. I think that anything <IE 8 is a lost cause for CORS, as support for that may be impossible. Thankfully anything <IE 8 is going out of style fast.

Go to forum: Juicebox-Pro Support

11 Topic by ryan

(7 replies, posted in Juicebox-Pro Support)

I'm posting this in the Pro forum as I'm a Pro user, but I believe this topic should apply to both the Lite and Pro versions.

Given that Juicebox galleries are described in XML the are by nature quite portable. This makes them very friendly to "Create Once Publish Anywhere" (COPE) concepts, as a gallery (i.e., its XML) can be managed on one server but shown/embedded on another. Of course, if doing this "same origin policies" must be taken into account when hosting the XML on a domain that's different from the one the gallery is embedded in. In this regard CORS seems to be the best practice, and adding an "Access-Control-Allow-Origin" response header when the XML is served seems to work as expected when embedding a gallery in one domain and hosting its XML in another.

However, a problem arises if viewing such a gallery in IE 8 or 9. It seems that IE 8 and 9 don't support CORS 100% correctly. So even if the XML is fetched from a (different) domain that adds a header like "Access-Control-Allow-Origin: *", Juicebox will still not load the XML as it gets incorrectly blocked by the browser's security controls.

As the Juicebox code is not open I can only guess on why this might be. Perhaps it is because you are using XMLHTTPRequest to get the XML? For IE 8 and 9 it seems that the recommended technique is to use XDomainRequest instead, as this will correctly support CORS. See: http://blogs.msdn.com/b/ieinternals/arc … ounds.aspx

IE 8 and 9 are fairly old now, but given that Juicebox is suppose to support them I wonder if you also have interest in ensuring everything works with CORS. I'm sure you have some browser-detection backed into your code, so perhaps that needs to conditionally use XDomainRequest instead of XMLHTTPRequest when IE 8 or 9 is detected? At the moment at least (as of v1.3.3), it seems like this is not happening.

I'm not an expert on this topic, and am only basing all this on observation and testing. It would just be interesting to know more about what level of cross-browser CORS support has been included in Juicebox.

Cheers

Go to forum: Juicebox-Pro Support

12 Reply by ryan

(496 replies, posted in Juicebox-Pro Support)

I'd like to inquire if the Juicebox devs have given any thought to adding support for adaptive/fluid image source concepts. Perhaps this has come up in this list of requests already, but it's a little tricky to navigate the history as this thread seems to be a bit of a free-for-all :) Anyway, sorry if this is a dup.

I'm the author of the Juicebox integration module for Drupal (https://drupal.org/project/juicebox) and as you may know there is quite a bit of interest around the concept of adaptive/fluid image handling in the Drupal community. To be clear I am not referring to vanilla responsive concepts, but more specifically viewport-aware image delivery for different devices. There are numerous ad-hoc methods to do this kind of thing server-side (with cookies and whatnot), but current trends seem to point more to the usage of client-side solutions like the <picture> element and the srcset attribute. Have you given any thought to one or more of the following?:

  • Adding markup support for the <picture> element when rendering the main images of a gallery. This would probably require support that allows users to define multiple source URLs for each image in the config XML, along with metadata about breakpoints, etc.

  • Adding markup support for the srcset attribute when rendering the main images of a gallery. This too would require multiple image source details to be passed in the XML.

  • Allowing users to specific the raw markup to be used for each image manually in the XML (such that they could implement their own adaptive image solutions for used in Juicebox).

Given the way Juicebox needs to dynamically re-size the <img> elements based on viewport changes I'm guessing the last option may not be feasible, but what about the first two? There are surely a lot of considerations at play with something like this, but it will be interesting to know if this kind of feature is on your radar.

Some related links:
http://responsiveimages.org/
https://drupal.org/node/2023851

Go to forum: Juicebox-Pro Support