Make WordPress Core

Tagged: 31compat Toggle Comment Threads | Keyboard Shortcuts

  • Mark Jaquith 5:04 pm on November 20, 2010 Permalink
    Tags: 31compat   

    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.

  • Andrew Nacin 6:27 am on November 17, 2010 Permalink
    Tags: 31compat   

    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 10:16 pm on October 27, 2010 Permalink
    Tags: 31compat   

    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 10:18 pm on October 27, 2010 Permalink | Log in to Reply

      Even though that’s certainly a way to accomplish the same thing, the logical solution would be to make another hook for activation.

      • Ryan Boren 10:20 pm on October 27, 2010 Permalink | Log in to Reply

        Which would not run for manually upgraded plugins. Hooks for upgrades is a non-starter. Plugins have to do it.

        • Michael Torbert 10:25 pm on October 27, 2010 Permalink | Log in to Reply

          I would guess that most plugins are automatically upgraded, making this a simple solution.

        • Ryan Boren 10:29 pm on October 27, 2010 Permalink | Log in to Reply

          Many people use git or svn, and relying on a hook is not multisite compatible.

    • Stephen Cronin 1:55 pm on October 28, 2010 Permalink | Log in to Reply

      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 2:16 pm on October 28, 2010 Permalink | Log in to Reply

        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 2:19 pm on October 28, 2010 Permalink | Log in to Reply

          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 2:47 pm on October 28, 2010 Permalink | Log in to Reply

          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 2:49 pm on October 28, 2010 Permalink | Log in to Reply

          @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 11:48 am on October 29, 2010 Permalink | Log in to Reply

          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: https://codex.wordpress.org/Function_Reference/add_option

    • Jarkko Laine 7:35 pm on April 12, 2011 Permalink | Log in to Reply

      Hi, just a quick note to point out that this documentation page is still giving wrong instructions for plugin developers: https://codex.wordpress.org/Creating_Tables_with_Plugins


    • Clint 2:54 am on May 15, 2012 Permalink | Log in to Reply

      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 8:40 pm on August 31, 2012 Permalink | Log in to Reply

        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 5:06 pm on October 13, 2010 Permalink
    Tags: 31compat   

    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 7:45 pm on October 13, 2010 Permalink

      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. 11:54 pm on October 13, 2010 Permalink

        Note how the color is red. The code was removed.

        • miqrogroove 4:43 am on October 14, 2010 Permalink

          Note how WordPress is used on millions of websites that do not have this changeset.

        • Alex M. 4:48 am on October 14, 2010 Permalink

          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 1:18 pm on October 14, 2010 Permalink

          unregister_globals has nothing to do with this. Variable variable syntax in PHP gives direct access to everything in memory.

    • miqrogroove 7:51 pm on October 13, 2010 Permalink

      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 8:20 pm on October 7, 2010 Permalink
    Tags: 31compat   

    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 8:35 pm on October 7, 2010 Permalink | Log in to Reply

      Can we not make WP_User_Search a wrapper of WP_User_Query and preserve backwards compatibility?

      • Andrew Nacin 8:44 pm on October 7, 2010 Permalink | Log in to Reply

        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 4:59 am on October 7, 2010 Permalink
    Tags: 31compat   

    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.

  • Andrew Nacin 7:18 pm on September 20, 2010 Permalink
    Tags: 31compat   

    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.

  • Ryan Boren 3:29 pm on August 30, 2010 Permalink
    Tags: 31compat   

    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 5:26 pm on August 30, 2010 Permalink | Log in to Reply

      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 Boren 3:24 pm on August 30, 2010 Permalink
    Tags: 31compat   

    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.

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc
Skip to toolbar