On Saturday Matt posted to the WordPress Blog…

On Saturday, Matt posted to the WordPress Blog that the plugin directory has been refreshed.

Also also posted to our new P2 at make.wordpress.org/plugins: what this means for developers. @otto42, @coffee2code, and I go through the changes in detail. They include:

  • The new Developers and Support tabs for plugins
  • Subscribing to commit emails (Hint: see the Developers tab)
  • Following and managing support threads
  • How the new support statics are calculated

(Sidebar: We hope to use make.wordpress.org/plugins for announcements and resources for plugin developers. This blog will also move to make.wordpress.org soon. More to come.)

#plugin-directory, #plugins

The plugin directory’s licensing guidelines have been updated…

The plugin directory’s licensing guidelines have been updated. The guidelines will now allow code that is licensed under (or compatible with) version 3 of the GPL.

The guidelines still encourage use of “GPLv2 or later,” the same license as WordPress. However, we understand that many open source libraries use other licenses that are nonetheless compatible, such as GPLv2 only, GPLv3, and Apache 2.0.

Now may be a good time for plugin authors to review their plugins to ensure a license is specified. You can add License and License URI headers to readme.txt and the plugin’s headers. (You may also wish to include a copying permission statement.) For example:

License: GPLv2 or later
License URI: http://www.gnu.org/licenses/gpl-2.0.html

You can see this used in the sample readme.txt.

This change brings the guidelines in line with the themes directory, which has for some time accepted GPLv3-compatible code. (Probably a good time to note that Creative Commons licenses are still incompatible with the GPL, and the theme and plugin directories.)

#gpl, #plugin-directory

Been giving a lot of thought to how…

Been giving a lot of thought to how to give plugin authors more control over their plugin pages. In WordPress custom headers have been hugely beneficial in people’s ability to make a theme their own without having to be a designer. (And designers can make them really sing.)

As an experiment we’ve turned on custom headers for the plugin directory. If you’d like to try out this feature:

  1. Make a 772×250 pixel jpeg or png. (No animated GIFs. :))
  2. Check it in to your plugin’s SVN directory with the path assets/banner-772x250.(jpg|png). Note that the assets directory is added to your plugin’s root directory, not trunk.
  3. On the next plugin directory refresh (every 15 minutes or so) you should see your image start showing up on the page.

For an example of this in action, check out Hello Dolly, natch. Our goal is to mainly see how people use them, so if you try this out leave comment below with a link to your plugin!

Final note: this is just an experiment, and there is a 98.254% chance the dimensions, placement, and text overlay for this header will change in the future, or the idea might not work at all. But I think it’s a nice toe in the water for letting authors really make their plugin pages shine.


New and improved this morning, we have a…

New and improved this morning, we have a two-fer.

First, on the extend plugin directory, you may notice some new pie chart fun on the stats tab for each plugin. This shows a percentage breakdown of the versions being actively used by that plugin’s users. Only slices greater than 1.0% are shown.

Secondly, since data kept in a box is not very useful, there’s a new API for getting this data. Usage is fairly obvious from just a simple example, which gets the version breakdown of one of my own plugins:
The callback parameter is optional, of course, and provided for people who want JSONP usage.

Note that the version data is relatively new, so we don’t have it for all plugins at present. It will get better as reporting continues. For those interested, it’s saving the total counts of the version numbers as reported by the plugin update-checks over the last week. Since the data at present is only from one day, it’s not very accurate.

#api, #plugin-directory, #wporg

Most newer plugins in the plugins direct…

Most newer plugins in the plugins directory are not showing up in search results. We’re working on a solution, but it will probably be a few days before everything’s back to normal.

Lame, we know. Apologies for the hassle.


I upgraded the WP.org Plugins Directory …

I upgraded the WP.org Plugins Directory to bbPress trunk/ today. I’m sure there’s still glitches to work out. In particular, search may be a little out of date until I get the new sphinx index set up correctly.


Plugin Directory: Community

As one of two 3.org groups tasked with improving the WordPress.org Plugin Directory, the Plugin Directory: Community (PDC) group has read through all the Potential WordPress.org Improvements and has weighed what ideas would best improve the community and would be manageable to do before development on WordPress 3.1 starts. This group is tasked with improving the user interaction with the directory, the authors, and the rest of the community. Here are the ideas that have made it to the final round of the selection process:

  • A standardized taxonomy for organizing plugins and making tags more relevant.
  • Allow filtering of plugin search results based on version compatibility.
  • Allow the community to publicly ‘Like’ plugins.
  • Allow plugin pages to display hash-style URLs from the Read Me file.
  • UI Improvements for i8n support.
  • Allow users to publicly review plugins.
  • Small UI changes to the Plugin Directory
  • Plugin Adoption Stats
  • The formation of a Plugin Security Review Team.

PDC would like for each of you, members of the WordPress community, to look over these ideas and suggest ways of how they could be best implemented. We would like each of these ideas to be sustainable for the long term, meaning they would not create overwhelming work for people contributing to the community or have a negative impact on portions of the community.

To get the ball rolling with one of these ideas, the Plugin Security Review Team, we would like to suggest that responsibilities and obligations of this team be ramped up in stages. Instead of just throwing nearly 11,000 plugins at the team and having the them read every line of code, the team would pro-actively develop solutions that would aid developers in making their own plugin more secure. The Plugin Security Review Team could provide detailed tutorials, presentations, working examples, scanning programs, or any other ideas as they see fit.

The PDC group is open to ideas, suggestions, and help, feel free to contact any of our members: Peter Westwood, Austin Matzko, Dan Cole, Brian Layman, and Michael Torbert. Hopefully with the communities’ help and feedback we will be able to implement all of these ideas.

#3-org, #plugin-directory

Plugin authors can now change the “Reso…

Plugin authors can now change the “Resolved” status on support topics made about their plugins on .org.

Note: This only works when the topic is made from the plugins area, using the “Got something to say? Need help? Write a new topic.” link at the bottom of the plugins screen. Topics that are simply manually tagged with the name of the plugin won’t work.

Mods and higher can still change the resolved status on any topic, as always. So you may not be able to see this change easily. 🙂

#plugin-directory, #plugins, #resolved, #support

There was a bug in the process that gene…

There was a bug in the process that generated plugin screenshots in the WordPress.org Plugins Directory.

The bug has been fixed, and I’m currently running a brute force script to update all plugins. The script is not very efficient and will take a couple days to finish.


Plugins can now include videos in their readme.txt files

The plugins directory now supports videos in readme.txt files. YouTube, Vimeo, and WordPress.com VideoPress videos are supported.

Videos are included using one of two formats.

Shortcode: YouTube, Vimeo, WordPress.com VideoPress

Include a normal looking shortcode anywhere in the readme.txt file.

For YouTube and Vimeo, the shortcode has one unnamed parameter: the video’s URL.

[youtube http://www.youtube.com/watch?v=7EiKx_WSesk]
[vimeo http://vimeo.com/173714]

For WordPress.com VideoPress videos, the shortcode has one unnamed parameter: the video’s ID. The shortcode can be copied from the video’s embed menu.

[wpvideo OO4thna8]

To prevent shortcodes from being parsed, enclose the shortcode in backticks.

`[wpvideo OO4thna8]`

Autolink: YouTube, Vimeo

Include a YouTube or Vimeo URL by itself on its own line in the readme.txt file.




The Validator shows the videos too.

NB: Directly including object/embed HTML into the readme.txt file is not supported; the goal of the readme.txt file is to be human readable.

PS: Videos are not currently supported as replacements for screenshot images in the screenshots section. It’s silly that the Plugins Directory doesn’t yet support that 🙂 It’s on the todo.