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

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