Media tags plugin

Note: This post remains available to discuss the original 1.0 version of the Media Tags plugin. As of July 15 2009 version 2.0 of the Media Tags plugins has been released. Please refer to the update post for information on changes to the use of the plugin.

Working on a client project recently I needed to extract 2 attachments uploaded from a post and display these along with the post title into the sidebar on another page. I’ve done this a few times before and always sad to say a little different. Probably the best solution is to name the ‘special’ attachments using some defined naming convention like image_sidebar_1.jpg, image_sidebar_2.jpg, image_sidebar_x.jpg. This works but can get ugly if you even want the client to follow your instructions on the naming conventions.

I’ve figured out a better way. With my latest plugin you can now add tags to your media attachments. I write ‘media’ because this does not just apply to images. You can tag Word document, PDF documents basically anything you upload via the standard WordPress Media upload tool.

Here are some screenshots:

The media tag input field is displayed directly on the media form.


So now you can tag you media files. But how do you actually use the tags? How to you actually access attachments that have ‘x’ tag? Excellent question. And your answer is below.

As part of the plugin I also wrote a function to be used in your template. To follow the example I started this article with I need to display 2 of the 5 uploaded images in the sidebar. My first step was to upload the images and tag the two special images with ‘sidebar’.

Now I use the function get_media_by_tag(). I pass the tag I want to access, in this case ‘sidebar’ and the ID of the post parent. What is returned is an array of attachment items. This array is similar in fact to the return object when calling the WordPress get_posts which is partly what the function does.

Download the Media-Tags plugin via the plugin repository

Future plans

I’ve already starting thinking of some enhancements for the plugin. Which include a tag management screen and other utility functions. If you have any other needs post them here in the comments.

Revisions WordPress plugin update 1.8

I’ve just released an update to my Revisions plugin released just a few short weeks ago, Revisions. The update to the plugins are in areas both architectural and UI based.

Architectural Improvements

On the architectural side one big improvement was made in the way the plugin created new Revisions of content. In the old version of the plugin a revision was made too late on the post update process after the user clicked the Save/Publish buttons. Effectively the updated post content and the latest revision were the same. In the newer version of the plugin the revision is generated earlier in the WP core processing. This mean we can take a copy of the post content before it is updated by WP core. This means the latest revision is the real previous version of the content.

UI Improvements

For the UI changes there are quite a few.

  1. Above the revision listing I added two new checkboxes, Minor Edit and a Revisions Status. The Minor Edit checkbox is a single-use option to tell the plugin NOT to generate a new revision when you save the post item. This functions like most wikis. The Revisions Status allow you to totally disable revision generation for the post. This is handy if you just don’t want to use revisions on certain post items. Or if you are like me trying to make some complex edits and just want to disable new revisions because you will be making a dozen or so minor edits. So you can turn it off make you changes then turn it back on.
  2. I’ve added logic to limit the display of revisions to the last 5 items. Below the list of revisions is a link. When you click this link the page will slide to reveal the older revisions.
  3. Added checkboxes at each revision to allow deletions. This is pretty handy is you just want to clean house. Not that if you delete revision 5 of 8 the numbering will NOT re sequence itself. But if you delete the latest revision then the revision number will be reused.
  4. On WP 2.5 and higher I added the Minor Edit and Revision Status checkboxes to the sidebar. This will make it easier to set the checkboxes to keep from scrolling to the bottom of the editor form. And with some jQuery magic when the sidebar checkboxes are set the lower checkboxes are also set.

Future Changes

I still have a long list of changes I’m reviewing for possible inclusionin future releases.

  1. One change was submitted that included actual changes to plugin to support versioning categories and tags. This was great. But I’m still holding on the change. In my view categories and tags are not as volatile as text content. Beside if a revision used a category that had since been deleted what should the action be?
  2. How to handle delete of the main post/page. Currently the plugin will delete all revisions when the parent post/page is deleted. I don’t like this. I want to build an interface to allow recreation of a post from a revision.

I also have some other small items on the list but they are not work mentioning. If you have any other suggestions please feel free to send them my way.


You can download version 1.8 of the Revisions plugin from the plugin repository.

SimplyExclude Plugin for WordPress

I’ve moved all information regarding the the Simply Exclude plugin to a different page. Feel free to leave a comment there.

Versioning your Blog content

Have you ever made an edit to some Post, saved the results then sometime later wished you had an undo option? Or worse have you setup a site for a client and they ‘accidentally’ wack one of the Pages? Then they call you to ‘fix it’. Well I have some good news for you…

Introducing a new plugin, Revisions


The Revisions plugin is based on a very old plugin, Bliki (Blog + Wiki), written by the fine folks at Automattic. There are a few other good versioning plugins out there. But in my opinion they all offer too many admin bells and whistles like Version Diff-ing, Funky rollback schemes, Complicated admin interfaces, etc.

Sticking with my ‘Simple’ philosophy, I’ve opted to cut the functionality to the necessities. The Revisions plugin provides the user with three specific types of integrated functionality.

  1. The ability to create a backup of the edited Post/Page. This is built-in once the plugin is activated.
  2. The ability to view a Revision just as you would preview a Post in the Theme.
  3. The ability to reset or rollback a version into the admin editor

Below is a screen capture of the Revision section that is added to the Admin editor screens. This is a screen of 2.5 but looks just the same under pre-2.5 versions of WordPress.

Revisions plugin admin interface

From the screen image you can see there are 3 Revisions to this one Post. Each Revision notes the version number, the time of the Revision and by what author. Below each Revision items is a link ‘View Revision’. This will display a themed version of Revision. There is also a second link that will load the Revision content into the Post/Page editor. Once reloaded the author can Save or make changes to the content. This reload and save will generate a new Revision. In other words the original Revision will remain intact.


Download the Revisions plugin. Unzip it. Upload the ‘Revisions’ folder to the plugins folder of your WordPress site. Once uploaded go to Manage -> Plugins and activate the plugin. That is it. Now when you make a change to any Post or Page the version is saved. A suggestion is to perform a Save on an existing Post or Page first before starting to make changes. I’ve tested this plugin on WordPress 2.5 down to 2.0.3.

Future Plans

As I mentioned this plugin is basic on purpose. One feature I might be adding in the near future is the ability to delete individual Revisions. Sometime while you are in the Edit & Save cycle you can build up a few unnecessary Revisions. Another possible option will be to define a threshold for comparing the new version to the next previous Revision. If the amount change is below the threshold the Revision is not saved. This would prevent some very minor Revisions.


Check WordPress Core Files for Hacks

Over the last 2 years I’ve worked on literally dozens of client WordPress projects. Many of these projects have been the simple cut the theme and go. Wham-Bam Thank You, Pay me, projects. The rest have been like normal projects. Tons of code written, different developers between phases of the site, custom plugins, themes from hell with very dynamic functionality. I hate to admit but in my early days exposed to WordPress, I found it easier to make mode direct to the core files before writing a plugin to extend the core functionality. This of course creates a problem because I don’t always remember what changes I’ve.

In more recent projects I’m been hired to make changes to an existing client WordPress site. Many of these project involve upgrading WordPress from some version 2 years ago to the most current. Not knowing the previous developer’s changes this has always been a concern of mine since a flat upgrade would mean potentially killing custom changes to some of the core files. So going in I will normally zip the entire tree of files. And pull a dump of the database just to be safe. Then perform the upgrade and do some visual and functional checks on the site to see if I can find things before the client sees the site.

At best this process is haphazard. Without doing a full diff on each and every file it would be near impossible to find file differences. Until now.

Announcing a new plugin Hash Checker

This plugin will help you determine changed file in your WordPress core before you upgrade.


Download the plugin from the link above. Unzip this into the plugin directory. This should create a folder named ‘hashchecker’. Open your browser to your WordPress Admin interface. Go to the Plugins page and activate.

Checking your site

To check your WordPress installation, find ‘Hash Checker’ on your Options menu. The plugin will automatically determine your current WordPress version and start comparing files. In this version there are two types of errors reported.

  • Errors reported because the hash values do not match.
  • Errors because the code file from the hash config are not found on your site

Customizing the Hash config files

Let’s say for example you like to secure your WordPress installation by removing the wp-admin/upgrade.php file or some other file. And you don’t want to see this error all the time when running the check.

Simple enough. Under the plugin install directory is a sub-folder ‘wp_version_cfg’. This folder contains a cfg file for many of the latest WordPress version. Each config file is a full set of files distributed for that release. To get the error off the screen simply edit the config file, find the line for the file and remove it.

Want to add files to the config? Well this can be done but it’s all manual at this point. The config file format is your basic format

Filename=hash value.

The filename is the path relative to where WordPress is installed. This is not your site root in all cases. The hash is a simple md5 hash of the file. The filename part is pretty easy. But how do you generate an md5 for a file? If you are lucky enough to run OS X or Linus you can easily do this from the command line:


The returned alphanumeric value returned is the md5 hash. This goes on the right of the equal sign in the config.

Testing and Problems

I’ve tested this plugin under versions 2.3.3, 2.2.2 and 2.1. I’ve not been able to test this fully under all WordPress version. so please if you run into problems please give me a note using the comment form below. Will be glad to on this with you.

Also, this plugin assumes you are using the core WordPress files as downloaded from If you are running some SVN version or some ISP’s one-click custom installed version this plugin may not work. My apologies.

Future Plans

I’ve already started thinking about other options to put into the next release. Some of these are:

  • Adding the output to the Dashboard
  • Having the checker run on a cron at selectable intervals and emailing the admin on erros
  • Adding the ability to generate hash for non-core file via an interface.

If you think of anything please tell me below.