The Xavisys WordPress Plugin Framework

A few months ago I was chatting with Joost de Valk and he was talking about a new plugin toolkit that he was making. The basic idea was to make a flexible base that he could use to build on for all his plugins. It would handle all the tasks that are common to all his plugins (options page, dashboard widget, etc) and still be easily extended so each plugin could handle more specific tasks as well. Now his plugins (at least some of them) use his toolkit.

It was a great idea, and I finally got around to writing one for my own plugins. I built it as an abstract class (and a tiny CSS file) that I extend for each plugin. Here you’ll get to see a quick tour of what the framework does. Let me know in the comments if you’re interested in seeing a walkthrough of how it was built, and feel free to download Efficient Related Posts to see it in action.

Here are some of the things it does:

  • Stores plugin settings in a protected variable, making them easily available to all methods.
  • Registers the options for the plugin (making sure it works in WPMU and that options.php can handle updates to the options).
  • When an update to the plugin is available, it shows a changelog from the currently installed version to the newly available version (whether they’re one version apart or twenty).
    Changelog
  • Adds an options page for the WordPress plugin settings, complete with a page heading and a Xavisys icon.
  • Styles the options page as two columns with meta boxes (similar to the two column dashboard layout).
    Options Page Screenshot
  • Adds basic meta boxes to the sidebar of the options page, including one with a donate link, one with a link to the support forums, and one showing the latest news from Xavisys.
    Sidebar screenshot
  • It adds links to the plugin row on the plugins page. One link to the support forums and one to the plugin options page.
    Plugin Row Image
  • It adds a dashboard widget with a feed from Xavisys, complete with the Xavisys logo and a way to subscribe via RSS to the Xavisys site.
    Xavisys Dashboard Image
    Dashboard Screen Options Image

It does all this based on variables set in the extending class. For example, the setup for Efficient Related Posts looks something like this:

require_once('xavisys-plugin-framework.php');
class efficientRelatedPosts extends XavisysPlugin {
	protected function _init() {
		$this->_hook = 'efficientRelatedPosts';
		$this->_file = plugin_basename( __FILE__ );
		$this->_pageTitle = __( 'Efficient Related Posts', $this->_slug );
		$this->_menuTitle = __( 'Related Posts', $this->_slug );
		$this->_accessLevel = 'manage_options';
		$this->_optionGroup = 'erp-options';
		$this->_optionNames = array('erp');
		$this->_optionCallbacks = array();
		$this->_slug = 'efficient-related-posts';
		$this->_paypalButtonId = '9996714';
	}
}

About Aaron D. Campbell

Owner and lead developer at BlueDog, Aaron has 10+ years of web development experience, it a regular core contributor to the WordPress project, and has released many WordPress plugins.
This entry was posted in WordPress Plugins and tagged , . Bookmark the permalink.

17 thoughts on “The Xavisys WordPress Plugin Framework

  1. giovannimc says:

    Pretty interesting. In fact, I’ve been thinking about “The basic idea was to make a flexible base that he could use to build on for all his plugin” for a while. Do you have any plans in releasing a meta-framework like this? This is so great that IMHO should be integrated in WordPress Core itself.

    I really like some of your plugins. I always read the source code from plugins that I use in my installations, and yours are among the best. Keep the good work!

    • Thanks for the compliment! As for releasing a meta-framework, I’ll probably tweak it some more and see what else it should do. For example, I think it should probably handle the uninstall functionality, removing all settings, etc.

      I’m not sure it’s really core material. After all, it does change quite a bit from plugin author to plugin author. Maybe it would be good as a resource on the new developer resource that Matt Mullenweg’s been talking about.

  2. shawn says:

    Did you ever decide to release this?

    From what I can tell from the plugin source code, it looks like this would make building plugins so much easier than it is now.

    I’m curious what other input type of fields have been built into the framework as well, media etc…

  3. Davit says:

    Cool. I was thinking of something like that for a long time too. Today copy/pasting just another plugin with similar blocks I suddenly realized that there already should be some frameworks… or at least efforts to create them.

    I do suspect that advanced guys already use them widely. One thing that I think will be really great to see in a plugin framework is MVC. Throwing the whole logic into one class looks pretty dirty to me, no?

    • In my opinion, using MVC for something so small and simplistic as your average WordPress plugin is simply overkill. They require extra files and add considerable complexity to what is currently a very simple system.

      If you’re building something like an E-Commerce system or some other larger application that’s powered by WordPress, then I could understand it. For 99% of all WordPress plugins, it’s just not needed.

      • Jason Nathan says:

        True, it would only be needed for complex plugins like CRMs or similar. I made a router class – approaching a little different and put it up in a post on my blog.

        You can have a look at it in the website above…

        • Davit says:

          At the end I’ve came up with routes and router as well. And yes, my plugins are mostly very complex and without MVC or any other way of strict organization I tend to get lost in functions and files and spent most of my time and efforts keeping it my head.

          • Jason Nathan says:

            I agree. It’s exactly what I’m going through right now! It is especially problematic when people create complex plugins and mash html, css and php together. Mind bloggling task to debug

  4. Mike says:

    Any new advancement on the framework?

    There is a new CMS coming out built on top of the Recess MVC framework that is worth looking into if you are interested in structured and powerful plug-ability. However, until their 1.0 release, we are stuck with WordPress being the big-dog in town, and this kind of a framework would be pretty awesome.

    It’s a pretty epic project. I did some work with the guys on it (HiFi CMS) and I have been working with the Recess Framework for about a year now. If it gets enough notice I am sure it will revolutionize this stuff. (http://www.gethifi.com)

    Anyway, enough of the plug already, how’s your framework coming?

  5. eddie says:

    how is this idea progressing? I’m interested in seeing a walk through.

    i searched joost’s site for any mention of his plugin toolkit and found nothing…

  6. George says:

    Thanks for your work and make it free.

  7. FX Siteworks says:

    Hi Guys,

    Like some of the other commenters on this post, I too am keen to see how this idea has progressed, but cannot seem to find any info on it on the sites.
    Any plans to post on your developments since this was originally aired? Is the project still ongoing.

    It did look so full of potential….

    Cheers

  8. Milen says:

    Hello, how do you change the style of the bullets? I want to add bullet image?

  9. I discoved your framework when looking at the source code of Twitter Widget Pro, an interesting idea. I think I agree with the others that it’s possible got a little much in it. It does not seem to reduce the amount of code needed in the main class.

    One thing that does seem to be lacking for wordpress developers is the display of the admin UI. All the examples I’ve seen are switching back and forth between PHP and HTML which can’t be very efficient.

    _slug); ?>
    <input id="twp_username" name="twp[username]" type="text" class="regular-text code" value="_settings['twp']['username']); ?>” size=”40″ />

    • Amereservant says:

      Actually, it’s better to exit PHP when rendering pure HTML because it avoids the PHP engine having to process the HTML when it’s not necessary. How much difference does it make? I’m not sure, but I can read HTML as HTML a lot better than I can several lines of echo …., which gets messy to maintain.

      But yeah, it’s taught as being better to exit PHP when outputting straight HTML.

Leave a Reply

Your email address will not be published. Required fields are marked *

Note: If you are replying to another commenter, click the "Reply to {NAME} ↵" button under their comment!