If you come from an object-oriented background or try to build all of your solutions for WordPress using object-oriented techniques, then there are going to be times where it might feel like you’re hitting a nail with a sledgehammer.
For example, let’s say that someone comes to you and needs a custom plugin developed that works with a third-party plugin but it only needs to do one thing.
Is it worth taking the time to create an interface, implementing the said interface in a concrete class, set up subscribers, write unit tests, and so on?
Let’s say a potential client comes to you who:
- is working with a very tight budget,
- has a third-party plugin that does not fit well with there theme,
- needs only light styling,
- and has the funds to contract you for the work.
Assuming all of the above is true, then I’d say working through the solution seems simple enough, right? We need to audit the site so we can:
- determine the color scheme,
- find the necessary selectors for the CSS,
- then begin building the plugin.
Now when it comes to doing this, I still try to employ a handful of best practices. Even though I tend towards object-oriented programming, I don’t always use it nor do I always recommend it.
Instead, I think using a simple function or set of functions hooked to the WordPress API in a procedural manner works just fine. However, that doesn’t mean we shouldn’t aim to create a solid file organization structure because you never know when you may have to come back to maintain the project.
To that end, here’s what I normally do:
- create a src directory for the code that will be responsible for hooking into WordPress,
- add the usual LICENSE, README, and plugin bootstrap file.
The resulting directory may look something like this:
From there, I don’t even bother with an autoloader. Instead, I include the files in the source directory. You could iterate through those files versus doing something like this:
But that might be dependent on when and what you’re doing.
This is Too Simple
Maybe. Here’s the thing: Whenever a person becomes entrenched in using a certain programming paradigm, said person tries to apply it everywhere and tries to do so all the time.
Not everyone, but many. Myself included.
And when you find yourself over-architecting something, why not take a step back and try to make your workload a little simpler?
The problem is still solved, and it’s done so in a way that has significantly less overhead.