Tutorials UPDATED: 10 February 2022

Part 4 – WordPress and Object Oriented Programming: A WordPress Example – Design

Tassos Antoniou

6 min read
Image for Part 4 – WordPress and Object Oriented Programming: A WordPress Example – Design

At this point, we’ve got clearly defined requirements as they were described in Part 3 of this series (check it out here if you missed it).

Now is the time to start thinking about the design of our new and improved plugin!

We’d like to remind you that this step may take you a long time when you try it out on your own projects. You probably won’t get everything right the first time either. Odds are you’ll come up with a design, start implementing it, and then realize that you need to go back and rethink your approach.

It is totally worth the effort though so take as much time as necessary to get everything just right. A well-structured project will make it easier to maintain and extend it, and even reuse its code in other projects so in the long run it’s a good use of time.

Right up next, we’ll focus on some key parts of the plugin and discuss how we came up with our design.

Dissecting the Settings Page

Let’s take a closer look at the admin page of the plugin.

You will notice that there is a title (“Limit Login Attempts Settings”), several sections containing some fields, and a “Change Options” button at the bottom of the page.

Each section consists of a title, like “Statistics”, and a few fields.

Each field has a title on the left, and the rest of its content on the right side. There are text fields, radio buttons and checkboxes and, some of them, like “Total Lockouts”, only display information and cannot be directly modified by the admin user.

Some fields also include a description, like the “Site Connection” field, but not all of them.

With the above in mind, we have to break it down into conceptual pieces that will later on become classes.

The WordPress Settings API allows us to register settings pages, sections within those pages and fields within the sections:

Pages → Sections → Fields

We thought, why not add one more “layer”, the Elements, in order to make our plugin easier to extend in the future.

Pages → Sections → Fields → Elements

So, Pages and Sections are what we’ve already explained above, and Fields will contain Elements of any content type on the right side.

Taking under consideration all these different kinds of elements, we went with an Element class and several classes, extending it, for the checkboxes, radio buttons, numbers etc. that will render different output.

We may also need to add more pages and sections in the future. So it’s likely that we’d need to extend these admin page and section classes.

The same goes for the fields. The classes for “Total lockouts”, “Active lockouts” etc. will extend the same (parent) class.

Here’s a simplified visual that demonstrates those relations:

Of course, not all “components” are included in the diagram.

A structure like this makes the plugin easier to extend; we’re able to easily add a field, element or section if the need arises. We’ll be able to easily add more components—fields, elements, or sections—by creating new child classes, without having to modify existing ones.

Thinking and Abstracting

Now it’s a great time to start thinking about what the various components of our plugin do. During the design phase, we don’t have to go into much detail about how something works.

For example, consider all elements, tables, statistics and pretty much anything else that is going to be displayed to the user. They might be separate components with nothing in common, but will all eventually render some output. Therefore, some functionality will be common for components that are otherwise completely unrelated. Of course, this extends to the rest of our components as well.

In the above visual, we see how a UI interface is implemented by multiple classes.

Pay attention to the fact that the UI interface is implemented by the Statistics, Lockout Logs, Table, and Element classes that are referred to as parent classes. There’s no need for the Radio/Number/Checkbox Element classes to implement the interface directly, since they inherit all interfaces from their parent class. However, a child class could override a method of its parent class.

Since we know that our plugin’s going to deal with settings, we can safely assume that we’ll read and write their values. That is, being able to get, set, and remove options.

All these actions will be bundled together in a class. We’ll probably store our options in the WordPress database or something like that. For now, we don’t have to care about how or where we’re going to store our data.

We can keep the get/set/remove options abstraction in our minds, simplifying things conceptually, and keep designing our plugin.

Main Plugin File

Here, we’ll provide some information about the plugin to WordPress through the header comment and perform some initialization. We’ll organize our code, by wrapping everything in a small class.

Depending on how the classes of our plugin will work together, the main class will have to instantiate most of them. As far as we know, this will include classes related to options, admin pages, retries and lockouts.

Potential Classes

We took some time to try and figure out what classes we’re going to need and we ended up with a list as follows:

  • Retries
  • Lockouts
  • Cookies
  • Error messages
  • Email notifications
  • Admin notices
  • Buttons
  • Lockout logs
  • Active/Total lockouts
  • IP address

Keep in mind that there’s no one single “correct” way to structure your plugin. As with most things in software development, there are multiple, equally valid, ways to solve a problem.

In the “General” section, for example, the relations between our classes would look like this:

The “Statistics” section will be similar to this:

Finally, the “Lockout logs” will be very similar to “Statistics”:

Conclusion

So far we defined our requirements and thought of a design for our new and improved plugin. We explained how we came up with our structure and also provided some simple diagrams showing how our classes will be related to each other.

Click here to read Part 5 in our Objected Oriented Programming Series

See Also

Host your Website with Pressidium!

View our price plans

Host your website with Pressidium

60-DAY MONEY BACK GUARANTEE

SEE OUR PLANS

Do you like this article?

Subscribe to our blog and get awesome WordPress content straight to your inbox.

SUBSCRIBE

OUR READERS ALSO VIEWED:

WordPress Custom Header: What Is It and How to Create One

What is a WordPress Custom Header? How do you customize a header in WordPress? Find out in this article!
Tassos Antoniou
Tassos Antoniou
8 min read

Visitor Behavior Analysis: A Guide To Identifying Revenue Leaks

This guide helps you find out how to identify revenue leaks using visitor behavior analysis improving revenue and the user experience.
Jenna Bunnell
Jenna Bunnell
11 min read

A Helpful Guide to Moderating WordPress Comments Like a Pro

Learn how to moderate comments in WordPress by tailoring your website settings in order to maintain helpful discussions in your comments!
Jenna Bunnell
Jenna Bunnell
12 min read

8 Proven Strategies to Recover Abandoned Carts in WooCommerce

Abandoned WooCommerce carts are shopping carts that are just waiting to be checked out. Find out how to recover these to maximize your sales!
Juliette Anderson
Juliette Anderson
6 min read
SUBSCRIBE