I have been debating the various merits of Lightbox, jQuery Lightbox, Greybox, etc. Obviously, Lightbox2 is becoming the swiss-army-knife of lightbox-style modules. Choosing between these modules is difficult, to the point where numerous (very good) comparison articles leave you *still* guessing what to do.

I was also reading the proposal to merge jQuery Lightbox and Lightbox 2 (#205907: merge with jQuery Lightbox module ?), which would seem to be to be mostly irrelevant, as Lightbox2 is a superset of jQuery lightbox and I can't imagine what "merging" would mean.

But the larger issue is that Lightbox2 is simply getting too feature-rich and there are too many interdependencies between Lighbox and the modules which use it (frequent references in other modules to whether or not lightbox/thickbox is present, and conditional code to use its features).

I would suggest a split into two modules:

  • Lightbox2 API - a module which provides fundamental Lightbox2 integration, perhaps with imagecache support, and robust hooks for extensibility, being as forward-looking as possible to D7 and beyond. It would include hooks to register your own rendering functions so that each module that supports lightbox could manage the lightbox pop-up content itself. So, formatters like theme_lightbox2_formatter_emimage would not be part of Lightbox, but rather registered by emimage using a hook provided by the API.
  • Lightbox2 Extras - a module which provides all the extra features currently embodied in Lightbox2, using the API. Features such as video support, visual effects, automatic image detection, login support, zoom capability, skin and animation configuration, etc. Obviously these could be many additional modules, but creating a single "plug compatible" extras module makes delivery simpler and saves time and consideration for those who need to upgrade.

This simple separation would have many advantages, and if this has already been discussed elsewhere, I apologize for being redundant....

  • Ability for those who have custom content to be displayed in lightboxes to integrate easily using the API.
  • Eliminates baggage which is not needed by some implementations (we, for example, have our own video modules).
  • Eliminates ties between Lightbox and other modules. For example, many video modules and many image modules could support the API without the API having to support or know about them. The code is currently littered with module_exists() checks.
  • The API module can focus on longevity and upward-compatibility.
  • The extras module can focus on supporting short term ways of doing things (for example, perhaps maintaining many of the cross-module support features present in Lightbox2 now). That way, the API is not corrupted by adding more and more features, yet support for the current (very desirable) featureset can continue.

This split would make it possible to maintain strict upward compatibility. So, if people were using Lightbox2 today, they would simply use Lightbox2 API + Extras and their site will operate unchanged.

I have a lot of personal dev stories that led me to this conclusion. They would probably bore you and may be only relevant to our project, which uses Lightbox extensively for managing the thousands of videos on our new site. However, suffice it to say that jQuery lightbox is very lean and simple, and provides almost all we need.... if only it had ONE OR TWO features of Lightbox2 + some extensibility for our own video modules. So, jQuery Lightbox almost feels like a "lean API" module, except that it has no extensibility.

I will feel really stupid if there is a huge discussion somewhere that makes this post irrelevant. But, it just seems like an obvious direction to me and I figured I might as well write down my thoughts.

Members fund testing for the Drupal project. Drupal Association Learn more


stella’s picture

Version: 5.x-2.x-dev » master

A similar discussion has being going on offline between sun and myself. Our plan is to restructure lightbox and make it more modular for Drupal 7.

garywiz’s picture

Maybe it will be useful food for thought or maybe not, but over the last two days I put together a prototype implementation of an extensible "Litebox-style" framework which demonstrates exactly the kind of things I was talking about above.

The module(s) are attached, and have the following features:

  • A lean API which allows any number of presentation interfaces such as Litebox, Thickbox, etc. and any number of data source interfaces such as video, images, html pages, etc.
  • A very clean separation between modules which provide display technologies and those which provide data to be displayed.
  • Implemented so that code is loaded only when needed by a page. So, there is almost no overhead in having many extension modules if they are not actually used on pages.
  • Built using a reasonably robust inheritance mechanism similar to the way views is built.

Included in the prototype package are the following modules, each designed mostly to demonstrate a feature of the API:

  • ShowMe API - provides the basic framework. Required. The rest are optional modules.
  • ShowMe Lytebox Presentation - uses Lytebox (a Lightbox2 derivative) to display graphics or html content.
  • ShowMe Browser Window - provides an extremely simple "targetted browser" window as an alternative to Lytebox.
  • ShowMe Link - provides support for "link" types so that pages can be displayed using any available presentation module.
  • ShowMe Image - provides support for images in imagefield or filefield fields, and automatically creates formatters so that link and presentation presets can be chosen.
  • ShowMe Text - provides basic text fields as data sources (this truly is useful only as an example).

Yes, the name ShowMe may be strange, sorry... but at least implies the purpose. The API is designed so that presentations do not have to be visual and can present data in virtually any MIME type. So, for example, presentations could be developed that play audio files when links are clicked, or create PDFs, etc.

We have also added a ShowMe provider interface to our internal video modules. We have our own player and video server API so these modules are not useful outside of our system. However, it was enough to prove to me that the API is robust enough to handle video easily.

Installation is simple. Enable the modules, and you should instantly find new field display options present for existing fields. There are no settings whatsoever. However, during implementation it was obvious that some of the sub-modules could benefit from some customization settings, but none of that was needed to create a demonstration. Also, there is no consideration for "user login" or "contact form" providers, though those could be implemented as well after considering how such "link scraping" additions should best be done in a generic fashion.

Of course this code is free for anybody to do anything they want with, or nothing at all. It is a prototype, really just for discussion or experimentation. Though I have tested it thoroughly, it has only been used in a limited environment and of course there are bugs. But, I believe it works well enough for demonstration purposes. My environment:

  • Drupal 6.14
  • Firefox

Some of this has been based upon various bits of code and the good examples of how to do things set in the Thickbox, Lightbox2, and jQuery Lightbox modules, but it is mostly new code.

Note that I have never contributed any Drupal code, nor do I really have any plans to do so. So, I expect that there are coding standards gaffes and I am certain there are things which could have been done much better if I were more familiar with the Drupal core APIs.

Let me know if it is a useful demonstration of the concept.

garywiz’s picture

This is an updated version with changes in some function names, terminology, and comments about how things work. The terms source, target, provider, presentation were not used consistently. This is the version we are now using in our internal development.

mikeytown2’s picture

+1 for doing this. Example of this working very well IMHO: http://drupal.org/project/wysiwyg.

stella’s picture

Assigned: Unassigned » stella
Status: Active » Needs review

First of all, thanks for all the amazing work you've put into this. It's been something I've been meaning to do for the past year but never gotten around to.

I'm crazily busy this week with a site deployment, but I promise you I'll take a look at what you've provided next week.

garywiz’s picture

Glad to hear you think it's on the right track. I am crazily busy with site development as well, so take your time. But, this module is part of our new site so we will be working out bugs and I will provide an update if anything significant changes. As far as what to do with it, I'll wait until you get a chance to take a look.

sun’s picture

Alan D.’s picture


Alternative approach:

As most of the JQuery plugins follow the simple paradigm HTML, I was about to look at writing something that would have allowed me to chop and change between the image lightbox plugins at will. There are currently 116 Window & Overlay plugins listed at http://plugins.jquery.com/, although only 30 or so are relevant here. My search of existing issues / projects lead me here.

From briefly looking at the code, this doesn't appear possible using this approach, as each lightbox plugin would end up with it's own formatter. Not a big deal in small sites, but if you have a site with 30+ content types and 3 or 4 shared ImageFields, this becomes a large undertaking.

Simply put, would it be best to create adapter functions between standard Drupal formatters and the chosen popup / overlay / lightbox plugin? Just like WYSIWYG with textareas.

E.g. External links can be easily located via JScript and then targeted to a specific display plugin (target=_blank, add class FancyBox, etc). Related projects; http://drupal.org/project/extlink & http://drupal.org/project/external

Images from specific imagecache presets also have classes to target, making it trivial to add lightbox triggers. Galleries are a bit more difficult as there is limited native markup to use, but carefully designed #pre_rendering functions would probably resolve this limitation.

@gary - If this gets released for Drupal 6 with the code above, you should place a PHP 5 warning + restriction in your info file. [Just to appease the 17 or so PHP 4 users still out there.] The code you provided is generating multiple PHP warnings too, as the array keys 'ShowMeDataProvider' and 'ShowMePresentation' are not always present in the results from showme_api_get_class_info().

garywiz’s picture

Thanks for the comments everybody, and the alternative approaches. Now that our project has calmed down, and our site has been running for a while, I am considering creating a proper module for release.

Alan... your suggestions are interesting, but one thing that is worth noting is that the ShowMe API makes it possible to completely revise the way both the source and targets are handled, making it possible to do things like play audio media using non-Js techniques. So, I'm not sure I'd like to bind it too tightly to Jquery.

The solution isn't perfect though, and it favors a "formatter based" model. I have to look at D7 to make sure that the fundamental ideas behind the way formatter classes work is preserved, so I will probably get all this working in D7, then backport it to make sure the implementation favors D7.

patcon’s picture

(thanks for the heads up mikey!)

patcon’s picture

Hey gary,

Not sure if you're willing to compromise on the name, but snufkin reserved a cool namespace and has started a project with a similar premise:

As in *box. Seems pretty clever :)

Nothing really committed yet, but perhaps you guys could work together with your code?

++ to Alan's comments though, for the record

stella’s picture

I emailed garywiz last week some time about this - still waiting to hear back. Starbox is still at a very early stage. We want to ensure we plan it correctly from the start to account for all scenarios - unlike lightbox2 which has grown very organically.

patcon’s picture

awesome. thanks stella. I'll try to keep watch on Starbox and help if I can :)

lpalgarvio’s picture

thats good news :)

meanwhile, perhaps patch the code to separate Lightbox2 js scripts from the module and place them in /sites/all/libraries ? maybe even support Libraries API?

Colorbox (the replacement for thickbox) already did both (dir and API) for the colorbox scripts.

and Shadowbow requires that the shadowbox scripts be in /sites/all/libraries, but doesn't support yet Libraries API.

that could be a step forward (or backward depending on perspective)...

garywiz’s picture

Stella, sorry I actually must have missed your email or I would have replied.

We have been using the "Show Me API" that I mentioned above on our site (http://treet.tv) for about 8 months and it has been working great for us. We've extended it to have ipad support as well as many other "plugins" to allow us to display lots of different kinds of information.

There was never enough momentum to formalize the module here on drupal.org, though the code was written for that purpose.

I'll take a look at starbox though. Maybe it will provide something for our next version.

Fidelix’s picture

I'd like to see this awesome idea done.

Hania1973’s picture

Component: Code » User interface
Assigned: stella » Unassigned
Category: feature » support

Hi, I hope it is OK to post here. I have just integrated lightbox2 into my website, www.wavecrestscuba.com on the gallery page and while I am impressed by its speed and useability I can only use 5 albums, everything I have added after will not show properly when lbx2 is activated. Am I missing something in the way I have implemented it or is this a bug?

Any help would be greatly appreciated

Fidelix’s picture

Component: User interface » Code
Category: support » feature

Hania1973, are you serious?

If you have a problem, create a new issue for it, and don't hijack issues.

patcon’s picture

Hi Hania,

Sounds like you might be new to issue queues, but they are used by modules (and software projects in general) to organize feature requests, bug reports, and specific support questions that may be of value to others.

It's considered very bad etiquette to enter into one issue thread and ask a question unrelated to what everyone else is talking about. If you're going to open a new one, you're expected read through any README/installation files that come in the module folder, as well as any supporting documentation listed on the project description page:

If you read through and it doesn't resolve your problem, then you are best to ask a support question in the interest of helping to clarify the documentation for everyone. You should test the plugin in it's simplest sense (to be sure the issue is with the module and not some other module), and you should provide as much relevant detail as possible to that people can reproduce your issue in as little steps as possible (since they're not rebuilding your whole site).

Yeah, this is a bit of work, but when you ask a question, you're asking potentially multiple strangers to take the time to help you, so there's the expectation that you'll do your due diligence in research and explanation.

But like it was already said, please continue this elsewhere :)

(I don't know lightbox, and so am not the person to help with your specific issue.)