Simple Lightbox already has a fairly robust framework for building administration menus and pages. However, a few pain points remain, so the admin framework is getting an overhaul for SLB’s next update.
The objectives are pretty simple:
- Make building the user interface (UI) for admin pages simple and straightforward
- Decouple UI building for external components from the admin framework
- Prune unnecessary and inefficient code from admin framework
Simple UI Building
SLB 2.0 embraced the concept of modular admin pages. Admin pages are composed of modules (meta boxes), which organizes the content on the page and makes it easier to find what you’re looking for.
This update will make adding modules to admin pages even easier. For example:
$admin->add_page() ->add_content(...) ->add_content(...) ->add_content(...)
Modules (content) are now added directly to admin pages, which is easier than having to do it through a callback. Even better, modules can be chained to the admin page instance, which makes adding modules very quick indeed.
The best part though is that it is obvious what content will be on an admin page because the modules are added directly to the admin page instance.
Decoupling the User Interface
One of the focuses for SLB 2.0 was to automate the building of the UI for SLB’s options. Options can be added, removed, and modified and the admin page is updated seamlessly. The big win here is that new features can be implemented much faster because the options UI does not need to be manually updated whenever SLB’s options are changed.
However, because of this focus, there is a lot of options-specific code in the admin framework. Not good. The admin framework should have no explicit ties to external code. Instead, this update will add hooks to allow other components (e.g. options) to handle their own UI building.
A quick example:
$admin->add_page() ->add_content($options) ->add_content(...)
If unexpected content types are encountered when rendering the admin page’s modules (such as an options instance), a hook will be fired to allow other components to handle the rendering of that module. In other words, SLB’s options framework will manage the UI for options modules on admin pages.
This also paves the way for any code to build modules for admin pages (hint: add-ons).
I’m looking forward to adding this functionality simply because it makes the admin framework so much more extensible. There’s really no limit to the type of content that can be added to an admin page!
Along with removing options-specific code from the admin framework, I will be on the lookout for any other code that is unnecessary, inefficient, or misplaced (i.e. should be part of a separate component) to make sure that the admin framework is lean and mean.
Inefficient code: you’ve been warned.
Even though most of this work will be completely invisible to users, I’m pretty excited about it. Just like the options framework added in a previous version, the refinements to the admin framework will save me from manually dealing with each new change, which lets me focus on adding new user-focused features.