Multisite Recap for the week of July 23rd

Office Hours Recap

There was no agenda post this week. This week’s chat was a continuation of last week’s. The conclusion last week was: more discussion around specific items that will be in the roadmap is needed in order to construct an effective roadmap.

The first item to be discussed (and the topic for this week’s office hours) was network meta.

Meeting’s chat log

Attendees: @desrosj, @flixos90, @jeremyfelt, @johnbillion, @maximeculea, @mista-flo, @spacedmonkey, @stevenkword

Chat Summary:

Discussed in the meeting were current pain points and limitations in network options that network meta (the replacement) would help address:

  • Autoloading network options is very poor. Only a predefined list of core options are autoloaded and cached properly. Any other code utilizing network options without object caching causes additional queries.
  • Network options are a siloed area of Core that only multisite developers utilize. This prevents growth, and sometimes allows long lasting bugs.

Also discussed were other benefits of introducing network meta:

  • The Meta API is used by many other areas of Core and has many more developers using it. It is a very solid foundation. Using it means network meta will receive any improvements to the Meta API with a trivial amount to no effort.
  • Allows networks to be queried with a meta_query(see #38025).
  • Allows *_network_options to utilize the metadata API (see #37181).
  • WP-CLI already uses the Meta API for network options.
  • Converting network options to meta makes everything much cleaner and easier to maintain.
  • Network meta opens the door for networks in the REST API, allowing them to be consistent with other meta endpoints.

Some things to keep in mind:

  • A good list of goals that summarizes previous discussions.
  • If network and network meta REST API endpoints are merged into utilized by Core, they should give developers the tools needed to manage networks, but be un-opinionated (custom plugins and code like WP Multi Network are for opinionated).
  • There are likely not many people utilizing *_network_option(). Of those uses, it’s more likely that it’s to manage core network options. If they use it to manage custom network options, then it should be single only.
  • Meta query is closely connected to meta and should be rather trivial to implement.

The suggested workflow moving forward:

  • Reopen #37181 (for network meta API inside of the network options API).
  • Open a ticket for a networks endpoint.
  • Open a ticket for a network meta endpoint.
  • Add site meta endpoint to #40365 (to be discussed in a future office hours meeting).
  • Add all of these tickets to the ms-roadmap keyword.
  • The first thing needed would be #25344Introduce *_network_meta() functions

Problems that were solved and other important thoughts:

  • Network options are always $key => $value while network meta would be $key => $values (multiple ones). So there could be conflicts if people misuse it. However this was considered a negligible issue that can easily be prevented by properly educating developers about the changes in a dev-note. The internal usage of the Meta API in the *_network_option() functions will be implemented in a way that prevents this.
  • When/if network meta is implemented, it should be clarified that existing core options will always be treated as single.
  • get_network_option() should always return the first value, if multiple values exist for it (which should not happen per the above).
  • Migrating network options should be the last step (#37181 – Use metadata api in *_network_options will be reopened for keeping those concerns separate).

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 tickets targeted during this ticket scrub were tickets in the 4.9 milestone with multisite focus or the Networks and Sites component.

The meeting’s chat log

Attendees: @earnjam, @euthelup, @flixos90, @jeremyfelt, @sergey, @spacedmonkey,

Chat Summary:

  • The meeting ended up being a discussion entirely dedicated to #29684 and the get_main_site_id() function it will introduce.
  • There are two patches on it both of which have advantages and disadvantages. A combination of both will be best (see below).
  • The function should rely on the multisite constants if they are set.
  • Instead of relying on the cache, a network option main_site should be introduced for this data. This will allow relying on that option and only run the more complex query logic in case it is not set. Furthermore, it allows more custom things by letting developers filter the option. When creating a new network, the option should be set from the beginning on, while for existing networks it should be set as needed.
  • The function should only use the domain and path-based comparison if no main site value has been stored and no such constants are set.
  • The existing cache key, although not necessary any longer, should probably be preserved for backward-compatibility.
  • @flixos90 is going to create a new patch which @jeremyfelt will then 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