So I’ve adopted a new development style for WordPress plugins and thought I’d share the method I’m using to dynamically load classes. First of all this is the syntax I was using:
I personally feel like this is super clean, easy to read, and extremely flexible when calling various different classes and methods. Here’s what some real-world code might look like:
The previous way I was doing this started getting tedious to maintain. This is how I would handle auto-loading these classes when needed:
In this example, I had to create private class variables for every subclass to be used as well as a public method for loading the class and returning the object. This isn’t that hard to maintain when loading one or two classes, but when you start loading in 8-10 classes, it becomes a lot of repetitive code and adds more room for copy/paste error.
So the solution I came up with uses spl_autoload_register
and the __call()
magic method. Now before I get into the functioning code, there are a few things to keep in mind:
- I’m using Namespaces. For this to work, I believe this is a requirement, but I haven’t really tried to use it without.
- I’m basing my class file naming conventions off the WordPress Coding Standards (
class-myclass.php
) and nesting subclasses within folders, all nested inside a folder with the same name as my namespace (/classes/my-namespace/folder/class-subclass.php
). - I’m using a “default” subclass name (
Core
). This was handy when I wanted to nest classes within folders. For example, callingmy_plugin()->admin()
will first check to see if/classes/my-plugin/class-admin.php
exists, but will then check for a default subclass within the admin folder:/classes/my-plugin/admin/class-default.php
. - This is best utilized with one-time use classes. For example, in my project, I may have a
Sessions
class and I’m only going to need 1 instance throughout the entire plugin. A bad example would be using this for aProduct
class. You may need to use this class separately over and over, so would not be a good candidate for this methodology.
I feel like this solution could be adapted to work with whatever folder structure and naming convention you prefer, but this is just how I chose to do it. So now onto the meat & potatoes. Here are all the helper functions I used to accomplish this:
And this is class to extend for the chainable functionality:
It’s important to note here that the Chainable class is within the same Namespace as the rest of my code. It doesn’t have to be, but if you chose to put it outside your namespace, it won’t autoload, so you’ll have to include it manually and when extending it, you’ll need to be sure to use \Chainable
or uses \Chainable as Chainable;
. Now in order to use it, all you have to do is extend your base class:
Now all we have to do is create files and folders that match our code structure. That could look like this:
So using this example, all this could be possible without having to add an extra code:
That’s pretty much it! Now all you have to do is create the class files and you can immediately start calling them! Hope you found this useful! Feel free to comment below if you have questions.
Great stuff here! I thought I post here just to say I like the Halloween hack you got going on with your site.