Welcome to the Swiss-Army-Plugin for WordPress. My unique design offers a way to have an endless number of handy features in our WP blogs and reduce the number of plugins we need to install. The project is still very new right now (2017) so it’s not bursting with tools but it won’t take long to add plenty more. I fully intend to use the plugin for all of my own blogs, adding many tools whenever I can.
If you create an extension for Multitool you can get a link to it’s repository added here.
- GitHub (download package)
- Slack (development discussion)
- Discord Live Chat (free WordPress support)
- Report Faults/Bugs
- Projects Blog
Read More About Multitool
As with most of my plugins, the WordPress Multitool Plugin started as a prototype. The initial plugin had everything I created for other plugins, I would just copy it from a new plugin into Multitool. It included a PHP class for the Twitch.tv API – purely online gaming. My initial experiment was to pack a plugin full of working features (tools) and I tried to design an interface for managing what quickly became a bloated plugin!
It is safe to say the initial design failed.
- It was inefficient.
- There were no boundaries to create consistency from tool to tool.
- Development was far more difficult than it should be.
- The types of tools being added were far too niche i.e. the Twitch API.
Re-Development Looks Great
I re-developed Multitool using the WordPress Plugin Seed – a boilerplate plugin that saves hours of time when starting new plugins. The new design, is my own, despite using a boilerplate. I’m still working towards a plugin offering many tools but I’ve added boundaries. If a new tool cannot fit within the boundaries, it really should be a plugin of its own. The strict boundaries will protect the user experience and encourage high development standards.
Tool Types Explained
The plugins tools are now split into three types based on how technical they are. Each type has a different user-interface and development interface. My approach offers consistency for both users and any developer who needs to add new tools. The three tool types I came up with…
- Quick Tools
- Configuration Tools
- Advanced Tools
These tool types can be found in the Tools menu, making great use of a menu rarely visited. It’s an underused menu and this plugin will change that.
Individually, these tools are visually basic. The innovative part is that they are presented in a data table (WP_List_Table). The table offers search and sorting ability. This is going to allow unlimited expansion of basic tools, without the interface becoming bloated and difficult to navigate. I will encourage the addition of Quick Tools to perform tasks that need no settings. Developers should easily understand this restriction.
Configuration Tools are those that require options. These tools are not offered in a table, so we lose some of the great advantages like search. Eventually we can still present these tools in a data-driven way, but for now, they are coded within a WP settings page. If you’re unfamiliar with WordPress, that basically means the view that the tools are on, interfaced with the WP Options API in a way that makes development very easy.
The options for a configuration tool are hidden until the tools single checkbox is checked. Checking a box for a tool activates that tool. It might activate for one submission or the tool might apply a long term change to the blog.
The advanced tools view is not complete but the design is decided and development ongoing. This tool type is where I risk the plugin becoming over-bloated again because I’m essentially inviting a more complex feature as done in the prototype. This time, there are boundaries and the advanced tools system restricts tools to a step by step process, much like the plugins installation wizard. If a tool cannot work within this system, it should be a plugin of its own.
We can add as many advanced tools as we like and the many steps for each are hidden. So the plugin will not be visually bloated and overwhelming.
An indicator of success for this plugin will be when it begins assimilating other plugins. What I mean by this is, offering the same feature as another plugin, using the same outputs where possible so that users can switch to Multitool easily, and inviting the community to move unsupported plugins into Multitool themselves.
I fully intend to do this. There are many plugins that are unsupported but still used by hundreds of blogs. There are plugins that do a very small thing that would get away with not being a plugin on its own. The success of another plugin will pave the way for what is added to Multitool.
The great thing is that my plugins design has no drawbacks. The advancement of WordPress, PHP, and server technology means that we can increase the size of a plugin and maintain a great level of performance.
So add a tool or hire a developer to add a tool, then become a long-term and happy use of Multitool.