In computing, a plug-in (or plugin) is a set of software components that adds specific abilities to a larger software application. If supported, plug-ins enable customizing the functionality of an application.
Wikipedia
Couldn't have said it better myself!
In Quam Plures a plugin is a folder containing a few files that will magically add something to your installation. For example we have a "TinyMCE" plugin that lets you use the TinyMCE editor when writing a blog post and a "Twitter" plugin that tweets each time you post. Not everyone will want these things, some might want all of them. And some folks might want something no one has thought of yet. That's when you contact me and we work out how to get 'er done.
Plugins work by taking advantage of "hooks" in the core. A hook is basically an empty function that (typically) provides some information to a plugin, and (typically) allows some sort of action and return information from a plugin. For example the "twitter" plugin first has to get your approval to tweet in your name. After that, when you post the core tells all plugins "there is a new item in this blog" and shares the post information with the plugins. The twitter plugin takes action: it forms a "tweetcerpt" of 140 characters including a linkback to the item, then posts it to your twitter account. The plugin then returns information: it tells core "I'm done". When all plugins have taken action and returned information the core moves on to the next task.
Plugin authoring is part science, part art. Mostly art 
To write a plugin an author must first be familiar with all the hooks available in Quam Plures and what you can do with them. Need to add a style sheet or a javascript on the public side? There's a hook for that! The author then needs to be familiar with the entire scope of work for Quam Plures. "Multiple authors who may or may not be posting in multiple blogs" means the author should consider how the plugin will work for more than one author, and more than one blog. The plugin author, knowing what feature they want to add, then has to code the plugin with appropriate settings to allow each user and installation to dial it in the way they want. When I write a plugin that I intend to share with the world for free I prefer more settings than less, but that's just me. Others might prefer "function over form" and concentrate more on how it does it's job than how flexible it is.
When I make a custom plugin for a client things are different: I focus entirely on what that exact installation needs and make it happen. For example I don't need to make a variable out of your paypal account info to add easy-for-you paypal buttons when you post. Pricing this work can't be done without talking about the scope of work and giving you a range that I can work in. I do NOT charge by the line of code or hours of work! In the end the complexity of your work will drive the price.
Comment feed for this post
