In part 10 of Plugin Development 101 we are looking at how to create your first OOP-based plugin.
Object Oriented Programming, OOP for short, is a way of writing your PHP. In general it is considered “more complex” and often thought of as “scarier” than standard procedural (function based) programming. The procedural method is certainly easier to learn, at least from my experiences, but gaining an understanding of OOP and knowing how to write it, as well as when you should use it, is tremendously valuable.

This video walks you through creating a basic plugin that is written in an Object Oriented approach.

Note: this video does not propose to explain the indepth reasons to how OOP works, why you should use it, when you should not use it, etc. It simply illustrates an introductory example of how to write an OOP-based plugin. It is meant to give a basic comprehension of OOP so that you can get your feet wet.

It really depends on the plugin. If it is a large plugin, such as bbPress, Easy Digital Downloads, or Restrict Content Pro, then there will likely be a combination of procedural and OOP. For example, in EDD, we have a class called EDD_Payment_Stats that is just used to retrieving earnings and sales stats for products. Also in EDD, we have a lot of global (procedural) functions that perform various tasks as well. Usually a class will be a collection of functions, variables, etc, that all have a unified purpose.

In smaller plugins, however, such as Multi Site Plugins Add New, http://wordpress.org/plugins/multi-site-plugins-add-new/, the whole plugin may be wrapped in a single class. The only benefit this has over procedural functions is that all variables, methods, etc, are contained within the single class, so there is only one global namespace to worry about.

A lot of it really comes down to personal preference, though there are definitely cases where OOP is a much, much option, though that is another discussion

jgalea

September 26, 2013

Ok, so it’s safe to say that you can use OOP for any kind of plugin, right? My understanding is that we’re also barely scratching the surface of OOP with WordPress plugins, since the primary goal here is to keep things tidy and have a nice namespace.

Now that you mention it, in EDD for example, why the mix? Can’t everything be wrapped in classes? If there are functions that are somewhat unrelated, can’t they be grouped in a UTILITY class?

Pippin

September 26, 2013

Yes, you can use OOP in any kind of plugin.

EDD is a mix primarily because it started as purely procedural and has moved more towards OOP as its development has progressed.

Thanks Pippin for the great tutorial series! I have a question though regarding more complex plugins such as EDD and bbpress. I know they both started as procedural programs, but if you were to start either from scratch how would you go about programming them in an OOP fashion? Having looked through the source of both I notice you lose the name spacing ability once you include the various plugin files.

Personally I prefer a mix of OOP and procedural, but that is besides the point.

It really just comes down to thinking out the various aspects of your plugin. For example, if I were to rewrite EDD, I would do something like this:

1. Have a main EDD class that handles loading the plugin, including files, etc, exactly as the current version of EDD has.

2. I would then write a class specific to each section of the plugin. For example, there would be one main class for querying, creating, editing, and deleting payments. There would be a class just for handling customer data. A class just for payment gateways.

When writing a plugin in OOP, you really want to write focused classes and avoid the “god class”, a.k.a. a class that is little more than a bundle of random functions under one namespace.

Kyle

October 29, 2013

Pippin, I noticed the above video won’t play on my iPad, anyway you can use a format compatible with all devices?

I’ve looked at your intro videos on plugins and it seems as if I’m missing something when I start doing my own plugin. I put my file in the wp-content then there’s a folder for plugins, which where my file is. Now when I went onto my website to see if the plugin even exists, it’s not there.

Excellent tutorial Pippin and great series too!
Although I do not have in-depth knowledge of OOP, writing a OOP based plugin does not seems so scary now
Btw, I’m trying to write my first OOP plugin and I got a recommendation as the new PD_101 should not be in the same file as the class declaration. How do you think about that? It’s a valid recommendation?

Also, I don’t know where is the best to place an options variable like this:

$mfwp_options = get_option(‘mfwp_settings’);

If I use classes it is ok to put it in the top lines of the plugin right after headers nad before de class? Do you think the global constants clutter up the global namespace? If so, how do you think it is the best way to pass the path of the current plugin file to the main controller?

One of the main architectural strategies behind oop is that each class has one purpose (represent a product, represent a user, etc). If you have a class like that, put it in its own file. If you have just one class that is used to wrap all functions of a plugin, go ahead and out it in the main plugin file, as I did in this video.

For the options, I’d simply call that option when ever you need it. It does not need to be global.

Sayed Taqui

November 13, 2014

Great tutorial, the only reason why I dont take the objected oriented programming way when developing wordpress themes is because in standard procedural programming I can write if(!function_exits()) and the child theme developers can take advantage of it by redefining the function in the child theme, but I am not sure how the functions can be overriden in OOPs though the child developer can certainly unhook or deregister the functions which are hooked but what about the functions which have been used internally and are not hooked to any action.