WP-Slimbox2 v1.0.1 Released!

That’s right, another update already! Unfortunately, this one was to fix an issue some users were reporting regarding an error after installing the plugin that sadly made their sites unusable. I hope everyone who was experiencing that issue has since upgraded and can get back to enjoying the benefits of the plugin.

Several users reported errors similar to the following:

Fatal error: Call to a member function get_option() on a non-object in /var/wordpress/wp-content/plugins/wp-slimbox2

In each case, it appeared that for some reason the $options variable, which was declared as a global variable, was not being properly recognized as an object. I don’t know why this is, though I suspect it’s tied into either the version or the settings of PHP being used on the host. This would explain why several users had no problems, and several others did. In one case someone had no problems on one site, but on another site they did.

If anybody can explain to me why this is, I’d appreciate it. Either way, I was able to resolve the issue by just recreating the variable in each function. This seems to me like it would be less than ideal, but someone else informed me that WP already caches options after fetching them, to minimize calls to the database, and so by recreating the object, I’m just pulling from the cache, or something like that. It works, that’s the important thing!

While attempting to diagnose the problem I also discovered a tiny glitch resulting from one of the new features I’d added. The grouping of autoloaded images wasn’t correctly grouping my images by post anymore. The original code was written as follows:

slimbox2_options.selector = "div.entry-content, div.gallery, div.entry, div.post, div#page, body";
return (this==el) || ($(this).parents(slimbox2_options.selector)[0] && ($(this).parents(slimbox2_options.selector)[0]==$(el).parents(slimbox2_options.selector)[0]))

I misunderstood this to mean that it would search through the parent elements for each image, and progressively search for an element that matched the selector. In this case it would look for a div of class entry-content, gallery, entry, or post, as well as a div with an id of “page” and if that all failed the body element. In actuality, while this would do that, it would also sort the results, which screwed them up. I revised the code as follows:

slimbox2_options.selector = "div.entry-content, div.gallery, div.entry, div.post, div#page, body";
return (this==el) || ($(this).closest(slimbox2_options.selector)[0] && ($(this).closest(slimbox2_options.selector)[0]==$(el).closest(slimbox2_options.selector)[0]))

I could even drop the [0] as closest only returns a single element anyway. This function actually searches for the first parent element that matches the selector, not all of them. If it finds a gallery first, that’s what it returns, if it finds entry-content, that’s what it returns, etc. This would allow a bit more granularity in the selection, and also better enable out-of-the-box support for more users and themes.

The downside to this change is that closest was introduced in version 1.3 of jQuery, which WordPress didn’t include until version 2.8. I’d hope most people aren’t hanging around updating their plugins and not their WordPress install, but you never know. If someone actually did want to do that, they could change closest back to parents, and just be more specific with the selector.

As translations are updated, or added I plan to make a few more minor releases, but hopefully I’ve got all the main things in now.