It’s been a while since I’ve written anything, but we have so many cool things going on internally, that I just needed to share our latest internal technology services update. If you want to look directly at all of our work, just come over to our GitHub page at https://github.com/designink-digital.
The Framework
A lot of the cool things we have been doing recently revolve around the “framework” that I wrote for WordPress. Long story however long I decide to write it, we use several plugin products from a great company, SkyVerge (https://www.skyverge.com/). You’ll see, the pattern to success is having two words together in camel case in your company name. Jokes aside, I was writing code to do some custom work for our clients and I noticed that they used a custom library of their own in all their plugins that they released, and it sparked an idea with me to do the same thing. The thing I wanted different was that I wanted a generalized WordPress plugin framework rather than just for WooCommerce. It would be an abstract library of extendable classes that would represent the literal pieces of WordPress (plugin, screen, post type, meta, etc) and would take care of the native WordPress function calls in the background (nonce checking, data saving, etc.). Futhermore, the framework would also serve to encourage the proper usage of the WordPress coding standards (https://make.wordpress.org/core/handbook/best-practices/coding-standards/) and would be properly documented. The work of setting up a plugin would already be taken care of and a developer could just write the functional code. So, I did it.
It has been a couple years since I released my first revision of my framework, and it has lived up to my expectations. I can’t tell you how many times I have been grateful to have it. There have been struggles and a period of several months where there were no updates to the framework, but this year, I have developed out everything that I wanted from the very beginning. I also feel like there is more potential for this project than attention that I could possibly give it, and I think I’m finally at a point where I am okay with my work and would be comfortable hearing from other developers.
I have created a demo plugin (https://github.com/designink-digital/designink-wp-framework-test-plugin) which shows how to use the framework, and will have a write-up describing how to use it, but I’ll just go over the basics to give you an idea of how it works. Your main plugin file name is always the same as the plugin folder name, and that’s where the main plugin class goes. All of the other (non-admin) code naturally goes in the “includes” folder inside of a proper subfolder. Plugins have “modules” that are loaded when the plugin is loaded (they go in “includes/modules”), which are intended to represent the different parts of your plugin functionality, just like the framework represents the pieces of WordPress. In fact, modules are based on singletons, a common pattern in WordPress, and plugins are actually modules in this framework. Modules are intended to attach action and filter hooks when they are constructed, and the hooks are given a function name from that module class. So, this is how the plugin would look so far:
my-plugin/my-plugin.php
<?php
/**
* Plugin Name: My Plugin
* Plugin URI: https://designinkdigital.com/
* Description: It’s mine. My own! My preeeeciooouuss...
* Version: 1.0.0
*/
defined( 'ABSPATH' ) or exit;
use DesignInk\WordPress\Framework\v1_1_0\Plugin;
// Include DesignInk's framework
require_once __DIR__ . '/vendor/designink/designink-wp-framework/index.php';
if ( ! class_exists( 'My_Plugin', false ) ) {
/**
* The wrapper class for this plugin.
*/
final class My_Plugin extends Plugin {
/**
* Module entry point.
*/
final public static function construct() { }
}
// Fire it up
My_Plugin::instance();
}
my-plugin/includes/modules/my-module.php
<?php
defined( 'ABSPATH' ) or exit;
use DesignInk\WordPress\Framework\v1_1_0\Module;
if ( ! class_exists( 'My_Module', false ) ) {
/**
* A test module to demonstrate functionality.
*/
final class My_Module extends Module {
/**
* The module entry point.
*/
final public static function construct() {
add_action( 'init', array( __CLASS__, '_init' ) );
}
/**
* The WordPress 'init' action hook.
*/
final public static function _init() {
die( “Congratulations!” );
}
}
}
The Plugin Update Server
Another cool thing that I’ve been holding onto for a while is our plugin update server (https://github.com/designink-digital/designink-plugin-update-server). It began with a plugin we used on all of our WordPress sites using a particular theme, and I wanted to be able to update my plugins using the WordPress dashboard. I only did not want to have to go through the process of putting my plugins on the WordPress market, plus there were some plugins I wanted to have private. Even better, I decided I would support private repos from GitHub. I use GitHub to host all of our projects, so I decided to map all of the information from the GitHub API to the WordPress updater API.
The basic functionality of the system is that you have plugins saved on your GitHub account, and an update server that looks at specific plugins for information and verifies they are WordPress plugins. These plugins have to be connected to the update server using our plugin update helper library (https://github.com/designink-digital/plugin-update-helper), but that part is all too easy. Then when each site with the plugin pings the update server, they get a response of the GitHub plugin data, and if a newer version of the plugin has been released, it allows you to update it with the other plugins in the WordPress update dashboard.
I’m not going to lie, I haven’t been using this plugin as much recently, but I’ve always thought it was really cool. I feel like it could easily be extended to support theme updates as well, but I’ve had no interest in taking the task and I keep hearing the whispers of themes being obsolete in an age of blocks and page builders. Honestly, after using some Elementor, I believe it, but I’m not here to be controversial. The plugin update server works great, though: you can upload the icons and banners for the plugins, it gives you a summary of the GitHub changes in the admin panel, it caches API responses for half an hour so your WordPress sites don’t have to take an extra 3 seconds loading the page when WordPress is looking for updates, and it’s pretty. Did I mention it works great? Check it out! Use it! Give me ideas or take it and make improvements!
“You’re welcome.” – DesignInk Digital. No, but seriously, we all hope we can help improve your quality of life, and we want to remind you to send those in need of digital help our direction. “Thank you!” – DesignInk Digital.
“I hope I’m not out of line speaking for everyone like this.” – Kyle Niemiec
