The majority of the plugins I have created have created have an output visible to the user. For example, the Posts Archive can be used in a widget (see the side menu) or on a page. And to display the output to the best advantage it needs to be formatted; while this can be done using inline styles it is better done using an external stylesheet (or CSS file).
To use an external stylesheet, create the .css file, which I typically call style.css, in the plugin folder next to the main php file (you can put it in a sub-folder should you wish).
This file then needs to be loaded within the plugin. When working with procedural code, the following snippet of code from my Floating Featured Image plugin shows how the file can be loaded:
wp_enqueue_style( 'azurecurve-floating-featured-image', plugins_url( 'style.css', __FILE__ ), '', '1.0.0' );
The add_action hook can be used to call a function which then calls wp_enqueue_style; this is the “safe” way of loading a style sheet for a WordPress plugin.
The structure of the call is:
- handle – the first parameter is the name of the style and is mandatory.
- source – the location of the stylesheet and is mandatory; this should never be hard-coded as it cannot be guaranteed to be the same on every site. Using the plugins_url function the path of the current file can be automatically retrieved
The first parameter to plugins_url is the file we want, and __FILE__ will be used to determine the folder location of the plugin file; the returned data will be the path concatenated with the filename.
- dependencies – an array containing all of the files which must be loaded before the one being loaded here.
- version – the style sheet version number; used to ensure the correct stylesheet is passed to the client
- media – optional string specifying the media for which this stylesheet has been defined, such as ‘screen’, ‘handheld’ or ‘print’. See this list for the full range of valid CSS-media-types. If not otherwise set will default to ‘all’
By using wp_enqueue_style, the stylesheet is loaded at the right time alongside the other stylesheets.
Having covered the basics of a WordPress plugin from the php tags to the file header, I thought a quick discussion of the code types in which WordPress plugins can be written and which I have used.
There are two code types that can be used:
- Procedural Programming
- Object Oriented Programming
There has been many a flame war fought over which is better and which is worse, but in all honesty I believe that both can have their place and there is no one true way of coding.
I was going to cover the differences between the two types, but when I was researching for good definitions I came across an article by Tom McFarlin linking to articles he and Stephen Harris wrote on the coding paradigms which can be used with WordPress plugins.
I am not old, but my programming career (short as it was and now a few years in the past after I moved into being a consultant) tended to be with older languages such as Databasic and Visual Basic; I also self-taught myself Lua and later PHP.
In all of the programming/scripting languages I have worked with the code has been procedural; I’m not saying all of these languages are only procedural, just that all of the code I worked with was. As such I am far happier in a procedural world and so I have used this for writing my plugins.
I do intend to delve into object oriented at some point, and probably rewrite the plguins as I do, but the plugins I have created I needed to get done fairly quickly as I was using cobbled together code stored in a theme functions file; the number of WordPress sites I run has risen quite quicky and I needed an easy way to distribute the code between them (this also explains why I make all of my plugins multisite compatible). Most of the examples available online for WordPress plugins is procedural which made my choice easier.
The exception to this is widgets; WordPress widgets can only be written using object oriented programming so I will be covering some of this coding paradigm as the series progresses.
A new version of the azurecurve RSS Suffix is now available from the WordPress.org Plugins Directory.
I have added $post_title and $post_url as variables which can be used in the RSS Suffix; they will be replaced with the name and url respecitvely so you can form a link back to the original post.
The RSS Suffix plugin is now available for download on WordPress.org.
Throughout this Anatomy Of A WordPress series I am going to be running through a number of the functions I use a lot and other items required when developing plugins. But, for the first post, it is probably best to start at the very beginning.
When creating a WordPress plugin, the first thing to do is to create the folder in which the files are to be stored. When doing so it is best to pick a name which is going to be unique; I am also typically giving them a name which will group all of my plugins together.
All of the plugins I have created so far have azurecurve at the start of the name. e.g.
Within the file create a php file of the same name with the php suffix:
Open the file and enter the php tags, between which all php code will be entered, at the top and bottom:
Having recently taken up writing plugins for WordPress I am currently on quite a step learning curve; these posts will serve as reminders to myself on what the different parts of a WordPress plugin arehow they hang together.
If anyone spots something which could be better, or is flat out wrong, please leave a comment explaining why and how to do better.
This post is the series index, displayed below, which will expand to show new posts as they are published:
My sixth plugin has just been published via the WordPress.org Plugins Directory; the RSS Suffix allows a suffix, such as a copyright notice or link back to be added to each item in the RSS feed.
This plugin is multi-site compatible and allows a network default RSS suffix to be set via the Network Admin area while each site in the network can set their own RSS suffix.
The RSS Suffix plugin is now available for download on WordPress.org.
My fifth plugin has just been published via the WordPress.org Plugins Directory; the Multisite Favicon allows each site in a multisite network have a separate favicon.
This plugin is multi-site compatible and allows a network default icon to be set via the Network Admin area while each site in the network can set their own favicon which can be stored in a site specific folder if necessary.
The Multisite Favicon plugin is now available for download on WordPress.org.
I have just had a fourth plugin published via the WordPress.org Plugins Directory; this one is a Floating Featured Image.
This plugin displays a floating image in the top right of a post or page using a custom featured-image Shortcode; this plugin supports a default image with defaults for hyperlink, alt and title which are all maintainable through a Admin Settings page.
There is a range of floating image default options to configure for the plugin which can be set via an options page in the WordPress Admin panel.
The plugin is now available for download on WordPress.org.