Tag: WordPress Plugins

Over the years, I think the concept of a “drop-in” plugin has become overloaded. What once referred to a very specific type of functionality has evolved to mean a couple of things.

1. One of the definitions retains the original definition which is you can place specific files into the plugins directory to replace core WordPress functionality. These are not standard WordPress plugins, though. For example, you’ll likely often see files like advanced-cache.php or object-cache.php in the plugins directory. These are the original type of ‘drop-ins’ when it comes to working with WordPress.
2. Another definition are plugins that aren’t specifically mu-plugins and they aren’t standalone plugins either. Instead, these are pieces of functionality that can be dropped into any other plugin and add functionality. Say you have two different plugins that are used by a lot of people and you want to give them the ability to add a feature without activating a new plugin. The way in which you can do this is have them drop a file into their existing plugin.

Here’s the challenge with the second definition: When you drop functionality of into the context of another plugin, that plugin may not be the only one already running the same code.

In other words, say you have a file called acme-functionality.php that can be added to any plugin. If you drop acme-functionality.php into multiple, activated plugins then you may end up with all kinds of results none of which are ideal. And why isn’t it ideal? Because you want the code to run only once.

What’s a way to check to see if a file is already running in the context of another plugin before running it’s code?

The idea of an “iterative process” is nothing new in software development. It’s present in a number of different methodologies and likely because it works well especially when getting customer feedback.

One of the places that I also find it useful is when building administration interfaces for WordPress plugins.

To be clear, I’m not a designer, so when it comes to front-end work, I always refer to the style guide and the mockups the designer provides to me from the outset of the project. (I only mention this because I think it’s a practice anyone who’s not a designer should follow, but I digress).

But when it comes to working on administration screens or back-end screens for WordPress, I tend to follow a strict rule: Make sure it looks as natural as possible.

How, then, do iterative development and the interface of WordPress administration screens have anything to do with each other?

Continue reading

I joke with friends that Jetpack has become like the operating system of WordPress.

This isn’t to knock the good work the people at Jetpack are doing (because they are doing good work, are actively engaged in the community, and continue to iterate on the product).

But there are times where people don’t want to install Jetpack. Instead, they prefer to use third-party tools for whatever reasons. To each their own, right?

And there are quality Jetpack alternatives.

Continue reading