Multisite Recap for the week of July 31st

Office Hours Recap

The agenda for this office hours meeting included the discussion of a “global” state for multisite.

The meeting’s chat log

Attendees: @desrosj, @flixos90, @paaljoachim, @johnbillion, @feshin, @spacedmonkey, @stephdau, @jeremyfelt

Chat Summary:

  • In the multisite context, “global” is the hierarchy level above networks. A global installation of WordPress has one or more networks. Each of these networks has one or more sites.
  • Users are global in that wp_users provides the same set of users used across all sites on all networks. There is no concept of a global role other than super admin. Another level could be created so that a global admin controls all networks and network admins control individual networks.
  • Two important pieces of this discussion are global storage, data about the configuration of the whole, and global roles, data about global users’ relationships with sites.
  • Items that fit under global storage could be a total user count, a total site count, a network count, globally active plugins, globally enabled themes, update checks.
  • @jeremyfelt showed a custom UI for activating and deactivating global plugins. @flixos90 mentioned his global admin plugin as a UI example. It seems like these are good examples of how core can provide APIs to make interfaces easier to build. We should not necessarily be focused on trying to build the UI.
  • There are two options for storing global data — as network ID 0 in wp_sitemeta or as a new global table. After some discussion it seems that using network ID 0 is the best answer. As part of an effort to use the meta API for managing network meta (see #37181), the API will need to be updated to support an object ID of 0. It may be that this is only necessary for network meta, but it’s possible other components could find it useful.
  • The current plan is to implement global multisite storage in wp_sitemeta with a network ID of 0. This is relatively low priority compared to other efforts, but implementation itself will not be too involved. A lot of testing for breakage must be done. As @stephdau mentions, “we all know how much room there is for error with 0 values in data”. 🙂

The next office hours will take place on Tuesday 16:00 UTC. An agenda for it will be posted in advance.

Ticket Scrub Recap

The agenda for this ticket scrub was to continue reviewing multisite tickets assigned to the 4.9 milestone.

The meeting’s chat log

Attendees: @desrosj, @drewapicture, @flixos90, @florian-tiar, @jmdodd, @sergey, @spacedmonkey

Chat Summary:

  • A third opinion would be appreciated regarding the discussion around #29684 about whether to store the main site of a network in a network option. @spacedmonkey argues that it would provide an easier lookup, while @flixos90 argues that it would be redundant and unreliable because of existing sites not having it and the new get_main_site_id() would be just as easy-to-use.
  • @sergey is going to review #41285 to come to a conclusion whether removing the unused $site_id and $public globals in the multisite bootstrap process would have any bad side effects.
  • #38645 and #36961 are closely related as they both deal with switching context, the first for roles, the latter for user capabilities. Their methods and properties used for that should be similar, for a better DUX. @spacedmonkey pointed out that eventually the new blogmeta table would be helpful with this, however that shouldn’t be the focus of these tickets. At the point of this writing, @flixos90 has updated patches on these that require a review.

The next ticket scrub will take place on Monday 17:00 UTC. An agenda for it will be posted in advance.

If you were unable to attend one of these meetings but have feedback, please share your thoughts in the comments on this post. In case there’s a need for further discussion we will ensure to make time for it in one of next week’s chats. See you next week!

#4-9, #multisite, #networks-sites, #summary