Drupal Association members fund grants that make connections all over the world.
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 (), 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.