WordPress 3.1 uses jQuery 1.4.4, and jQu…

WordPress 3.1 uses jQuery 1.4.4, and jQuery UI 1.8.6. You should check your plugins to see if anything broke. If you were enqueueing jquery-ui-core and using the “widget factory,” or something that depends on the widget factory you will have to update your plugin to enqueue jquery-ui-widget instead. In jQuery UI 1.8.x, the widget factory was separated from jQuery UI core. Please examine wp-includes/script-loader.php to see the entire dependency tree.

#3-1, #dev-notes

Changes to meta capability handling in 3.1

If you were doing something crazy with custom or meta capabilities and custom post types in 3.0, you’ll probably want to read #14122.

Custom post types had inconsistent meta capability handling in 3.0. current_user_can( ‘edit_post’, $id ) and current_user_can( $post_type->cap->edit_post, $id ) mapped to different capabilities when capability_type = post. We never called the former in core, however, so this would have only affected plugins in a very particular situation.

Now, we have the map_meta_cap flag for CPTs, which allows this to be throttled properly. map_meta_cap is also true by default if capability_type = post or page, and no custom capabilities were defined.

Making this post out of due diligence, but I don’t think this should break any plugins, except in the “This was never supposed to work” situation (which I do want to know about).

#3-1, #dev-notes

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.

#3-1, #dev-notes

Feature status: * Post Formats landed. D…

Feature status:

#3-1

There was some ancient code in WP::parse…

There was some ancient code in WP::parse_request() that looked in $GLOBALS when setting up query vars.

This is no longer the case: [15796]

#3-1, #dev-notes

WP_User_Search has been replaced by WP_U…

WP_User_Search has been replaced by WP_User_Query. WP_User_Search exists, but is deprecated and has been moved to wp-admin/includes/user.php to deprecated.php.

If you were for some reason including wp-admin/includes/user.php and were expecting WP_User_Search, you’ll need to adjust.

#3-1, #dev-notes

The theme mod functions now store their …

The theme mod functions now store their values differently. This has the potential to break plugins that were directly querying these options instead of utilizing the API.

If you are using the API, i.e. get_theme_mod(), set_theme_mod(), remove_theme_mod(), remove_theme_mods(), then you’re fine.

Reference: https://core.trac.wordpress.org/changeset/15736.

#3-1, #dev-notes

wp-db.php is now always included. Databa…

wp-db.php is now always included. Database drop-ins should continue to work without any adjustment in most cases (or can be adjusted to work with small tweaks).

This is for performance as we are no longer conditionally including a file. It also allows db.php files to cleanly extend wpdb, which previously required a bit of tinkering.

See https://core.trac.wordpress.org/ticket/14508.

#3-1, #dev-notes

At this week’s dev chat, we’ll start t…

At this week’s dev chat, we’ll start talking about scope for 3.1. We won’t decide things until the following week, but if there’s a feature you think should be in 3.1, suggest it in a comment here, and we’ll discuss as many as we can get through on Thursday.

[Edit: Comments closed as of the start of the 3.1 scope meeting, for organizational purposes.]

#3-1, #agenda

Don’t use the conditional query tags (i…

Don’t use the conditional query tags (is_page, is_post(), is_*) prior to init. In 3.0 and earlier, this merely failed quietly. In 3.1 this will produce a fatal error. We’ll workaround the fatal error prior to the release of 3.1, but in the meantime we’ll leave it to serve as a flag for improper use of the query conditionals. If you see a fatal error of the form “Call to a member function is_*() on a non-object” then a plugin or theme is using that function prior to init. See ticket 14729.

#3-1, #dev-notes