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.
scbLoad4class is loaded immediately and registers its path in a global.
plugins_loadedaction 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.
Also, required WP version was bumped to 3.0.
If you want to develop a plugin using scbFramework, just download it, open
plugin.php and start hacking. This is all it contains:
<?php /* Plugin Name: scbFramework Version: 1.6 Description: Useful classes for plugin developers Author: scribu Author URI: <a href="http://scribu.net" rel="nofollow">http://scribu.net</a> Plugin URI: <a href="http://scribu.net/wordpress/scb-framework" rel="nofollow">http://scribu.net/wordpress/scb-framework</a> */ require dirname(__FILE__) . '/scb/load.php'; // The rest of your plugin code goes here
If you don’t want to bundle scbFramework with your plugin, you can use the updated
scb-check.php file instead.
I’ve moved the
debug() function and related code to a separate file to avoid errors with the Magpie RSS library. If you release your plugin, you should leave out the
I’ve recently learned that
register_uninstall_hook() allows a single callback per plugin. This meant that if you were using both
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
scbBoxesPage now require
scbUtil to work.
scbAdminPage::submit_button()accepts an array of arguments
scbAdminPagecan create top level menus
scbBoxesPagecan assign the same handler to multiple boxes, with different arguments
debug()outputs at the end of the page, only for administrators
Here is the full changeset.
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_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.
Here are the changes from the earlier version:
Admin pages generated with AdminPage or BoxesPage will be slightly faster because data is sent through AJAX.
The scbCron class has two new methods:
The scbOptions class has a new method set() that replaces update_part(). It also has a new documentation page.
Finally, version 1.3 of scbFramework only works with WordPress 2.8 or older.
Here is the list of changes.
When you need to create a new database table, all you should be thinking about are the table columns, right? Well, with the new scbTable class added in version 1.2, you can.
Creating a table is as easy as:
new scbTable('my_table', __FILE__, " id bigint(20) unsigned NOT NULL default 0, foobar varchar(100) NOT NULL, PRIMARY KEY (id), ");
The class takes care of creating or updating the table structure, as necessary.
Also, you can access it with
$wpdb->my_table, just like you would any other WordPress table.
The first update for scbFramework has an important bugfix in the scbOptions class.
The scbBoxesPage now creates perfect WP 2.8 style dashboard-like admin pages.
Also, several methods have been added and revised in scbAdminPage. Because of this, version 1.1 is not fully backwards compatible.
You can see all the changes from version 1.0.1 here.
While developing plugins for WordPress, I found that one of the most time-consuming and error prone tasks was creating user-friendly settings pages.
That is how this framework was born. It’s basically a set of extensible classes that make plugin development faster. I already use it in most of my plugins.
It requires PHP5 and WordPress 2.5 or newer.
This by far the most useful class. With it, you can create any type of form element without writing a single line of HTML.
This is a class that handles storing and updating plugin settings in a single field in the wp_options table.
This class extends scbForms to provide an easy way to create custom admin pages.
This is an extension to the scbOptionsPage class that lets you easily create dashboard-like pages with collapsible boxes.
This is a class that lets you create wp-cron schedules easier.
This class makes scbForms work with the new WP_widget class in WP 2.8.
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)
You can see a usage example by looking at the Front-end Editor plugin.