What is the correct way to build a WordPress plugin, the official, recommended way that was always intended? The idealised standard?
The Problem
Plugins are not discrete modules in the WordPress world. Their isolation exists only on the filesystem, but once that code is loaded into memory it shares the same space as Core itself. No distinction is made, and there are no special borders telling WordPress which parts are plugin, which are theme, etc.
A plugin at its most basic, is a PHP file with a comment at the top in a particular folder. WordPress says nothing else about what should go inside that file.
This means that a plugin could be anything, and many people have very different ideas. For example, some people:
- Use a handful of helper functions dumped into a single large PHP file
- Use functional programming
- Include files and build an Object oriented application that hooks into core
- Use Composer and Symfony libraries to build their plugins internal structures
Core may make recommendations about individual operations, such as the correct way to make a post loop, but it can never answer the question being asked, how do I build a program? There are plenty of bad methods, but there is no correct way to do it.
Some answers here are better than others, but there is no right or wrong answer, and different answers work better for different things. Dumping functions into a large file makes it difficult to read and maintain, but a small program won’t benefit from a Symfony controller stack, just as a large plugin might benefit more from an autoloader than a plugin with 5 files.
All these answers have one thing in common, they’re not WordPress answers, they’re generic programming problems. There is no correct answer, and no best way
Starting Points
There are several starting points, but you can:
- Find a boilerplate that works for you as inspiration
- Plan out an object graph in bullet points, giving each task a plugin needs a bullet/class. Indent to show which objects contain what
- Try, and try again
Different tasks lend themselves to different approaches. So long as you identify what your code needs to do, and plan it out ahead of time, things should work out fine.
I like to promote is the use of Namespaces and OOP where necessary. In my opinion, your ENTIRE plugin should not be 100% object oriented. Meaning don’t stuff everything into one or two classes. Your classes should be short, and concise (having specific duties).
Everything should be labeled clearly and to it’s fullest extent. Try to void `$var` and spell it out… `$variable` makes it much easier to identify through out your code. The same thing applies to your Namespaces, Class/Interface names, file names, Post Type/Taxonomy Names, and database tables, etc.
Personally, I like to organize my plugins file structure into three sub-directories to organize my code. Something like: “backend”, “frontend”, and “global”.
Everything all around should flow and be easy to read and you should be able to quickly find what you’re looking for. After-all, code is poetry, right?