Roy Schestowitz wrote:
Pardon my skepticism, but people rarely comply with the accepted
structure (blame sloppiness and/or misunderstandings). Free-form text is
a route to problems, confusion and---consequently---support burden. One
alternative would be to validate or autogenerate a file using, for
example, a Web-based form on WordPress.org.
RedAlt has been parsing these text files forever, and they look pretty
reasonable to me. (I'm not sure what's the intention with the mentioned
markdown requirement though, since the rest of the site uses wiki syntax.)
The plugins listing there also provides the details for plugins directly
from their header info, including Google-Juice-infused direct links to
both the plugin site and the author site.
It makes every tagged version (including the trunk) available for
download, and warns you when you try to get trunk (in-development) from
a version that has published version tags.
It will display the readme version from the tag that you select, so if
there have been documented changes, you can know it.
It will display plugin details for every plugin that's in the file, so
if a project contains more than one plugin file, it shows them all.
You can see at a glance which authors bothered to include readme files,
and which authors bother to tag their versions.
Like the page posted earlier with zip downloads, the RedAlt listing
provides zip downloads of every trunk and tag for every plugin in the
As of a few minutes ago, it supports substring multi-word searching
within all readme files, headers, author names, plugin names, and urls.
It's possible that the moment that a new readme format is used, plugins
that use those details will have them appear in the RedAlt listings.
It's also possible that there's a REST interface for the directory
You can find the RedAlt plugin mirror here:
wp-hackers mailing list