This was quite eye opener for me. For long I reckoned that creating a plugin was hard and labour intensive. Not to speak of the challenges that came up with WordPress in general. But the framework was there and it didn’t feel that difficult at all. I’m glad it all worked out.
For some of my own SEO/SEA projects, that merely serve as testbeds for theories, I needed some plugins to help me do the job. After searching for a while I kinda hated them all. That’s where my own plugins and Betacore happened. From one thing into another. You know how that goes.
Starting with a plugin
I used one-file plugins before in WordPress. To change things on the WordPress installation or a WordPress theme on a non-destructive way. So I already knew how to start with this:
A folder with the name of the plugin and a similarly named php file. In that file there have to be some comments to make WordPress recognise the entire thing.
/** * Plugin Name: The title of my plugin * Plugin URI: the url to your plugin website * Description: Something to describe your plugin * Version: 6.66 * Author: Your name * Author URI: your website **/ // start coding here!
Yes, it is that simple! A good file structure is important as well. So I’ve started with a basic /inc/ folder where all the php files with function sets would be housed. Every file has some functions that are kind of related. Some of them are sort of interchangeable so I can edit and update multiple plugins rather quickly.
Then there is the /templates/ and /css/ folders for all the things that make a plugin pretty. And in the end I get something along the lines like this:
/plugin-name/ // the folder /plugin-name/plugin-name.php // in this file I include everything and ofcourse put the information displayed above. /plugin-name/uninstall.php // clean up after you are done /plugin-name/inc/functions-wpadmin.php // some useful functions for editing and saving settings /plugin-name/inc/functions-thisplugin-core-functions.php // what it is all about, the meat of the plugin, the functionality basicly. /plugin-name/inc/functions-navigation.php // all the navigational functions /plugin-name/css/admin.css // this is backend theme stuff /plugin-name/css/style.css // this is frontend theme stuff /plugin-name/template/form-wpadmin.php // the form page for the wp-admin side of the function /plugin-name/template/some-frontend-stuff-files.php // the things that show on the frontend of WordPress.
That is about it.
Sanitising your form and outputted data
For making and keeping the data safe I trust the sanitisation functionalities of WordPress for now. However I am researching other possibilities as well. Double checking that the data inputted and outputted is limited to the information that should be put in the form as well ass the stuff that comes out the database is always a good practice.
Making use of the Uninstall.php
What I love about creating good plugins is that when everything is done and the day is over, when you want to delete the plugin, all the accompanying data is removed with it. Yes, cleaning up after yourself is good practice. Especially if your plugin is corrupting a WordPress installation you want to make sure nothing stays behind.
This is kind of how I go about creating the tools I need for the job and change my WordPress installation to fit my needs. Probably the next release will be a WordPress Janitor plugin that does some sweet stuff in the WP-admin panel like cleaning up those pesky widgets and keeping up with updates. I’ve also managed to tie a function into the cron so that you can receive an update every week on how the site is running and if there are things that need attention. The Super Simple Site Offline and Simple Analytics Tag tie in this plugin seamlessly and I made the thing feel like it belongs in the core WordPress. At least, I hope.