Create a Custom Plugin in OpenCart 2.1.x.x: Part One

As a developer, it's always exciting to build custom stuff in any framework, and the same is true for OpenCart plugins as well. 

In this two-part series, I'll explain custom plugin development in OpenCart. From the perspective of a newbie developer, we'll go through the details of extension development in OpenCart. We'll also create a small custom plugin to demonstrate each and every aspect of the OpenCart plugin structure. 

In this first part, we'll build a custom plugin that displays recent products in the store front-end, and you'll be able to configure the number of products from the back-end itself. That's what the aim of this article is—develop a back-end plugin with a configuration form.

I assume that you've set up the latest version of OpenCart, which is 2.1.0.2 as of writing this. Before we go ahead and develop an actual plugin, I'll walk you through the basic plugin architecture of OpenCart in the very next section.

MVCL in a Nutshell

The OpenCart is developed with one of the most popular web development patterns, the MVC pattern, with a minor variation, or rather I would say it's an addition. The addition is in the form of a language component that makes it MVCL in the world of OpenCart. It could be that you've heard of this pattern, but for the sake of beginners, I'll quickly summarize what the pattern is all about.

The M in MVC stands for model, and that's where most of the business logic resides. In the context of OpenCart, it's the model that interacts with the database abstraction layer to do all the heavy lifting required to run the store. It's an area where you'll find yourself most of the time as a developer.

Next, the V stands for View, and it represents the presentation layer of the application. As the name suggests, it only deals with the presentation logic of any page, and it receives the input from other layers and generates the XHTML output most of the time. The business logic of an application should be kept away from this layer; it should only worry about what to do instead of how to do it.

It's the C, the controller, in MVC that sits in front of everything, handling every request and treating it accordingly. It's an area that includes most of the application logic, ranging from handling and validating user input to loading the proper model and view components to prepare the page output.

Finally, there's an additional component, L, which stands for language. It makes setting up multilingual sites a breeze.

So that's a quick view of the OpenCart architecture, and it'll make more sense as we move on to the in-depth explanation of each component.

The Skeleton of Any OpenCart Plugin

Let's have a quick look at the list of files that we need to implement for the custom back-end plugin.

  • admin/language/english/module/recent_products.php: It's a file that holds static labels used throughout admin application area.
  • admin/controller/module/recent_products.php: It's a controller file that holds the application logic of our module.
  • admin/view/template/module/recent_products.tpl: It's a view template file and holds XHTML code.

In the next section, we'll create each file mentioned above, with an in-depth explanation.

As per the conventions, we need to place the custom plugin files under the module directory. In this case, as we're developing a back-end plugin, it'll be the directories under admin that hold our files. Of course, the files are spread across different directories, or rather components, as per the OpenCart architecture shown above.

Create Files for the Back-End Plugin

In this section, we'll start creating the module files. First, we'll create a language file admin/language/english/module/recent_products.php with the following contents. It's an important file from the perspective of OpenCart, as it's a must for your plugin to be detected by OpenCart.

As you can see, we're assigning static labels to a PHP array. Later on, you'll have access to these variables in the view template file as the array is converted to PHP variables.

You may have also noticed that the file is created under the english directory as it's the default language of the store. Of course, in the case of a multilingual site, you'll need to make sure that you create it for other languages as well. For example, the French version of the same file should be created at admin/language/french/module/recent_products.php.

Next, we'll create one of the most important plugin files—the controller file. Let's go ahead and create admin/controller/module/recent_products.php with the following contents.

It defines the new class for our custom plugin that extends the base Controller class. As per the conventions, the name of the class should mimic the directory structure under which the file is placed. So, the path controller/module/recent_products.php is converted to ControllerModuleRecentProducts by replacing the slash and underscore characters according to camel-case convention!

Next, there's a de-facto index method that's called when the plugin is loaded in the front-end. So, it's an index method that defines most of the application logic of the plugin.

In the context of the current application, the shorthand $this->load->language loads the corresponding language file. In our case, it loads the language file defined in the earlier section. The syntax is quite simple—you just need to pass the plugin name prefixed by module/. The language variables can be accessed by the $this->language->get method.

Next, it sets the page title by using the setTitle method of the document object.

Moving ahead, the shorthand $this->load->model is used to load the module model. It’s the model class that provides utility methods to save the module parameters and the like.

Following that, there’s an important snippet as shown below that checks if it’s POST data submission, and saves the module configuration in that case.

Further, we’re assigning language labels like heading_title and text_edit to the $data array so that we can use them in the view template file.

Following that, there’s a snippet that builds the correct breadcrumb links for the configuration page.

Had the module already been configured earlier and in edit mode, the following snippet populates the default module configuration.

Finally, we’re loading the common page elements like header, footer and left sidebar. Also, it’s the $this->load->view shorthand that loads the actual view file recent_products.tpl and displays the configuration form.

There are a couple of important notes to remember in the controller file. You’ll see lots of calls like $this->load->ELEMENT, where ELEMENT could be view, model or language. It loads the corresponding view, model and language components.

The next and last file for today’s article is a view template file admin/view/template/module/recent_products.tpl. Go ahead and create it!

Users with sharp eyes will already have noticed that it’s just displaying the variables that were passed from the controller file. Other than that, it’s simple XHTML code to display the configuration form, and the cherry on the top is that it’s responsive out of the box.

So, that’s it as far as the file setup is concerned for our back-end custom plugin.

Enable the Plugin

Head over to the back-end of OpenCart and navigate to Extensions > Modules. You should see Recent Products in the list. Click on the + sign to install the module as shown in the following screenshot.

Back-End Listing

Once it’s installed, you’ll see an edit icon. Click on that to open module configuration form.

Configuration Form

In the configuration form, you could set the number of recent products you want to show in the front-end block. Also, don’t forget to set the status field to Enabled! Save the module, and it should look something like this.

Replicated Module

There’s a new entry for the module titled Recent Products > My Recent Block Plugin. The reason is that you could replicate it multiple times for different pages!

So, we’re almost done! We’ve made a full-fledged back-end custom plugin in OpenCart. In the next part, we’ll go through the front-end counterpart of it that displays a nice-looking products block in the front-end!

Conclusion

Today, we’ve discussed custom plugin development in OpenCart. In the first part of this two-part series, we went through the back-end plugin development and created a working custom plugin that provides a configuration form.

If you're looking for additional OpenCart tools, utilities, extensions and so on that you can leverage in your own projects or for your own education, see what we have available in the marketplace.

In the next part, we’ll complete the plugin by creating the front-end part that displays product listings in the front-end. For any queries and feedback, please use the comment feed below.

Tags:

Comments

Related Articles