In the early days of computers, there was a 1970s-era mainframe called the UNIVAC Series 90. The Series 90 ran the Unisys VS/9 operating system and sported the EDT text editor. EDT had the unique ability to store a running program in its buffer, allowing external programs to access the session in memory. This “plug-in” program was commonly utilized by the Waterloo Fortran compiler to allow interactive compilation. Shortly after that, plugins began to appear in other software, notably HyperCard and QuarkXPress. In 1988, Ed Bomke coined the term plug-in to describe any piece of software which was designed to extend another application.

Despite its early beginnings, neither the word nor concept took off until the advent of Mozilla Firefox in 2002. Firefox was the first application to support the genuinely flexible plugin model that we know and love today, but it was far from the last. Today, various forms of the plugin system can be found in desktop software such as Microsoft Office and virtually all modern web browsers, as well as many web content management systems.

So… just what is a plugin? It’s a piece of software which adds additional functionality to the software with which it is designed to work. Since we’re predominantly interested in WordPress (this is a WordPress blog, after all) let’s focus on the relevant context. I would hope that everyone knows at least a little bit of the history behind our favorite platform. WordPress began in 2003 as a simple fork of b2 cafelog; thus, it was designed to be a blogging platform. Throughout the years WordPress has grown, and so has its plugin repository. Today, it supports well over 36,000 plugins and counting and is capable of doing significantly more than simple blogging.

Now that we’ve established that plugins extend the functionality of WordPress, what about themes? The frequently add functionality right? Well, yes, but no. Plugins add functionality, themes handle global design elements. Yes, some of them include functionality (which, by the way, is a hotly-debated topic), but the core purpose of a theme and a plugin are two drastically different things. I believe that themes shouldn’t include any functionality outside of that which is required for their use to the website. In other words, a theme designed for podcasting may need an audio streaming or playing interface integrated tightly into it to accomplish its purpose. In this case, I’m OK with that functionality being part of the theme. The same theme, on the other hand, probably doesn’t require a custom page builder to function. This type of “convenience” functionality belongs in bundled recommended plugins, not in the core of the theme itself.

This one <em>really</em> gets on my nerves. Lately, I’ve seen many people asking whether they should “install a widget or plugin” to achieve specific functionality. In the WordPress ecosphere, <em>you can’t install a widget</em>! You can install a plugin that adds a widget to WordPress. You can install a theme that comes with custom widgets. You can even write your own widgets, but <em>there is no such thing as a widget installer in WordPress</em>!

So what is a widget? A widget is a piece of code which allows the addition of content to the sidebars defined within a given WordPress theme. WordPress itself comes with some widgets allowing the display of various data related to post categories, tags, and navigation, among other things. Widgets added by themes or plugins can do almost literally anything: display content, interact with remote APIs, get user feedback, the sky’s the limit!

Still confused? The WordPress Codex has some great references on plugins, themes and widgets. Not good enough? Feel free to post your questions!