This post is extremely late in coming (v1.1.1 was released several days back, and before that I released v1.1 shortly after the release of v1.0.3.4, and even further back we had the release of v1.0.3.3), but I am proud to announce the release of of WP-Slimbox2 v1.1.1.
The biggest change between versions was, obviously, from v1.1 to v1.0.3.4, but I’ll lay out everything for you. It’s about time I got around to it, anyway.
v1.1 has actually been in the works for likely over a year, unfortunately, do to medical issues as well as just a lack of time, I just kept getting started on updating it, only to find myself getting sidetracked or bogged down. Next thing I knew, I’d be going back to the code and trying to figure out what I’d just done. Meanwhile, translations were pouring in. My initial plan was to release the translations along with v1.1 of the plugin, unfortunately, as more and more time was passing I came to realize that for the most part I was just sitting on these translations instead of releasing them for the community. Sure, some people may have stumbled onto the files in our support forums, or through other means, but even more people could benefit from them if they were built into plugin by default. Eventually I got fed up with my progress on v1.1 and decided I’d switch back to the v1.0.3.3 codebase and make a much smaller modification to incorporate all of these translations. At the same time, I also chose to remove the usage of the function encodeURI because it seemed to create more problems than it solved. That small code tweak, along with the additions of Brazilian Portuguese/Português brasileiro (provided by Marcelo), Italian/Italiano (provided by Giacomo), Lithuanian/Lietuviškai (provided by Nata Strazda of Web Hub), and Japanese/日本語 (provided by ackie00h) translations culminated in the release of v1.0.3.3 of WP-Slimbox2 on Dec 18th, 2011.
Shortly after the release of v1.0.3.3 I was given yet another translation, Russian/русский язык (provided by nafanyabr). While I was briefly tempted to again wait until the release of v1.1, I looked at my code and decided it would be best to just make a small update to the v1.0.3.3 code to include the translation – thus v1.0.3.4 of WP-Slimbox2 was released on Jan 25th, 2012.
After v1.0.3.4 was released, I was determined to chug ahead and get v1.1 out, and so I focused on that. This release was massive, at least in regards to how much was changed. An extensive re-write was done that included several minor fixes to eliminate PHP warnings and errors. In most WP environments, errors and warnings are suppressed. It wasn’t until someone mentioned them to me that I realized they were there, and when I enabled their output, it was ugly. Luckily, it’s pretty easy to debug them once you’ve got them outputting. I also removed a few WordPress functions that had been deprecated, to avoid breaking the plugin at a later date. That was actually a challenge, since the deprecated function wasn’t actually been called directly from my code. Unfortunately, I’ve already forgotten what it was, or I’d share it so that others could benefit. Also added was the ability to use rel="nolightbox" to exclude an image. This served little purpose if you manually set rel="lightbox" on your images, but if you were using autoload, occasionally had an image you didn’t want the lightbox effect on this would allow you to exclude it. Another new feature that had been requested was the ability to link to a URL different than the image. I couldn’t really think of a good way to do this, but I managed to write some parsing code that would let you place a URL in front of your caption variable as so /*DESIRED URL*/. It would essentially split your URL and your caption into two pieces, and replace the images direct URL with the one you provided. Also as part of the rewrite, I took my increased understanding of Javascript, jQuery, and the Slimbox2 script to allow you to group Flickr, Picasa, and other images into the same group. Before you had to have them in distinct groups per their origin. Now, if you were autoloading your images, you could group a Picasa, a Flickr, and a locally hosted image all in the same group by choosing the correct selector. If you specified them using rel="lightbox-group" you could manually group them by using the same group name. As if this wasn’t enough, I finally got around to ditching the usage of WPlize. At the time I integrated WPlize with my code either WordPress didn’t support option arrays, or I incorrectly thought it didn’t. Either way, WPlize allowed me to group my options into an array and store them as a singular option. Conveniently, it stored the options array the same way that WordPress did (after WordPress added this ability…whenever that was). I just needed to replace the WPlize functions I’d been using with their WordPress counterparts. Unfortunately, when I did this I created a problem that would need to be fixed in v1.1.1, but I’ll get to that in a bit. Since I was already dealing with the options again I decided to make several other changes to how they were handled. In WordPress 2.7 they modified the get_option function to support a default option value. Also added was something called the “Settings API.” In short, the settings API “allows admin pages containing settings forms to be managed semi-automatically.” This actually makes for much cleaner code that is easier to later modify/add to. At the time I’m not sure I was aware of exactly how robust the entire API was, since all I wound up using was the register_setting() & settings_fields() functions, but in research since then I’m tempted to utilize more of it in an upcoming release. Anyway, settings_fields is used on the options page to link the form fields to the settings specified by register_setting. register_setting takes 3 parameters – $option_group, $option_name, and $sanitize_callback. settings_fields only accepts 1 parameter, the $option_group. I believe this is pretty straightforward, but the addition of the $sanitize_callback allows you to create a function that will review and process the settings such that they actually match what they’re supposed to, so no one feeds in invalid data. Invalid or missing data was then set to the default value. While unnecessary, since I now had a validation function, I decided I’d use it when I load the options variable as well, so I placed a call to it around my get_option call. Now, like I said above, get_option supports to new $default value. For v1.1 I chose to actually just use my initialization function call. These functions helped a great deal in ensuring that the WP-Slimbox2 settings would be valid and available even if something went wrong. I also decided it was time to remove the localization tracking I’d added shortly after I started to get translations. Not only did I not particularly care about the data anymore, I found out it may have even been in violation of the WordPress ToS…oops. I did forget to remove the actual file, but nothing was calling it anymore. Lastly, as I wrapped up my code changes I received yet another translation, this time it was Tradition Chinese/繁體中文 provided by shachi. And so, v1.1 of WP-Slimbox2 was released on Jan 31st, 2012.
Unfortunately, shortly after the release a larger number of users reported having major problems. For some reason their settings weren’t loading, and even when they tried to update them they wouldn’t save. Luckily it would function after they downgraded. Seeing as how it was running beautifully on my system, I was at a bit of a loss. For nearly a month I was wracking my brain for a reason, and then it hit me while I was in the shower. I’d actually encountered this problem once before, in a much earlier release of the plugin. The problem was that when I removed WPlize in v1.1 I also consolidated my get_option calls into one singular call at the top of index.php. My thinking was that, rather than calling it within each function I needed to use it, I’d just set it once and then access it through use of global $options whenever a function needed it. As I said, in my test and production environments, this worked like a charm. Unfortunately, for some reason that I still can’t figure out (after much searching), certain environments do not like this. As a result, when the function attempted to load the $options array, it was pulling up a non-existent variable. Obviously that would keep things from working. I quickly modified the code so that each function that needed it would populate the $options array on it’s own. In the end, I only needed this in two locations – once on the admin page, and once on the actual site page, so it should never really need to be called more than once at a time anyway. Finally, on Feb 22nd, 2012, I was able to release a fix, v1.1.1, that resolved the issues being experienced by people using v1.1. If anyone happens to know the reasons behind why I needed to do this to fix certain WP installs, please drop a comment!
I’ll be following up shortly with a post about the future of WP-Slimbox2, since I do have some plans!
