We are today with our series post number five about the Divi Post Settings plugin creation. The plugin is already finished and perfectly working but we want to go further starting from a better code organization by adopting the OOP approach.
At this point, indeed, our plugin have a very simple folder structure with just one main php file, the Readme and License text ones, an Assets folder and a Js folder with our ‘idivi-ajax.js’ file inside. The main plugin file looks now like this:
Just one main file (if we exclude the ajax one in Js folder) with 407 lines of code. It’s not so much cause our plugin after all is really simple and for such a kind of plugin it can be ok just this way. But if you are dealing with more robust plugin is pretty recommended to adopt a better code organization.
So, let’s give a look at what OOP means and which the best practices we can take advantage of in order to write our plugin as best as we can.
The first thing we have to do is split our code in more than one file and organize these files in a good folder structure. So, for example, we will create an ‘ADMIN’ folder in which we’ll put all our files that handle the code for our admin side; similar we could create a ‘PUBLIC’ one if our plugin require a public side ( but in our case this folder is not necessary ).
We’ll add also an ‘INCLUDES’ folder while we don’t need, for our purpose, a ‘LANGUAGES’ one but your plugin could need it too.
So we will create a new php file called ‘class-divi-post-settings-admin.php’ in our ‘ADMIN’ folder and another couple of php files called respectively ‘class-divi-post-settings.php’ and ‘class-divi-post-settings-loader.php’ in ‘INCLUDES’; we also include our ‘JS’ folder in ‘ADMIN’ in order to avoid confusion as best as we can.
If we go to compare now the folder and file structure before and after we will already see a good starting point for a better file organization:
We have, of course, in our case a really simple structure because of the limited number of files and code lines we have, but this is the way to follow all the times we can do it. So our main plugin folder has to be always as clean as possible, as WordPress itself says:
The root level of your plugin directory should contain your
plugin-name.phpfile and, optionally, your uninstall.php file. All other files should be organized into sub folders whenever possible.
We will talk in a moment about ‘uninstall.php’ file; we can, however, leave here also the Readme.txt and License.txt ones.
Adding an Uninstall.php file in your plugin is not mandatory but we recommend you to do it. Doing so, in fact, when the user delete your plugin (not simply deactivate it!) also the options and custom database table/rows will be deleted leaving no trace and saving space in the database itself.
In order to do it WordPress give us two methods, the first one that you can achieve with just few lines of code by using the ‘register_uninstall_hook()’ function; the second one more secure and recommended is to add an ‘uninstall.php’ file in the main root that will be magically executed when the plugin is deleted (see here if you want to know more about the WordPress uninstalling process).
So in our case we will create the ‘uninstall.php‘ file and add the following code in order to delete our plugin options and our custom ‘usermeta’ table row called ‘wp_idivi-dismiss’:
Is time to move to action and write our new empty files populating them with “Classes”. OOP stands for ‘Object-Oriented Programming‘, so – the name itself says – a programming type that uses ‘Objects’, that is handling the code by wrapping it in ‘Classes’. A ‘Class‘ – without go too deep in this pretty wide argument – has properties (our variables) and methods (our functions); so we’ll move our functions inside different classes in different files and then we’ll simply call the classes or the methods when needed.
The OOP approach has the great and more eye-catching advantage of avoiding naming collision problems: you don’t need more to prefix every function you write taking care to avoid using function names other plugin or theme developers used; you just have to prefix your classes and inside of them put your unprefixed and pretty common named functions.
If you are just interested in avoiding name collisions you can simply wrapp all your code in a class and then in the same main plugin file instantiate it (see the example).
However the main advantage of using classes and an OOP approach is also the better code organization, its flexibility and code re-use aspect; and if you want to take advantage of this you have to write more than one class in more than one file in more than one folder.
Ok, so let’s see how our three new files have to look like.
Then we can add every hook we need just calling ‘loader’ class and the ‘add_action/add_filter’ methods this way:
$this->loader->add_action(‘here the name of the hook‘, $plugin_admin, ‘here the name of the function‘);
Finally we write other three simple functions called ‘run’, ‘get_plugin’ and ‘get_version’ (the first one to run the hooks, the latter ones for getting the plugin name and version we use in ‘define_admin_hooks()’ function); so at the end we see our file just looks like this:
Of course you can imagine in advance how your plugin will be and, thus, if the case, we recommend you to start writing it with the OOP approach directly; however, as we saw above, is not so difficult to transform a standard-writed plugin into a better organized OOP-writed one.
This way we have a final result more coherent, clean and easy to maintain and to update for you and other developers.
In the next Divi Post Settings Plugin series post, next tuesday, we will add – keeeping our OOP approach of course – a complex extra feature to our plugin. It will be our last step before we upload the plugin in the WordPress repository.
So, stay tuned on How-i Divi-t!
DIVI POST SETTINGS INDEX
You are here!
You are here!
You are here!
You are here!
Divi Post Settings Plugin III
Write our main functions and use our settings.
Divi Post Settings Plugin IV
Add Ajax to our Info notice, Testing and Commenting.
Divi Post Settings Plugin V
Re-arrange all our plugin code in a OOP approach.
Divi Post Settings Plugin VI
Adding an ‘Extra Feature’: Remember the last options used.