Unused , hidden Juicebox view generates an error

Hi,

You said that you are making the field "inactive". Can you elaborate a bit on exactly how you are doing that? Is it a viewsfield-specific setting or general field visibility setting that you are using?

That error message is something that the Juicebox javascript library generates when the gallery javascript is loaded/fired on the page, but the embed markup is not on the page. Because the javascript and embed markup are always added to the page simultaneously (when building the gallery's render array) this can only really happen if some mechanism, that likely fires very late in the page building process, selectively removes some parts of the final page markup. There are really only rare cases when I think this could happen (one was explained here: #2217791: Prevent javascript from being added in contexts were embed code may not be displayed (e.g. "Cannot find div with id" error on search results)) and for field visibility the conditional controls to show/hide a field typically happen long before the gallery is built or rendered. So I'll probably need a bit more info about how you are controlling your field visibility to get a real understanding of things.

Also, do you have a public URL that you can share to a page that demonstrates this problem?

It looks like you are working on a pretty interesting project, thanks for sharing those details. It's great to see that this module is proving useful for your case.

Anyway, please note that I don't think there are any existing patches that will address this (the issue I referenced earlier is already fixed/closed based on a different problem). However, I have a couple thoughts on ways I think you could address this. I'll try to formulate some more notes shortly....

I think I follow the general panels and views config that you are using, though there may be some details that are still a little cloudy. Anyway, here are some reactions:

1: Some pests have galleries, some dont. When Rendering these, Juicebox displayed a blank div, no amount of trying could get it to display nothing when empty.

This one I'm not too sure about. My experience has been that when a view is empty it won't even trigger the formatter at all, and so all the Juicebox rendering logic won't even be called. In your case though this does not seem to be happening (I guess this is an example: http://www.infonet-biovision.org/content/african-nightshade). That's strange. I wonder if the fact that it's a panel pane display changes the way the formatter is triggered when the result set is empty. If you add a normal page display to you view (gallery_in_phcfv) and then visit it with the same contextual filter that triggers an empty results set (e.g. 28271) what happens? Do you still see an empty Juicebox div rendered?

2: So I added a normal field for the gallery, and overwrote it using the token for the gallery, and could then rewrite the output of the field and insert a token for the juicebox gallery, and where empty , insert a single image 300 px wide with a caption. At least in this instance since the field was checking the images for empty entries and not the views, I could get to hiding the view when empty.

Interesting technique, though I'm not sure I follow exactly where your conditional logic is active to choose which token (Juicebox gallery vs single image) is active. Is that in your panels pane config or in the view itself (I'm guessing the former). Anyway, it seems like the system ends up rendering each token regardless of which one is finally displayed on the page. The result would be a rendered Juicebox gallery (render array) that never makes it to the page output, hence the Javascript error. Have you considered instead some kind of alter hook to conditionally modify the display at a lower level? You might be able to do something in hook_panels_pane_content_alter() to totally change the way the panel is rendered based on whatever conditions you want (remove the Juicebox render array if there is only one image). You could also use hook_juicebox_gallery_alter() to automatically hide the thumbnails if there is only one image. This would allow you to keep all pages consistent and leverage some useful Juicebox features (adaptive images, fullscreen expand, etc.) even for single image cases. Something like this would probably work:

/**
 * Implements hook_juicebox_gallery_alter().
 */
function MYMODLE_juicebox_gallery_alter(JuiceboxGalleryDrupal $juicebox, $data) {
  // The $args array can be used to identify a gallery and only fire some logic for certain fields/views
  $args = $juicebox->getIdArgs();
  $images = $juicebox->getImages();
  // If there is only one image then set some custom options dynamically.
  if (count($images) == 1) {
    $juicebox->addOption('showThumbsButton', 'FALSE');
    $juicebox->addOption('showThumbsOnLoad', 'FALSE');
  }

There might be other ways for the module to be improved to allow special configurations like yours to work as-is without those "Cannot find div with id" errors. However, situations like this have seemed to be a bit "edge case" so I've not looked at it too deeply.

Other Issues not related to this post:
=> Captions dont all show, some show, some dont.
=> First image almost always has no caption.

This could have something to do with the way your File Entity fields are configured and mapped to Juicebox title/caption sources. It may be easiest to get into that after the other issues are resolved.

So it sounds like your plant pages will eventually have multiple Juicebox galleries embedded on them and the same couple of base problems are simply being repeated as a result.

I think the following should seriously be considered :

a) Option to disable thumbnails if the gallery only has one image.
b) Option to disable Juicebox at a much lower level if there is no image.

For "A" I agree that this would be a very useful option for quite a few users. The only reason I'm hesitant to build-in an option for this (in the GUI) is that it requires a PRO version of the Juicebox javascript library to work. This is because the showThumbsOnLoad option must be toggled, which is a PRO-only option. My policy has been to keep the GUI universal for both LITE and PRO versions of the library, while still allowing static PRO options to be set in the "Manual" options fieldset and dynamic PRO options to be controlled via hook_juicebox_gallery_alter(). This is an example of a dynamic PRO option and so the hook example from comment #7 should do the trick. Just note that it will only work if it's implemented as a proper hook in a custom module, and it only addresses the dynamic control of thumbnails when there is just one image (it has no impact on how things work for empty galleries, which I think is a totally separate issue).

For "B" things get very tricky. The module and Drupal already do a pretty good job of ensuring the the Juicebox javascript is always added simultaneously to the embed code at a low level (preventing cases where the javascript could be triggered erroneously). The error cases that remain are ones where a gallery is fully rendered (Drupal is committed to placing it on the page) but something conditionally removes the rendered markup very late in the page building process. This is quite rare, but as you have demonstrated there are probably justifiable use cases where it happens. Any pending work on this problem will best be addressed in a separate issue, so I've opened one here: #2581285: Use JS in Drupal behavior to confirm that gallery div exists before triggeting Juicebox JS.

I think the remaining piece is related to the handling of empty view-based galleries. If there are no images to display in a Juicebox view then we need to figure out if anything should be rendered. Anyway, I'll need to check into this a bit more as it seems like the behavior is somehow different for different types of view displays (e.g. page vs. panel).

A patch is now available for testing in #2581285: Use JS in Drupal behavior to confirm that gallery div exists before triggeting Juicebox JS. This would only address the "Can't find div with id" error for unique cases like yours. If you can test it out and report back in that linked issue that would be great.

Also, regarding the other issue where you have an empty gallery rendered when there are no images to show, I believe this could be related to a non-empty view result. As I noted in an earlier comment, the view will not trigger the formatter at all when there are no results to display. The fact that you have Juicebox gallery divs rendered, even when there are no images displayed implies that the view result is not in fact empty. This could happen if you have nodes listed in the view that do not have an image on them. In that case the gallery/formatter divs are rendered (because there are resulting view rows), but no images are shown (because the resulting rows do not have any images). You can likely get around this by adding a filter to your view that formally eliminates any nodes that have no image from the view results (perhaps add a filter that checks if the fid of your image field is not null/empty).

Since we have now separated the part of this issue that may involve specific code change, I'll adjust the status of this issue. We can always spin-off other more specific issues if there is still something missing.

Thanks for the diagram.

I think we need to focus on that view shown in the upper-right corner of the diagram. I assume that's the view with machine name plant_pest_gallery?

It looks like that view lists nodes, filtered by content type "Plant Health: Pests", and further filtered by a contextual filter of a specific (Pest) node ID. The result would then be a single view row, representing a single "Pest" node, and then showing that single node's "Media Gallery" field. What I can't quite figure out is how you are using that as the basis of a gallery (with the view's Juicebox gallery formatter). I can only assume that there are some relationships configured on the view that are not shown or that you have unchecked the "Display all values in the same row" option for that "Media Gallery" field's settings (under the "Multiple Field Settings") fieldset.

If I assume for a moment that you are in fact depending on that disabled "Display all values in the same row" to make this work, then two things would become clear:

1. Your plant_pest_gallery view results will never actually be empty, and the no results behavior will never be fired when you embed that view as a field on your other view. This is what I was starting to conclude in earlier comments. Just because there are no images on the "Media Gallery" field (for the nid specified in the contextual filter) does not mean the view is empty, as it still contains at least one row representing the "pest" node. This means the view still triggers the Juicebox formatter, and then the formatter simply has nothing to show. To get around this you would need to add another filter to the view that checks if the "Media Gallery" field is not empty.
2. The fields defined on the file entities that are referenced in your "Media Gallery" field will not be available for use as titles and captions in the Juicebox configuration. This is because the Juicebox formatter can only leverage explicit fields on the view as caption and title sources, and in this case those fields are limited to what's available on the "pest" node. It seems like you need to leverage another relationship to get at the fields on the file entities.

I may still be missing things, but I think your plant_pest_gallery view would be more flexible if it queried files (file entities) instead of nodes, and was then configured with filters to list only the files used on a specific Pest node's "Media Gallery" field. I can't recall all the configuration details for this, but it should be possible. I think file-based views offer some sort of contextual filter based on file usage that you could use (though a views relationship may need to be setup first). The File Entity and Media views integration is pretty robust, so there should be a way to pull that off.

That's great to hear. I'm glad it's coming together.

I realise that neither the caption nor copyright allow for html. Is there a field setting to allow this from this module? I have tried my hand at the media field settings, but still getting it rendered as plain text.

For view-based galleries the formatting and sanitation settings for any fields used as title/caption sources is handled totally by views. Any settings you configure on the field itself should be respected. Are you seeing something different?

For field-based galleries (thought I don't think this applies to you) see the "Titles and Captions" section on this doc page... but again, I don't think that applies for your views case.