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

Multisite Agenda for the week of August 14th

Office Hours Agenda

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

  • Discuss about the format for the multisite roadmap. We have the content ready to be written now. What should it look like, how verbose should it be, where should it be published?
  • 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.

  • Discuss approaches for better clarifying the different site statuses and solving inconsistencies (see #17164).
  • 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 7th

Office Hours Recap

The agenda for this office hours meeting was to discuss whether a function to retrieve a site by specific details should be introduced as a successor to the legacy-bloated get_blog_details().

The meeting’s chat log

Attendees: @desrosj, @drewapicture, @earnjam, @flixos90, @jeremyfelt, @jmdodd, @spacedmonkey, @stephdau, @stevenkword

Chat Summary:

  • It was decided that the get_site_by() function proposed in #40180 should be introduced. It might need to get a more suitable name though. While it can work similar as other existing functions like get_term_by(), a significant difference is that it can also accept an array of multiple fields to query by, which makes the name a bit confusing.
  • Some examples of how get_site_by() can be used:
    • get_site_by( 'id', 2 )
    • get_site_by( 'slug', 'subsite1' )
    • get_site_by( array( 'domain' => 'mainsite.com', 'path' => '/subsite1/' ) )
    • get_site_by( 'domain', 'subsite1.mainsite.com' ) (only works in a subdomain install)
  • In addition to the above, a lookup by path only, when in a subdirectory network, should be supported as well, but isn’t in the latest patch.
  • In the documentation it should be clarified that, when multiple results are found which can theoretically happen, the first result will be returned.
  • get_blog_details() will wrap the new function, and apply some tweaks to remain backward-compatible.
  • After the discussion, it was time for an open floor:
    • The *_blog_details() functions were further discussed in regard of a possible deprecation. They are still widely used, so that should probably not happen any time soon. It was however decided that, once the changes in #40364, #40180, #40228 and #40201 have been completed, a new ticket should be opened to further discuss the path towards deprecating get_blog_details(), update_blog_details() and refresh_blog_details(), all of which will be unnecessary at that point.
    • The new site CRUD functions from #40364 should only be merged once the wrapping functions that handle both the wp_blogs table as well as setting up the individual site tables are ready as well. It should be clarified that the CRUD functions do not actually set up the site’s database tables and should not be used on its own in most cases.
    • @drewapicture brought up #25650, which deals with a rather critical bug that has been around for a while: When switching to another site in multisite, the media base URLs still point to the original site. @flixos90 proposed a get_content_url( $blog_id = null, $path = '' ) function that could help with this. @drewapicture will have a closer look at the ticket.
  • All planned discussions for the multisite roadmap have been completed now, so @jeremyfelt and @flixos90 will be focussing on elaborating the results into a proper format over the next couple days and weeks.

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 finish reviewing multisite tickets assigned to the 4.9 milestone, and then have an open floor for further tickets.

The meeting’s chat log

Attendees: @desrosj, @flixos90, @jeremyfelt, @mista-flo, @sergey, @spacedmonkey, @vizkr

Chat Summary:

  • A third opinion for #29684 was requested as the discussion there needs further input to proceed.
  • #36961 (a bug where initializing user capabilities for another than the current site fails) and #38645 (which aims at improving role switching) need reviews. They are kind of related as they both deal with site switching. @flixos90 has patches up that revamp the switching process for both to bring them in line with each other and improve some unnecessary legacy bloat. While they do more than switching the original bug, without these changes the bug could only be fixed in a quite hacky way. @jeremyfelt will review these proposals.
  • @spacedmonkey is working on patches for the site meta related tickets #37923 and #40229. He has also worked on network meta code and will update all these tickets soon.
  • @flixos90 has a patch up for #40364, which will provide the foundation for the planned wp/v2/sites endpoint for the REST API by implementing a full CRUD API for sites. A particular focus for the new functions was to only deal with the wp_blogs table and have all connected functionality be handled by hooks. @jeremyfelt has since reviewed the ticket and patch and left a comment.
  • #40764 and #41538 are both being reviewed by @swissspidy.
  • #41538 is a straightforward fix, but should wait until #39677 has been merged to account for the new capability.
  • Open floor:
    • @spacedmonkey brought up #41507 as part of a few tickets to improve the understanding of the multisite codebase. The ticket was milestoned and has since been committed.
    • In relation to function replacements, @flixos90 brought up replacing the *_site_option() and *_network_option() calls once the *_network_meta() functions are in core. In the discussion it was decided that the network meta functions cannot be a direct replacement for the network option functions, as meta functions have always required passing an ID and should continue to do so. They can still replace them in several areas, however a solution needs to be found for the hooks that the *_network_option() functions trigger, but the *_network_meta() functions wouldn’t.
    • @jeremyfelt pointed out #41520 in the above discussion, as WordPress never removes deprecated functions. It would be helpful if a setup could take care of that manually by setting a specific constant preventing deprecated functions from being loaded.
    • @spacedmonkey asked for feedback on #41510. The ticket has been milestoned and committed as of now.

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 7th

Office Hours Agenda

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

  • Discuss whether we are going to introduce a new function get_site_by() as an improved replacement for get_blog_details() (see #40180), or whether we’re going to stick with simply improving get_blog_details() itself (see #40228).
  • If the decision is to introduce get_site_by(), we need to discuss whether the current patch is good or which changes it requires.

Ticket Scrub Agenda

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

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 July 31st

Office Hours Recap

The agenda for this office hours meeting included the discussion of a “global” state for multisite.

The meeting’s chat log

Attendees: @desrosj, @flixos90, @paaljoachim, @johnbillion, @feshin, @spacedmonkey, @stephdau, @jeremyfelt

Chat Summary:

  • 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. Another level could be created so that a global admin controls all networks and network 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 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 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 will need to be updated to support an object ID of 0. It may be that this is only necessary for network meta, 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 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

Chat Summary:

  • 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 $site_id and $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!

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

Multisite Agenda for the week of July 31st

Office Hours Agenda

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

  • Discuss global state in multisite. In this scope, “global state” means what goes beyond network scope. In a regular multisite network, network state mostly equals global state, however in a multinetwork setup, global state is a higher level in the hierarchy.
  • The goal is to figure out how far our efforts for core should go to improve support for this, and what exactly should be part of these efforts.

Ticket Scrub Agenda

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

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 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

Multisite Recap for the week of July 17th

Office Hours Recap

The agenda for this office hours meeting was to review the current state of the multisite roadmap and plan out how to complete it for publishing as an official document on the make blog.

The meeting’s chat log

Attendees: @desrosj, @earnjam, @feshin, @flixos90, @jeremyfelt, @jmdodd, @johnbillion, @maximeculea, @spacedmonkey, @stephdau, @stevenkword

Chat Summary:

  • @jeremyfelt shared a link to the draft roadmap document for review.
    • @desrosj suggested using the Taxonomy roadmap posts an example
    • We agreed that the roadmap should be broken up into specific sections for REST API, Internal APIs, and Implementation, with each of those sections having their own users, sites, and networks areas.
    • We will also need a section of the document dedicated to “bootstrap” or file organization and load order. See #40647, #40948, #29684, #40646
  • The first priority should be the REST and Internal APIs. Once those are in better shape, they can be used to make improvements to the multisite UX/UI and we can focus on the different network admin screens that need attention.
  • Because networks are managed in widely varying ways, the primary goal of multisite should be to provide standardized data structures and low-level database APIs to support a range of network and multi-network implementations through plugins and custom code. The roadmap should reflect this philosophy.
  • We will need to discuss the “global” state (data spanning multiple networks) and make decisions on what should be implemented there. Right now users are the only global data, but even things like number of users are stored per-network and not globally.
  • Before getting too detailed on the actual roadmap document, we will spend the next few office hours meetings discussing specific items that will go into and affect the direction of the roadmap, including network meta, global state, and some Internal API decisions (See #40180 and #40228)

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 continue going through the list of multisite-related good-first-bug tickets for new contributors, review their status, and adjust keywords as necessary.

The meeting’s chat log

Attendees: @earnjam, @euthelup, @flixos90, @greatislander, @maximeculea

Chat Summary:

  • #40363Remove current_blog_ cache invalidation from clean_blog_cache()
    • Waiting for feedback from @jjj and @jeremyfelt over possible backward compatibility concerns with removing these
  • #41163: Display active theme name on Sites screen
    • This could make use of a wp_blogmeta table if it gets implemented, but in current form would require switch_to_blog() calls for each row in the list table.
    • Related to #40268
    • good-first-bug keyword removed since it will require further discussion across multiple tickets.
  • #41168: Identify the active theme when editing a site’s themes
    • Discussion revolved around disabling ability to disable the active theme to protect users from not being able to switch back after changing the theme.
    • Because of a possible inconsistency with network-enabled themes and a common paradigm of deprecating old themes by disabling them, the agreed upon suggestion was to only apply a label for the active theme and not change the enable/disable functionality.
  • #41166: .htaccess config should not be shown on network setup screen when Nginx is in use
    • Existing patch is in good shape, but needs minor update to use $is_nginx global
    • Suggested updates to the codex for subdirectory/subdomain configuration
  • #41169: Inaccurate descriptive text when adding a new site
    • Slight verbiage change to patch suggested.
    • Patch has since been committed and ticket closed.

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