Categories
Web WordPress WordPress Plugins

WORDPRESS PLUGIN BOILERPLATE

What is Plugin Boiler Plate?
A foundation for WordPress Plugin Development that aims to provide a clear and consistent guide for building your plugins.

Every time I start working on a new plugin I find myself renaming files names, searching and replacing plugin-namePlugin_Name , the packages, sub packages names, etc. All these tasks take me around 5-10 minutes every time, and I don’t like repeat unnecessary tasks.

So I found an easy way to generate WordPress plugin basic structure with in seconds. Of course it saved a lot of time.

Please visit  WordPress Plugin Boilerplate to generate plugins boiler plate. Obviously it won’t generate all of the files you require for your plugin. You can add more files once you have your basic structure.

WordPress Plugin Boilerplate Generator Configuration
WordPress Plugin Boilerplate Generator Configuration

There is no standard way to write a plugin. People follow different ways to write plugins. Some plugins require OOP to be followed and some don’t. But this is the best OOP structure that I had ever found and used in my Plugins development.

Please visit WordPress Plugin Boilerplate GitHub repository to get the essence of the final plugin structure.

It is meant to be a starting point for plugin development, an object oriented way of creating a standardized plugin. Since it is coded with OOP principles, it is mainly intended for intermediate coders, but you can easily use it even as a beginner if you know what goes where. By the end of this article, you should know what’s what and how you can get started with it – regardless of your coding experience.
Lets dig deeper into it.

File Structure.
The boilerplate is meant to be used as a GitHub repository, so the main directory contains files commonly found in GitHub repos. The README.md file is a general readme and shows up on your main repository page as the description and details about the plugin. The .gitignore file is for setting files that git should ignore when working with files.
The main folder here plugin-name is where the plugin is stored. It should have at least one fine your-plugin-slug.php with all the plugin details (Plugin Name, Version, Description, Author, Plugin Slug).

<?php

/**
 * 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              www.authoruri.com
 * @since             1.0.0
 * @package           Your_Plugin_Slug
 *
 * @wordpress-plugin
 * Plugin Name:       Your Plugin Name
 * Plugin URI:        www.yourpluginurl.com
 * Description:       This is a short description of what the plugin does. It's displayed in the WordPress admin area.
 * Version:           1.0.0
 * Author:            Author Name
 * Author URI:        www.authoruri.com
 * License:           GPL-2.0+
 * License URI:       http://www.gnu.org/licenses/gpl-2.0.txt
 * Text Domain:       your-plugin-slug
 * Domain Path:       /languages
 */

// If this file is called directly, abort.
if ( ! defined( 'WPINC' ) ) {
	die;
}

/**
 * Currently plugin version.
 * Start at version 1.0.0 and use SemVer - https://semver.org
 * Rename this for your plugin and update it as you release new versions.
 */
define( 'YOUR_PLUGIN_SLUG_VERSION', '1.0.0' );

/**
 * The code that runs during plugin activation.
 * This action is documented in includes/class-your-plugin-slug-activator.php
 */
function activate_your_plugin_slug() {
	require_once plugin_dir_path( __FILE__ ) . 'includes/class-your-plugin-slug-activator.php';
	Your_Plugin_Slug_Activator::activate();
}

/**
 * The code that runs during plugin deactivation.
 * This action is documented in includes/class-your-plugin-slug-deactivator.php
 */
function deactivate_your_plugin_slug() {
	require_once plugin_dir_path( __FILE__ ) . 'includes/class-your-plugin-slug-deactivator.php';
	Your_Plugin_Slug_Deactivator::deactivate();
}

register_activation_hook( __FILE__, 'activate_your_plugin_slug' );
register_deactivation_hook( __FILE__, 'deactivate_your_plugin_slug' );

/**
 * 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-your-plugin-slug.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_your_plugin_slug() {

	$plugin = new Your_Plugin_Slug();
	$plugin->run();

}
run_your_plugin_slug();

Activation, Deactivation & Uninstall:
This file ( your-plugin-slug.php ) also includes activation and deactivation hooks. These hooks are fired when plugin is activated and deactivated. This file is a gateway to the functionality of the whole plugin. You can add your whole code in this file but its not recommended you should follow MVC separate your models, views and your controllers. Any code you want to run when the plugin is activated should go in includes/your-plugin-slug-activator.php. In this file, there is a class named Your_Plugin_Slug_Activator inside which there is a activate() method you should use.

<?php

/**
 * Fired during plugin activation
 *
 * @link       www.authoruri.com
 * @since      1.0.0
 *
 * @package    Your_Plugin_Slug
 * @subpackage Your_Plugin_Slug/includes
 */

/**
 * Fired during plugin activation.
 *
 * This class defines all code necessary to run during the plugin's activation.
 *
 * @since      1.0.0
 * @package    Your_Plugin_Slug
 * @subpackage Your_Plugin_Slug/includes
 * @author     Author Name <author@gmail.com>
 */
class Your_Plugin_Slug_Activator {

	/**
	 * Short Description. (use period)
	 *
	 * Long Description.
	 *
	 * @since    1.0.0
	 */
	public static function activate() {
		//activation code here
	}

}

The code you need to run on deactivation should be placed in includes/your-plugin-slug-deactivator.php. The deactivate() method within the Your_Plugin_Slug_Deactivator is what you’ll need to use.

<?php

/**
 * Fired during plugin deactivation
 *
 * @link       www.authoruri.com
 * @since      1.0.0
 *
 * @package    Your_Plugin_Slug
 * @subpackage Your_Plugin_Slug/includes
 */

/**
 * Fired during plugin deactivation.
 *
 * This class defines all code necessary to run during the plugin's deactivation.
 *
 * @since      1.0.0
 * @package    Your_Plugin_Slug
 * @subpackage Your_Plugin_Slug/includes
 * @author     Author Name <author@gmail.com>
 */
class Your_Plugin_Slug_Deactivator {

	/**
	 * Short Description. (use period)
	 *
	 * Long Description.
	 *
	 * @since    1.0.0
	 */
	public static function deactivate() {
		//deactivation code here
	}

}


Do you think this is a bit too complex? I don’t blame you! When you start using object oriented concepts you’ll see the benefit of this over procedural code. If nothing else, it provides a very obvious place to put your code which is in itself a huge help. For uninstallation, the recommended method is to use uninstall.php which is what WordPress Plugin Boilerplate does. Your code should be placed at the very bottom of that file. You should dump everything that your plugin has created it is a sign of good plugin development to clean what is of no use. WordPress will automatically call uninstall.php if found in the plugins main folder. You can also use uninstallation hook.

<?php

/**
 * Fired when the plugin is uninstalled.
 *
 * When populating this file, consider the following flow
 * of control:
 *
 * - This method should be static
 * - Check if the $_REQUEST content actually is the plugin name
 * - Run an admin referrer check to make sure it goes through authentication
 * - Verify the output of $_GET makes sense
 * - Repeat with other user roles. Best directly by using the links/query string parameters.
 * - Repeat things for multisite. Once for a single site in the network, once sitewide.
 *
 * This file may be updated more in future version of the Boilerplate; however, this is the
 * general skeleton and outline for how the file should work.
 *
 * For more information, see the following discussion:
 * https://github.com/tommcfarlin/WordPress-Plugin-Boilerplate/pull/123#issuecomment-28541913
 *
 * @link       www.authoruri.com
 * @since      1.0.0
 *
 * @package    Your_Plugin_Slug
 */

// If uninstall not called from WordPress, then exit.
if ( ! defined( 'WP_UNINSTALL_PLUGIN' ) ) {
	exit;
}

//write uninstallation code here.

Adding Hooks

Hooks are handled by WordPress Plugin Boilerplate amazingly, but it may seem a bit unwieldy at first. All your hooks should be placed within includes/class-your-plugin-slug.php. More specifically, inside the Your_Plugin_Slug class, within two methods:

  • define_public_hooks() when adding a hook that is used on the front-end for public.
  • define_admin_hooks() when adding a hook that is used on the back-end for admins.

Instead of using add_action() or add_filter() as usual, you’ll need to do things slightly differently. Here is how you add an action.

$this->loader->add_action( 'init', $plugin_public, 'display_message' );

Here we have a loader class Class Your_Plugin_Slug_Loader that automatically adds actions and filters for us.
The first parameter is the name of the hook, the second is a reference to the public or admin object. For public hooks this should be $plugin_public, for admin hooks it should be $plugin_admin. The third parameter is the hooked callback function.

While it seems more convoluted it standardizes the addition of hooks completely, splitting them into two distinct groups in the process.

Public And Admin Content

WordPress Plugin Boilerplate splits hooks into admin/public groups but that’s not all. It splits all your code in the same way by asking you to write public-facing code in the public folder and admin-facing code in the admin folder.

Both folders contain cssjs and partials folders. You should place used CSS/JS assets into these folders and write templates and other reusable bits of HTML into the partials folder. It’s okay to create new files in the partials folder, in fact, that’s what it’s there for!

You should write your hooked functions in these folders as well, within the class in the respective directories. When we hooked the display_message function to inti hook above, we told WordPress Plugin Boilerplate where to look for it as well. Since we added this to the public facing side, WordPress Plugin Boilerplate expects it to be defined within the Your_Plugin_Slug_Public class which is in the public folder. Simply create this function within the class and write everything else as required.

Resources And Dependencies:
You can add other resources and dependencies in includes folder, admin or public folder depending on the use of that resource.

At first, using WordPress Plugin Boilerplate may seem like a hassle, but it will pay off in the end. You will come back a year later and know where everything is, your plugin development will be standardized across products and other developers will be able to figure out what’s going on as well.

Finally, don’t forget that a plugin providing a simple widget may not need such a framework. While the use of WordPress Plugin Boilerplate won’t slow down your plugin it does clog up the view if all you need is a few simple lines of code!

Cheers!

  • plugin-boiler-plate-overview
  • plugin-boiler-plate-admin-overview
  • plugin-boiler-plate-includes-overview
  • plugin-boiler-plate-public-overview

And if you have enjoyed this post, feel free to share it or subscribe to my newsletter below.

Categories
Web WordPress

WordPress Basic Terminologies 📃

This article will help beginners to get conformable with the terms used within the WordPress ecosystem.

Some of these terminologies might seem known to you depending on your level of experience with WordPress, and web development in general.

These terms will help you to better understand the WordPress official documentation, support articles, and other WordPress developers. Now, here are some terms which you will find handy when talking about WordPress .

  1. Back End – The back end refers to the area of your site where you can log in and manage everything from your Dashboard.
  2. Content Management System – A software which helps to manage content a website.
  3. cPanel – A web-based administration tool for managing your web hosting account.
  4. Database – A software used to store and manage data in an orderly fashion.( i.e. MSQL )
  5. Codex – The official WordPress manual with support articles, documentation, code snippets, and links to external resources.
  6. Default theme – The theme that comes by default with a fresh installation of WordPress. Also used as a fallback theme if the current theme breaks.
  7. DNS – Refers to the Domain Name System which maps domain names( like google.com) to its IP address.
  8. Domain name – A system used to assign easy to remember names to IP addresses of websites.
  9. DOM – An interface that allows programmers to dynamically access HTML and XML on a web page.
  10. Footer area – The horizontal area at the bottom of the website where widgets and copyright information are usually displayed.
  11. Header Image – A wide picture that can be set to appear at the top of your website.
  12. Front end – The user-facing part of your website where visitors can view and interact with your content.
  13. Gravatar – A service which lets users associate a global avatar (image or photo) with their email addresses.
  14. Hosting provider – A company which sells space on a web hosting server for a fee.
  15. IDE – An application which provides you with all the tools you need to develop and test software.
  16. Menu – A collection of links to pages, categories, and social media profiles on your website usually displayed in the navigation area.
  17. Meta – Can mean different things in WordPress depending on where it is used. Usually used to refer to administrative data.
  18. Navigation – A set of links on your website which helps site visitors navigate through your content.
  19. Nonce – A one-time token generated by WordPress to protect your site against unexpected or duplicate requests which can cause permanent or unintended consequences.
  20. Multisite – Create a network of WordPress sites from a single WordPress installation.
  21. Permalink – A permanent link to content on your website. Can be used to share unique pages on your website with others easily.
  22. Sidebar – A place on your website where you usually display the search bar, recent and popular posts, and other important widgets. A website can have more than one sidebar.
  23. XML-RPC – A remote procedure call (RPC) protocol which uses XML to encode its calls and HTTP as a transport mechanism.
  24. Toolbar – The small black bar just above your site from where you can access quick links to various parts of your website. Usually visible only to logged in users.
  25. Post – Also known as “articles” and sometimes incorrectly referred to as “blogs”. In WordPress, “posts” are articles that you write to populate your blog.
  26. Post Slug – A few lowercase words separated by dashes, describing a post and usually derived from the post title to create a user-friendly (that is, readable and without confusing characters) permalink. Post slug substitutes the “%posttitle%” placeholder in a custom permalink structure. Post slug should not be changed and is especially useful if the post title tends to be long or changes frequently.
  27. Post Type – Post type refers to the various structured data that is maintained in the WordPress posts table. Native (or built-in) registered post types are postpageattachmentrevision, and nav-menu-item. Custom post types are also supported in WordPress and can be defined with register_post_type(). Custom post types allow users to easily create and manage such things as portfolios, projects, video libraries, podcasts, quotes, chats, and whatever a user or developer can imagine.
    1. Related articles: Post Types
  28. Role – A role gives users permission to perform a group of tasks. When a user logs in and is authenticated, the user’s role determines which capabilities the user has, and each capability is permission to perform one or more types of task. All users with the same role normally have the same capabilities. For example, users who have the Author role usually have permission to edit their own posts, but not permission to edit other users’ posts. WordPress comes with six roles and over fifty capabilities in its role-based access system. Plugins can modify the system.
    1. Related article: Roles and Capabilities
    2. External link: Role-based access control (Wikipedia)
  29. Screen – In WordPress a screen is a web page used for managing part of a weblog (site) or network. The term ‘screen’ is used to avoid confusion with ‘page‘, which has a specific and different meaning in WordPress. For example, the web page used to manage posts is known as the Posts Screen.
    1. Related article: Class_Reference/WP_Screen
  30. Shortcode – A Shortcode is a technique for embedding a snippet of PHP code into the body of a page or other content item.

To learn more about WordPress terminology, have a look at the WordPress Glossary page.

WordPress Terms

And if you have enjoyed this post, feel free to share it or subscribe to my newsletter below.

Categories
Servers Web WordPress

How does the web work?

The Web is a subset of the Internet.

While the Internet makes up all communication between computers within any application, port, or protocol — the Web generally refers to networks of computers communicating over Hyper Text Transfer Protocol (HTTP), serving Hyper Text Markup Language (HTML) and related assets, such as images, stylesheets, and scripts.

All these technologies work together to create web sites and web applications, parsed by the web browsers and various Application Programming Interfaces (APIs).

When a user requests a web page in a web browser, the process typically looks like this:

  • Search, Social, or Direct Access: If a user types in a search phrase, and the browser bar also acts as a search bar, the web site of the default search engine is queried.
  • DNS Lookup: If the user types in an exact web address, or clicks a link from a social web site or search engine, a Domain Name Server lookup determines which computer should respond to the request.
    • Domain name servers can be overridden with a hosts file.
    • Some domain name servers can intercept, modify, and optimize content. For example, Cloudflare, which can add SSL, optimize HTML, optimize images, etc.
  • Connection & Headers: Browser negotiates either an insecure HTTP connection on default port 80, or a secure HTTPS connection on default port 443. Request headers and response headers are sent. These are viewable in the Web Inspector.
    • A web server doesn’t have to be running on default ports. For example, many development servers might load websites at localhost:8080 or any other arbitrary port.
  • Initial HTML & AJAX: If a browser request is the first request, HTML is most likely returned. This HTML usually contains references to hundreds of other files, which are requested and processed by the browser.
    • Initial HTML and AJAX requests, in our case, are typically handled by a Content Management System such as WordPress.
      • Each request spins up a new PHP process. One page might involve hundreds of HTTP requests!
        • Content Management Systems, such as WordPress, will typically not only spin up a programming language process, but also a database instance for content. This might be MySQLSQLiteMongoDB (NoSQL), or many others.
      • If WordPress is not in use, PHP might still be in use with another PHP-based CMS such as Laravel.
      • If PHP is not in use, the web server could be using any number of server-side technologies, such as static assets (plain HTML or JavaScript), a NodeJS framework such as AdonisJS, or another language such as Ruby, Java, Python, or C# (Microsoft ASP.NET).
  • Static Assets: If the requested file is a static asset, such as CSS, JavaScript, or images, a PHP process is typically not spun up (though PHP can serve these things!) Instead, they are typically served directly by the web server (ApacheNginx, a combination of these, or another server, such as Lighttpd or ASP.NET’s Kestrel server).
    • Serving static assets without PHP is faster than spinning up a PHP process — often by an order of magnitude.
    • Nginx is usually faster than Apache. For this reason, they are sometimes used together, with Nginx as a front-end proxy.
    • Static assets are sometimes offloaded to another server entirely — for example, a CDN such as Cloudflare CDNJetpack, or JSDelivr.
    • Each static asset, JavaScript, CSS, and images, require processing by the browser.
  • Once a web page is loaded, the user starts to interact with the page. From here, simple web pages might link to other pages, re-initiating the entire cycle. If JavaScript is in use, as with Decoupled WordPressReactJS, or plugins like Flying Pages, JavaScript might be used to update page content without reloading initial HTML.

Caching: It’s important to note — caching may take effect at almost every step of the connection process. The browser has a cache. DNS may have a cache (Cloudflare), the CMS may have a cache, and there may be various application-level caches (WordPress wp_object_cache, WordPress Transients API, or plugins such as W3 Total Cache) or server-level caches, such as RedisVarnish, or Nginx.

Resources

Whether you believe it or not, there are great resources out there that have helped hundreds of people with no technical background become web/WordPress developers. If you would like to explore this more for yourself, or just learn more about web development in general, here are some useful links:

And if you have enjoyed this post, feel free to share it or subscribe to my newsletter below.