Tag Archives: multisite

Felix Arntz 2:40 pm on August 12, 2017
Tags: , multisite, ,   

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 networknetwork (versus site, blog), should be supported as well, but isn’t in the latest patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing..
  • 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 ticketticket Created for both bug reports and feature development on the bug tracker. 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 CRUDCRUD Create, read, update and delete, the four basic functions of storing data. (More on Wikipedia.) 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 bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. that has been around for a while: When switching to another site in multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site, 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 metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. 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 APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. by implementing a full CRUD APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. 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 hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same.. @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 coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. 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

Felix Arntz 4:07 pm on August 7, 2017
Tags: , , multisite,   

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 patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. is good or which changes it requires.

Ticketticket Created for both bug reports and feature development on the bug tracker. Scrub Agenda

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

  • Continue the task of reviewing the list of multisite tickets in the 4.9 milestone and checking where each ticket stands.
  • Open floor for any multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site-related tickets.

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

Jeremy Felt 4:00 pm on August 7, 2017
Tags: , multisite, ,   

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 multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site.

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 adminadmin (and super admin). Another level could be created so that a global admin controls all networks and networknetwork (versus site, blog) 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 UIUI User interface 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 coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. 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 APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. will need to be updated to support an object ID of 0. It may be that this is only necessary for network metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress., 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.

Ticketticket Created for both bug reports and feature development on the bug tracker. 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

Felix Arntz 7:56 am on July 29, 2017
Tags: , , multisite,   

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 multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site. In this scope, “global state” means what goes beyond networknetwork (versus site, blog) 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 coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. should go to improve support for this, and what exactly should be part of these efforts.

Ticketticket Created for both bug reports and feature development on the bug tracker. 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

Jonathan Desrosiers 7:42 am on July 29, 2017
Tags: , multisite, ,   

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 networknetwork (versus site, blog) metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress..

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 coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. 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 multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site developers utilize. This prevents growth, and sometimes allows long lasting bugs.

Also discussed were other benefits of introducing network meta:

  • The Meta APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. 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-CLIWP-CLI WP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/ https://make.wordpress.org/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 APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/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 ticketticket Created for both bug reports and feature development on the bug tracker. 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 #25344 – Introduce *_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 filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. 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 patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. 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

William Earnhardt 1:06 am on July 19, 2017
Tags: , multisite, ,   

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 multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site roadmap and plan out how to complete it for publishing as an official document on the make blogblog (versus network, site).

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 TaxonomyTaxonomy A taxonomy is a way to group things together. In WordPress, some common taxonomies are category, link, tag, or post format. https://codex.wordpress.org/Taxonomies#Default_Taxonomies. roadmap posts an example
    • We agreed that the roadmap should be broken up into specific sections for REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/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 UXUX User experience/UIUI User interface and we can focus on the different networknetwork (versus site, blog) adminadmin (and super 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 metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress., global state, and some Internal APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. 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.

Ticketticket Created for both bug reports and feature development on the bug tracker. 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:

  • #40363: Remove 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 NginxNGINX NGINX is open source software for web serving, reverse proxying, caching, load balancing, media streaming, and more. It started out as a web server designed for maximum performance and stability. In addition to its HTTP server capabilities, NGINX can also function as a proxy server for email (IMAP, POP3, and SMTP) and a reverse proxy and load balancer for HTTP, TCP, and UDP servers. https://www.nginx.com/. is in use
    • Existing patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. 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

Felix Arntz 1:30 pm on July 17, 2017
Tags: , , multisite,   

Multisite Agenda for the week of July 17th

Office Hours Agenda

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

  • Review the current state of the multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site roadmap and discuss the next steps to get it ready as an official document that we can publish on the make blogblog (versus network, site).
  • We especially need to define the scope of the roadmap. This includes looking at which work areas of multisite belong into it. For these areas we will need to either have the major decisions already made or plan respective meetings to come to a conclusion.

Ticketticket Created for both bug reports and feature development on the bug tracker. 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

Steven Word 8:26 am on July 17, 2017
Tags: , multisite, ,   

Multisite Recap for the week of July 10th

Office Hours Recap

The agenda for this office hours meeting included a discussion around the introducing a wp_blogmeta table and related *_site_meta() functions to store arbitrary data for sites, particularly as a means to extend the future sites REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. endpoint. See #37923 for the respective ticketticket Created for both bug reports and feature development on the bug tracker..

The meeting’s chat log

Attendees: @dac @earnjam @flixos90 @jeremyfelt @jjj @maximeculea @spacedmonkey @stephdau @stevenkword

Chat Summary:

  • There is a feature plugin available for installing site metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. (the database table is called blogmeta for legacy reasons).
  • A consensus was reached for proposing a new blogmeta table which will be beneficial but not required for the planned REST API sites endpoint.
  • Priority for the 4.9 release will be the introduction of this new table with focus on adding a related meta_query to wp_site_query deferred to a subsequent release. See #40229.

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 go through the multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site good-first-bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. tickets. We worked off of this report with the aim of general gardening, adjusting keywords as necessary and removing good-first-bug keywords for tickets that are overly complex or have been open and without activity for an extended period of time.

The meeting’s chat log

Attendees: @danhgilmore @earnjam @flixos90 @pcarvalho @pmbaldha @stevenkword

Chat Summary:

  • #20537: Don’t spawn cron requests for suspended blogs.
    • We successfully applied the latest patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. and provided a request for user testing.
  • #37799: Add progress indicator to “Upgrade Networknetwork (versus site, blog)” page
    • We successfully applied the latest patch and provided UIUI User interface feedback.
  • #39213: Audit the network pages notices.
    • We successfully applied the latest patch and provided a request for user testing.
  • #39419: Explicitly globalize global variables in ms-settings.php
    • We successfully applied the latest patch and provided a request for documentation.
  • #41167: Remove help text duplication on Site editing screens in network adminadmin (and super admin)
    • We successfully applied the latest patch and provided a request for a refreshed patch that resolved warnings from trailing CRs.

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

Felix Arntz 5:30 pm on July 9, 2017
Tags: , , multisite,   

Multisite Agenda for the week of July 10th

Office Hours Agenda

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

  • Discuss the state of introducing a wp_blogmeta table and related *_site_meta() functions to store arbitrary data for sites, particularly as a means to extend the future sites REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. endpoint. There have been several discussions at WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. Europe, and we should soon come to a conclusion, whether it should be part of coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. or not. See #37923 for the respective ticketticket Created for both bug reports and feature development on the bug tracker..

Ticket Scrub Agenda

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

  • Go through the list of multisite-related good-first-bug tickets for new contributors. The major goal is to look at those tickets, briefly review where they’re at and adjust keywords as necessary. If a ticket appears to be overly complex or has been open and without activity for a longer while, the good-first-bug keyword should be removed.

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

Maxime Culea 10:03 am on July 6, 2017
Tags: , multisite, ,   

Multisite Recap for the week of July 3th

Office Hours Recap

The agenda for this office hours meeting was to focus on the new sites CRUDCRUD Create, read, update and delete, the four basic functions of storing data. (More on Wikipedia.) APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. (not the REST endpoint).

The meeting’s chat log.

Attendees: @flixos90, @jjj, @maximeculea, @schlessera, @spacedmonkey.

Chat Summary:

  • Discussion about sites CRUD API (not the REST endpoint), see #40364. The goal here was to determine how we could refactor the site insertion and installation.
    • We’re planning to implement wp_insert_site()(for adding a row to the wp_blogs table) and wp_install_site() (for installing the site’s DB tables, populating options, etc). Both should be wrapped by a new wp_create_site() which will become a replacement for wpmu_create_blog().
    • Similarly, we will have wp_delete_site() and wp_uninstall_site() wrapped inside wp_remove_site(), which are counterparts of those before. The latter may not be clear enough, so we might need to find a better name. The naming discussion will continue on the ticketticket Created for both bug reports and feature development on the bug tracker., and we’ll provide a summary about all the new functions.
    • About the technical details, a patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. has been posted couple weeks ago. It seems to be a great first pass. However it passes around WP_Site objects which was the result of previous discussions, and there were concerns expressed at WCEU due to inconsistency with similar coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. functions. We therefore decided to use the common “$args pattern” instead for now, but maybe a chat could take place in #core-php at some point especially about consistency and new patterns.

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 through multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site tickets without a response and provide feedback.

The meeting’s chat log.

Attendees: @afragen, @andy, @flixos90, @ipstenu, @jmdodd, @maximeculea, @sergey, @spacedmonkey.

Chat Summary:

  • As we only had two tickets, we gave feedback and asked for more details to the first one, #40459.
  • The second one (see #41177) was more tricky. We had a chat about site deletion which is not triggering an AYS notification. As pointed, this should not be a JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. Driven AYS but more be handled with a separate page which is showing up. A patch has been submitted.
  • In addition, we highlighted a great new feature for multisite development: Thanks to @loreleiaurora, it’s now easily possible to setup VVV development multisites for both subdirectory and subdomain setup.

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