Software, Development, and WordPress

Custom Plugins: What’s Loaded, What’s at the Ready?

The longer I work in building custom plugins for other people, the more I’m convinced of the advantages of maintaining a personal library of classes (or functions depending on your style) that help expedite tasks that are common to every project.

Sure, it can be hard to determine what you’ll require for every project and what you’ll require for some projects.

Custom Plugins and Required Files

And there’s nothing wrong with focusing specifically on the latter, but there are advantages that you have, at the bare minimum, a foundation off of which you can build custom plugins for others without constantly re-writing the same code over and over and over.

And over.

And you get it.

So what are the things that we should have and what are the things we should save, say, at the ready?

Custom Plugins and a Library of Components

If you’ve worked in WordPress for a significant amount of time and have been focusing on plugins during that time, then you’re likely used to writing some of the same code over and over for projects.

I’d venture to say that you likely have the ability to begin seeing how the plugin will function even before you get to programming (you know, that whole intuition thing). Going one step further, it’s likely that much of your work is going to include various components such as the need to load assets, display different information on the front-end and so on.

Will these be common to all custom plugins? Probably not. But it wouldn’t hurt hurt to have them available as modules ready to load into your existing project, would it?

Required Components

When creating plugins, there’s very little that I consider a requirement. I regularly included the following in all of my projects:

  • A bootstrap for registering the plugin with WordPress and for setting the plugin in action,
  • A LICENSE file,
  • A README file (sometimes in Markdown, sometimes in text depending on where I’m releasing it),
  • A for logging all of the changes that go into the project (and that follows Semantic Versioning and Keep a Changelog),
  • A languages directory,
  • A CodeKit configuration file (because I use CodeKit and have much love for the recently released version 3).

Obviously, the base of a plugin is not that many files. I mean we’re talking about five files and a directory (excluding the files that may exist in that directory).

This is the foundation for any necessary plugin. And I know this is coming from the person who started the WordPress Plugin Boilerplate. This isn’t meant to overwrite or compete with anything it has to offer.

WordPress Plugin Boilerplate

But it’s to help separate what we truly need for a plugin and what might we might require of a plugin.

Optional Components

So what are optional components, anyway? Custom plugins can do a variety of things. Sometimes it’s small, sometimes it’s large, and sometimes it falls somewhere in between.

For example, some of my plugins require the following:

  • Loading assets such as JavaScript, CSS, image, and so on,
  • These assets may be for the front-end, the back-end, or both,
  • There may be logging functionality I want to incorporate,
  • Perhaps I’m creating my logging mechanism to hook into what WordPress already offers,
  • Maybe I need to communicate directly with the database,
  • On occasion, I may need to include Ajax functionality for both public and private aspects of WordPress,
  • And so on.

So here’s the deal: When it comes to building these types of modules, I’ve found it help to namespace these components as necessary. For example, sometimes I’ll have something like namespace Admin\Assets which is where the assets for all of the administration assets.

Maybe I’ll need them; maybe I won’t. Regardless, that collection of libraries is ready to be loaded into my project as needed.

And the same goes for all of the other various points mentioned above (and many of the points not mentioned).

Package Management

When it comes to including all of these modules, your method of including that may vary.

  • Perhaps you have all of them located in a directory on disk, and you load them up directly.
  • Maybe you have them available in a repository in which you can use Composer to bring the files into your project as needed.
  • Or there could be another way you go about including them.

The point is that if you have these libraries at the ready, it should be easy to include them in your current project in whatever way suits you best.

Custom Plugins with Composer

Remember, though: Since each project is different and going to require a different set of assets, it’s important to have a consistent directory structure, but that doesn’t mean the class (or classes or collection of functions) need to have a lot of functionality.

Instead, it could have nothing more than a namespace, class name, and a couple of functions (all of which are implemented according to an interface, though I digress on this).

Track What You Need (And What You Don’t)

Ultimately, my point is that if you’ve not taken stock of the work you’re doing when creating custom plugins, try to do so. Notice what you’re doing in each project and then determine what you’re doing all the time and what you’re doing some of the time.

From there, you can begin to implement a collection of files and classes that can help you kickstart you custom plugins, so you’re going from nothing to something without a lot of repetitive behavior.


  1. frank

    I agree with you 100%. Another very important thing you need is to have a predefined folder/file structure for all your plugins. That will make maintenance very easy since you know what is where.

  2. Eric

    Thanks Tom for another helpful article.

    You mentioned, “A bootstrap for registering the plugin with WordPress and for setting the plugin in action”

    If you are not using as your bootstrap, I wonder if you wouldn’t mind sharing what your bootstrap does look like?



  3. Rick

    Hi Tom,

    Been a while. Things are doing really well w/ the “MS” site.

    Working on some more custom WP code. I ran across your autoloader posts and decided to visit your home base.

    What I’ve found in having to cope with many external plugins is that many developers do not think about efficiency at all more or less someone else looking at altering their code.

    While efficiency in the admin end of plugins is relative as one does not expect hundreds or thousands of folks accessing it the front facing code is a different story. I am not speaking strictly about algorithmic issues but code brought in that is only executed under varied circumstances. They eat RAM and RAM equates to sessions availilable.

    On the other side of the coin I’ve encountered plugins that have everything so broken into individual files I/O time in simply getting the software into RAM takes a hit.

    There is a balance.

    Exacerbating this is exactly what you are pointing at, structure.

    What I’ve done is build my own loader.

    Essentially a common structure across the entire plugin file hierarchy for a given plugin I am working on.

    The structure off the plugin root is an admin,frontend,common directory structure. Within each, CSS, Assets (images, icons etc), JS, DOC, Class and Lib and Views.

    Within each of these directories subdirectories can (or not) exist towards named assemblies.

    If a plugin for example has only two views its no biggie have them all sit under the /frontend/views directory. However, if there are 20 I can group those under named directories such as say, frontend/views/logged .vs. not.

    So, we have one level of being able nest within any of the directories (admin,frontend or common)

    I might have say a CPT lib general purpose that sit within /common/lib/admin and common/lib/frontend

    Or perhaps its specific to the plugin, doesnt need all the labels or options need be set. That would reside in /admin/class/ and /frontend/class respective. If I have buckets of file classes we nest one level, /admin/class/cpt/ and respective on the frontend files.

    Anything in a Lib directory (aka: a complete library) ALWAYS has its own directory structure under the associated Lib directory.

    If its say a front facing only lib, say a DOM parser it’ll sit in frontend/lib/domparser/

    If used by admin/front facing it’ll sit in common/lib/domparser IF its WP specific.

    IF however its someone else’s lib, classes, code… These have their own directory structure under a named directory in the root, “externals”

    So we might have /externals/lib/simple_html_dom.

    Anything can be autoloaded or brought in on demand or enqueued accordingly.

    Files can be registered w/ the autoloader via singular files or arrays of filenames.

    Directory selection (admin/frontend) are done automatically based on if the user is in the admin screens or not.

    aka: Register_File( type, filename, assembly=’ ‘);

    If the type is preceded by an @ symbol that denotes using the “WP common” directory off the root.

    If a type is preceded by a # symbol that denotes using the externals directory.

    One thing I have not yet done is a ‘frontadmin’ which again would mimic structure perhaps denoting that in the TYPE (class,view etc) with a ^ or something and lastly bringing up external libraries / classes “IF” they need any sort of sophisticated WP integration. Should be simple enough, an admin / frontend directory within the particular externals root.

    The loader also has the capability to use wildcards so it can bring in everything or specific files based on wildcards. I try avoid this as it’s quite the performance hit on the front facing performance.

    One of the thoughts I had related is a set of task based files. So given a task where “xxx” complex assets need be loaded what need be brought in can sit in call it an actions file towards the specific task.

    It contains the array (and/or Register_Files()) calls. Thus loads up one file .vs. wildcard usage and in some respects makes sense for all tasks. Thus only the code assets needed to perform a task are brought in something a WHOLE LOT of plugins just dont do. They haul in the kit and kaboodle no matter the tasks.

Leave a Reply

© 2020 Tom McFarlin

Theme by Anders NorenUp ↑