Office Hours Recap
The agenda for this office hours meeting included the discussion of a “global” state for multisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site.
The meeting’s chat log
Attendees: @desrosj, @flixos90, @paaljoachim, @johnbillion, @feshin, @spacedmonkey, @stephdau, @jeremyfelt
- 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 (and super admin). Another level could be created so that a global admin controls all networks and network (versus site, blog) 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 User interface 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 Core is the set of software required to run WordPress. The Core Development Team builds WordPress. 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 An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. will need to be updated to support an object ID of
0. It may be that this is only necessary for network meta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress., 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 Created for both bug reports and feature development on the bug tracker. 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
- 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
$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!