Make WordPress Core

Updates from scribu Toggle Comment Threads | Keyboard Shortcuts

  • scribu 2:02 pm on October 27, 2010 Permalink  

    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:


    • demetris 2:55 pm on October 27, 2010 Permalink

      Argh! I do not like this!

      I don’t have a good grasp of the issue, but I somehow feel we shouldn’t remove this feature, even with its current inconsistent behaviour, without having something to replace it first.

      Why not wait until we have an update hook?

      • scribu 3:24 pm on October 27, 2010 Permalink

        It’s not a feature, it’s a an inconsistency that leads to obscure bugs.

        As for the update hook, please lobby for it’s inclusion then.

      • Peter Westwood 3:29 pm on October 27, 2010 Permalink

        It is a bug pure and simple and this fixes it.

    • Rich Pedley 3:48 pm on October 27, 2010 Permalink

      argh. darn dagnabit. better change my update routine then. I’m so relieved I did some changes in preparation for this, it’s going to catch a lot of plugin authors out though.

      • Rich Pedley 3:51 pm on October 27, 2010 Permalink

        actually quick query, what is the best thing to hook onto for updates at the moment? init?

      • Peter Westwood 3:52 pm on October 27, 2010 Permalink

        That is what they get for holding it wrong.
        Relying on a hook for update detection is not a good ideatm as there are too many scenarios in which is won’t fire.
        Good plugins would use something similar to the $db_version that core uses itself.

        • Andy Skelton 3:58 pm on October 27, 2010 Permalink

          For ages I have used a constant and bumped it only when the updated plugin will need to run some upgrade code. I agree this is the way to go.

        • demetris 4:52 pm on October 27, 2010 Permalink

          “Good plugins would use something similar to the $db_version that core uses itself.”

          I would agree if you said “Perfect plugins”, because I know of good plugins that rely on this inconsistently fired hook to run their upgrade code. 🙂

          I think the problem I see with this change is that we remove something people use without telling why it is removed and what should be used instead.

          If an update hook can never be reliable (because plugins are often updated through channels of which WP cannot be aware), then we should wontfix that ticket and tell people clearly that the only reliable method is what you and Andy describe.

        • scribu 5:11 pm on October 27, 2010 Permalink

          I think the problem I see with this change is that we remove something people use without telling why it is removed and what should be used instead.

          We announced it here and described the reasons for it.

          We also suggested a fix.

          If an update hook can never be reliable (because plugins are often updated through channels of which WP cannot be aware), then we should wontfix that ticket and tell people clearly that the only reliable method is what you and Andy describe.

          The register_update_hook() proposed is exactly what westi and Andy describe, so it is reliable.

          In conclusion, please check your facts first.

        • demetris 6:23 pm on October 27, 2010 Permalink


          If I understand correctly, the feature is removed because it cannot be relied upon: the hook is fired in some cases, but not in others. This announcement says nothing of the sort.

          The fix suggested is slated for a future release (and we are now into feature freeze). What are people to use for 3.1?

          About the way register_update_hook works, my apologies. I had not looked at the code and, going by the function’s name, I thought it was a hook. But it is not a hook. It is not hooked on to anything. It is a helper function that, as you said, does what Peter and Andy described and that runs everytime the admin is loaded.

          (Which does not provide for all scenarios: If I don’t update via the admin, the update code will not run until I visit the admin.)

        • scribu 6:32 pm on October 27, 2010 Permalink

          To clarify, the activation hook can’t be relied upon for updating. Makes sense?

          Furthermore, it’s not removed, just restricted to it’s intended purpose.

          Also, we still have a few days until feature freeze, so I’m hopeful.

          Anyway, register_update_hook() doesn’t require any other core modifications, so plugin authors can just drop it in their plugin, wrapped in an if ( !functions_exists() )

        • demetris 6:55 pm on October 27, 2010 Permalink

          According to the schedule, feature freeze was on the 15th of October:


          In any case, I think an extra post explaining all this would be useful:


          We don’t fire the activation hook anymore on plugin updates because it was not reliable for update detection:

          1. It did not work for bulk updates

          2. It did not work for network updates

          3. It did not help for updates not done via the admin


          The reliable method for update detection is [what Peter and Andy described].


          [What we say here depends on whether register_update_hook makes it into 3.1.]

        • scribu 7:45 pm on October 27, 2010 Permalink

          I meant to say primary code freeze.

          Anyway, nice summary.

        • Alex M. 8:51 pm on October 27, 2010 Permalink

          +1 to using a constant/variable. I’ve always stored a version number in my settings array and when I loaded the settings, I checked the version and did an upgrade if need be.

          Relying on a hook is poor form in general.

    • Will Anderson 11:31 pm on October 27, 2010 Permalink

      I’m thinking this should be a simple s/register_activation_hook/register_update_hook for 99% of plugins that will be broken, assuming register_update_hook makes it into 3.1

      • scribu 8:38 pm on October 28, 2010 Permalink

        Yeah, the only thing would be that register_update_hook() requires a version too.

    • Jeff 4:46 am on October 28, 2010 Permalink

      Reading this and Nacin’s post really helped clarify this. It does make sense to not expect activation hooks to handle upgrades. Especially if a plugin is not deactivated on upgrade (svn, ftp etc).

      Excuse me while I go make updates.

    • arena 12:28 pm on October 28, 2010 Permalink

      Is there a way to avoid an automatic plugin update ?

      • scribu 8:39 pm on October 28, 2010 Permalink

        Yes. There’s a plugin called something like “No Plugin Updates” that does this. You should check it out.

    • Cian Kinsella 4:21 pm on February 28, 2011 Permalink

      This really did catch us out, I’m sure we won’t be the last. Shouldn’t the automatic update process stop displaying misleading messages such as “Deactivating the plugin…, Removing the old version of the plugin…, Plugin updated successfully, Reactivating the plugin… 🙂

      • scribu 4:32 pm on February 28, 2011 Permalink

        It doesn’t say “Successfully fired activation hook”, so it’s not misleading. 😉

        • Cian Kinsella 5:33 pm on February 28, 2011 Permalink

          You are pulling my leg aren’t you?

        • scribu 5:39 pm on February 28, 2011 Permalink

          Only partly. Read the discussion again (including the one on trac).

    • face-gamers.com 10:43 am on March 8, 2011 Permalink

      We lost all of our comments by updating the plugin.

      How can we stop this happening in the future apart from not updating?

    • Steve 3:19 am on October 25, 2011 Permalink

      Had a question about testing my changes to my plugin’s upgrade routine once I’m done making those changes.
      I don’t want to push an update (the next higher svn tag) to my plugin’s SVN repo on WordPress just to test how an automatic update would behave. Do I simply just downgrade my live wordpress to the lower version of my plugin and then with filezilla ftp , just copy over the newer version of my plugin ?
      thanks for the info above

      • Steve 1:41 pm on October 25, 2011 Permalink

        You can ignore that. The obvious solution to testing the auto upgrade (without pushing a newer version that I didn’t want wp users to download) is to simply install a version going back to two versions to my WordPress blog, and then I can test what the auto update does after tweaking my current version a little.

    • Mika "Ipstenu" Epstein 1:07 pm on October 25, 2011 Permalink

      Steve – That’s not really a question for this post 🙂 You could either post in the support forums: https://wordpress.org/support/ or email the hackers list: http://lists.automattic.com/mailman/listinfo/wp-hackers

      But basically if you wanted to test an upgrade, and knowing that the activation hook is called “when the user activates the plugin and not when an automatic plugin update occurs” then you really don’t even need to downgrade. I would upload the plugin as trunk and NOT make it the release version, then download the ‘development’ version from https://wordpress.org/extend/plugins/YOURPLUGIN/download/ and use the zip-uploader in WP to upgrade it.

      If you need more help on doing that, post on the forums or mail hackers, please 🙂

  • scribu 5:06 pm on October 13, 2010 Permalink
    Tags: ,   

    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.

  • scribu 8:54 am on July 23, 2010 Permalink  

    Trac Component Cleanup 

    As discussed in yesterday’s meetup, here’s a list of proposed changes to the Components in Trac:

    1. Merge Optimization into Performance: they’re basically the same

    2. Remove JavaScript: tickets should be moved to specific features, like Menus, Widgets etc.

    3. Create Libraries component: tickets dealing with upgrading third party libraries, like jQuery or SimplePie, should go there.

    4. Merge TinyMCE into Editor: there should be a single component that deals with the editor as a whole.


    After this is done, I plan to document each component in the Codex, so that we have a clear description of what goes where.

    • Mr mist 9:54 am on July 23, 2010 Permalink

      Megre Export and Import into one?

    • Dion Hulse 10:16 am on July 23, 2010 Permalink

      Some generic terms could also be renamed to fit their purpose, For example, is “HTTP” for HTTP-level responses? Or as it was originally intended as, tickets for the WP_HTTP class, perhaps “WP_HTTP” could be used instead.

      Another one, is Upgrade/Install, Originally intended for Automated systems bugs, but now, often includes DB Upgrade issues. The 2 are similar, and so can live together really, but that just goes back to the Generic names sometimes.

      • scribu 10:21 am on July 23, 2010 Permalink

        Perhaps a clearer name would be HTTP API?

        Regarding Upgrade/Install, the problem is that the automated upgrade feature involves several other components: HTTP & Filesystem.

        • Dion Hulse 10:24 am on July 23, 2010 Permalink

          Actually, make that 3 types in the HTTP component. WP_HTTP Issues, Outgoing Header issues, and also SSL URL’s, #14360

          HTTP API would probably suit more, but not entirely sold on it either.

          I agree with the Upgrade/Install though, The problem with some of these is that its entirely possibly to have a bug in the Upgrade, but its due to a bug in HTTP, and same for other areas. Categorizing by ‘Components’ in such interlinked systems is often confusing. I wont go into what it should be though 😉

    • Ryan McCue 1:01 pm on July 23, 2010 Permalink

      +1 for tagging libraries. Being able to see SimplePie issues via a feed would be better than how I currently do it (search, which can have broken feeds). Even better if you could auto-cc me to all SimplePie issues (I’m not sure if that’s possible though).

      • Alex M. 6:36 pm on July 23, 2010 Permalink

        If we had a SimplePie component, it’s easy to auto-assign all tickets to you.

  • scribu 9:00 pm on January 17, 2010 Permalink

    Menu Management UI 

    Here’s a quick preview of the new menu management admin page (still alpha stage).

    It highlights the dropdown section, which is the only unfamiliar element. All the rest are borrowed from the widget management screen.

    Feedback on the UI is very welcome, either here, or on the dedicated ticket: #11817.

    • Jane Wells 9:08 pm on January 17, 2010 Permalink

      A couple of things. In the widget code, you can have multiple sidebars open. Here it looks like you can only have one open at a time, but it seems like it would make sense to be able to see them all at once. So the dropdowns adding to “the open menu” feels potentially awkward. Would the add have an automatic save, would the item need to be saved, would the menu need to be saved… what’s the ‘go live’ mechanism?

      The dropdowns seem to perform the same function as “available menu items,” so am wondering of function of latter. Inactive menu items seems unnecessary, since it’s not like widgets where there might be a lot of custom code you want to hold on to.

      In the menu items themselves, it’s cool you can change the display name, but there should definitely be a place in the there to show the actual page/category name so that users don’t wind up accidentally confusing themselves by renaming things.

      Also, the dropdown

      • scribu 9:21 pm on January 17, 2010 Permalink

        Looks like your comment was truncated.

        Don’t really know how to tackle the “multiple open menus” problem, short of including the dropdowns in each menu.

        Related to the available menu items section, I was thinking of putting all of them in a “Other items” dropdown.

        Agree on the “inactive menu items” section: it will be removed.

        I plan to include some sort of preview link for pages and categories, probably at the bottom of each widget.

        • Jane Wells 9:23 pm on January 17, 2010 Permalink

          Hm, weird. Yes, looks like it was truncated, and can’t for the life of me remember what it said. I’m getting old! 🙂

      • scribu 9:58 pm on January 17, 2010 Permalink

        You can have more than one menu open at one time and move items from one to the other. The dropdowns will just add elements to the first open one.

        The menu is saved every time you add an item to it (from one of the dropdowns or otherwise), as well as when you rearange the existing items.

        • scribu 10:05 pm on January 17, 2010 Permalink

          Maybe you could have a “menu assembly” spot:

          You move the menu you want to work on to that spot and use the dropdowns to add elements to it, while still being able to interact with the other menus.

        • Shane 3:39 am on January 18, 2010 Permalink

          I was just thinking the same thing. Just like Widgets where they sit there and you drag them over (The inactive section.) Then you can drag them over to the area’s in which you want to place it in.

        • Daryl Koopersmith 3:44 pm on January 18, 2010 Permalink

          Some UI ideas in a similar vein… take them for what you will. (After I wrote this, I noticed that you mentioned that you were moving the “Available” section into a dropdown… I’ll post this anyway.)

          Consistent UX:
          1. Make the dropdowns collapsable and their contents draggable (like the “Available” section is now).
          2. Or make the “Available” section a dropdown.

          —I personally like option 1 more. Users could drag items to whichever menu they wanted. You could use it as a starting point to add a UI to select all children of a certain page, and it’s more in line with what users are used to (i.e. widget admin). It also could result in much fewer clicks for people who are building large menus.

          Central Focus:
          1. Move all items and dropdowns into one “Available Menu Items” section.
          2. Or separate the dropdowns into their own sections: “Special Menu Items” (Home, Link), Pages, Categories, Bookmarks, etc.

          —I think option 2 would potentially have a cleaner UI and be a better use of screen real estate. Why should we be cramming everything into a small selection menu?

          Also, +1 to the idea to indicate when you’ve renamed a link to a page.

      • scribu 2:48 pm on January 21, 2010 Permalink

        For all the people who are asking about nested menu items:


    • Ptah Dunbar 11:16 am on January 18, 2010 Permalink

      How/Where are the actual menus created in the UI?

      • scribu 2:45 pm on January 21, 2010 Permalink

        You mean in the theme?

        It will probably be similar to how widgets are displayed – using a template tag:


        • Ptah Dunbar 2:42 am on January 22, 2010 Permalink

          No, in the backend. In the vid, you have “Menu 1” and “Menu 2”, im assuming those auto appear after calling register_menu()?

        • scribu 7:57 am on January 22, 2010 Permalink

          Yeah, it uses register_menu(). The patch in the ticket includes a modified functions.php file in the default theme.

    • Paul 2:24 pm on January 18, 2010 Permalink

      Forgive ignorance. I know how to use trac and svn but was wondering if there is a known standard way to incorporate your .diff files for this menu functionality into the latest trunk? Or do we have to wait for it to be committed to the core. I am eager to play and test some theme ideas.
      Many thanks!!

      • scribu 2:44 pm on January 21, 2010 Permalink

        Read How to Submit Patches

        It explains how to apply patches as well.

        • Paul 5:06 pm on January 21, 2010 Permalink

          Thank You!

        • Paul 6:46 pm on January 21, 2010 Permalink

          I was wondering whether there is a reason to limit the viewable items to 5? There is a lot of unused white space below the three columns. Why not have up to 20 viewable items so the average blog user will not need to scroll. And blogs with a lot of categories and pages will be a lot easier to manage, as more of the menu structure will be viewable at once. I believe this would enhance usability.

        • scribu 7:35 pm on January 21, 2010 Permalink

          Since the size is set through JavaScript, we might as well resize them dynamically, by the number of items in each select, but no larger than 20, as you said.

    • Cristian Antohe 3:44 pm on January 18, 2010 Permalink

      What about child pages and grand-child pages? There is no default way of doing this using the Widget UI.

      I think the easiest way to do this is with a dropdown similar to the one you have to select pages. On each “menu element” from the right we have the possibility to select the Parent page. If we select one then the menu order should reorganized and the child menu item should be indented.

      I hope this makes sense.

    • Carl Hancock 4:11 pm on January 18, 2010 Permalink

      Is this going to support menu items that have a parent-child relationship (ex. drop downs)? Judging from the UI example above it isn’t there, but is it a planned feature?

      Also, any plans for the functionality that the widget that can then display these menus will offer in the way of features? (ex. show all, only show children of current page for sub-navigation side nav, etc.).

    • scribu 4:17 pm on January 18, 2010 Permalink

      “Why should we be cramming everything into a small selection menu?”

      Because some sites will have 100 pages, 30 categories etc., which would take up a lot of screen space.

      We need a more compact way of displaying items.

      In the next version, each selection menu will show 5 items at a time, instead of 1.

    • Jason 4:51 pm on January 18, 2010 Permalink

      Amazing! Thanks for the ‘sneak peak’ 🙂

    • Steven 7:37 am on January 19, 2010 Permalink

      Looks wicked!! Will this also include an option to create multi level menu structures?

    • Jean-Patrick Smith 9:37 am on January 19, 2010 Permalink

      Pretty slick, I’m lovin it

    • Flavio Paiva 11:37 pm on January 23, 2010 Permalink

      This new feature will take WordPress to a higher level of personalization. I remember this resource from Joomla.

    • Paul 5:02 pm on January 25, 2010 Permalink

      I am too new to leave this on the Trac in response to the latest screens. And even here I fear the ‘dunce’ syndrome coming on. But I just cannot help wondering why the new Menu Management could not be a Multiple Instance Widget, managed from the widget section. My reasoning is as follows:
      1. Can use existing Registered Sidebars instead of additional Registered Menus in themes
      2. That means one user of a theme can place a menu in a dynamic area, and another user of the same theme may place a widget.
      3. Widgets are already established with menu-like features (Categories/Pages), so less learning curve for WP novices.
      4. No need to create an additional admin interface.
      Menu items could be represented by simple check boxes in the Widget Options panel.
      I await the eggs (glad I went to school before kids were armed :).

    • scribu 5:07 pm on January 25, 2010 Permalink

      I would agree with you, if it weren’t for those pesky “check boxes”.

      It’s not easy to cram all the pages and all the categories in a tiny space, while at the same time making it easy to work with and allow the level of customisation that people want.

      That’s why we’re going for a new admin page.

      • Paul 5:11 pm on January 25, 2010 Permalink

        I see.
        One last shot: What about placing the scrolling list/selection box you have designed, inside a widget. Keep the new method of selection, but wrap it in a familiar widget structure.

        • Paul 5:14 pm on January 25, 2010 Permalink

          Ignore. I think you are right.

    • Peter Wade 1:00 am on February 1, 2010 Permalink

      Will the Menu Management 3.0 provide for external links (outside WP but same URL) to go into the menu? Or will this require a plugin?

      • sc0ttkclark 6:54 pm on February 2, 2010 Permalink

        External Links are supported, as shown in the Demo Video as an option

    • Jess Planck 2:55 am on February 6, 2010 Permalink

      It has to be one of the biggest requests I get: “I want to add a link to something into the where-ever menu” This will be so very useful.

      I know a lot of the ui was taken straight from Widgets, and I can see how the open and close options for menu items would start getting cumbersome. Perhaps you can separate the ui for the menu organization and menu items by using a thickbox / colorbox instead. That might help with some performance and give users an interface to change a menu item properties.

      For example: A user could visit Appearance > Menus and arrange the menu order. Then click a control for the “About” page item that would open a Thickbox / Colorbox widow where they then change the properties for that menu item to a Category Link and change the Link Text to “News”.

      • Alex M. 9:13 am on February 6, 2010 Permalink


        Lightboxes allow you to only edit one thing at a time, you can’t click elsewhere on the page, etc.

        I see nothing wrong with the widget style UI.

        • Jess Planck 2:00 pm on February 6, 2010 Permalink

          Yea, too true I don’t like the lightbox losing the rest of the screen interface.

          The only place the Widget UI falls apart is if you go hierarchical or if you want to change menu content types. Perhaps (stealing from Media UI ideas) moving the menu item properties UI to a drawer or using a single UI for the properties.

          I would not be opposed to the users I’ve dealt with having to focus on one menu item and one menu at a time. With some of the complex menus I’ve seen (and been forced to create) the end client desire has been more for quick arrangement of the hierarchy not menu item properties. They don’t have any idea the complex differences between a Page, Category, or Link. But they will get frustrated when they have to; 1. remove a the Category, 2. replace with a Link, & 3 THEN try to move that item to it’s final position.

          I guess I should put up or shut up! If I’ve got time I’ll at lest put a wireframe on the ticket.

    • RJ 6:29 am on February 12, 2010 Permalink

      I’m really excited for this to make its way into WP 3.0. Having worked with Joomla’s interface, it’s something that I feel makes WP a much friendlier and powerful “non-blog” CMS. Leaving menu management to a handful of experienced designers is one thing, but it’s another to bring it right into the hands of the least experienced end-user.

    • kathy 4:02 am on March 15, 2010 Permalink

      umm that looks awesome. i was trying to figure out how to code something similar (if basic) that into an options page. can this be available already. 🙂

    • Michael 10:48 pm on April 6, 2010 Permalink

      First, Love this – such an awesome leap.

      Second, my only BIG issue with this is that (and maybe I’m missing something) the menu’s should not have to be enabled by the user – only managed by the user.

      For example, as a theme designer, If I build a menu into my theme that’s great – but as a user, when I activate the theme, it doesn’t automatically create the menu. Two issues arise from this.

      1. as a theme developer, If my user makes 4 menus, how do I control which menu goes where?
      2. as a user, I have to manually create (and name correctly) my menus for them to show up in the proper places in the theme.

      I see an simple solution to this, treat the menu management like you treat widget management.

      • allow theme developers to register menus like they register sidebars, that way the menus will automatically show up in the management area, ready to be filled, AND they’re exactly where the theme requires them to be (all upon activation of the theme).

      Hopes this makes sense.

      • MadtownLems 6:36 pm on April 12, 2010 Permalink

        This is the exact problem I’m hitting already. I’m all about coding custom menu displays into the themes; in fact, I’ve been doing this with my own (much simpler) UI backend for quite some time.

        I need the ability to, when someone activates Theme X, to have it automatically create (register?) the necessary menus and let me hardcode displays of certain menus in certain places.
        Is there any way to do this currently?

    • Acts7 6:09 pm on October 5, 2010 Permalink

      Here’s what I just don’t get. Currently we have “Automatically Add Top Level Pages”
      That REALLLY Needs to be the other way around.
      As of right now, there is no benefit … when adding a new page … to being able to select the parent page.
      If you select it… Its not in the menu.
      Why is that?
      Auto-Add a parent page … thats one easy click to add.
      But if its children do not follow.
      We have saved 3 seconds not adding one parent page.
      But lose 100 seconds dragging all the children.

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