WorkPlace Snippets

Tag: WordPress Tips

  • Separate theme display and functionality with a build-your-own custom functionality plugin

    Having worked with child themes for some time, it was great to learn something new today, one that will cause a paradigm shift in the way I work with themes. The epiphany came from Dave Clements, who built on Ryan Mel‘s WPCandy article How to create your own WordPress functionality plugin and essentially tells us to use a plugin to introduce custom functionality instead of putting (most) of the code into the theme functions.php file.

    The basic premise is this:

    Create custom functionality for your site but don’t tie it down to a theme

    What do you mean?

    To clarify: we all know what happens when we switch themes – custom taxonomies disappear, shortcodes cease to be of use and Favicons are no longer – unless we build them in, again.

    Why waste time and energy doing this when you can retain all these by creating your own custom functionality plugin?  Then you or your client can switch themes at will.

    Then when should I use functions.php?

    Both Dave and Ryan maintain that not everything should be put into the plugin; some things should still remain in the theme file’s functions.php, for example registering sidebars and custom nav menus, which are specific to your theme.

    Others, including custom image sizes are more open for debate and will be up to your discretion.

    Ryan produced a helpful table to provide some examples, reproduced below:

    Screenshot of comparison table for when to use a functionality plugin vs functions.php

    More content is available by clicking on the image or link above, which will take you to the full article (with even more discussion and recommendations) but hopefully this gives both you (and me) a better idea of what to put in our functionality plugins.

    So how do I create a custom functionality plugin?

    It’s as simple as taking the relevant codes from your functions.php and placing it into a plugin-name.php file. Both articles – WPCandy and Dave – kindly provide blank templates, and Ryan (on WPCandy) actually goes a step further to advise maintaining a readme.txt file.

    I have not included a blank file here since that would be duplicating the good work done by both; direct file linkage is not ideal either.

    Effectively, much like a style.css file, the header in your plugin-name.php is very important:

    /*
Plugin Name: Site Name Functionality Plugin
Description: Summarise the key elements of your site functionality plugin.
Version: 0.1
License: GPL
Author: Your Name
Author URI: Your URL
*/

    This file then goes into /wp-content/plugins/plugin-folder-name. Then you simply activate your new custom functionality plugin.

    Further comments

    It might be reassuring to know that heavy weights like Otto, Michael Fields, PTah Dunbar and Konstantin Obenland have all stated in the comments that they agree this to be good practice and some of them use it on their own sites.

    Dougal Campbell also suggested the following:

    If I switched themes, and this functionality disappeared…
    …would I miss it?
    …would it ‘break’ my site in some way? (I’m using ‘break’ loosely here, subject to interpretation)

    If I installed this theme on somebody else’s site…
    …would they need this?
    …would it expose any of my account info?

    Last but not least, Justin Tadlock also wrote a post about this as well and advises us to ask ourselves two questions:

    Is this something I only want to happen when using my current theme?

    • Is this functionality I want to keep regardless of the theme I’m using?

  • To WordPress and not to WordPress

    Having been overwhelmed with Olympic fever, it’s been awhile since I’ve made a post relating to WordPress, but the community is as active as ever, especially with the release of WordPress 2.6.1 and the final round of voting for the WordPress Plugin Competition.

    This will, fortunately for you all, be a short post with what maybe a catchy title! The good book ‘how to write a good blog post’ sites teach us that a catchy title is very helpful in attracting the attention of browsers. Whether this will be one of the popular posts as a result remains to be seen, but there is a point to this post and the title: it turns out I have been spelling that special word wrong.

    That word, of course, is:

    WordPress

    I’ve always spelt it as WordPress, and never thought more of it, so I was utterly mortified when I started reading Lorelle‘s excellent article Tips on Writing Good WordPress Tips. The first point she made (as convincingly as always) was that:

    WordPress is a trademark and thus must be spelled appropriately.

    That sentence came like a bolt from the heavens (or stepping on a garden rake) and I was left with a sinking feeling in my stomach – just hours before I had chided someone on the WordPress Forums about getting the name of a plugin wrong, and yet I was already making an even more fundamental mistake about something I read about almost everyday – WordPress!

    That feeling of guilt happened to coincide with me reading a new post by Mark Ghosh on WLTC called Be Kind, Educate, (which is just as inspirational as Matt Mullenweg‘s Price of Freedom) where he analyses why there are so many fans of WordPress, and nature of the WP community. His last point, and the title of his article, credits Lorelle as an inspiration for his new pledge:

    to be as kind as I can be … to educate everyone that cares to listen

    So at the end of this post, not only am I going to spell WordPress correctly from now on, I am also going to endeavour to be a lot more patient and polite when I reply on the forums!

    p/s: Apologies to anyone I’ve offended on the forums from before.

    p/s2: I think I’ve patched up this site for WordPress, but if you spot any omissions, please let me know!