WordPress.org

Make WordPress Core

Updates from Jeremy Felt Toggle Comment Threads | Keyboard Shortcuts

  • Jeremy Felt 6:13 am on August 19, 2016 Permalink |
    Tags: 4.6.1,   

    Bug Scrub for 4.6.1 

    The first bug scrub for 4.6.1 will be Tuesday 23 August, 15:00 UTC in #core.

    There are currently 9 11 tickets open on the 4.6.1 milestone in various stages of verification, patching, and testing. Working with these over the next several days before the bug scrub will help determine when a 4.6.1 release will be necessary.

    Any tickets reported against trunk at this point in the cycle should also be checked for issues that may have been introduced in 4.6.

    All testing is helpful, so please take a look if you have time.

    See you on Tuesday!

     

     
    • Ian Dunn 7:54 pm on August 21, 2016 Permalink | Log in to Reply

      when a 4.6.1 release will be necessary

      I can’t attend the meeting, but #37736 seems particularly nasty to me.

      I’m guessing that it’s causing most emails sent by most sites to be rejected, but is going largely unnoticed by admins.

  • Jeremy Felt 6:27 pm on July 20, 2016 Permalink |
    Tags: , ,   

    Additional register_meta() changes in 4.6 

    In the last 2 weeks, the direction of register_meta() has changed significantly from the original write-up. There was a meeting to discuss some of the changes and a recap of that discussion. Some other discussion after that meeting led to a much more simplified version of register_meta() that is now shipping in 4.6.

    Here’s what registering meta looked like in 4.5. This meta key has sanitization and authorization callbacks.

    register_meta( 'post', 'my_meta_key', 'sanitize_my_meta_key', 'authorize_my_meta_key' );
    

    The above code will continue to work in 4.6, though will not be considered completely registered. The callbacks will be registered, but the key will not be added to the global registry and register_meta() will return false.

    Here’s what registering meta looks like in 4.6. This meta key will have sanitization and authorization callbacks, and be registered as public for the WordPress REST API.

    $args = array(
        'sanitize_callback' => 'sanitize_my_meta_key',
        'auth_callback' => 'authorize_my_meta_key',
        'type' => 'string',
        'description' => 'My registered meta key',
        'single' => true,
        'show_in_rest' => true,
    );
    register_meta( 'post', 'my_meta_key', $args );
    

    The above will register the meta key properly and return true.

    There will no longer be a check for unique object types and subtypes for meta keys. There is no CURIE like syntax involved. Instead, be sure to uniquely prefix meta keys so that they do not conflict with others that may be registered with different arguments.

    Additional helper functions get_registered_metadata(), get_registered_meta_keys(), unregister_meta(), and registered_meta_key_exists() have been added to make the innards of the global data more accessible.

    The $wp_meta_keys variable should not be altered directly. It is possible that its structure will change in the future.

    Any code currently using register_meta() and expecting pre-4.6 behavior will continue to work as is. Please report any breaks in compatibility that might be found.

    For the full history, see #35658. 🙂

     

     

     
  • Jeremy Felt 10:02 pm on July 14, 2016 Permalink |
    Tags: ,   

    register_meta() Discussion Recap (July 14, 2016) 

    As announced yesterday, there was a discussion today covering the future of register_meta(), something that has been in progress for WordPress 4.6 in #35658. This is a recap. 🙂

    Attendees: @helen, @ocean90, @rachelbaker, @mikeschinkel, @jsternberg, @sc0ttclark, @richardtape, @swissspidy, @joemcgill, @seancjones, @achbed, @jeremyfelt

    Chat log.

    Overview

    In #35658, register_meta() uses object subtypes when registering meta so that key registration can be considered unique.

    In 4.6 trunk, this information is passed as part of the 3rd argument—array( 'object_subtype' => 'books' )—to register_meta() and $object_subtype = '' has been added as an extra argument to several other pieces as a way to support that.

    After exploring a bit more, it’s clear that $object_subtype will continue to spread as an additional argument throughout many _meta() functions so that registered meta is handled properly.

    An alternative is to use CURIEs to describe complex meta types in a single string—'comment:reaction' rather than 'comment' and 'reaction'—so that the extra argument is not needed. Instead, processing exists to turn that string into an object type and subtype.

    Examples

    • post:post
    • post:books
    • term:category
    • user:user
    • comment:reaction

    The main question for today’s discussion

    Is CURIE like notation the right way forward for handling complex meta types?

    Decisions

    After a very good and thorough conversation about the above and other points, these are the decisions for moving forward with work on #35658:

    1. Meta keys will be registered using CURIE like syntax.
      • register_meta( 'post:book', 'isbn', $args );
    2. The : used in the string to register meta keys will also be used in filters.
      • sanitize_post:book_meta_isbn
    3. Core object types will fallback to default subtypes if one is not specified.
      • post becomes post:post, comment becomes comment:comment, user becomes user:user, and term becomes term:category.
    4. Meta key registration for all/any subtypes of an object type will not be included in 4.6, but is likely something to add in the future.

    Please check out the latest patches on #35658 and contribute code and thoughts on that ticket or share any questions/concerns in the discussion below.

    Thanks everyone for attending today!

     
  • Jeremy Felt 9:16 pm on July 13, 2016 Permalink |
    Tags: , ,   

    register_meta() discussion on Thursday, July 14 

    Howdy!

    There will be a meeting in #core at Thursday July 14, 19:00 UTC to discuss the changes in register_meta() for the 4.6 release. The dev notes have been published, but there is still work to be done to ensure things are great.

    Of particular interest is a proposal to change to a CURIE like notation when working with the registration of meta. Instead of using two arguments (object type and subtype), there would be one argument containing both.

    As an example, If a post type was registered with books as the slug and ISBN was stored as sanitized meta:

    // In WordPress 4.5
    register_meta( 'post', 'isbn', 'my_sanitize_callback' );
    
    // In current trunk for 4.6
    register_meta( 'post', 'isbn', array( 'object_subtype' => 'books', 'sanitize_callback' => 'my_sanitize_callback' ) );
    
    // After proposed change
    register_meta( 'post:books', 'isbn', array( 'sanitize_callback' => 'my_sanitize_callback' ) );
    

    Please stop in #core at Thursday July 14, 19:00 UTC tomorrow if you are interested. If you can’t make it, please leave a comment on this post with your thoughts.

     
  • Jeremy Felt 10:15 pm on July 8, 2016 Permalink |
    Tags: , , ,   

    Multisite Focused Changes in 4.6 

    The 4.6 release cycle has been a productive one! Several major and a few minor updates are described in detail below. If you’d like even more detail, here is a full list of multisite focused changes for 4.6.

    Introduce WP_Site_Query and WP_Network_Query

    WordPress 4.6 introduces WP_Site_Query and WP_Network_Query as well as their companion functions, get_sites() and get_networks().

    WP_Site_Query

    With WP_Site_Query (or get_sites()), sites can now be queried from the $wpdb->blogs table in a flexible way by id, domain, path, and more. For a full list of supported arguments, see the documentation attached to the __construct() method.

    New filters and actions associated with this change include parse_site_query, pre_get_sites, the_sites, site_search_columns, sites_clauses, and found_sites_query.

    Query results are cached as part of the global sites group. This will provide a performance boost for sites using a persistent object cache.

    The introduction of this class helped resolve several long standing issues with WP_MS_Sites_List_Table. Expect to see a faster and more relevant search when browsing through a network’s sites. See #36675.

    For the background discussion around these changes, see #35791.

    WP_Network_Query

    With WP_Network_Query (or get_networks()), networks can now be queried from the $wpdb->site table by id, domain, and path. Query results are cached as part of the global networks group. For a full list of supported arguments, see the documentation attached to the __construct() method.

    WordPress core does not provide a UI for managing multiple networks, but any sites using a plugin to do this will start to see a benefit from having this available.

    New filters and actions associated with this change include parse_network_query, pre_get_networks, the_networks, networks_clauses, and found_networks_query.

    For the background discussion around these changes, see #32504.

    Enhancements to WP_Site and WP_Network

    New utility methods

    New functions get_site() and get_network() have been introduced to retrieve a specific site or network respectively. They both accept either an ID, database object or class instance as the first parameter. If that parameter is omitted, the current site / network is returned.

    Property changes on WP_Site and WP_Network

    The WP_Site and WP_Network objects now support access to their respective ID properties through property names which match current naming conventions. Furthermore, by accessing the properties with the new names, it is ensured that these are returned as integers rather than strings. The old properties are still accessible and valid, but these changes should encourage developers to use the new property names.

    The following is the list of property improvements:

    • $site->id is the site’s ID. (previously $site->blog_id)
    • $site->network_id is the site’s parent network ID. (previously $site->site_id)
    • $network->id is now an integer instead of a string.
    • $network->site_id is the network’s main site ID. (previously $network->blog_id)

    For background discussion around these changes, see #36717 and #37050.

    Lazy-loading extended properties

    Additional properties of a site object normally accessed with get_blog_details() are now automatically lazy-loaded when requested. This allows developers to use get_site() as a replacement for get_blog_details() which is likely to be deprecated in a future release. See #36935.

    New Actions and Filters

    Several new actions and filters were added as part of the WP_Site_Query and WP_Network_Query changes. Here are some others of note:

    • ms_loaded fires at the end of the multisite bootstrap process in ms-settings.php. At this point the current site and network are available in the global scope. See #37235.
    • pre_get_blogs_of_user allows developers to alter or short-circuit the results of get_blogs_of_user(), which can be an expensive function to run on configurations with many users. See #36707.
    • clean_site_cache fires after cache has been cleared with clear_blog_cache(). This can be useful for clearing any custom cache keys associated with a site record. See #36203.
    • network_edit_site_nav_links filters the list of links displayed at the top of Edit Site views as a “tabbed” interface. See #15800.
    • ms_sites_list_table_query_args filters the arguments passed to WP_Site_Query when building the MS Sites List Table. See #26580.

    Other enhancements of note

    Introduce get_current_network_id() as a helper function to find the current network’s ID. See #33900.

    The MULTISITE and SUBDOMAIN_INSTALL constants can now be overridden in a project’s wp-config.php when running unit tests. See #36567.

    Deprecated Functions

    wp_get_sites() has been deprecated and get_sites() should be used instead. Please note when making code changes that get_sites() returns an array of WP_Site objects where wp_get_sites() returned an array of arrays.

    WP Multi Network compatibility

    The introduction of get_networks() in 4.6 conflicts with the function of the same name in WP Multi Network, a plugin commonly used to provide multiple networks on a multisite installation. A fix for this is already in the master branch of the plugin, and will be included in the next release. In the same change, many other functions were wrapped in function_exists() calls to prevent similar conflicts in the future. If you are using WP Multi Network, please be sure to update accordingly.

     
    • David Naber 8:14 am on July 9, 2016 Permalink | Log in to Reply

      wp_get_sites() has been deprecated and get_sites() should be used instead.

      The introduction of get_networks() in 4.6 conflicts with the function of the same name …

      Am I the only one who spots the problem here? Why gets prefixed functions deprecated in favor to use unprefixed ones and even unprefixed functions gets introduced today?

      • Jeremy Felt 8:39 pm on July 9, 2016 Permalink | Log in to Reply

        Thanks David, you aren’t the only one. 🙂 We deliberated on this before going forward. In addition to conversations during the weekly multisite chats, we brought this up for discussion in the weekly core dev chat – https://wordpress.slack.com/archives/core/p1462395264003378.

        In general, it was agreed that for the benefit of developer experience, having `get_site(s)` and `get_network(s)` match the existing experience for posts, users, comments, etc… made sense here.

        We did some due diligence and searched the plugins directory for any usages, knowing in advance that WP Multi Network would conflict. There are no other obvious conflicts and WPMN has been a good example multiple times where a function there makes sense in WordPress core.

        The deprecation of `wp_get_sites()` is a benefit of making this decision as it also broke with developer experience and returned an array of arrays rather than `WP_Site` objects as one would expect. A similar change has happened with `wp_get_network()`, though it has not yet been deprecated.

        • David Naber 4:47 pm on July 10, 2016 Permalink | Log in to Reply

          With «developer experience» you mean the weekend hours to workaround naming collisions when using WordPress together with other code bases, for example?

          Prefixing is something fundamental when not using namespaces. Why not just the other way around and deprecate everything non-prefixed and introduce a prefixed version of it?

          • Ipstenu (Mika Epstein) 9:27 pm on July 10, 2016 Permalink | Log in to Reply

            Currently we enforce plugins hosted on .org to use namespaces or prefixes, to prevent these kinds of issues. When we introduce new functions, we are highly aware of the potential for conflicts. As the ‘parent’ project, WordPress’ use of function prefixes is less of a requirement than for the children of themes and plugins.

            We’ve had as many issues with wp_ or wordpress_ as prefixes, compared to nothing as a prefix. It’s simply the bane of project management when you have an ecosystem this large.

            In general we search for all plugins in the repository and attempt to find any potential conflicts.

    • Martin Stehle 12:11 pm on July 22, 2016 Permalink | Log in to Reply

      Can you please confirm that code will be correct:
      // get registered site IDs
      $site_ids = array();
      if ( version_compare( get_bloginfo( ‘version’ ), ‘4.6.0’, ‘>=’ ) ) {
      $sites = get_sites();
      foreach ( $sites as $site ) {
      $site_ids[] = $site->id;
      }
      } else {
      $sites = wp_get_sites();
      foreach ( $sites as $site ) {
      $site_ids[] = $site[ ‘blog_id’ ];
      }
      }

      Thank you.

      • Felix Arntz 7:01 pm on July 27, 2016 Permalink | Log in to Reply

        Hi Martin, yes that code is correct and works in a backward compatible way. A minor improvement: In the first clause you could use the following code:

        $site_ids = get_sites( array( ‘fields’ => ‘ids’ ) );

        By using that code, you don’t need to query the entire site objects and thus can get rid of the foreach loop. Note that this only works for the first clause (4.6 version).

  • Jeremy Felt 8:30 pm on July 8, 2016 Permalink |
    Tags: , , , ,   

    Enhancing register_meta() in 4.6 

    Note: Note: The direction of register_meta() has changed since this was published. Please see the most recent developer note explaining these changes.

    In 4.6, register_meta() expands to support the registration of meta keys and what to expect from those keys. See #35658 for the discussion around this change.

    The behavior of register_meta() is similar to register_post_type() in that the registration of this data is stored in the global scope. This makes an object’s meta data more accessible to parts of core and extending code.

    Why make this change

    In 4.5 and earlier, WordPress provided no method to explicitly register a meta key’s public state. Instead, register_meta() provided “protected” and “authenticated” meta. This can be used effectively for some things, particularly to determine what meta appears in the Custom Fields metabox when editing a post. It can not be used as a basis for arbitrarily showing meta keys and values to unauthenticated visitors.

    What does this change involve

    A global variable, $wp_meta_keys, contains all registered meta keys.

    The function signature of register_meta() has changed to support 3 arguments, the last being an array. That array should contain data about the meta with these key/values:

    • sanitize_callback, a callable method to provide sanitization. This is the new version of the current 3rd parameter in register_meta().
    • auth_callback, a callable method to provide authorization. This is the new version of the current 4th parameter in register_meta().
    • object_subtype, a string containing an object subtype slug. If there is no object subtype, meta will not be registered and a WP_Error will be returned instead.
    • type, a string indicating what type of data the meta value will be. This is intentionally not restricted to a specific list of data types, however full names should be used when possible. (e.g. boolean, integer)
    • description, a string containing a basic description of the meta value.
    • single, whether code retrieving meta for this key should expect a single or multiple values when using something like get_post_meta().
    • show_in_rest, whether this should be shown as part of a post’s meta endpoint in the WordPress REST API. Note that this should be treated as experimental until the WordPress REST API provides support for meta.

    The register_meta_args filter is available to add support for additional arguments. This need to explicitly whitelist further arguments is to reserve the right for core to add further arguments in the future; should you choose to use this filter, you should be prepared to follow along with further development. Your testing with trunk or betas is greatly appreciated!

    By default, only WordPress core object types (post, user, term, comment) can be registered. To add support for custom object types, use the wp_object_types filter. This whitelisting is similar to the above.

    Object sub types provide specific registration of meta keys to a type of data.

    • A standard WordPress post has an object type of “post” and an object subtype of “post”.
    • A custom post type registered with a slug of “my_cpt” has an object type of “post” and an object subtype of “my_cpt”.
    • A WordPress user has an object type of “user” and an object subtype of “user”.
    • A standard WordPress comment has an object type of “comment” and an object subtype of “comment”.
    • A standard WordPress category term has an object type of “term” and an object subtype of “category”.
    • A custom taxonomy registered with a slug of “my_tax” has an object type of “term” and an object subtype of “my_tax”.

    Meta keys must be explicitly registered for each object type and subtype combination.

    Additional helper functions get_registered_metadata(), get_registered_meta_keys(), unregister_meta(), and registered_meta_key_exists() have been added to make the innards of the global data more accessible.

    The $wp_meta_keys variable should not be altered directly. It is possible that its structure will change in the future.

    Any code currently using register_meta() and expecting pre-4.6 behavior will continue to work as is. Please report any breaks in compatibility that might be found.

    Example

    Here’s what registering meta looked like in 4.5. This meta key has sanitization and authorization callbacks.

    register_meta( 'post', 'my_meta_key', 'sanitize_my_meta_key', 'authorize_my_meta_key' );
    

    The above code will continue to work in 4.6, though will not be considered completely registered. The callbacks will be registered, but the key will not be added to the global registry. A WP_Error object will be returned with this explanation.

    Here’s what registering meta looks like in 4.6. This meta key will have sanitization and authorization callbacks, and be registered as public for the WordPress REST API.

    $args = array(
        'object_subtype' => 'post',
        'sanitize_callback' => 'sanitize_my_meta_key',
        'auth_callback' => 'authorize_my_meta_key',
        'type' => 'string',
        'description' => 'My registered meta key',
        'single' => true,
        'show_in_rest' => true,
    );
    register_meta( 'post', 'my_meta_key', $args );
    

    If you are currently using register_meta() and would like to maintain support for older versions of WordPress, the best method will be to check for the registration of the sanitization and authorization callbacks after calling register_meta() and then registering them manually if not present. This manual registration is all that register_meta() was previously doing. Continuing from the example above:

    // Pre-WordPress 4.6 compatibility
    if ( ! has_filter( 'sanitize_post_meta_my_meta_key' ) ) {
        add_filter( 'sanitize_post_meta_my_meta_key', 'sanitize_my_meta_key', 10, 4 );
    }
    
    if ( ! has_filter( 'auth_post_meta_my_meta_key' ) ) {
        add_filter( 'auth_post_meta_my_meta_key', 'authorize_my_meta_key', 10, 6 );
    }
    

    What’s next

    While the initial work on this is largely driven by the need to move the WordPress REST API forward, its scope is not limited to solving the problem of public access to metadata. By having information about the meta keys used in a code base, it becomes much easier for other pieces of code to make decisions about what can be done with this data.

    This data can one day be useful to everything from the Customizer, the editing experience for all object types, the Fields API, and many plugins that rely on metadata. Work will continue on transforming this $wp_meta_keys object and the methods surrounding it to be flexible and explicit. As WordPress core becomes familiar with register_meta() and more confident in the approach, the set of default arguments can and likely will expand to include more data about registered meta keys as required.

    Feedback

    Please leave any feedback you have on this new iteration of register_meta() in the comments below. Test it out in your plugins and themes to be sure it is working in a backwards compatible way. Try out the new function signature and register meta for objects and their subtypes. This continues to be a work in progress and feedback is important.

     
  • Jeremy Felt 6:51 pm on June 15, 2016 Permalink |
    Tags: , ,   

    Multisite Office Hours Recap (June 14, 2016) 

    Multisite office hours are held every Tuesday at 16:00 UTC in #core-multisite. The next will be Tuesday 16:00 UTC. A more casual bug scrub is on Thursday 20:00 UTC.

    The weekly agenda for the 4.6 cycle is to (a) address blockers and share status on bigger initiatives, then (b) walk through a few multisite focused tickets on Trac.

    Today’s chat log

    Attendees: @flixos90, @spacedmonkey, @jeremyfelt

    Tickets Covered

    • #36675, WP_MS_Sites_List_Table should use WP_Site_Query. This is almost ready and should also close #33185, #24833, and #21837. Soon after an effective patch can be written for #26580. Available search columns in WP_Site_Query will remain as domain and path. Once everything is in, an assessment can be made on the usefulness of searching custom columns on the wp_blogs table.
    • #35791, WP_Site_Query has a patch that will go in before the above so that search columns are available. Most of the functions mentioned in the ticket description have been updated to use get_sites(). New tickets should be created for the replacement elsewhere in core.
    • #36935 implements lazy-loading of site details in WP_Site and will go a long way towards the—possibly silent—deprecation of get_blog_details() in core. It implements a new global cache key (site_details) that will help clear up some of the issues that come with the blog-details cache key. Once this is in, get_blog_details() can be replaced almost everywhere. See #37102 for that progress.
    • #36717 is still in temporary limbo. The private blog_id and site_id properties will likely need to be made public again, but there remains a sliver of hope that this can be worked around inside get_blog_details() for the time being. If it’s still in for beta, it will mostly be for testing.
    • #32504WP_Network_Query still has 2 weeks before beta. A patch and tests are already there, so there’s a high chance it can go in this week.

    If you aren’t available during the weekly multisite office hours, feel free to leave a comment here or in #core-multisite with a ticket number you’d like to see discussed.

    See you next week!

     
  • Jeremy Felt 4:50 pm on June 8, 2016 Permalink |
    Tags: , ,   

    Multisite Office Hours Recap (June 7, 2016) 

    Multisite office hours are held every Tuesday at 16:00 UTC in #core-multisite. The next will be Tuesday 16:00 UTC. A more casual bug scrub is on Thursday 20:00 UTC.

    The weekly agenda for the 4.6 cycle is to (a) address blockers and share status on bigger initiatives, then (b) walk through a few multisite focused tickets on Trac.

    Today’s chat log

    Attendees: @iamfriendly, @ipstenu, @spacedmonkey, @flixos90, @paaljoachim, @jeremyfelt

    Tickets Covered

    • #35791, WP_Site_Query, is almost complete. It’s open as a task to help track any issues, but can probably be closed as fixed soon. Specific implementation can be handled in other tickets.
    • #36675, implementing WP_Site_Query in WP_MS_List_Table, is the biggest remaining piece at the moment. Patches are getting closer and will likely solve a handful of tickets when done—#33185, #24833, and #21837.
    • #36994 was committed after office hours and wp_get_sites() is now deprecated. It wraps the new get_sites() instead.
    • #32504, WP_Network_Query is still possible for 4.6. There’s a patch and tests. @jeremyfelt will review this week.
    • #36717 adds magic methods so that WP_Site and WP_Network have nicely named properties. It was committed after office hours and broke the routing of sites on w.org. 🔥 It has been reopened for further exploration. See comment 20 on the ticket for more information. @flixos90 has already been looking at the issue and how #36935 can help.
    • #37050 was opened because it would be nice if id was an int on WP_Network. The concern with this is that anything doing a strict comparison on a numeric string would break. Feedback please. 👋
    • #33900 introduces get_current_network_id() and is close to commit. @jeremyfelt will likely get that in today.
    • #18088 and #35379 are still on deck. @jeremyfelt owes reviews.

    If you aren’t available during the weekly multisite office hours, feel free to leave a comment here or in #core-multisite with a ticket number you’d like to see discussed.

    See you next week!

     
  • Jeremy Felt 4:33 pm on May 25, 2016 Permalink |
    Tags: , ,   

    Multisite Office Hours Recap (May 23, 2016) 

    Multisite office hours are held every Tuesday at 16:00 UTC in #core-multisite. The next will be Tuesday 16:00 UTC. A more casual bug scrub is on Thursday 20:00 UTC.

    The weekly agenda for the 4.6 cycle is to (a) address blockers and share status on bigger initiatives, then (b) walk through a few multisite focused tickets on Trac.

    Today’s chat log

    Attendees: @flixos90, @DrewAPicture, @richardtape, @ipstenu, @jeremyfelt

    Tickets Covered

    • The commit for #34941 landed. This ticket will stay open for a bit to track any issues that come up and any new tests that are written. A dev note will be needed to describe the changes and hopeful lack of impact.
    • WP_Site_Query is now in core as part of #35791. There is still some work to do to implement get_sites() as a wrapper for queries and apply it throughout core, but we’re moving along. @jeremyfelt is going to work on getting that in shortly.
    • Once get_sites() is in, a ticket should be created to deprecate wp_get_sites() as it will no longer be useful.
    • #36935 was opened to lazy load details on WP_Site objects. This could allow for the deprecation of get_blog_details() in the future. For inspiration see #15458, which did something similar for user meta. @flixos90 has a patch up already.
    • #36717 introduces getters and issetters to WP_Site and WP_Network so that we can use better named properties for ID, network_id, etc… The topic of naming should be discussed in the core meeting first so that we can settle on id vs ID or something else.
    • #35379 and #18088 cover the differences in option sanitization between site and network options. There are good patches on both. @jeremyfelt will take a closer look this week.

    If you aren’t available during the weekly multisite office hours, feel free to leave a comment here or in #core-multisite with a ticket number you’d like to see discussed.

    See you next week!

     
  • Jeremy Felt 7:47 pm on May 18, 2016 Permalink |
    Tags: , ,   

    Multisite Office Hours Recap (May 17, 2016) 

    Multisite office hours are held every Tuesday at 16:00 UTC in #core-multisite. The next will be Tuesday 16:00 UTC. A more casual bug scrub is on Thursday 20:00 UTC.

    The weekly agenda for the 4.6 cycle is to (a) address blockers and share status on bigger initiatives, then (b) walk through a few multisite focused tickets on Trac.

    Today’s chat log

    Attendees: @iamfriendly, @flixos90, @nerrad, @ericlewis, @ocean90, @jeremyfelt

    Tickets Covered

    • #35791, WP_Site_Query() is still in progress. Most (all?) of what’s left is assigned to @jeremyfelt. @iamfriendly is going to try things out in their staging environment. @ocean90 may put portions on wp.org. More testing is always welcome. Hoping to have the first patches for this in within a day or two.
    • #34941, which wraps the multisite bootstrap process into ms_load_current_site_and_network is also getting closer. @ocean90 tested it on wp.org and nothing exploded, so the ticket is okay to move forward.
    • #17904, managing user login character restrictions in single and multisite, has an updated patch and tests and needs feedback. @ericlewis has been working on moving that along. @jeremyfelt left feedback. Other eyes always welcome.

    It was quiet. See you next week!

     
c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel
Skip to toolbar