Sunday, May 20, 2012

100 Million Plugin Downloads and Counting

WordPress 3.0 Thelonious passed 3 million downloads yesterday, and today the plugin directory followed suit with a milestone of its own: 100 million downloads.

The WordPress community’s growth over the years has been tremendous, and we want to reinvest in it. So we’re taking the next two months to concentrate on improving WordPress.org. A major part of that will be improving the infrastructure of the plugins directory. More than 10,000 plugins are in the directory, every one of them GPL compatible and free as in both beer and speech. Here’s what we have in mind:

We want to provide developers the tools they need to build the best possible plugins. We’re going to provide better integration with the forums so you can support your users. We’ll make more statistics available to you so you can analyze your user base, and over time we hope to make it easier for you to manage, build, and release localized plugins.

We want to improve how the core software works with your plugin and the plugin directory. We’re going to focus on ensuring seamless upgrades by making the best possible determinations about compatibility, and offer continual improvements to the plugin installer. And we also want to give you a better developer tool set like SVN notifications and improvements to the bug tracker.

We’re also going to experiment with other great ideas to help the community help plugin authors. We want it to be easy for you to offer comments to plugin authors and the community, including user reviews and better feedback. We may experiment with an adoption process for abandoned plugins as a way to revitalize hidden gems in the directory. I’m not sure there is a better way to show how extendable WordPress is and how awesome this community is at the same time.

As Matt said in the 3.0 release announcement, our goal isn’t to make everything perfect all at once. But we think incremental improvements can provide us with a great base for 3.1 and beyond, and for the tens of millions of users, and hundreds of millions of plugin downloads to come.

3.0 RC3

A weekend present, in haiku:

Last call; final bugs
Itch, scratch, contort; calmly wait
For now: RC3

That’s right. What will hopefully be the final release candidate, RC3, is now available for download and testing.

Plugin developers: test your plugins!

Expanding the Theme Review Experiment

When I was a kid my dad used to practice his typing skills (on a real typewriter no less) with the phrase:

Now is the time for all good men to come to the aid of their country.

For some reason that has stuck with me all these years. Today I’m going to rephrase and re-purpose that line:

Now is the time for great theme developers to come to the aid of their community.

The theme directory has been chugging along for more than a year now. During that time we’ve tinkered with the review process and some of the management tools, but haven’t really opened it up as much as we’d like. It’s time to rip off the band-aid and take some action; to that end, we’re looking for community members to help with the process of reviewing themes for the directory.

Right now this is a bit like a New Year’s resolution to exercise every day: it’s what we need to do, but we’re still figuring out exactly how it will all work. That’s part of the community involvement as well — we expect that those who pitch in will also help shape the process.

What’s involved in reviewing themes for the directory? There are some obvious things, such as being familiar with PHP and WordPress theme code (and the theme development checklist), with an eye for security issues. You would also need to have the ability to set up a separate install of the latest version of WordPress for testing theme submissions.

Hopefully a few talented theme developers are reading this right now and saying to themselves, “I’d love to help! How do I get started?” Just join the new theme reviewers mailing list and we’ll get you up to speed on this new opportunity to come to the aid of your community.

WordPress 3.0 Release Candidate

As Matt teased earlier, the first release candidate (RC1) for WordPress 3.0 is now available. What’s an RC? An RC comes after beta and before the final launch. It means we think we’ve got everything done: all features finished, all bugs squashed, and all potential issues addressed. But, then, with over 20 million people using WordPress with a wide variety of configurations and hosting setups, it’s entirely possible that we’ve missed something. So! For the brave of heart, please download the RC and test it out (but not on your live site unless you’re extra adventurous). Some things to know:

  • Custom menus are finished! Yay!
  • Multi-site is all set.
  • The look of the WordPress admin has been lightened up a little bit, so you can focus more on your content.
  • There are a ton of changes, so plugin authors, please test your plugins now, so that if there is a compatibility issue, we can figure it out before the final release.
  • Plugin and theme *users* are also encouraged to test things out. If you find problems, let your plugin/theme authors know so they can figure out the cause.
  • There are a couple of known issues.

If you are testing the RC and come across a bug, you can:

We hope you enjoy playing with the 3.0 RC as much as we’ve enjoyed making it for you. Enjoy!

Download WordPress 3.0 RC1

2010: A Theme Odyssey

After the video from the core team meetup was posted, the topic that seemed to get the most attention on Twitter and various community sites was Matt’s announcement that there would be a new default theme in 2010, so I thought I’d start with that as the first of the meetup summaries.

When Kubrick was bundled with core back in 2005, it was a cutting edge theme. Custom header, rounded corners, clean design… if you were using WordPress back then, let’s face it, you were impressed. Time moves on, though, fashions change, new styles become old standards, and what was once cutting edge suddenly seems old-fashioned and out of date.

So, a new bundled theme in 2010? We think it’s a good idea. Something nice and light that can serve as a good example theme, include newer theme-based features, and look nice (and current) on a public site. We’d like to introduce a new default theme with version 3.0, which is anticipated to come out in mid-2010 (hence the name), and think it would be good for it to blend well aesthetically with WordPress itself.

I’d been advocating moving toward Elastic, the theme framework/WYSIWYG theme editor that was one of our Google Summer of Code student projects, but after some discussion I agreed with the guys that while Elastic is awesome and should be promoted as a community development project, it’s heavier than a default theme needs to be. The default theme doesn’t need to be a full-featured framework, it just needs to work well, look awesome, have good code and be a good starting point for beginning themers. We were thinking of a fairly minimalist design that would make it easy to customize.

As for the code, there’s a question of if it will really be a new theme, or if it will be a re-styled and updated version of Kubrick.  We don’t know the final answer to that yet, because the ultimate decision will be made with the community’s input, but we believe all new markup is the way to go. What do you think? Without venturing into theme framework territory, are there features you think a new default theme should have? Some people have been talking about it on Trac over the past year, if you wonder what’s been tossed around so far. I thought about posting a poll here (you know how I love posting polls to gauge opinion), but in this case I think a discussion thread might be better, so that each vote can explain the reason behind it. So, have an opinion on what a new default theme should include? Weigh in at the forums.

2.9 Release Candidate 1

We’re at that exciting point in WordPress development where the dev team feels like version 2.9 is complete and ready for the world.

If you’ve been waiting for your moment to pitch in, it’s now. First we need tech savvy testers to upgrade their blogs and kick the tires, make sure everything is rolling like you expect it to. Here’s a list of all the fun and geeky new stuff in 2.9 to try out. Second, and more importantly, we need everyone to test out their plugin compatibility.

If you’re a user of plugins, there’s a groovy new compatibility feature on the plugin directory where you can vote on whether a plugin is compatible with a version or not and it’ll get registered in the new plugin compatibility checker. This is as a replacement to the old wiki-based lists we’d do before. To see it in action check out this Akismet plugin page, as you can see 14 people have already registered that it’s compatible with 2.9.

If you’re a plugin author, of course you should update your “Tested up to:” in the readme.txt for your plugin.

If all goes according to plan, WordPress 2.9 will be out before the end of the week. You can download the release candidate here.

For more details on the changes since Beta please review the revision log on Trac, and happy testing!

Core Team Meetup Results

To get started, here’s a short video from the meetup discussing some of the topics and 2.9. In the opening pan, you’ll see (L-R) Andrew Ozz, Mark Jaquith, Jane Wells, Peter Westwood, and Ryan Boren, followed by Matt Mullenweg as the first person talking. Tip: go full-screen in HD to feel like you were there.

Last week, I posted about the fact that Trac would be quiet for a few days while the core commit team met in person for the first time to talk about some goals for WordPress in the coming year. That prediction wound up being a little inaccurate, as having everyone together inspired a Trac sprint to get us closer to shipping 2.9. As of this morning there are only 11 tickets left against the 2.9 milestone. Yay! I’m sensing a Release Candidate in the near future.

I’d planned to write a summary post to encapsulate the discussions we had over our 3 day meetup, but to be honest, all-day (and night) every-day meetings creates a ton of things to summarize, and the post would be a novella. So instead of one long post, I’m going to split it up into a series and post a summary of the discussion on one or two topics per day until I’ve posted them all. Think of it like a WordPress advent calendar. For today’s post, enjoy the video above and I’ll list the topics we covered to give you an idea of what will be included in the upcoming summary posts.

Topics: Direction for the coming year(s), canonical plugins, social i18n for plugins, plugin salvage (like UDRP for abandoned plugins), WordPress/MU merge, default themes, CMS functionality (custom taxonomies, types, statuses, queries), cross-content taxonomy, media functions and UI, community “levels” based on activity, defining scope of releases, site menu management, communications within the community, lessons learned from past releases, mentorship programs, Trac issues, wordpress.org redesign, documentation, community code of conduct.

You can see why I didn’t want to try to cram it all into one post, right? :)

Just to make sure it’s clear in everyone’s minds, I want to reiterate that these discussions were just that: discussions. They were not secret meetings ending in hard and fast decisions. The idea was to 1) get the core commit team on the same page in order to improve workflow efficiency and communication, and 2) come out of the meetup with a long list of things we know we want to work on in the coming year, and from there to work with the broader community to determine priorities/strategies before starting the work of getting it all done. As I finish off 2009 by posting summaries of the meetup conversations, I hope you’ll all plan to start 2010 with enthusiastic participation in one or more of the projects that will take these conservations from concept to reality.

Canonical Plugins (Say What?)

There have been a lot of references to “canonical plugins” over the past year, especially at WordCamps by Matt, but we haven’t really posted anything official about the idea, nor have we really made much progress beyond discussions about how awesome it would be to have canonical plugins and how good it would be for the community. But what are canonical plugins, you ask? Well, that’s one of the many things the core commit team has been talking about over the past few days, and everyone agrees that we need to prioritize this aspect of the project sooner rather than later. So, here’s a super high-level description of how we’re currently thinking about canonical plugins, which we’d like to use to initiate some focused community discussion on the topic.

Canonical plugins would be plugins that are community developed (multiple developers, not just one person) and address the most popular functionality requests with superlative execution. These plugins would be GPL and live in the WordPress.org repo, and would be developed in close connection with WordPress core. There would be a very strong relationship between core and these plugins that ensured that a) the plugin code would be secure and the best possible example of coding standards, and b) that new versions of WordPress would be tested against these plugins prior to release to ensure compatibility. There would be a screen within the Plugins section of the WordPress admin to feature these canonical plugins as a kind of Editor’s Choice or Verified guarantee. These plugins would be a true extension of core WordPress in terms of compatibility, security and support.

In order to have a system like this, each canonical plugin’s development community would probably need similar infrastructure to WordPress itself, including things like Trac, mailing lists, support forums, etc. These things will be worked out within the development community over the coming months, but in the meantime, we really need a better name for this. Many people have no idea what canon/canonical means (clearly, they are not Dr. Who fans!), and having to define the word distracts from discussing the core ideas behind the concept. So, we thought we’d do a community poll to see what people think we should call canonical plugins. We brainstormed a few dozen ideas yesterday and whittled it down to our top handful. Based on the definition of canonical plugins given above, which of these terms do you think best describes them? I’m including a short description of our thoughts on each.

Standard - Implies that these are the standard by which all other plugins should be judged, as well as the idea of them being the default plugins.
Core - Makes the close relationship to core WordPress development very clear, and has the implication of bundled plugins (even though we don’t need to actually bundle them now that the installer is right in the admin tool).
Premium – Identifies these officially-supported plugins as best-in-class and of the highest value, and could potentially disambiguate the word Premium as it is currently being used in the community (to refer to anything from commercial support to licensing terms to actual code quality).
Validated - Focuses on the fact that the code is reviewed for compatibility with core and for security.
Official – Makes it plain that these are the plugins officially endorsed by the core team as being the best at their functions.
Canonical – Maybe once people get used to it, canonical wouldn’t confuse so many people?

Cast your vote in the poll below to have your opinion considered during the decision-making process. And if you can think of a word that we haven’t listed here that you think is better, please submit it in the poll! The poll will remain open until 11:59pm UTC Thursday, December 10, 2009.

Upcoming WordCamps

Every now and then I see someone ask in the dev channel how they can meet up with other local WordPress developers. We’re thinking about ways to make WordPress.org more of a resource to facilitate local connections, but in the meantime, I thought it might be helpful to publicize some upcoming WordCamps, the weekend conferences organized by local communities to talk about all things WordPress.

WordCamp New Zealand: Wellington, New Zealand, August 8-9, 2009

WordCamp Huntsville: Huntsville, Alabama, USA, August 15–16, 2009

WordCamp Los Angeles: Los Angeles, California, USA, September 12, 2009

WordCamp Philippines: Makati City, Philippines, September 19, 2009

WordCamp Portland: Portland, Oregon, USA, September 19-20, 2009 (Last year’s PDX WordCamp was awesome, IMO.)

WordCamp Seattle: Seattle, Washington, USA, September 26, 2009

WordCamp Birmingham: Birmingham, Alabama, USA, September 26-27, 2009

WordCamp Netherlands: Utrecht, Netherlands, October 31, 2009

WordCamp NYC: New York, New York, USA, November 14-15, 2009 (Logo contest in progress!)

WordCamp Mexico: Mexico City, Mexico, November 20, 2009

If any of these are within a reasonable distance to you, consider attending. WordCamps are a great way to meet other WordPress users, find collaborators, and expand your t-shirt collection*. I know I’ll be hitting at least a few of these; WordCamps are also a great way to get user feedback to take into consideration while we’re making decisions about what to include in core.

You can always find an up-to-date list of upcoming WordCamps at WordCamp Central. You can also try searching for WordPress groups at Meetup.com to find more regular monthly gatherings in your area.

*Most WordCamps include an event t-shirt in the registration fee.

The WordPress 2.0.x Legacy Branch is Deprecated

The WordPress team had initially committed to maintaining the WordPress 2.0.x legacy branch until 2010. Unfortunately, we bit off more than we could chew—the 2.0.x branch is now retired and deprecated, a few months shy of 2010.

Many of the security improvements to the new versions of WordPress in the last couple of years were complete reworks of how various systems were handled. Porting those changes to the 2.0.x branch would have been a monumental task and could have introduced instability or new bugs. We had to make hard decisions between stability and merging in the latest security enhancements. Additionally, far fewer people stayed on the 2.0.x branch than we anticipated. I take that as a testament to the new features in WordPress and perhaps even more the features offered by plugins, many of which don’t support older versions of WordPress!

I’m disappointed that we weren’t able to keep the branch maintained until 2010, but since one of the big reasons for that failure was the massive scope of our security improvements for the newer versions of WordPress, 2.0.x doesn’t die in vain!