WordPress Plugin SVN Tip: How to Resolve the ‘Last Updated’ Issue

One of the recurring issues that seems to pop up for WordPress plugin developers as of late is the “Last Updated” problem. For those of you that don’t release your plugins on the WordPress plugin repository or haven’t noticed when downloading a plugin, there is a bit of information right below the download button called “Last Updated.”

Essentially, this date is an indicator of the last time a version of the plugin was released. A big issue for a lot of developers lately is when releasing a new version of their plugin, this date will not update and continue to use the previous version’s date.

Now, this isn’t really a huge deal because users who have a plugin installed will be notified when there is a new version through their site’s admin panel. However, what most plugin authors want, though, is to be listed in the Recently Updated section on WordPress.org. This equals exposure, which equals downloads and more active users.

To solve this problem is pretty simple, but something that isn’t clear because of the lack of communication from whomever controls the Plugin Repository.

With each plugin SVN, you should have three folders: branches, tags, and trunk. Typically, when uploading a new version of your plugin you will place everything into the trunk folder. In addition, you will also copy these files into a new folder under tags with the appropriate version number. The problem lies in how you actually commit your updates.

The Wrong Way

1. Update your plugin and commit the changes to trunk
2. Copy these files into a new folder under tags and commit

The reason this is wrong is because the “Last Updated” date reflects whatever is in the tags folder. If the new version’s tags folder does not exist when you update your trunk, it will not be able to find the most recent date. I can’t be sure on this part and it’s only a guess, but I think committing your tags folder at this point causes a bug in the SVN to never look for it.

The Right Way

1. Update your plugin in the trunk folder
2. Copy these files into a new folder under tags
3. Commit ALL changes (trunk and tags) at once

This kind of commit should indicate to the SVN that there is a new version.  From here, it will build the download, update the information (including the Last Updated date), and populate the Recently Updated section.

If there’s some SVN guru out there that can explain to me why it needs to happen this way, please do. All I know is that this needs to be the process a plugin developer must take if they want their work to be hosted on the Plugin Directory.

UPDATE: Otto officially responds on WordPress StackExchange with an answer.  Basically, there is a problem and he’s been trying to fix it.

Restrict Categories – My Experience Writing a WordPress Plugin

Two months ago today I released my first WordPress plugin, Restrict Categories, and in that short time it has already reached over 1,000 downloads.  I thought this milestone was a good chance to write about my experiences developing a plugin.

Background

A couple of months ago, I was doing some research for a project here at Web Communications and it needed to have a particular functionality within WordPress.  We needed to control which categories certain users would be able to edit and post.  At first, I had hope this was possible because I discovered several plugins that appeared to accomplish what I wanted.  However, I quickly realized that none of them worked or didn’t really do what I wanted them to do.  My options were slim: 1) fix one of the broken plugins or, 2) write my own.  After trying to fix a couple of the plugins that had promise, but failing to do so, I started the process of developing my own.

Where to start?

The first place I looked was the WordPress Codex and leaned on it heavily in the early goings.  Specifically, I looked at the Plugin Development pages.  The pages I relied on the most were Writing a Plugin, Adding Administration Menus, Creating Options Pages, and the always helpful Function Reference.

I also think it’s beneficial to check out WordPress Coding Standards, Inline Documentation, Internationalization, and Data Validation.

Initial Development

In very basic terms, this is what I needed my plugin to do:

• Display a list of all user roles (Administrator, Editor, Author, etc)
• Display a list of all categories next to each role
• Allow the plugin user some way to select categories and assign them to that author
• On the Posts screen, display only those posts with categories from those selected above

Tackling development on this went in pieces.

1. Create the basics of what I need to get my settings page to show up in the WordPress menu
2. Get a list of user roles
3. Get a list of all categories
4. Combine all of these things on my plugin page and have a process that saves the information to the database
5. Use that information to filter the Posts screen for restricted user roles

Some of these steps were easier than others and there were many days where I tried one thing, thinking it was the solution, only to be deterred and abandon it for a different route.  But, after a week and a half of trial and error, I finally had a working plugin.

Getting my plugin in the WordPress Plugin Directory

If you’ve ever wondered how people get their plugin on the WordPress.org site, you first start with the Plugin Developer Center.  I signed up and then began my learning process with SVN (Subversion).  Having never used SVN before, I was a bit unfamiliar with where to start or what program to use!  If you are on a Mac, your best bet is to use Terminal.  There are some graphical interfaces that are supposed to make it easier, but I then found it hard to follow the SVN directions from the WordPress documentation.

Anyway, once I figured that out, my plugin was soon live and being displayed in the “Newest Plugins” section.  Very cool.

Improvements

In many ways, Version 1.o had many of the pitfalls that most newbie WordPress plugin developers fall victim to.  In fact, I’m pretty sure I was committing a couple of these Top 10 mistakes.  I was also getting some users with errors.  So, I began troubleshooting my code as well as looking into how to make my plugin better.

For the first couple of revisions, the updates were mainly bug fixes.  Then, I decided to test it in the alpha version of WordPress 3.1.  One of the changes they made to the Posts screen inadvertently would allow a restricted user to bypass all restriction and they could get to a post they weren’t allowed to view.  What was even worse was that I couldn’t figure out how to fix my code to make it work with new Posts screen.  Uh oh.

So, I reached out to the WordPress community asking for a solution.  I asked a question on the wp-hackers mailing list and, when I couldn’t get a workable solution there, headed towards the WordPress Stack Exchange.  Luckily, someone responded with an answer.

I was resistant to the “solution” presented to me at first because I felt I was so close to the answer and was getting the run-around.  What I was really doing was not wanting to do the work to change my code.  However, once I actually took the time to work this solution into my code, I realized it was better.  This wasn’t the last time that asking a question in the community led me to a better solution.

It took two months and 1,000+ downloads to make me a better WordPress developer and a better PHP coder.