So far I have built a view style plugin into this module that allows view-based galleries to be embedded into page displays, but this does not offer a good way to immediately show the result in "fullscreen" (which is something that juicebox excels at). Once the gallery is loaded it is possible to toggle into fullscreen mode via the Juicebox toolbar buttons, but it does not seem to be possible to trigger this toggle immediately when the gallery is loaded (e.g. when someone follows a link to a gallery view). A new view display plugin that uses the general fullscreen page markup ( could be implemented to add this option.


rjacobs’s picture

Title: Add view display for fullscreen galleries » Allow option to launch stright to fullscreen

A note for myself...

It looks like there might be some ways to trigger the fullscreen mode directly via javascript no matter how the gallery is embedded. For example the following might work (though only for PRO):

  jQuery("document").ready(function() {
    setTimeout(function() {

A setTimeout would probably be needed to let all the Juicebox logic load first....

Without PRO, something like the following might work:

  jQuery("document").ready(function() {
    setTimeout(function() {

This would require a long timeout as we have to be sure that not only does the main juicebox javascript load, but also that all the viewer UI parts load first (buttons, etc.). Even with a long timeout this may not be a very stable way to do things.

There are just some thoughts, it may be that the only reliable way to do this would be with properly fullscreen-friendly markup (such as a new views display plugin).

rjacobs’s picture

Ok, so the more I think about this, the more it feels like this should be handled at the theme layer, with theme overrides, independent of this module itself.

The override would need to happen to html.tpl.php, as this is the themeing level where we can "take over" all of the page output. An override of something like the following seems to work:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "">
<html lang="en">
    <title><?php print $head_title; ?></title>
    <?php print $styles; ?>
    <?php print $scripts; ?>
    <meta charset="utf-8" />
    <meta name="apple-mobile-web-app-capable" content="yes" />
    <meta name="description" content="This is a Juicebox Gallery. Get yours at" />
    <style type="text/css">
      body {
        margin: 0px;
    <?php print render(module_invoke('system', 'block_view', 'main')); ?>

This will just print the suggested Juicebox full page html, and include only the main system content block content in the body (which is where the module will be rendering the juicebox embed content in standard cases).

This template file just needs to be named correctly to become active. For view-based galleries the following html.tpl.php override file name works:


This would also work for node/entity-based galleries, but is not very practical given that each gallery is at a separate path. For this case it makes more sense to setup content-type-specific overrides, which can be done by adding the following to template.php:

// Add template suggestions for html per node type
function THEME_preprocess_html(&$vars) {
  $node = menu_get_object();
  if ($node && $node->nid) {
    $vars['theme_hook_suggestions'][] = 'html__' . $node->type;

After this, the following html.tpl.php override file name should work:


If doing this it's important to note the following:

  • The gallery configuration needs to specify 100% width and height.
  • The node/entity or view should be setup to output only the gallery content. This means any other fields that are part of a node/entity need to be hidden, the field label for the gallery field needs to be hidden, no views headers/footers (if a view), etc.
  • The gallery content must be setup to render in the main system content block (which is typically the case anyway). So this method of course won't work for views blocks placed in a sidebar, etc.

I just wanted to get my thoughts about this documented somewhere. Somebody who is more expert in clever themeing techniques may see a better way to do this. I suppose a downside of this is that a bunch of other templates (page, all other blocks, etc.) are still rendered by Drupal, but never used anywhere (which is not super-efficient)....

rjacobs’s picture

Component: Code » Documentation

For now I think it's just a matter of getting this documented.

rjacobs’s picture

Status: Active » Fixed

I just updated the project page and the readme to reference these notes. The relevant commit is:

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Anonymous’s picture

Issue summary: View changes

change some wording