I released the first version of my Rewrite analyzer plugin with a commit on 2010-05-12. The WordPress.org plugin directory however still displays 2010-11-27 as the "Last Updated" date - this is the date when the plugin directory was created in the repository.

The Developer FAQ states:

Last updated time
Time of last check in to the appropriate directory (trunk/ or the stable tag directory) after a version number change.

Most developers commit their first version right after their plugin directory gets created, so you won't notice the difference. But I have seen the same discrepancy in other plugins that were committed more than one day after the directory was created.

I committed both the trunk/ and tags/1.0/ directories in one go (with a local copy and then a commit), but the other plugin with this problem did it like most people do: a commit of trunk/ and then a remote copy to tags/1.0/.

Otto recently said:

The only time the readme gets parsed and the entry gets rebuilt is when the version of the plugin changes. However, for people using tags, this generally happens after they make the new tag and update the Stable Tag.

The readme file got parsed, so I don't know what else I could have done to make it update correctly?

  • This is becoming a very common problem and I have not been able to consistently reproduce exactly why it will sometimes update and sometimes not. I don't really have an answer for you other than it might be something buggy with the WordPress plugin SVN. I'd be interested to hear an official answer. May 25, 2011 at 14:38
  • Did you try encoding your readme.txt file as UTF-8?
    – Bainternet
    May 25, 2011 at 14:55
  • @Bainternet: They contain no special characters, so you could say they are UTF-8 (tested by comparing the MD5 of the "standard" file, the converted-to-Latin-1 version, and converted-to-UTF-8 version: all equal). They do not contain a BOM character at the start, but I assume this is optional?
    – Jan Fabry
    May 25, 2011 at 15:06
  • I'm not sure if its optional but when i had the same problem, saving my readme.txt (also with no special characters) in UTF-8 format fixed it 15 minutes later.
    – Bainternet
    May 25, 2011 at 15:12
  • @Bainternet: Maybe there it was just the extra commit that triggered the update? WP.org detected a new readme.txt and thus parsed the file again and thus updated the timestamp?
    – Jan Fabry
    May 25, 2011 at 15:31

3 Answers 3


I've been trying to work out the issue for months now, and have made several adjustments to try to solve the problem.

In short: Yes, we know there's a problem. No, I don't know how to fix it yet. You can stop reporting it already.

Current workaround: ANY commit of any kind should trigger it to update. So simply adding a space to the readme.txt and waiting 30 minutes should do the trick. If it doesn't, then contact me: [email protected]

  • Description: I've updated both trunk and current tag readme files and they don't show up the updated text in the plugin's page. 1): Does readme.txt only gets parsed one version at a time? Any cache at wp.org side nowadays? 2) Best venue to ask about this? Your email, plugins at wp org, wp-hackers, forum, twitter?
    – brasofilo
    Jul 3, 2013 at 22:18

Based on the comment discussion in the question, I believe we have an answer to this.

Saving the readme.txt file with Unicode-8 (UTF-8) encoding seems to correct the 'Last Updated' problem.


For the record, it seems one should also always make a tag copy of the latest version too to ensure that both last updated date and version number get updated.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.