The vast majority of WordPress plugins function as stand alone “systems” within WordPress. By this I mean that most plugins run more or less by themselves and do not interact with other plugins running on the same install. Depending on what you’re plugin does, this can definitely be a good thing, as you do not want your plugin’s features clashing with another plugin. But have you ever considered purposely creating interaction between plugins? The concept of plugins working in tangent together is what I like to call an “ecosystem” for your plugin, and it’s something you should seriously consider.
WikiPedia provides a nice definition of “ecosystem”:
An ecosystem is a community of living organisms (plants, animals and microbes) in conjunction with the nonliving components of their environment (things like air, water and mineral soil), interacting as a system.
An ecosystem in the terms of WordPress plugins describes plugins that are actively interacting and working together, or at least available to be worked with. It describes plugins that are “friendly” with other plugins and plugins that are ready to be modified and extended from other plugins. It describes a plugin that the developer has intentionally made available to other developers as a helpful member of the ecosystem that is the WordPress install it resides in.
It is really easy to build a plugin that does one thing and one thing only, or even a multitude of things. It is really easy (and I use this term loosely) to build a plugin that functions entirely on its own. It is really easy to write a plugin that talks to itself, and only itself. It is not nearly as easy, however, to develop a plugin that actively participates and enhances the ecosystem it exists in.
Have you ever been using a plugin (and it worked great!), but then installed another plugin (also works great!) and suddenly neither of them worked nearly as well? They both work really well by themselves, but together they tend to clash. This clash may be in script conflicts, style conflicts, admin UI overlap, or anything else.
These two plugins are examples of “non-helping members of the ecosystem”. The developers have not taken the time to go the extra mile and extend their plugins in such a way that they can be helpful members.
Without a lot of work, and a lot of testing, it is impossible (for hopefully obvious reasons) to write a perfect plugin that works well with all other plugins. There are always going to be plugins that a developer hasn’t (or can’t) test against, and there are always going to be those plugins that just make things really difficult for others. You as a developer, however, can choose to make your plugins as ecosystem friendly as possible.
There are a lot of ways that you can make your plugin ecosystem friendly. Here are just a few:
Write clean code
This may seem simple or like a no brainer, but the number of times I have opened a plugin and found a rat’s nest of code tells me that a lot of developers do not take the time to nicely format their code. You may not think this makes a big difference, but I will challenge you to go find two plugins, one with clean code and one with messy code, and read them both. Figure out what they both do and learn how the developer made it. Which do you think is going to be easier? Obviously the plugin with clean code.
Load scripts, styles, and files when needed, and only when needed
I see this a lot: plugins loading scripts and styles when they aren’t needed. There is no reason to load your custom JS file on every page in the admin when it is only used on one, and there is no reason to globally enqueue your CSS on the front end when it is only used if a short code is present on the page. This also goes for PHP file includes; there is no reason to globally include a large file of functions if those functions only pertain to the admin area.
Test your code
Just because your syntax and logic looks right doesn’t mean the code works in a real-world environment. It is also very important that you know what version of WordPress is required to run your code. Have you used brand new functions introduced in WP 3.4? Guess what! They won’t work in 3.3. I have definitely been the guy that forgot about using new functions a few times, and I had some angry customers as a consequence.
Use your code (the most bugs are found when actually using a plugin in a real environment)
Every plugin looks awesome when you write it. You probably slaved away at it for the last week and everything is perfect. Right? No, wrong. You will never, and I repeat never find all of the bugs the first time, and that’s okay! The highest number of bugs are found while the plugin is in the wild and running in different ecosystems across the world. It’s these different ecosystems that are going to help uncover obscure bugs. I assure you, there are always bugs that you would have never thought of. I’ve seen bugs that were found after releasing a plugin that I could hardly believe, even when seeing them happen myself.
Bugs are okay (they’re great actually), as long as you use them as a way to better improve your plugin and your own development skills. Take the bugs, fix them, and make your plugin a better member of ecosystems while doing it.
Follow the examples of good plugins that already do things well
Your plugin has been written before by someone else, almost guaranteed. Even if your exact plugin hasn’t been written before, aspects of your plugin has. Find those plugins that are exemplar models of functioning in different kinds of ecosystems and learn from them. Look into their source and see how they have done things and follow their example (if applicable).
Use good existing plugins as models, but do not, and I mean never, simply copy the code from these plugins and put it into your own plugin without understanding exactly how it works. Blindly copying code is one of the biggest problems currently facing the commercial WordPress theme market; please do not be a perpetuator of this terrible practice.
Refactor your code when needed
Just because your code was perfect the first time you wrote it does not mean it will be perfect in two weeks. Overtime you will always find sections of your plugin that need reworked, and that’s okay! I recently rewrote a very significant portion of one of my plugins, and at the time of writing it initially I thought the code was awesome! It was the best darn code I’d ever written. While rewriting it, however, I looked at it with dread because it was so bad.
The more code you write, the better you get. It’s as simple as that, so there is nothing wrong with your old code being below par or below your present standards. Take your old code as a learning experience (believe me, it will be). You’ll open your old code and realize so many things you did wrong, and it will be enlightening. It’s a really cool experience to see your old code and then realize just how much you have learned in a short period of time. I look at code from six months ago and already I do not like it.
You will also never get something completely right the first time, and that’s just fine. Refactor it over time and make it better and better.
Don’t be afraid of new things
Did one of your friends on Twitter post a really cool looking tutorial talking about something you’ve never seen? Read it! Did it go over your head? That’s okay! Working to better ourselves by reading and implementing things we don’t fully understand is one of the best ways to improve your development skills. This is assuming you do not simply copy and paste. Take the parts you don’t understand and explore them; go find the code in WordPress core and follow it line by line. Even if you don’t completely understand it or have the ability to write it yourself, you are still learning, and that’s extremely valuable.
For the longest time the ajax system in WordPress befuddled me. It was a mystery! I finally took the time to explore the system in WordPress core (wp-admin/admin-ajax.php) and it was like a light clicked on. I understood exactly how it worked and how to use it within five minutes. It was awesome! Never before had I felt so confidant about using a system in WordPress as I did that day, and that was because I knew how it worked, not just how to use it.
Make your code extensible
This is the holy grail of the ecology of WordPress plugin development. If you are serious about making your plugin one that plays nice in WordPress ecosystems, both large and small, you must make your plugin extensible.
Extensible means that your plugin can be directly modified from other plugins, but without ever touching the source code directly. An extensible plugin lets others tie into it and alter behavior, which could be text, data arrays, boolean values, HTML markup, scripts, or anything else.
Why is extensible code so important? It’s so important because often times, in order to play nice with others, a plugin may need to alter the behavior of another plugin to make things run smoothly. Take for example my Restrict Content Pro plugin. It has a meta box that it adds to all public post types that is used for restricting the content of the item to specific member levels. This meta box is needed for posts, pages, and any other public custom post type that is used for actual content on the site, but what about public post types that are purely for admin use? What about post types that are used by other plugins for custom data storage, such as the payments post type in Easy Digital Downloads? These post types have no need for this meta box added in Restrict Content Pro. Well RCP is a good member of the ecosystem and provides an extremely simply way to remove the meta box (WP core also provides a way, but it’s bit more involved).
Everything, and yes I mean everything in your plugin should be extensible because you never know when someone is going to need to alter it in some way or another. I guarantee that real-world users, and other plugin developers, will have needs that you never imagined, not even in your “this could happen on 1 out of 10000 sites scenarios”. Account for these early by making your entire plugin extensible.
To be a good member of the WordPress plugin ecosystem, your plugin does not need to actually interact with others, but it does need to provide the means for others to interact with it. If another developer needs to change a return value in your plugin, they should be able to.
The oldest living creatures in nature are those that adapt to their surroundings and have learned to work with other creatures and things in their environment. Non living organisms, such as giant sequoias, have also learned to adapt and survive with the environment in which they reside. Your plugins should follow the true members of real ecosystems around the world as models. Adapt to other plugins. Adapt to other developers. Be flexible. Be extensible. Fight for the survival of your plugin by constantly making it better, by making it work with other members of the ecosystem, by getting rid of pesky bugs. Plugins that do not do these things will never last very long.
All of this is the ecology of WordPress Plugin Development.
Great Ideas! To be honest, they were not something I had put a lot of thought into in the past; but, they are definitely something to consider and implement going forward.
I find that very few developers think about “ecosystems” for plugins until they are given a reason to seriously think about it, perhaps because someone told them to or because they had a problem that gave them the idea.
Once you get into the mindset of coding for an ecosystem, however, you will never go back.
This got me thinking… maybe I should come up with WP Ecology. lol! A spot where plugins interact.
For wordpress ecology to be actually effective, clean code should be the number one priority. I always come across plugins that made me think the code was actually
.code{visibility: hidden;}. lol!There is absolutely no way to understand it due to lack of commenting.
Anyway, thanks for the awesome post Pippin. Your website is like a class to me.
Clean code is by far one of the most important, though to be truly effective, a plugin needs to have clean code and be extensible.
Great post Pippin, you’re right many plugins do not follow these rules, i will for sure update my plugins even if in some cases i don’t know where to start. I mean it’s easy to do a plugin that works, but the thing is where to add filters, hooks or actions? That’s not always simple to understand. Do you have any tips about that ?
One tip for where to place filters is just about anywhere you setup an array (such as post query args) or return data. If you want a really good plugin to look at, go explore bbPress, it is an exemplary model.
Ok, thanks! I will!
Great article as usual. When do you cross the line of extensibility into a full on thought out plugin framework? I find the more I try to make things work together the more I start making more and more utilities to reuse on other projects and at some point I am going to need to start documenting these functions and so no in a framework like manner.
Sorry for the clumsy wording.
I think it depends on how you define “framework”. EDD, for example, has a lot of functions that I reuse in other places, but I don’t consider it a framework.
To me a framework has to be something that always provides the same set of functions and utilities. Each of the items in the framework can then be extended or modified, depending on the plugin it is being used in.
A framework is definitely not required, however, to make a plugin extensible, or to make it play nice with others.
Great post pippin! One I might add is to use the jQuery/jQuery UI scripts provided, and not to load your own from your plug-in/theme folder. I’ve also seen themes register their own version of jQuery (sometimes very outdated versions) from Google. Things like these have caused havoc for my events plug-in’s front end calendar.
The worst I’ve seen is when jQuery has be included in the head on every front-end page (not using the WordPress API) and they had ‘re-registered’ jQuery via the API with an empty string…
The trouble is there are lot of code ‘snippets’ out there which a simply poorly coded and can/will break things (case in point: http://blog.japh.com.au/2012/09/06/problems-with-themes-on-themeforest-are-problems-with-themes/). Part of the solution I guess is posts like this, and tutorials with ‘good code’ (I try to do this in posts for WPTuts+ – and Tom has said the same thing). What I think would be really effective is official guidelines on how to check your plug-in, common pitfalls, best practise and maybe even ‘correct’ code snippets. These already exist, but brining them together under some ‘official’ status might bolster its exposure. Maybe this will come out of the recent discussion about a plug-in review team?
Absolutely! jQuery conflicts both because of UI libraries and jQuery loaded from Google are two of the most common conflicts I run into.
I think you’re right that one of the only ways to combat the problem is to continue writing good examples. There are an abundance of problematic themes and plugins that are a problem because they copied from bad tutorials, so let’s at least do our best to give them something good to copy from.
If only the wordpress plugin directory had a strict code policy most of the free plugins will be ecosystem friendly… like what apple does with apple store.
just my two cents!
The major problem with imposing code quality restrictions on the repository is that it then makes it much harder for developers who are just starting out to get exposure. As a beginning developer, the WordPress plugin repository can be one of the most valuable assets, but if it’s impossible for you to get accepted, then it’s worthless. Plugin developers get better by having others use and look at their code.
It’s a bit of a catch 22.
Timely post for me; I’m just working on a project where I had to write a bunch of plugins that interact with each other. You didn’t mention creating custom hooks, which is a great way to make a plugin extensible. Good post!
btw, are those zombie sequoias you’re talking about? Pretty sure an organism that has ‘learned to adapt and survive the environment in which they reside” is a living organism.
Glad to hear it! I actually just wrote an article on using action and filter hooks in plugins on WP Tuts+.