Multisite Recap for the week of September 11th

Office Hours Recap

The agenda for this office hours meeting was to resolve the remaining discussion and blockers for #29684, the proposed get_main_site_id() function and related integration.

The meeting’s chat log

Attendees: @afragen, @desrosj, @flixos90, @jeremyfelt, @johnjamesjacoby, @spacedmonkey

Chat Summary:

  • The main purpose this function could serve initially is to auto-fill the $blog_id property of the WP_Network class, which currently is only being populated for the current network in the bootstrap process. There is no database field for the main site of a network, therefore custom logic must run for it to be set. get_main_site_id() makes it easy to detect the main site for a network, and magic getters in WP_Network would allow to automatically set the property once it is first accessed, using the new function. In the end of the discussion it was decided that the logic to auto-fill the property makes sense and can be merged with the new function.
  • It was also discussed whether a network option should be used to store the main site ID. This would bring a performance benefit for multisite setups without an object cache and without the network constants enabled. On the other hand, the main site ID at this point is not really an option, since many areas of WordPress assume it is always the site whose domain and path match the network’s ones. Getting rid of this restriction is something that could be evaluated more closely in the future, but for now this restriction exists, and introducing a network option would give the impression that it would be possible to change the main site ID without any issues. Therefore it was decided to not use a network option at this point, but it can be reconsidered later in a separate ticket.
  • Another topic was whether the actual logic should go into the get_main_site_id() function or whether the function is not required at all and instead the logic should be part of WP_Network. Eventually it was agreed to go with the regular function and call it from WP_Network. Moving the logic into a private WP_Network method would not align well with existing core patterns, where pretty much everything relies on a function. As long as there is no methodological approach for this, functions should remain the source as it currently is.
  • Naming of the new function was discussed as well. It was suggested to call the function get_main_site_id_for_network() or get_network_main_site_id() to be more precise. On the other hand, is_main_site() already exists and would have been called similarly in order to align with the new function. Furthermore the function is available for non-multisites, making the extra network affix a bit more confusing. It was decided to proceed with the current idea of get_main_site_id().
  • All remaining items were solved and as of now the patch has been merged into core.

Next meeting

The next office hours will take place on September 19, 2017, 16:00 UTC. Its agenda will be to further plan 4.9 work and which tickets should receive the main focus in the few remaining weeks until Beta 1.

Ticket Scrub Recap

The agenda for this ticket scrub was to review and discuss some multisite tickets in the 4.9 milestone.

The meeting’s chat log

Attendees: @afragen, @desrosj, @flixos90, @jeremyfelt, @sergey, @vizkr

Chat Summary:

  • The first ticket discussed was #40764: @afragen asked for feedback. @flixos90 verified that the latest patch applies cleanly. @desrosj plans to review the patch itself soon.
  • #41285 was discussed: @jeremyfelt was asked for feedback and responded that he is confident that this change can happen, at least for the $public global. He will dive deeper into whether the $site_id global is safe to remove as well. He furthermore stated that the related tickets #34217 and #39419 should be considered as well. A response from Automatticians working on wordpress.com would be much appreciated.
  • #40364 was the last ticket for the meeting: The proposed action hook names used in the new functions wp_insert_site(), wp_update_site() and wp_delete_site() using the same names were questioned and whether it may be more useful to use more precise names using past tense, such as wp_inserted_site(), so that it is clear they run after the database transaction. It was also considered to run multiple actions. Eventually it was decided to go with the simple approach for now, and stick with one action having the function name. Regarding timing, while the latest patch may possibly be merged at this point, it should rather wait until #41333 has also been completed, to have the full new site API in core in one release. The latter ticket is something that can be worked on during the 4.9 beta, to aim for an early 5.0 merge.

Next meeting

The next ticket scrub will take place on September 18, 2017, 17:00 UTC. Its agenda will be to review multisite bug tickets awaiting review with a focus on recently opened tickets.

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