Divi Post Settings V – Rearrange our code in OOP approach

by | Nov 28, 2017 | Featured, iDivi Plugins, Php, Snippets | 0 comments

Divi Post Settings V – Rearrange our code in OOP approach

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.

BEST PRACTICES AND OOP APPROACH
Wordpress, in fact, give us a list of best practices when we are dealing with the Plugin writing. So we will start following these guidelines step by step and this way we will re-organize our folders, files and code.
RE-ORGANIZE FOLDERS AND FILES

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:

/* BEFORE */
/* AFTER */

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.php file 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.

UNINSTALL.PHP

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’:

OOP: WRITING OUR CLASSES

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.

admin/class-divi-post-settings-admin.php
Our first operation in order to transform our standard plugin into a WordPress OOP one is just copy and paste our admin functions in ‘admin/class-divi-post-settings-admin.php’. So we will create a class, declaring a couple of properties and writing a very simple __construct function:
Then we will add inside the class our admin functions, so in our case this is the final result:
You can notice we added all the functions but not its ‘add_action()’ hooks. In an OOP approach, in fact, we can’t simply add them in our class; we’ll create, instead a specific class for orchestrating actions and filters, the ‘loader’ class.
includes/class-divi-post-settings-loader.php
This part begins to get a bit complicated; for ease we got started from the ‘WordPress Boilerplate Plugin’ working system and you just have to copy the following code in your ‘loader‘ file (in our case: includes/class-divi-post-settings-loader.php):
As we said, we don’t need to go too deep in the argument; we just need to know that thanks to this file you can now add in ‘includes/class-divi-post-settings.php’ all the hooks your functions need.
includes/class-divi-post-settings.php
In ‘includes/class-divi-post-settings.php’ we will create a class called ‘idivi_post_settings’; inside of it we have to write some functions starting from the ‘__construct‘ one in which we define first our plugin name and version, then we call the next two main functions, the ‘load_dependencies‘ and the ‘define_admin_hooks‘ ones that we will see in a moment:
So we add the function for loading the files from which our calls depend:
Then we add a private function ‘define_admin_hooks()’ in which we declare our ‘$plugin_admin’ variable that will be our context, in this case the ‘idivi_post_settings_Admin’ class and its methods/functions:

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:

THE MAIN PLUGIN FILE NOW
Ok, cutted off all our admin functions, we leave in the main file just the security and deactivation ones (we could, indeed, also create a new separated file in includes for deactivation) and the main functions ‘et_single_settings_meta_box‘ and ‘idivi_divi_post_settings_save_details‘; then just add a ‘require’ call to our ‘includes/class-divi-post-settings.php’ and a final function ‘run_idivi_post_settings‘ that will initialize our plugin by calling our ‘run’ method of ‘idivi_post_settings’ class:
FINAL THOUGHTS

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.

LET’S CONTINUE…

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.

Go!

Divi Post Settings Plugin IV

Add Ajax to our Info notice, Testing and Commenting.

Go!

Divi Post Settings Plugin V

Re-arrange all our plugin code in a OOP approach.

Go!

Divi Post Settings Plugin VI

Adding an ‘Extra Feature’: Remember the last options used.

Go!

Submit a Comment

Your email address will not be published. Required fields are marked *

SupportHost

You have Successfully Subscribed!

CodeCanyon Plugins

You have Successfully Subscribed!

Elegant Themes

You have Successfully Subscribed!

Try Divi!

You have Successfully Subscribed!

Divi Plugins

You have Successfully Subscribed!

Advanced Blurbs Plugin

You have Successfully Subscribed!

Bloom!

You have Successfully Subscribed!

Divi Cake Layouts

You have Successfully Subscribed!

Divi Cake Plugins

You have Successfully Subscribed!