After the best beta testing phase thus far, Simple Lightbox 1.5.5 (final) rolls out with a heap of new features, fixes, and updates.

Options Overhaul

Though additional features were added during the beta phase, overhaulin’ the internal options management code was my primary focus of this release.  Let’s take a short trip down memory lane:

• May 4, 2011: A few days before Simple Lightbox 1.5.4 is released, I muse about my plans to update Simple Lightbox’s options management code.  At this point, I was intending to migrate the options management code from Eyes Only over to Simple Lightbox because it was far better than what I was currently working with in SLB.  At the same time, I developed this code for Eyes Only some time ago and wasn’t sure if would meet my current requirements for a robust options management solution.  By the end of this post, I was already considering the completely different approach of using unrelated code from Cornerstone to improve options management.
• May 16, 2011: Over the next week, the beta phase for SLB 1.5.4 comes to an end, and I turn my focus fully to analyzing the viability of CNR’s code.  My conclusions were mostly positive, but there would also be a lot of work to strip down CNR’s code and adapt to SLB.
• May 17, 2011:The next day, I had CNR’s code considerably slimmed down and working as a mere options manager in SLB.  CNR’s code was pretty purpose-specific though so there was a lot more reworking yet to be done.
• May 26, 2011:A little over a week later, I declared SLB’s options management overhaul to be complete.  I noted that it took longer to complete than expected, but I consider this time well spent because my mission was to create highly adaptable code that could be applied to my other WordPress plugins as well without any reworking.  What I ended up with is a Fields class that is suitable for use as a base for a myriad of duties ranging from options management, to content type meta fields, and even dynamic form building for future plugins.  This was a big change in SLB’s codebase, so I started working to make sure the first beta was as stable as possible (read on to find out how that went).
• May 30, 2011:Public beta testing for SLB 1.5.5 begins…in the worst possible way.  In my zeal to get the new code out to users as quickly as possible, I release the beta with a bit of debug code that unfortunately crashed sites.  Not the type of beta feedback I like getting.  However, as a result of this failure, many lessons were learned and safeguards were put in place (more on that in a bit) to avoid issues like this in the future.

In the end, I’m insanely happy with having this new code as the backbone for SLB’s options management.  It’s a lot of code, so I don’t particularly look forward to migrating it to my other plugins, but that will be one of my next steps.

Attachment Compatibility

It wasn’t actually planned for version 1.5.5, but my curiosity got the better of me and I started looking into making SLB compatible with image attachment links in WordPress after releasing beta 2.   This is actually the feature I am most proud of for this release as it resolves a point of confusion for many users.

When inserting a linked image (e.g. a thumbnail linked to the full size image) into a post in WordPress, you have the option of using the File URL or the Post URL.

Multiple Link Types

Unfortunately, is not obvious to the user what the difference is between these two URLs are and if the user doesn’t make a selection, then it will use the link type that was last used (I believe the Post URL link type is used by default).  Up until this point Simple Lightbox worked specifically with links directly to images, so a user would have to have selected to use the File URL when inserting the image in order for the linked image to be opened in a lightbox.  This resulted in many users asking why SLB wasn’t working on their images as they were unknowingly inserting images using the Post URL, which pointed to an attachment page.

I believe that users should not need to know the ins and outs of the technology they’re using in order to use it effectively.  Good technology would allow users at all levels to benefit from it.  I had no interest in educating users on how SLB worked so that they wouldn’t have problems anymore, so I set out to solve the problem itself.

A couple days later, I released version 1.5.5 beta 3, which included support for image attachment links.  Now users can insert image links using either link type and the SLB will work with both.  Using the Post URL link type is now especially useful because visitors will be forwarded to an attachment page, rather than just a raw image, if SLB is ever deactivated.

Lessons Learned

As mentioned earlier, the initial beta release for version 1.5.5 did not go nearly as smoothly as I would have liked.  However, despite the frustration and stress of making things right, I learned many valuable lessons that have made my development and release workflow much stronger:

• Be Available– The work isn’t over once a new version is released– it’s just the beginning.  Right after a release is the most important time to be available as the first users update their versions and the reports start rolling in.  As excited as you are to get new code out to users, it is a bad idea to make push out a release when you won’t be around to respond to issues with the new release.  In short, don’t release a new version before heading out the door, going to a movie, or going to sleep.
• Test against clean installs of WordPress– Previously, my testing was fairly involved, but it all took place on the same server that I develop the plugin on.  Now, I have a development site set up on my server of clean installs for every WordPress version my plugins support.  Once I reach a point where I’m ready to release a new version, I test the code on each version before releasing.  It would be great to just test on the latest version of WordPress, but I know that a lot of users don’t upgrade to the latest version immediately (even I don’t), so if I’m going to claim support for an older version, I need to test to make sure my plugin works on those versions.
• Test with PHP 4 and PHP 5– More and more hosts are providing PHP 5 as the only option, which is a good move in the right direction.  However,  as WordPress 3.2 (currently in beta) is the first version requiring PHP 5, there is a good chance that users of earlier versions of WP are running PHP 4 on their server.  Much of the inner workings of PHP have changed between version 4 and version 5, so it is a good idea to test on both versions prior to releasing.
• Stay consistent, make a list–To make things easier, I’ve made a checklist using Todoist to cover all the bases prior to releasing a new version of a plugin to the masses.  This helps me stay consistent and make sure I haven’t forgotten or missed something in a release.
  

  Release Checklist

Next

Beta testing for SLB 1.5.5 was the best thus far because of the brave beta testers and the awesome feedback they provided to make this version filled with more new features, refinements, and fixes than any previous version.  The small hiccup at the start of this beta phase proved that you testers are truly the bravest around and this release wouldn’t have been as awesome without your input.

The primary focus of the next release of SLB will be additional refinements and functionality for themes, which will provide solutions for much of the recent feedback and requests that users have sent in.