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.