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
- Update your plugin and commit the changes to trunk
- 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
- Update your plugin in the trunk folder
- Copy these files into a new folder under tags
- 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.
Hmm, I was hoping you had a solution for me. I’m having the same issue you describe, where the “Last updated” isn’t being updated. However, every single time I’ve updated the plugin (which is literally 25 times) I’ve done it the “right way” as described above. As in, I always update the TRUNK, then add a new folder for the new version under TAGS and then commit to SVN. It seems to be that 1 out 5 updates will actually update the Last Updated time stamp. Also, my readme.txt file only gets parsed every few uploads. All of this is really starting to piss me off. Any other ideas or thoughts?
It could be the SVN program you are using, if any, or a hidden file in the directory created by your coding program. I’ve found the best results when following the steps above and not having the files open in my editor when committing.
The entire development of this plugin I have been using Tortoise SVN for committing to the repository and have used NetBeans PHP IDE as the code editor. In the last week I’ve released 4 updates using the “right way” as described, and yet my last updated date is still stuck at: 2011-2-1
As you’ve mentioned, my frustration for this not working is that:
1) even though I keep updating my software, I never get on the Recently Updated list, which is a great way to get new users.
2) when new users are considering downloading my plugin, they are going to look at the last updated date, and think that I haven’t released an update in months and therefore assume that the plugin is not actively maintained.
And in the end, it just pisses me off to no end that my hard years of working on this plugin are being tempered by what I am beginning to think is a problem with the WordPress SVN repository. Thanks for the help, hopefully this can get resolved for all us plugin authors that rely on their plugins to feed their families
You could always send an email to plugins@wordpress.org an see if they can resolve it for you, but it’s iffy on whether you’ll hear from them or not.
Well I definitely would not call myself an SVN guru, but i am consistently getting the plugin last updated update date to work for me every time.
I’m using Tortoise.
After I am done with all my new updates to my plugin I do a commit.
Next I Tag my new version from the Trunk (very important! – must be the Trunk folder or you’re in for a time consuming cleanup / fix job).
svn.wp-plugins.org/your-plugin-name/tags/your-plugin-verions (1.0 or whatever the version number really is)
Choose Head Revision
Click OK – by clicking ok this is another commit.
You will get a copy finished message if all goes well. “your working copy….”
Then you want to do a Tortoise Update. This will download the working server copies of your newly tagged plugin version files to your local plugin folders on your computer. It creates the new tagged version folder and downloads all the new plugin version files from the server to that new tagged version folder.
Now in the last 2 version releases of my plugin the Last Updated date did not update so i did this.
I just added 1 asterisk to the end of the == Changelog == section for = .46.1 = and = .46.2 = of my readme.txt file for the new tagged version ONLY and did another commit. The Last Updated Date updated almost instantly.
For the record,
mine was not updating, despite having some tagged versions. It used to update. I’ve used the same readme.txt for ages, when it used to update – it was ansi not utft8, so changed that.
Also I tagged the new version from the trunk AFTER i had committed the new. (I used to only tag the previous version and always have trunk as the latest version, but then it had not updated the last date from last couple of versions, although it had the version number.)
I mistakenly did one without taggingthe previous version and it did NOT update the version number then.
SO after readme as utf8 and tagging the latest version, It then updated fairly quickly.