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.
Tagged: 31compat Toggle Comment Threads | Keyboard Shortcuts
-
Mark Jaquith
-
Andrew Nacin
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).
-
Andrew Nacin
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.
-
Michael Torbert
-
Ryan Boren
Which would not run for manually upgraded plugins. Hooks for upgrades is a non-starter. Plugins have to do it.
-
Michael Torbert
I would guess that most plugins are automatically upgraded, making this a simple solution.
-
Ryan Boren
Many people use git or svn, and relying on a hook is not multisite compatible.
-
-
-
Stephen Cronin
Thanks for explaining that Nacin.
I’m currently misusing the activation hook – my activation function includes all the update logic I need. I’m aware it doesn’t work for FTP updates, so my update instructions tell people to deactivate and then reactivate the plugin. Of course, that won’t work for SVN updates, which I hadn’t considered (although with due respect to Ryan, I’d argue that not many *average users* would update via SVN).
If the logic needs to be handled via the plugins, that’s fine, I’ll update mine. In fac,t I used to handle it in the plugin but removed it because I figured that running something just on activation would be more efficient that checking the version number on every single page load. For one plugin, not much of a drama, but when you start having 30 plugins all checking their version number on every page load of the site… But if that’s what we have to do, then that’s what we have to do.
-
Andy Skelton
It’s not inefficient for every plugin to store a small amount of data in the options table. They will all be automatically loaded with a single query. The overhead added by a single, small row is small enough to ignore.
-
Peter Westwood
Agreed.
Also – you should try really hard to ensure your plugin still works even with the old settings until the upgrade had happened unless it can be done without user interaction.
In most cases if you need user interaction you can trigger an admin_notice on the next page load after the update.
If you have a update that takes a while consider using a wp-cron “job” to do the migration work. -
Stephen Cronin
Thanks for pointing that Andy.
I was assuming a separate DB call for each plugin’s options entry. I knew the core options were bundled into a single DB call, but was under the impression (from heresay, not anything resembling facts) that non core options weren’t included and needed a separate DB call.
And Peter, yes, you’re right of course, the plugin shouldn’t rely on something existing that may not be there. I code properly *most* of the time, but I guess I’ve leant on the activation hook crutch occasionally. I think I need to spend some time with my plugins and make sure I’m not making the problem I’m complaining about
-
Peter Westwood
@Stephen: As long as you ask for your option to be autoloaded when registered it comes in one query with the rest of the autoloads
-
demetris
Just a note regarding autoloading of options:
By default, autoload is set to yes for all options added via add_option. So, other than adding your option, there is nothing you need to specify if you want it to be autoloaded.
More here: http://codex.wordpress.org/Function_Reference/add_option
-
-
-
Jarkko Laine
Hi, just a quick note to point out that this documentation page is still giving wrong instructions for plugin developers: http://codex.wordpress.org/Creating_Tables_with_Plugins
Cheers,
Jarkko -
Clint
I am VERY late to this party, but when I manually de-activate a plugin, and then reactivate it again manually, won’t fire the “acivation hook”? Seems a little stupid. Also makes testing my plugin a huge pain.
-
Andrew Nacin
Even later to reply to you — If you manually de-activate and manually reactivate, yes, it fires the activation (and deactivation) hooks. This was only for core’s one-click updates — when we update a plugin, we do not fire an activation hook.
-
-
-
scribu
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]
-
miqrogroove
Get a security analyst to check that out ASAP. $GLOBALS[$wpvar] is a variable variable syntax. If that query_vars filter wasn’t hooked by something extremely conservative, anyone would be able to hijack WordPress just by setting $wpvar in a query.
-
Alex M.
Note how the color is red. The code was removed.
-
miqrogroove
Note how WordPress is used on millions of websites that do not have this changeset.
-
Alex M.
Note the usage of
wp_unregister_GLOBALS()at the beginning of every page load and how most hosts have the register globals setting disabled.
-
miqrogroove
unregister_globals has nothing to do with this. Variable variable syntax in PHP gives direct access to everything in memory.
-
-
-
miqrogroove
I see it was used only on the right side of the assignment and not on the left, so that does limit the attack surface to the query_vars array.
-
-
Andrew Nacin
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.
-
Peter Westwood
Can we not make WP_User_Search a wrapper of WP_User_Query and preserve backwards compatibility?
-
Andrew Nacin
I haven’t looked at it or asked scribu yet. Currently it does preserve back compat as it was revived into deprecated.php, but it’d be nice for it to utilize the new class.
-
-
-
Andrew Nacin
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: http://core.trac.wordpress.org/changeset/15736.
-
Mike Schinkel
Good change!
-
-
Andrew Nacin
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.
-
Aaron Brazell
So, essentially, a db.php class extends and instantiates itself?
class WP_Postgres extends wpdb { // foo } $wpdb = new WP_Postgres( DB_USER, DB_PASSWORD, DB_NAME, DB_HOST );Correct?
-
Ryan Boren
Correct. Hyperdb provides an example of how to do this in a way that is compat with 3.0 and 3.1.
-
-
Ben
What about finally fixing the problem with inserting null values.. ?
this is a really annoying bug for plugin developers..
(http://wordpress.org/support/topic/bug-fix-wpdb-insert-amp-update-with-null-values)
-
Peter Westwood
The best way to report bugs like this is in trac – https://core.trac.wordpress.org/
I’ve created a ticket here: #15158
Now we just need a patch for the improvements
-
-
-
Ryan Boren
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.
-
mikeschinkel
If they fail, wouldn’t it make sense for them to fail loudly? I guess there’s always WP_DEBUG but how many themers and even plugin devs know about it?
-
Ryan Hellyer
Does WP_DEBUG pick up on stuff like that anyway? I assumed not – haven’ tested it though.
-
-
-
Ryan Boren
Per ticket 14672, WP_USE_MULTIPLE_DB will not be supported in 3.1 I don’t think many were using it, thankfully. Hyperdb is preferred if you want to do a multiple db setup.
Ben, 
Even though that’s certainly a way to accomplish the same thing, the logical solution would be to make another hook for activation.