Posted by & filed under General, WordPress.

I noticed earlier today an interesting video in the WordPress.tv feed. Marc Lavallee & Wes Lindamood: Plugins are Blueprints talk about how they use plugins as a starting point to get to an end. I like what they had to say. It reminded me of what WordPress plugins are missing.

A few years ago, my thinking shifted in how WordPress plugins should be developed. Let me explain.

WordPress has evolved into a platform. You can build a site with just a blog or a project management system using the plugin API. The ways WordPress can be extended is the main reason I started using it and developing for it.

When a new feature gets added in WordPress, the core developers take into very careful consideration how both plugin developers and theme authors will want to extend it and then make it very easy to do so. They often add new hooks and filters for features that have already been in place. In short, they want the platform to be extended and make it easy to do so.

Even themes have been moving to a parent/child relationship. Many theme frameworks have been developed that at first glance are very plain. But after looking at code, you can see many hooks and filters added to make creating a child theme so much easier.

As a plugin developer, I think plugins could learn from this.

There are so many plugins for WordPress. Many are available for free download on the WordPress.org plugins site. A lot of these plugins were written by the author for a specific purpose. I think it is great that these people have released their plugins for others to use.

It is safe to say that most of these plugins were not written as a framework. Many of them shouldn’t be. Doing so would make WordPress an even more powerful framework.
legosInstead of blueprints, we should be providing ways to extend the plugins. We should provide ways to override the options panels. We should provide ways to change the behavior of a plugin. We should keep in mind that while developing plugins for a certain purpose, we can add a few more lines of code and let other developers change the plugin to do what they want.

There are various ways this can be done. Let me give some examples:

  • There are so many Twitter clients. How many of these clients have provided actions and hooks for plugin developers to quickly add custom functionality for a client?
  • I have used some plugins with many pages of options. Have you ever configured a plugin on a test site and then had to manually copy over the options to the production site? Wouldn’t it be so much easier to provide a way to disable to the options panels and configure in a ‘child’ plugin?

There are many more examples. Can you think of any?

Some plugins are doing a great job of this. Personally, I know I need to revisit some plugins and do better at this. More than anything, it requires a shift in how we are thinking of plugins.

Let’s make plugins frameworks instead of blueprints.

One Response to “WordPress Plugins as Frameworks”

  1. Luke Gedeon

    I was thinking about this the other day and then was pleasantly surprised to see your post today.

    I think the most important part of making this work is a system that let’s you “require” another plugin that you are extending.

    When someone attempts to activate a child plugin, they would be prompted to allow the parent plugin to be installed. If the user says yes, then WP can download and activate the parent before activating the child.

    The parent plug-in could possibly even have no UI at all but just provide the functionality that the child plugin can use.

    Reply

Trackbacks/Pingbacks

  1.  Preventing a Plugin from Automatically Updating | Ian Dunn
  2.  4. Los Ganchos: Acciones y Filtros – Sergio TOCA MORENO

Leave a Reply

  • (will not be published)