My little framework continues to evolve along with the plugins that use it.
I’ve dropped the traditional X.Y versioning method and opted to use the internal revision number instead.
The most important change since the last release (1.6) is that there’s a new method through which the framework loads its files.
The scbLoad4 class is loaded immediately and registers its path in a global.
When the plugins_loaded action fires, the framework loads the most recent version of its files.
At first, only the scbLoad4 class is loaded. Then, after all plugins are loaded (plugins_init action), and then loads the most recent versions of the framework files available, according to the revision number. The tricky part was getting the activation hooks to fire in these conditions.
The scbQuery class was replaced with scbQueryManipulation. More on that soon.
The scbRewrite class was removed, since it didn’t really do anything useful.
I’ve recently learned that register_uninstall_hook() allows a single callback per plugin. This meant that if you were using both scbOptions and scbTable, for example, when a user uninstalled that plugin, either the option wasn’t deleted or the table wasn’t dropped.
This is now fixed by using a new method, scbUtil::add_uninstall_hook(). It also prevents multiple UPDATE queries to execute on each page load.
This also means that scbOptions, scbTable and scbBoxesPage now require scbUtil to work.
new methods for scbOptions: get_defaults(); cleanup(); __isset();
new method for scbAdminPage: page_help();
scbAdminPage::submit_button() accepts an array of arguments
scbAdminPage can create top level menus
scbBoxesPage can assign the same handler to multiple boxes, with different arguments
debug() outputs at the end of the page, only for administrators
The plugin toolkit has been getting a lot of useful classes recently, so I though a version bump was in order.
scbUtil is a collection of useful little functions that I was using in a lot of my plugins. My favourite is the debug() function. Then there’s html() and html_link() for HTML generation. There are several other useful bits in there, but you’ll have to discover them yourself.
One of the areas I wasn’t comfortable working with was the Rewrite API. The scbRewrite class was distilled from a discussion on wp-hackers. It’s only job is to take the rewrite rules you specify and hook them in all the right places.
If you would like to “try before you buy”, you can browse the source here.
Before making this framework public, I used to include the files with each plugin. As the number of plugins increased, I had to update each one every time I modified the framework.
After a while, I found a way to make all plugins on an instalation use the most recent framework version installed. This didn’t help much.
Finally, I made it a standalone plugin which you only need to install once.
So, currently, there are two possibilities:
As long as the scbFramework plugin is activated, your plugin will work perfectly. If you want to spare users from ugly error messages, you can include a small file, called scb-check.php. It will check that scbFramework is installed and if not, it will deactivate your plugin and display a friendly notice with an install link.
Including class files
If you don’t want to require users to install the standalone plugin, you can include all the class files with your plugin. You will also want to include another file, called load.php that takes care of autoloading classes as needed. (It will have to be placed in the same directory as the class files)