Using Plugins for Custom Client Functions

photo credit: romana klee

This just never occurred to me: That you might want to use plugins when developing custom features for a client, rather than simply include the code in the functions.php file (or an extension of same).

Now, because the plugin was not necessarily for general consumption, there could still be an awful lot less labor, in the form of testing, compatibility QA, etc. Probably still more than if you were including in functions.php, but maybe not.

Reasons why you might want to include features for a client’s site as custom plugins:

  1. Including as plugins forces you to carefully encapsulate the code, into more clear, discrete units, based on function, which inevitably improves re-use.
  2. .. It also inevitably encourages better maintenance.
  3. It takes advantage of the plugin architecture, not as a means by which people all over the world could re-use very generic code functions, but more as a means by which a company (or independent developer) can re-use its own code and functions. The same cool, modular design that lends itself so well to contributions by the open source community, could also lend itself to flexibility within a company.
  4. It could encourage the company to distribute said code to the world, with numerous benefits.
  5. As the client requested more features, it could encourage me to add those features as the discrete, “pluggable” items that they are, rather than adding them as a sort of “spaghetti” of stuff to the functions.php file. An example is some custom post type code that a client has requested, and provides a very discrete new set of behavior to the site.
  6. You might be able to include this new, discrete functionality, without interfering with the existing theme files. If the code for the new feature, and the existing theme files, are really two separate things, it could be very nice to keep them quite separate.
  7. You can easily turn a particular function on or off. I am not sure exactly how that will benefit, but it might well.
  8. You could provide access—for yourself, or for a client—to whatever particular configuration settings or what not that you might want to be able to easily change. —Perhaps while you were developing a site, or say, from one project to another.
  9. If you do want to re-use code from one project for another, I think it will definitely be easier to see exactly what code you want to pull out and use, if it’s so well modularized as to be in its own plugin.
  10. [9/13/10] If you were trying to utilize a development methodology, such as Agile, that took advantage of modularity, and possibly with a more junior, you could use plugins as a way to enforce modularity, much like using object-oriented methods do. You could clearly specify inputs and outputs, and even embed test cases into the “stub” code for that plugin. You could actually provide a stub complete with a framework of coding standards, test case, etc. Ooh… that could be beauty-full

When you are developing a plugin for a general audience, you have to spend a lot of time managing the interface to the plugin—making appropriately user-friendly, pretty interfaces, that are fairly easy for the general user to understand, can take up a lot of extra time.

On the other hand, if I were developing plugins for internal use, I could make them less user-friendly, focusing on the specific user audience, and specific functions I needed to expose. For example, I might have a simple drop-down menu of options for the back-end (client’s) interface, and a series of configuration options within the code, that would be easy for a developer to change, and adapt to a specific project.

In fact, I could even have plugins that had no visible interface.

Disadvantages could include:

  1. Having theme files and other aspects of the site’s behavior in different areas. This is definitely a pro/con balance situation. If you have all the code with within the theme directory, it’s nicely self-contained (and I use this a lot when managing project code with git). On the other hand, if it’s in a plugin, then it’s nicely kept separate. (And of course, it’s not as though I don’t already have a client’s site set up with any number of other plugins that I have included).
  2. Even though I can keep the interface to my plugins simpler, there might still be a little more code required to manage a series of plugins, than just code stuck somewhere in a functions.php file.
  3. You might easily end up in a situation where you still do need to modify the theme file code. Now, you have had to manage modifications in two separate areas of code, just to get the feature to work.

— Update, September 13, 2010 —

I know maybe nobody is reading this, but if only for my own edification or remembrance, I will note some more things down.

This weekend, I began trying an extension of this experiment.

I started a http://generic.local install of WordPress, with the barest of themes, a very generic installation. Then, I started adding plugins to accomplish various functions that I might want to do for a variety of projects—custom post types, custom “fields” (e.g., meta data for various write panels), etc.

I then stored this entire plugin directory as its own git repository. I developed the custom post type and fields plugins in the generic install, until everything worked pretty well, in a generic way.

Then, I went to the actual site I was working on, and cloned the same repo, becoming the plugins directory for that actual site.

Now, I created a site-specific git branch, and started working in there, making modifications to the various plugins, as needed, for the particular project.

Also, I would add any publicly-available plugins as needed, and yes—they become part of that branch of the repo. Therefore, this branch of the repo becomes a snapshot of the entire plugin installation I need for this particular project.

The idea here, is that (a) there could be a lot in common between projects; (b) starting off from a common “root” branch of code, could encourage the re-use of said code in an organized way.

I may start to include all the standard plugins I might use in the “root” branch, so then it becomes a kind of library of commonly-used public plugins.

Unlike having to release a plugin publicly, I am still able to tweak and modify the code by hand, commenting out options or features I don’t need, etc., all within the code. So, it’s sort of a best-of-both-worlds situation. It allows me to know a lot more intimately what a particular function does—say, register_post_type(), for example—without having to re-write it all by hand every time.

The disadvantage I can think of, so far, is that for each project, I’ll have two stores of code—one, the project-specific branch of the plugins directory, and two, the theme directory repo.

But I think it is very interesting how this encourages me to think in terms of re-used, and modularized, code. But thanks to the power of git, re-purposing this core library of code is very easy, because I can so quickly switch between branches.

—- Update, September 14, 2010 —-

Realizing that a real danger here, is that you end up getting confused about where which files are, for which project. There is a beautiful simplicity in having everything for one project, in one place.

There are always tradeoffs between re-use and simplicity.

Somehow, I need to come up with the way to have both. For example, still have one repo per project, but have it point to both the plugins directory, and the theme directory. Perhaps create a directory that contains symlinks to both places, thereby making the repo contain both, while having WordPress work the same way it always does.

This solution would be beautiful, except that it squashes the idea of maintaining all of the plugins for my projects as a sort of shared core of code. Need to think about this some more.

Posted in