Create An Image Slide Plugin Part 2: Setup

Create An Image Slide Plugin Part 2: Setup

In the second post post from the series of tutorials on creating a WordPress plugin for displaying image slides we’ll learn how to setup a WordPress plugin that is more complex and using best practice techniques and code.

In the previous post of the series we’ve briefly introduced the basic concept of creating WordPress plugins. We’ve also created an example plugin to kick things off and see just how simple it can be to get going.

Although the example plugin was working fine, it was a very basic plugin that didn’t do much. Most WordPress plugins are more complex than that and that’s why they need a certain organisational feature that would make the code more extensible in the future should we and want to expand on it.

Starting with this post we’ll get more organised by using a piece of software called The WordPress Plugin Boilerplate that will help us keep our code nice and tidy.

In this part we’ll explore the benefits of using this boilerplate code and we’ll get into the structure that it offers us by looking at all the files and folders where we can place our code.

The WordPress Plugin Boilerplate

So, what is a boilerplate?

In computer programming, boilerplate or boilerplate code refers to repetitive pieces of code that are included in software projects with little or no change. It’s reusable code.

What is The WordPress Plugin Boilerplate?

The simple answer: it is a plugin, that, as is, does nothing.

According to the official website it is a standardized, organized, object-oriented foundation for building high-quality WordPress Plugins. As its name suggests it is made up of boilerplate code that is meant to help programmers write plugins in a way that is common among developers.

Create An Image Slide Plugin

Here is an overview of the functionality of our plugin:

  • The plugin will have a custom post type called mnsp_slide. This will be like a normal blog post only we’ll be able to pick and choose what goes inside it.
  • We’ll be able to group several slides into a  mnsp_slider with the help of a taxonomy.
  • Each slide will have some metadata information that the user will be able to fill in to alter the look and functionality of each slide. The metadata information for each slide will consist of:
    • Title
    • Subtitle
    • Description
    • Call To Action
    • Image
    • Aspect ratio
    • Alignment
    • Background color
    • Featured image opacity
  • The slider taxonomy will also have some metadata information which will be used to alter the behavior of the the sliders we create. The metadata for each slider will consist of:
    • Transition type
    • Transition duration
    • Timeout between slides
    • Show navigation
    • Pause slider on hover over slide
    • Autoplay
    • Aspect ratio
  • The plugin will offer two shortcodes for displaying the slides and sliders inside posts and pages.

As we can see in the list above, we’ll be creating a “mnsp_slide” custom post type and a “mnsp_slider” taxonomy.

Each slide will have additional metadata information used to describe it further and add additional functionality. The slider taxonomy will be used to gather multiple slides into sliders.

Now that we know what the key pieces functionality are, let’s get on with creating the plugin. We’ll start with analyzing how the code is organized.

The File And Folder Structure Of A WordPress Plugin

If you want to follow along I’ve set up a GitHub repository where you’ll find the code from this series. The finished code for this post is in the part_2 branch.

The main plugin folder has the following structure:

Folder structure for the Monospace Slides WordPress Plugin by

As we can see in the screenshot above, our plugin contains two folders for admin and public side functionality as well as some other folders and files which we’ll get into later on.

Here is a breakdown of the folders and their contents:

  1. /admin: as the name suggests, inside this folder lives all the functionality that we’ll use on the admin side. This folder breaks down even more into additional folders to make the code as streamlined as possible.
  2. /includes: this folder contains files related to the main functions that the plugin has as well as common code for the admin and public sides.
  3. /languages: as the name implies, this folder contains files related to the internationalization of the plugin.
  4. /public: similar to the admin folder, here lives all the functionality that will be used on the public side. It also breaks down into additional folders.

Now let’s take a look at some of the files that reside in the different folders we’ve seen above:

1. / this file contains information that people can read for a quick overview of the plugin. You can find more info about creating such a file, here.

2. /monospace-slides.php: this is the main file of the plugin. It contains the plugin header, as well as the code for initializing and running the plugin. It registers hooks for activating and deactivating the plugin and loads the main plugin class.


 * The plugin bootstrap file
 * This file is read by WordPress to generate the plugin information in the plugin
 * admin area. This file also includes all of the dependencies used by the plugin,
 * registers the activation and deactivation functions, and defines a function
 * that starts the plugin.
 * @link    
 * @since             1.0.0
 * @package           Monospace_Slides
 * @wordpress-plugin
 * Plugin Name:       Monospace Slides
 * Plugin URI:
 * Description:       A WordPress plugin for displaying image slides.
 * Version:           1.0.0
 * Author:            Mike In Monospace
 * Author URI:
 * License:           GPL-2.0+
 * License URI:
 * Text Domain:       monospace-slides
 * Domain Path:       /languages
// If this file is called directly, abort.
if ( ! defined( 'WPINC' ) ) {
 * Currently plugin version.
 * Start at version 1.0.0 and use SemVer -
 * Rename this for your plugin and update it as you release new versions.
define( 'MONOSPACE_SLIDES_VERSION', '1.0.0' );
 * The code that runs during plugin activation.
 * This action is documented in includes/class-monospace-slides-activator.php
function activate_monospace_slides() {
 require_once plugin_dir_path( __FILE__ ) . 'includes/class-monospace-slides-activator.php';
 * The code that runs during plugin deactivation.
 * This action is documented in includes/class-monospace-slides-deactivator.php
function deactivate_monospace_slides() {
 require_once plugin_dir_path( __FILE__ ) . 'includes/class-monospace-slides-deactivator.php';
register_activation_hook( __FILE__, 'activate_monospace_slides' );
register_deactivation_hook( __FILE__, 'deactivate_monospace_slides' );
 * The core plugin class that is used to define internationalization,
 * admin-specific hooks, and public-facing site hooks.
require plugin_dir_path( __FILE__ ) . 'includes/class-monospace-slides.php';
 * Begins execution of the plugin.
 * Since everything within the plugin is registered via hooks,
 * then kicking off the plugin from this point in the file does
 * not affect the page life cycle.
 * @since    1.0.0
function run_monospace_slides() {
 $plugin = new Monospace_Slides();

3. /uninstall.php: the functionality in this file is called when the plugin is uninstalled.

Looking at the code in the /monospace-slides.php file above, we can see that it branches out in the /includes folder. Here is what each of the files, in that folder, will be used for:

1. /class-monospace-slides-activator.php: this file contains functionality used during the activation process of our plugin.

2. /class-monospace-slides-deactivator.php: here we’ll put the code used during the deactivation process of the plugin.

3. /class-monospace-slides-i18n.php: this file deals with translation functionality.

4. /class-monospace-slides-loader.php: this is a key file responsible for registering with WordPress all the actions and filters of the plugin.

5. /class-monospace-slides.php: this file contains most of the action. The class contains two important methods for adding front and back end hooks.

 * Register all of the hooks related to the admin area functionality
 * of the plugin.
 * @since    1.0.0
 * @access   private
private function define_admin_hooks() {
 $plugin_admin = new Monospace_Slides_Admin( $this->get_plugin_name(), $this->get_version() );
 $this->loader->add_action( 'admin_enqueue_scripts', $plugin_admin, 'enqueue_styles' );
 $this->loader->add_action( 'admin_enqueue_scripts', $plugin_admin, 'enqueue_scripts' );
 * Register all of the hooks related to the public-facing functionality
 * of the plugin.
 * @since    1.0.0
 * @access   private
private function define_public_hooks() {
 $plugin_public = new Monospace_Slides_Public( $this->get_plugin_name(), $this->get_version() );
 $this->loader->add_action( 'wp_enqueue_scripts', $plugin_public, 'enqueue_styles' );
 $this->loader->add_action( 'wp_enqueue_scripts', $plugin_public, 'enqueue_scripts' );

In a future post we’ll be registering our own admin and public hooks inside these methods. We’ll be adding the functionality for these registered hooks inside the admin and public folders.

At the end

We’ve covered quite a bit of ground here and we’re off with a solid start.

Now, we have a solid foundation upon which we’ll build in the upcoming posts of this tutorial series. Our plugin follows best practice guidelines and has a clear organization of it’s files and folders. It is very clear where we’ll put the code related to any functionality we’ll want to build.

In the next part we’ll begin writing code for the custom functionality we’ve outlined earlier.

In the mean time please feel free to comment with your progress, things you want to see covered in more depth as well as any other suggestions you may have.

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.