Multisite Recap for the Week of August 28th

Office Hours Recap

The agenda for this office hours meeting was to take a look at progress on the multisite roadmap and to continue discussing the best approach to checking for the existence of a wp_blogmeta database table (See #37923).

The meeting’s chat log

Attendees: @flixos90, @desrosj, @stephdau, @dac, @johnbillion, @spacedmonkey, @jeremyfelt

Chat Summary:

  • During the core dev chat, everyone was open to the roadmap being published at make.wordpress.org/core/roadmaps/multisite. The REST API team is also interested in posting a roadmap under that structure.
  • Quite a bit of progress has been made by @flixos90 so far on the multisite roadmap document.
  • A good way to contribute to the roadmap now is to read through critically and make comments/suggestions on the direction and content.
  • Everyone is free to make changes/comments. Ping @jeremyfelt if you would like access.
  • @johnbillion is going to add some items related to multisite administration.
  • More needs to be built out around multisite’s bootstrap and the future of “global context” above the level of network.
  • There was some discussion on what an objective on the roadmap for multisite’s bootstrap may be. Everyone seems to agree that “increasing stability and testability” of the bootstrap is a good objective.
  • There should be a general section at the end that covers some things that don’t necessarily fit as part of the main roadmap at this time. That can be considered “a summary to encourage discussion/contribution even if what you want isn’t on the roadmap.”
  • Quite a bit of ground was covered on #37923 as to whether the existence of a wp_blogmeta table (after upgrade) should be stored as a main network option, as an option on every network, or in a new place entirely.
  • @spacedmonkey brought up concerns about the performance issues of loading an option from a different network. During multisite’s bootstrap, all of the current network’s options are loaded into memory. Storing in a single place would result in an extra DB query/cache lookup.
  • @flixos90 and @jeremyfelt prefer (so far) storing the data as an option on the main network. The idea that a global setting storage may exist one day makes it tempting to treat this data as global now.
  • A next step is to lookup more possible “global context” data that could be stored. @spacedmonkey brought up global terms and ms-files as two immediate options. Brainstorming should continue via chat and on the ticket (#37923).

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 review 4.9 ticket progress.

The meeting’s chat log

Attendees: @flixos90, @desrosj, @sergey, @paaljoachim, @jeremyfelt, @spacedmonkey

Chat Summary:

  • #29684 – Had a lengthy discussion on the possibilities of this ticket. Chatted through whether a networks main site ID should be stored as a network option. For the time being, let’s stick with not storing the data anywhere.

There will be no ticket scrub Monday 17:00 UTC. A schedule and agenda for the next ticket scrub will be posted next week.

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, #network-sites, #summary