SLB: Options Overhaul
The beta testing of Simple Lightbox 1.5.4 is coming to a close, with the final stable version scheduled to be released tomorrow. I’m blown away by the great feedback I received from users who were willing to test the beta to help work out any issues. This is the second time I’ve done a beta release of SLB, and I readily admit that I was quite surprised by the participation and the feedback I received. Several bugs were found, and we ended up working our way towards 5 beta releases, the most recent of which was released today.
I’m still not where I want to be in terms of running the beta tests as smoothly as possible, but I do have some ideas to make sending me feedback (reporting bugs, etc.) much simpler. I’m hoping to have some of these ideas implemented by the next beta release and I’ll do a writeup on them once I the ideas are fleshed out a bit more.
I wasn’t just sitting pretty waiting for feedback on the current beta version of SLB today, but instead started working on the next version with a few major changes in mind.
Options Management
The first major task in the next version will be an overhaul of the options management. I put a good deal of work into this functionality while working on Eyes Only, so I had been planning to simply migrate that code over to SLB. However, as I created the specifications and requirements for the options management functionality, I realized that I may need to rethink my plan.
A single option has several properties:
- ID – Unique internal name for option
- Label – Public facing option name
- Description – Additional instructions/description for option
- Default value – An option’s value upon initialization
- Value – User set value for an option
- Parent – The parent option (useful for conditional activation of options)
- Group – The group that an option belongs to
As I reviewed the option’s properties, I realized that this actually looks more like the field definition for Cornerstone’s content type functionality. Cornerstone’s field management code is quite robust, so I am going to evaluate that code for migration into SLB. Honestly, I’m still not quite sure if it’s overkill, but I when it comes to flexibility, I tend to get a bit carried away.
At any rate, my deadline is to have something implemented and working by tomorrow, so I’ll either adapt code from Cornerstone or Eyes Only.
Attachment Compatibility
One of the main issues that have kept Simple Lightbox from being as simple as possible is that, by default, WordPress will insert a link to an image’s attachment page as opposed to the image’s source URI. This has led many users to be confused as to why no lightbox is displayed when they click on an image that they inserted into a post. Users familiar with how lightboxes work will know that the reason for this is that lightboxes only work with direct links to image files. However, I don’t think that the average user should need to know this detail, so the 2nd major task for the next version of SLB will be to make it compatible with an image’s source URI and attachment page. Essentially, this means that regardless of how a user has inserted an image into a post or page, Simple Lightbox will work with it.
I’m not sure how much of a hassle this will be to implement, but I have some ideas that I’m going to explore over the next few days, so I should have something to report by Friday.