WordPress.org

Make WordPress Core

Tagged: multisite Toggle Comment Threads | Keyboard Shortcuts

  • Felix Arntz 11:22 am on January 11, 2017 Permalink |
    Tags: multisite, , ,   

    Controlling access to REST API user functionality for multisite 

    Following last week’s discussion in #core-multisite (read the recap) this week’s office hours agenda was to continue the chat about the multisite-related enhancements for the REST API users endpoint, focussing heavily on how to access the required functionality. Here is a wrap-up of the discussion.

    Chat log in #core-multisite

    Attendees: @jeremyfelt, @jnylen, @nerrad, @ipstenu, @earnjam, @kenshino, @maximeculea, @mikelking, @lukecavanagh, @flixos90

    Now that the way on how one should be able to modify user roles per site was clarified last week, this week the focus laid on where one should be able to perform those actions. The current state of the wp-json/wp/v2/users endpoint in multisite is:

    • The users overview accessible with a GET request to wp-json/wp/v2/users only lists users that are part of the current site.
    • When creating a user with a POST request to wp-json/wp/v2/users, that user is created and added to the current site. When providing the roles parameter, the passed roles are added to the user, otherwise the user will still be part of the site, but without any role. See #38526 for background.
    • It is possible to both read and edit any user from any site with a request to wp-json/wp/v2/users/<id>, regardless of whether the user is part of that site.
    • A DELETE request to wp-json/wp/v2/users/<id> results in an error. See #38962 for background.

    After the discussion about how to be able to add a specific user to a site, update their site capabilities and remove them from a site, this week’s chat revolved around where these actions can be accessed, as they are for the most part network-specific actions not available to a site administrator. The approach that was agreed on is:

    • The users overview at wp-json/wp/v2/users should continue to only show users of that site by default, but a request like wp-json/wp/v2/users?global=true should show all users in the WordPress setup. This parameter must only be available to network administrators though, more specifically users with the manage_network_users capability. In the future a network parameter might also be introduced for support of multi networks, but at this point core does not support querying users per network. Accessing global users should be available from all sites in a setup instead of only from the main site. While this approach makes these endpoints duplicates of each other, it has several benefits like preventing the requirement for cross-domain requests, allowing easier API discovery and not requiring the main site of a setup to be exposed to REST API calls to a sub site.
    • Assigning an existing user to a site and removing a user from a site should generally be only available to network administrators, and the site administrators of the site that is being interacted with.
    • Similarly, editing a user that does not belong to the current site should only be possible for a network administrator. Currently this is available to site administrators as well which is probably wrong.
    • Deleting any user completely should only be available to a network administrator. A good way to handle the reassign parameter needs to be found though.

    Before coming to the conclusion that dealing with multisite functionality at the existing users endpoint, the possibility of introducing a multisite-specific endpoint only available on the main site was discussed. However this was considered not practical due to the nature of how users work in WordPress. Having separate endpoints for other network-wide functionality might still be a possibility though as long as that component solely affects the network admin, so this idea is something to keep in mind for thought about further network functionality endpoints in the future.

    Back to the users endpoint, one related question that came up is:

    • Should the sites a user belongs to be available at the wp-json/wp/v2/users endpoint or at a future wp-json/wp/v2/sites endpoint? If they were available in the wp-json/wp/v2/users endpoint, every user entity would have a new sites key available if the current user had sufficient permissions to see these. If they were available in the wp-json/wp/v2/sites endpoint, that endpoint could easily support this functionality through usage of a user parameter.

    @jeremyfelt suggested to look at the “Add New User” screen in the site admin to have a good use-case for how to scaffold the multisite functionality of the API endpoint. This has helped during this week’s office-hours and can also be beneficial in the future. Eventually this screen should be revamped entirely, being powered by the REST API.

    Regarding the enhancements of the users endpoint, a general ticket for this task was opened at #39544. This ticket is meant to be used for discussion on the topic, while separate smaller tickets should be opened for actually implementing the individual pieces. For now feedback is welcome on that ticket. The discussion on multisite improvements for the REST API will continue at Tuesday 17:00 UTC.

    /cc @rmccue and @kadamwhite

     

     

     
    • James Nylen 6:40 pm on January 11, 2017 Permalink | Log in to Reply

      Excellent writeups and discussion, thanks Felix and everyone else involved.

      > It is possible to both read and edit any user from any site with a request to wp-json/wp/v2/users/, regardless of whether the user is part of that site.

      I think this should require the new `global=true` parameter as well. This is a change we would need to make sooner rather than later, in 4.7.2.

      • Felix Arntz 8:02 pm on January 11, 2017 Permalink | Log in to Reply

        I agree, however I think we should be fine by prohibiting access to users that are not part of the site as that would be the fix for the current bug. Adding the `global` parameter can happen in 4.8 IMO, as we only start supporting multisite behavior there in general.

  • Jeremy Felt 8:04 pm on January 9, 2017 Permalink |
    Tags: multisite, , ,   

    Improving the REST API users endpoint in multisite 

    One of the objectives for multisite is sorting how users are managed with the REST API. This was one of the agenda items for last week’s #core-multisite office hours and generated some good discussion. Here’s a wrap-up of the ideas and thoughts from that discussion.

    Chat log in #core-multisite

    Attendees: @iamfriendly, @johnjamesjacoby, @nerrad, @florian-tiar, @mikelking, @earnjam, @jeremyfelt

    Users in multisite exist globally and are shared among sites on one or more networks. Users are associated with sites in the user meta table with a wp_#_capabilities key.

    The current state of the wp-json/wp/v2/users endpoint for multisite is:

    • A POST request for a new global user to the main site creates the user and associates them with the main site only.
    • A POST request for a new global user to a sub site creates the user and associates them with the sub site only.
    • A POST request for an existing global user results in an error.
    • A PUT request for an existing global user to a sub site updates the user’s meta with a capability for that sub site.
    • A DELETE request on multisite is invalid and results in an error. See #38962.

    It is not possible to remove a user from an individual site or to delete the user from the network.

    Previous tickets: #38526, #39155, #38962, #39000

    The following are a few thoughts expressed separately from the above summary.

    • The right way to associate existing objects over the REST API is with a PUT request.
    • The right way to disassociate existing objects is with a PUT request.
    • Linked previous discussion – “Deleting an item should always delete an item
    • We already have functions like remove_user_from_blog() and add_user_to_blog() available to us.
    • Does “add” invite or literally add? This can probably be included as data in the PUT request.
    • What happens if an API client is built for single site and then that site gets switched to multisite?
    • Handling bulk actions on an endpoint would be nice. (e.g. Add a user to multiple sites) No endpoint has implemented batch handling yet though.

    Initial tasks:

    • It should be possible to remove a user from a site with a PUT request to the wp-json/wp/v2/users/# endpoint.
    • It should be possible to delete a global user with a DELETE request to the wp-json/wp/v2/users/# endpoint once all sites have been disassociated.

    New tickets will be created soon for these tasks. Please leave any initial feedback in the comments on this post covering the assumptions and conclusions made above. There will be another round of discussion during tomorrow’s #core-multisite office hours at Tuesday 17:00 UTC.

    /cc @rmccue and @kadamwhite

     
    • James Nylen 8:12 pm on January 9, 2017 Permalink | Log in to Reply

      I am assuming that “`PUT` request” is being used as a shorthand to refer to any of `POST/PUT/PATCH` to an existing user. These should be treated equivalently via the `WP_REST_Server::EDITABLE` constant.

    • John James Jacoby 8:22 pm on January 9, 2017 Permalink | Log in to Reply

      👍

    • Darren Ethier (nerrad) 8:33 pm on January 9, 2017 Permalink | Log in to Reply

      One thing that may have been brought up elsewhere, but I don’t think was brought up in the meeting (likely because its something that will happen on further implementation) is whether the schema response for the users endpoint would change in a multisite environment vs single site. For instance, does the `user` resource in a multisite environment include the sites the user belongs to? Is that something that should be exposed? If so, then its something that would need to go into the schema as well.

      • John James Jacoby 12:11 am on January 10, 2017 Permalink | Log in to Reply

        You’re right that this is an implementation detail. My hunch is not as part of the default user response (which probably has higher value as something that doesn’t have too many variants) but it would be useful to have a dedicated endpoint to get the sites of a User – that way the response can more easily be setup behind its own capability check.

    • Brainy 12:30 am on January 10, 2017 Permalink | Log in to Reply

      I may miss something (the wp-api.org documentation doesn’t tell me at least), but I think it would be great if there would be a way to list users sites via rest api as well since the current way of looping get_blogs_of_users is very, very slow.

    • Knut Sparhell 1:55 am on January 10, 2017 Permalink | Log in to Reply

      I think there should be a network level (endpoint) where users of a multisite may be removed from all sites in a network, or actually deleted if only one network. Then a top (installation) level endpoint for actually deleting users in a multi-network. When a removed or deleted user is the only/last user of it’s primary site, then maybe also mark the site as deleted.

    • Ryan McCue 2:28 am on January 10, 2017 Permalink | Log in to Reply

      Definitely want to see better API support for multisite. To that effect, @jnylen0 has volunteered to be the multisite API coordinator, so you’ll have a permanent point of contact. Obviously, the rest of the team is also always around. 🙂

      • James Nylen 2:30 am on January 10, 2017 Permalink | Log in to Reply

        s/volunteered/been volunteered/ 😉

        I’m happy to help, though, and it makes a lot of sense for me to be involved with this: I’m also responsible for the WP REST API integration on WordPress.com, the largest multisite installation in the world.

  • Felix Arntz 5:27 am on December 14, 2016 Permalink |
    Tags: , multisite,   

    Multisite Office Hours Recap (December 13, 2016) 

    Multisite office hours are held every Tuesday at 17:00 UTC in #core-multisite. The next will be Tuesday 17:00 UTC.

    The weekly agenda was to discuss long-term goals for multisite and prioritize tickets to work on related to one of the three new focuses, particularly the REST API.

    Today’s chat log

    Attendees: @iamfriendly, @mista-flo, @johnjamesjacoby, @loreleiaurora, @johnbillion, @jeremyfelt, @flixos90

    Chat Summary:

    • @jeremyfelt, @flixos90, @johnjamesjacoby, and @johnbillion sat down for a chat at WCUS to discuss multisite topics and possible future focuses. @jeremyfelt shared his notes from that session. Items of particular interest in today’s chat were:
      • Identify statistics for multisite usage, size of multisites: Possibly sending more general multisite-related metrics during core updates could be helpful and should be further discussed. In addition to whether multisite is enabled and the count of sites (on the main network) it could be helpful for future decisions to know how many sites there are in total, how many networks exist and whether user / site registration is open or not.
      • Implementation of network user roles: A ticket is in place at #39174. @flixos90 requested feedback: Everyone interested is asked to read through the ticket description and provide an elaborate response with how they think network roles should work. Then a discussion based on these approaches can start.
      • Network administrators should be able to enable themes on the site level: It is currently not very convenient for a network administrator to switch back to the network admin to enable a theme when currently working within the site admin.
      • Disable plugins per site in the network admin: Sometimes not all plugins should be visible on all networks or all sites, which is currently not possible. However, even for a disabled theme a network administrator should still be able to “silently” activate it on a site. Plugins would need to be enabled by default, so it would be the opposite way of how themes are currently handled. This also ensures there are no concerns with backward-compatibility. UI-wise an improved flow should be investigated instead of simply pursuing a similar approach to how enabling themes works: Having all the functionality inside the Network > Plugins screen would be helpful, with row and bulk actions for “Network Disable” as well as “Disable for Site…” with the latter having some kind of popover with an autocomplete field for sites. A related ticket to take into account for the implementation is #38652 which @johnbillion opened to introduce singular capabilities for managing plugins.
      • Whichever flow is agreed on for disabling plugins per site or network, once this functionality is implemented, it will probably make sense to “back-port” the behavior to improve the existing theme and maybe even user handling in a multisite.
    • At this point, the highest priority is multisite support for the REST API.
      • The users endpoint should be improved, particularly the implementation of DELETE for a user on a multisite as well as removing a user from a site or setting their capabilities per site via PUT (see #39000 and #38962 for related tickets).
      • A sites endpoint should be added.
      • A networks endpoint is not as important and should for now only live in a standalone plugin if there is interest to implement it.
    • A general question raised was how No-JS fallbacks for REST API functionality in the admin should be handled. Should JavaScript become a requirement to use such new functionality or should the REST API only be used to improve existing PHP-only features? These questions should be discussed in a broader scope than just multisite since they affect all of WP Admin.
    • Possible usage for a REST API sites endpoint:
      • Replacing “My Sites” in the toolbar with a menu that doesn’t load until needed and pulls all sites from the API.
      • The possible autocomplete field for disabling plugins for a specific site (see above) could pull sites from the API.
    • @mista-flo brought up #13743 and asked for feedback. Everyone in the chat agreed that the ability to set a default theme for a network would be a valuable enhancement over the existing constant. For the approach, introducing a new row action “Set default theme” the Network > Themes list table was suggested, alongside an indicator “Default Theme” in that same table. This is an enhancement that can be worked on beside the other important REST API features.
    • A Google document was opened a while ago to gather input for a future multisite roadmap, as a follow-up to 2013’s post. @jeremyfelt highlighted that this document should continue to move forward in order to hopefully be able to publish an actual roadmap in early January.
     
  • Jeremy Felt 11:11 pm on November 4, 2016 Permalink |
    Tags: , , multisite,   

    Multisite Focused Changes in 4.7 

    Howdy. The 4.7 release cycle has been a chance to build on some of the work from the last couple releases in multisite.  If you’d like more detail, check out the full list of multisite focused changes in this release.

    get_blog_details() replaced with get_site()

    A lot of progress has been made over the last few releases to get things in place for this transition. Now that WP_Site and WP_Network objects exist and are accessible with functions like get_site() and get_network(), they can be implemented throughout core.

    In WordPress 4.7, get_blog_details() was replaced throughout core code with the modern  get_site(). The roadmap for this includes deprecating get_blog_details() in WordPress 4.8, so take this cycle as a chance to move your code in that direction.

    get_site() is often a direct replacement, though get_sites() can also be used to query for sites when an ID is not available.

    See #37102 for details on this change.

    blog_details filter deprecated

    In combination with the decision to stop using get_blog_details() throughout core, the (not widely used) blog_details filter has been deprecated. It has been added to get_site() to provide backward compatibility with the above change and will fire with a deprecation notice. Plugin code should use the site_details filter instead. See #38491 for details on this change.

    _network_option actions and filters get $network_id

    The $network_id associated with the use of a _network_option() function is now passed to the filters and actions that fire within. This provides granular control that was not available when first introduced. See #38319, #38320, #38321, and #38322 for details on this change.

    wp_get_network() deprecated

    It is now recommended that get_network() is used instead. See #37553 for this change.

     

     

     
    • Brian Layman 11:39 pm on November 4, 2016 Permalink | Log in to Reply

      I’ve not used the function in years, but I believe that with one use case I had for get_blog_details(), I would pass in the domain and the path in the fields array. IIRC I used this when importing posts from a custom built blogging network into WordPress.
      Strictly out of curiosity, is that still possible now that it accepts a wp_site object? Do you create a new object and just fill out the known properties? or is this a use case not supported with get_site?

      • Felix Arntz 8:25 am on November 5, 2016 Permalink | Log in to Reply

        The WP_Site_Query class or its wrapper function get_sites() introduced in 4.6 should be used as a replacement for your use-case. It allows much more flexible arguments than get_blog_details() in general.

  • Felix Arntz 12:23 pm on September 21, 2016 Permalink
    Tags: , , multisite   

    Upcoming Multisite Bug Scrubs 

    After the initial multisite bug scrub in the 4.7 release cycle last week, we will continue going through the list of bug tickets this week on Thursday 20:00 UTC, in #core-multisite as usual. The respective report was about bug tickets with the multisite focus that were opened within the last year. We have 8 tickets to go for that report, so we should be able to finish it this week.

    After that, we will continue having regular multisite bug scrubs that are held every Thursday at 20:00 UTC, then focussing on multisite tickets milestoned for the 4.7 release.

    If you aren’t available during the weekly multisite bug scrubs, feel free to leave a comment here or in #core-multisite if you have other tickets you’d like to see covered.

    See you then!

     
    • Mikel King 7:46 pm on September 27, 2016 Permalink | Log in to Reply

      Wonder why we don’t use a public google calendar (or other iCalnedar based system) to keep track of these meetings?

      For the most part the iCalendar system would keep track of the timezone adjustments and make coordination of multiple meetings easier.

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

    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).

    • tazo todua 5:13 pm on September 1, 2016 Permalink | Log in to Reply

      get_site() doesnt contains these values, what we should do ?

      `public ‘blogname’ => string ”`
      `public ‘siteurl’ => string ‘http://127.0.0.1/mysub’`
      `public ‘post_count’ => boolean false`
      `public ‘home’ => string ‘http://127.0.0.1/mysub’`

      • Jeremy Felt 5:35 pm on September 1, 2016 Permalink | Log in to Reply

        @tazo todua The `WP_Site` object returned by `get_site()` should lazy load those properties once they are requested.

        • tazo todua 8:39 am on September 2, 2016 Permalink | Log in to Reply

          can you explain what’s lazy-load means? I called `get_site(3)` and it returned the values correclty (like `get_blog_details()`), but the above properties were missing.

          • Jeremy Felt 4:18 pm on September 2, 2016 Permalink | Log in to Reply

            Of course! Sorry for the bad description. 🙂

            If you do something like `$site = get_site( 3 ); var_dump( $site );`, you’ll get a WP_Site object that has default properties, but none of those listed in your first comment. As soon as you request one of those properties, say via `$site->post_count;`, then they will populate.

            This saves some processing until the properties are actually needed.

            • tazo todua 5:16 pm on September 2, 2016 Permalink

              thanks! now i understand.

            • tazo todua 5:18 pm on September 2, 2016 Permalink

              what is the way, to know, what lazy-load properties does any OBJECT has? how to predict what properties may be available?

              (thanks for your answers to my questions, that will be helpful to many others like me).

  • Felix Arntz 9:28 pm on July 6, 2016 Permalink
    Tags: , multisite,   

    Multisite Office Hours Recap (July 5, 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: @spacedmonkey, @ocean90, @paaljoachim, @richardtape, @flixos90

    Tickets Covered

    • #20537 seems possible, but needs an updated patch. @jrf left a note after office hours that she is going to work on it Friday.
    • #26855 is likely to be punted due to a lack of recent activity. However, @spacedmonkey would like to work on a patch there, so there is still a chance this could land.
    • #18088 has an updated patch by @flixos90 which needs some testing. @spacedmonkey will try to review it.
    • #35379 still lacks a decision which approach to take. Considering there might possibly be major changes in handling network options coming up (see #37181), more time is required to think about the best way to tackle this bug. The ticket got punted to a future release.
    • #37223 is a rather straightforward fix, but will need an updated patch. @flixos90 is going to leave a comment there to ask the author of the patch for an update.
    • #36954 is being reviewed by @jeremyfelt and is likely to be merged.
    • #37102 will, although being a straightforward change, not make it into 4.6 as the first beta has already been released. Furthermore the function get_blog_details() has not been deprecated yet, so the ticket is not necessary to complete at this point.

    Other Notes

    • The 4.6 dev note for the Networks & Sites component should get ready on Wednesday. A Google doc will be used for collaboration.

    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 6:51 pm on June 15, 2016 Permalink
    Tags: , multisite,   

    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,   

    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,   

    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!

     
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