Update: Simple Lightbox 2.0 has been released. Get it now!
Thanks to the incredible feedback from users, Simple Lightbox 2.0 Release Candidate 3 is now available and full of fixes and optimizations.
For the uninitiated, a release candidate is a version that is considered ready for official release. All features are finished and there are no known bugs. As there are many users with widely varying server setups who depend on Simple Lightbox to work without issues, release candidates are vitally important to make sure the kinks are worked out before releasing a new version to the masses.
Most of the optimizations in this release were focused on client-side functionality.
Improved Validation and Deferred Loading
To resolve this issue, all of SLB’s client-side code now has improved validation to make sure that the necessary components have been loaded prior to execution. Now caching plugins can do whatever they want with file loading and SLB should not miss a beat. At the very least, SLB should no longer throw any JS errors due to rearranged files.
The contexts in which SLB would load code in the WP’s admin have been refined so that SLB only loads when it is absolutely necessary. Aside from being good for performance, this should also help to avoid conflicts with unexpected code on other admin pages.
Except, everyone is doing it.
Extending prototypes is now dangerous– especially if you do it “safely” by checking to make sure that a method or property doesn’t already exist before you add it. If another library has already added a method using the same name, then your custom method will not be added. You can see how things can quickly go downhill from there.
These days, it’s far safer to create your own private class of methods or make use of a standard library (e.g. jQuery). In RC3, all of SLB’s prototype extensions have been removed or refactored so that they no longer modify an object’s prototype. This is a better way going forward as it isolates SLB’s code from potential issues introduced by conflicts with other libraries.
One of SLB’s unique features is that it uses the captions and other data you’ve set in WP’s media library when displaying an item in the lightbox.
However, it’s likely that you won’t always want to use the stored caption when displaying an item. Perhaps you want to use the stored caption for one post, but display the same item in another post with a different caption?
If so, it will require some HTML editing, but if you’re brave enough for this, SLB will reward you.
Simply put, if you edit a link’s
title attribute, SLB will use this value above all else when displaying the media from that link a lightbox.
If you can’t imagine why you’d want to do this, don’t worry, SLB will continue to work as it always has for you. This update is for the hand-coders in the house, yo.
Bonus: This also works for custom captions! When you insert an image from WP’s media library with a caption, the stored caption is inserted as well. If you update this caption in the post editor, then your custom caption will be used (that is, if you haven’t also set a custom value for the link’s
As a reference, here’s the order of precedence for how SLB chooses what to use as a caption in the lightbox:
- Manually-set link
- Manually-set caption
- Caption field from WP’s media library
- Title field from WP’s media library
- Link text
Now your dreams of customized lightbox captions can be fully realized!
Increased Hit Targets
Small but nice: the area of the default theme’s hit targets for the previous/next navigation buttons have been increased so that it is even easier to navigate between images. Personally I like using the arrow keys to navigate through slideshows in the lightbox because then I don’t even have to use the mouse, but if you’re the mousing type, then this one’s for you!
Though bittersweet, it’s always good to find some bugs to squash.
SLB user KevinPlusPlus rightly pointed out that the font loading (from Google’s Web Fonts) in SLB’s default theme may cause a message to be displayed when the rest of the page is loaded over HTTPS. The theme’s font is now loaded using a protocol-relative URL and the fix shall be forever known as “Kevin’s Theory of Relativity” for KevinPlusPlus’ contribution.
SLB user AnilAdvani reported that grouping was not working for galleries, which turned out to be due a conflict with Prototype. Prototype adds a custom
Object.Wrap() method which blocked SLB’s custom
String.Wrap() method (as
String inherits from
This was the first issue that precipitated the removal of all custom prototype methods as mentioned above. Thus, the fix shall now be known as the “Prototype Anilator” fix in honor of AnilAdvani’s contribution.
Gravity Forms Compatibility
Once again, custom prototype methods show their true colors, this time as a conflict with Gravity Forms as reported by Lucy Beer.
While I can’t say why Gravity Forms would be iterating over an array with a
for-in loop (more apt for iterating over objects than arrays), this was another issue that was resolved by banishing all custom prototype methods from SLB.
In honor of the Lucy’s contribution, the fix shall forevermore be known as the “Lucy’s in the Sky (without Gravity)” fix.
Overlay Opacity, where art thou?
SLB user zephyr88 reported that a user’s overlay opacity setting was no longer being used by SLB. How could this be?
But it was.
So I fixed it.
In honor of zephyr88’s contribution, the fix will be henceforth be referred to as the “Unseen Zephyr” fix.
2.0 Final: Knocking at your Door
I’m externally grateful (yes) for all the feedback I receive from brave SLB users. SLB would definitely not have come this far without you.
As always, it’s totally cool if you’re not comfortable with installing a beta version or even a release candidate on your site. You’ll just have to hold off from experiencing SLB 2.0 goodness for just a little bit longer while our brave testers kick the tires on these release candidates.