Multisite Recap for the week of November 13th

Office Hours Recap

The agenda for this office hours meeting was to discuss adopting Trello as a way to manage status, progress, and ownership on tasks, as well as progress on multisite roadmap with a target to publish an initial version before WCUS.

The meeting’s chat log

Attendees: @desrosj, @flixos90, @jeremyfelt, @spacedmonkey, @vizkr

Chat Summary:

  • The full roadmap draft should be in place by November 21st, in order for the document to be published a week later, on November 28th, so that it is out before WordCamp US. @flixos90 and @jeremyfelt will have another look to complete the remaining sections.
  • After discussing possible usage of Trello in a collaborative way, the conclusion was that what is missing the most is an easy-to-use UI to manage required tasks and assignees for tickets on Trac. However most of the functionality is already in place and could be used through workarounds, so the decision was made not to use Trello for now. Instead the goal is to be more precise with defining tasks when assigning a ticket and generally assign tickets around between the responsible parties for a part of it more deliberately, instead of having a single owner through most of a ticket’s lifecycle. In a perfect world, there would be more possibilities to choose from when assigning a ticket to somebody, such as “update patch” or “write unit tests”, but for now these tasks can also be determined in regular comment text.

Next meeting

The next office hours will take place on November 21th, 2017, 17:00 UTC. Its agenda will be to review the roadmap draft and then discuss #42252.

Ticket Scrub Recap

No ticket scrub took place this week.

Next meeting

The next ticket scrub will take place on November 20th, 2017, 18:00 UTC. Its agenda will be to determine the current state and required tasks of tickets scheduled for 5.0 and assign them accordingly.

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!

#multisite, #networks-sites, #summary

Multisite Focused Changes in 4.9

Here’s an overview of the developer facing changes made in multisite for the 4.9 cycle. If you’re interested in more detail, checkout the full list of tickets.

clean_blog_cache() replaces refresh_blog_details()

Since 3.5, refresh_blog_details(), which accepts a site ID, has been a wrapper of the clean_blog_cache() function, which requires a site object.

In WordPress 4.9, clean_blog_cache() has been adjusted to also accept a site ID and to invalidate caches for a deleted site in the same way. From now on clean_blog_cache() should be used instead of refresh_blog_details() which will be deprecated in a future release.

More importantly, the refresh_blog_details action has been deprecated in favor of the clean_site_cache action. See #40201.

New function get_main_site_id()

The WP_Network class has historically contained a $blog_id property indicating the ID of the main site of that network. However, since this property was never part of the wp_site database table, it is set manually in the multisite bootstrapping process. This results in it only being set for the current network. For any other network, code like get_network( $id )->blog_id would return 0.

The new get_main_site_id() function introduced in 4.9 provides the site ID of any network in an easy way. The function accepts an optional $network_id parameter, which defaults to the current network. Furthermore the magic property logic in WP_Network has been adjusted so that the $blog_id property (and its magic $site_id equivalent) is automatically set when requested. This ensures get_network( $id )->blog_id will always return a meaningful value. See #29684.

Refactored user capability and role switching

Switching the available roles and the current user’s capabilities no longer happens in switch_to_blog() and restore_current_blog(). Instead it has been moved to a new function, wp_switch_roles_and_user(), which is hooked into the site switching process. This provides a performance improvement by temporarily unhooking the function in cases where roles and capabilities do not need to be switched.

In addition, the available user roles are now correctly switched when switching sites, with refactored behavior in the WP_User and WP_Roles classes making this possible. These changes are more closely explained in the 4.9 post about role and capability improvements. For related tickets, see #36961 and #38645.

Site administrators can edit user roles through the REST API

While site administrators cannot edit user details in multisite, they are able to modify a user’s roles. In WordPress 4.9 this can now be achieved through the REST API by making a request such as PUT wp/v2/users/<id> and passing only the roles argument in the request body. No other arguments must be given as those would require the current user to have network administrator capabilities. See #40263.

Other Notes

  • The new can_add_user_to_blog filter can be used to prevent a user from adding specific users to a site or with a specific role. See #41101.
  • The old site network admin email address gets notified of a change to the address. See related security improvements for 4.9 and #39117.

#4-9, #dev-notes, #multisite, #networks-sites

Multisite Recap for the week of October 9th

Office Hours Recap

The agenda for this office hours meeting was to review 4.9 bug and task tickets that still need to be finished and merged within Beta, particularly continuing from where the ticket scrub meeting stopped.

The meeting’s chat log

Attendees: @earnjam, @flixos90, @jeremyfelt, @jjj, @johnbillion, @josheby, @spacedmonkey, @stevenkword

Chat Summary:

  • #41936: It was decided that the new filter pre_get_main_site_id should not actually set the WP_Network::$blog_id property when used and only override the return value when accessing it, as it could otherwise have unexpected consequences if a hook set for it was (temporarily) removed. The latest patch had one issue where a variable had not been correctly renamed after moving the code from the function to the class method. It was furthermore discussed how verbose and strict casting the value returned by a filter should be. It was decided to only return the filter value if 0 < (int) $value. Both issues have since been fixed in the latest patch.
  • #38570 and #41652: @sergey is taking care of these i18n tickets.
  • #41789: @johnbillion will provide feedback.
  • As there is now a 5.0 milestone on Trac, the priority tickets that were previously flagged with “Future Release” and “early” are now being moved into the actual milestone.
  • #40364: @flixos90 asked for feedback for this rather complex ticket, as it should preferably get ready early in the 5.0 cycle. That ticket should be discussed in detail in one of the next few weeks, once the multisite work for 4.9 has wrapped up.

Next meeting

The next office hours will take place on October 17th, 2017, 16:00 UTC. Its agenda will be to continue discussing 4.9 tickets and the dev-note for the Networks & Sites component.

Ticket Scrub Recap

The agenda for this ticket scrub was to review 4.9 bug and task tickets that still need to be finished and merged within Beta, similar to the office hours meeting agenda this week (see above).

The meeting’s chat log

Attendees: @afercia, @flixos90, @jeremyfelt, @jjj, @paaljoachim, @spacedmonkey

Chat Summary:

  • #41936: It was decided that moving the logic that is currently in get_main_site_id() is okay to be moved to WP_Network:get_main_site_id(), since that data is very specific to each individual network. It must furthermore be ensured that all values are properly typecast into the expected type (WP_Network::$blog_id is a string, WP_Network::$site_id is an integer and WP_Network::get_main_site_id() should always return an integer). Minor tweaks suggested were returning get_current_blog_id() instead of a hardcoded value of 1 in get_main_site_id() for non-multisite environments and using an internal variable for the cache key used. @spacedmonkey and @flixos90 will make sure this gets ready.
  • #42093: @jeremyfelt has been working on providing an easy way to run unit tests for a subdomain install. This ticket is currently a task scheduled for 4.9, but may as well be punted to 5.0 in case it does not get ready in time.
  • #39419: It was agreed on that the doc block for the globals should indicate replacements to use for those that are deprecated. @jeremyfelt has since updated the patch. It is still being considered whether globals such as $table_prefix, which are used there, but not actually set up there initially should be listed as well.
  • #41789: It was briefly discussed how to be most precise about the documentation of the get_sites() (and related WP_Site_Query method) return value, without making the description overly complex. @jeremyfelt added the final idea as a comment on the ticket and is now waiting for feedback. It was also mentioned that documentation for the other query classes should probably be changed in a similar way, however the ticket for now should only deal with sites and networks.

Next meeting

The next ticket scrub will take place on October 16th, 2017, 17:00 UTC. Its agenda will be to continue discussing 4.9 tickets, particularly the issue that came up with #40228.

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

Multisite Recap for the week of September 25th

Office Hours Recap

No office hours meeting took place this week.

Next meeting

The next office hours will take place on October 3rd, 2017, 16:00 UTC. Its agenda will be to get the 4.9 enhancements ready to be merged before Beta, and then coordinate remaining work on 4.9 bug tickets.

Ticket Scrub Recap

The agenda for this ticket scrub was to look through the multisite tickets without a response.

The meeting’s chat log

Attendees: @afragen, @flixos90, @schlessera, @spacedmonkey

Chat Summary:

  • The issue with the suggestion in #41443 is that wpmu_validate_blog_signup() is supposed to validate new sites submitted by regular users, not by administrators, so that function would not be applicable for usage on the New Site network admin page. However, some restrictions for new user-submitted sites do not apply to admin-created sites, so these restrictions should be reviewed and possibly adjusted to work more similarly to each other.
  • #41685 is a very early ticket, since it requires the site meta API and related blogmeta database table in order to be worked on. It was agreed on that it would generally make sense to store site database versions in the new table instead of an entirely separate table. However, since these versions are not used anywhere in core and since it is questionable whether the blog_versions table can be removed for backward-compatibility reasons, this still needs a deeper discussion once site meta is actually part of core.
  • #41936 was figured out to be a minor bug with the new get_main_site_id() not taking the possibly already set WP_Network::$blog_id property into account. This should definitely be fixed for 4.9. The current patch by @spacedmonkey moves the logic from the function to the WP_Network class method, which is not preferable, but might end up being the only way to accomplish the goal without running into an infinite loop issue. @flixos90 will try to find a better way to fix the issue, but if nobody finds one, the current patch is solid enough to go in. This can happen last minute though, as this will be a bug-fix and does not need to be merged before beta.

Next meeting

The next ticket scrub will take place on October 2nd, 2017, 17:00 UTC. Its agenda will be reviewing the 4.9 enhancements and coordinating who works on the possibly required changes so that another review can happen during the office hours a day later.

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

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

Multisite Agenda for the week of September 11th

Office Hours Agenda

This is the agenda for the weekly office hours meeting on September 12th, 2017, 16:00 UTC in #core-multisite.

  • Further discuss the approach on #29684, particularly the following questions:
    • Is get_main_site_id() useful enough on its own to merge it into core as a first step?
    • Is storing the main site ID in a network option worth it? How much do the network meta efforts (particularly #37181) affect this decision?
  • Plan further 4.9 organization as Beta 1 is getting closer.

Ticket Scrub Agenda

This is the agenda for the weekly ticket scrub meeting on September 11th, 2017, 17:00 UTC in #core-multisite.

  • Discuss and review one or two of the 4.9 tickets in more detail, depending on the interest of the meeting’s attendees.

Please join the chat if you’re interested in one of the topics. In case you cannot make the respective meeting, we will be working on publishing a recap post afterwards. If you have some thoughts beforehand or would like something related to be part of the agenda, feel free to share your ideas in the comments for this post. See you in the chat!

#4-9, #agenda, #multsite, #networks-sites

Multisite Agenda for the week of August 28th

Office Hours Agenda

This is the agenda for the weekly office hours meeting on Tuesday 16:00 UTC in #core-multisite.

  • Review progress on roadmap and related discussion.
  • Figure out how to check for existence of the wp_blogs database table for site meta (see #37923). This was discussed last week, but there is still some arguing in the ticket.
  • Open floor if there is time left.

Ticket Scrub Agenda

This is the agenda for the weekly ticket scrub meeting on Monday 17:00 UTC in #core-multisite.

  • Review progress on 4.9 tickets.
  • Open floor for any multisite-related bugs and small enhancements.

Please join the chat if you’re interested in one of the topics. In case you cannot make the respective meeting, we will be working on publishing a recap post afterwards. If you have some thoughts beforehand or would like something related to be part of the agenda, feel free to share your ideas in the comments for this post. See you in the chat!

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

Multisite Recap for the week of August 21st

Office Hours Recap

The agenda for this office hours meeting was to brainstorm about finding a solid way to check for the existence of the blogmeta database table for site meta (see #37923).

The meeting’s chat log

Attendees: @dac, @flixos90, @jeremyfelt, @johnbillion, @pmbaldha, @spacedmonkey, @vizkr

Chat Summary:

  • There is no global storage in WordPress, but the blogmeta table exists in global context, therefore we can’t reliably check whether the table exists based on the db_version setting of the current network. We need to find a way to cache this value somewhat globally and work around the limitation.
  • A network option site_meta_supported should be used to store the result of the direct database check. It should only be available on the main network to simulate the one central access point as if the setting was global.
  • A dedicated function is_site_meta_supported() should be developed to check whether the blogmeta table exists in global context or not.
  • The option site_meta_supported should not be set on every network, to prevent unnecessary clutter and to make possible future migration easy.
  • The function is_site_meta_supported() should check a specific filter first. If the filter returns something other than null, the function should return that result immediately. Otherwise it should check the main network’s site_meta_supported option. If that is not set yet, the function should run a direct database query to check for the table existence and populate the main network option accordingly.
  • The upgrade_network() function should set the main network option based on a direct database check.
  • The site meta ticket is getting closer to commit. It should be ready once the suggested changes are in place (see #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 look at the tickets #40764 and #41344.

The meeting’s chat log

Attendees: @afragen, @desrosj, @ina2n, @pmbaldha

Chat Summary:

  • In multisite, theme updates do not show the new version number. The patch to fix this bug is looking good. There was only some coding standard error (see #40764).
  • Secure Email Integration with SMTP: It was decided that the ticket is plugin territory due to the huge variety of mechanisms and services for sending mail (see #41344).

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

Multisite Agenda for the week of August 21st

Office Hours Agenda

This is the agenda for the weekly office hours meeting on Tuesday 16:00 UTC in #core-multisite.

  • Review progress on roadmap and related discussion.
  • Brainstorm about finding a solid way to check for the existence of the wp_blogs database table for site meta (see #37923).
  • Open floor regarding roadmap, related tickets and suggestions.

Ticket Scrub Agenda

This is the agenda for the weekly ticket scrub meeting on Monday 17:00 UTC in #core-multisite. Note that neither @jeremyfelt nor @flixos90 are available for that meeting, so we are looking for someone to host this one. Please ping one of us on Slack if you’re interested, help is much appreciated. If you want to attend the meeting, please check #core-multisite on Monday to see whether the meeting will take place or has been cancelled. Here is the planned agenda:

  • Review and discuss #41344.
  • Review and discuss #40764.
  • Open floor for any multisite-related bugs and small enhancements.

Please join the chat if you’re interested in one of the topics. In case you cannot make the respective meeting, we will be working on publishing a recap post afterwards. If you have some thoughts beforehand or would like something related to be part of the agenda, feel free to share your ideas in the comments for this post. See you in the chat!

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

Multisite Recap for the week of August 14th

Office Hours Recap

The agenda for this office hours meeting was to discuss the format of the multisite roadmap that will be compiled from many of our recent conversations.

The meeting’s chat log

Attendees: @desrosj, @flixos90, @spacedmonkey, @vizkr, @jeremyfelt

Chat Summary:

  • An initial multisite roadmap document has been started. If anyone would like access to edit, please ping @jeremyfelt on Slack.
  • The previous multisite roadmap (2013) was verbose. @jeremyfelt mentioned that it provided the thought process behind a lot of things that were going to become decisions at some point.
  • That the previous roadmap was posted on make/core and then lost in the timeline makes discoverability difficult.
  • There should be a specific URL where the roadmap can be published and evolve over time. Additional (verbose) updates on progress or new initiatives can be posted as posts on make/core and then linked from the roadmap as needed.
  • During the weekly core dev chat, we’ll propose a make.wordpress.org/core/roadmap/ structure under which make.wordpress.org/core/roadmap/multisite/ can exist as well as pages for other components or focuses.
  • It’s also possible we can follow the customizer component’s lead and publish under https://make.wordpress.org/core/components/networks-sites/. Note that this only covers one component rather than the focus.
  • A ticket should be created for everything we plan so that people can help when available.
  • @flixos90 is going to spend some time working on the roadmap document some more to get it closer to the format that we’ve been discussing.

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 discuss approaches for better clarifying site statuses, and then have an open floor for further tickets.

The meeting’s chat log

Attendees: @flixos90, @sergey, @ina2n, @afragen, @pmbaldha, @paaljoachim, @desrosj, @spacedmonkey, @jeremyfelt

Chat Summary:

  • #17164 – More elegant handling of site ‘archive’ options for Multisite
  • #39158 – Unify site deactivation process
  • #15801 – Network Admin: Deactivated / Deleted inconsistency
  • These 3 tickets are all related in some way, though deal with different issues around site statuses.
  • The checkboxes at wp-admin/network/site-info.php don’t convey any real information about their meaning or a workflow.
  • Different terms are used in the MS sites list table for network admins (deactivate) and in the site admin (delete).
  • Different error messages are displayed on the front end when a site is archived or deactivated. There should be better documentation for what these mean in the screen help.
  • @flixos90 – “Deactivating should be called deactivating everywhere”, “we should only use the term Delete when it really is delete”
  • It seems that #39158 is a ticket about workflow and unification of deactivate/delete. #15801 is a ticket about terminology.
  • Priorities via @flixos90:
    • change Deleted to Deactivated where it’s not actually Deleted
    • Figure out what all these actions do exactly.
    • Document what these actions do
  • We need to support these workflows in the sites endpoint.
  • #40736 – Ensure that get_blog_count() and get_user_count() return an integer. Specifically—Can the return type be safely changed without issue and/or should we deprecate get_blog_count() in favor of get_site_count(). We aren’t too worried about changing the return type as this function doesn’t appear to be used much outside of core.
  • #41344 – Secure Email Integration. We agreed to look at this ticket next week.
  • #40764 – Multisite theme update not showing new version number. This ticket came up right at the end and can be covered next week.

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