I submitted our application to be a participating organization in the Google Code-in.

We need to compile the task list. I put in some high-level placeholders for now, but people should go ahead and add suggestions for tasks. Note that the final task list will be pruned down to those tasks that are approved by the core leads and that have appropriate people available to oversee them, to ensure a positive outcome for the students and that we’re not wasting anyone’s time. If you want to suggest a task, leave it in a comment here. Specify if you are also offering to mentor any student taking on that task, or if it’s just something you think should get done. As tasks are agreed upon and have mentors assigned to them, I’ll add them to the codex page.

Agenda for today’s dev chat:

• 3.1 status updates
• 3.1 schedule: we need to get to freeze now
• Dev chat schedule: proposal to move back to Wednesdays and a couple of hours earlier
• Google Code-In
• GSoC Mentor Summit review if jjj, aaroncampbell or boonebgorges are around

Dropped the Awaiting Review queue by about 150 tickets in the last two evenings. There’s another 450 there, and 290 in Awaiting Triage. You may recall that Awaiting Triage were 3.1 tickets prior to us rebooting that milestone. Ideally Triage should be emptied.

Hoping to reduce both significantly before beta goes out and we get flooded, so I’m going to aim to handle about 50 a night.

Feel free to jump in at any point.

Suggest agenda items for tomorrow’s dev chat.

Plugin activation hooks no longer fire for updates

Following up on @scribu‘s post with further rationale and the 31compat tag.

The many problems. When plugin upgrades were introduced in 2.8, the activation hook fired for them. The deactivation hook did not. This was inconsistency number one.

When bulk plugin upgrades were introduced on the Tools > Updates screen in 2.9, the activation hook did not fire (during the bulk upgrade). This was inconsistency number two.

Bulk plugin upgrades were given greater prominence in 3.0, with the Updates move to under Dashboard, and a new bulk action on the plugins screen. This made the second inconsistency far more prominent.

Additionally, activation hooks could always fire on activation, because that has to be done through the admin, but updates don’t. Updates done manually (including SVN) was just one more instance where we may not have been firing updates. This was inconsistency number three.

We felt that the proper fix was to prevent the activation hook from firing on any upgrades, bulk or not, as this was not intuitive. Sorry if your plugin relied on this undocumented behavior.

The theory behind the right way to do this. The proper way to handle an upgrade path is to only run an upgrade procedure when you need to. Ideally, you would store a “version” in your plugin’s database option, and then a version in the code. If they do not match, you would fire your upgrade procedure, and then set the database option to equal the version in the code. This is how many plugins handle upgrades, and this is how core works as well.

The right way to do this. I would do what many other plugins do and do the upgrade procedure as I described, and as Peter and Andy described in the previous post.

Further reading. You can read more about this issue, on ticket #14915.

Plugin activation hooks

Attention all plugin authors:

If you were using register_activation_hook() to also handle updates from older versions of your plugins, you will not be able to do so any more in WP 3.1: [16012]

The activation hook is now fired only when the user activates the plugin and not when an automatic plugin update occurs. This is consistent with how the deactivation hook works.

There is a proposal for a register_update_hook() instead: #14912

Also, the callbacks for de/activation can now accept a network activation flag:

http://core.trac.wordpress.org/ticket/14170#comment:30

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:

http://api.wordpress.org/stats/plugin/1.0/simple-facebook-connect?callback=demo

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.

The codex now recognizes the single-sign-on wp.org cookies and signs you in with them.

Note that MediaWiki has its own cookies too, so logout doesn’t quite work right. I’ll work on that soon.

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.

Feature status:

• Post Formats landed. Discussing whether to do a core UI in 3.1 that themes can optionally enable.
• Theme Search/Filter is still sitting in rough first draft. Someone volunteered to finish it in the dev chat, but I forget who.
• Internal linking. Daryl has a patch that will go in soon.
• Admin Bar. The first round is in and filosofo is working on a cleanup.
• Ajaxified Admin. Been in for awhile with scribu addressing bugs as they come up.
• Update TinyMCE. azaozz updated to the latest.
• Multi-Taxonomy Queries. First rounds are in and scribu is handling bugs.
• Custom Post Type Index Pages. Nacin landed the first round.
• Cleanup Admin CSS. JohnONolan is working on a first pass.
• QuickPress Function. First round is in.
• User Admin. First round is in along with removal of dashboard_blog.
• Network Admin. Continued bug fixing. Considering moving theme/plugin/core updates to network admin for multisite installs.