One of the objectives for multisite is to determine how sites can be managed with the REST API. This has been an agenda item for the last two weeks and quite a bit has been processed. This will continue to be a topic, so please stop in for #core-multisite office hours on Tuesday 17:00 UTC and please leave your feedback in the comments on this post.
January 17 chat log and January 24 chat log in #core-multisite
Attendees: @kenshino, @vizkr, @danhgilmore, @iamfriendly, @flixos90, @schlessera, @sergeybiryukov, @pbearne, @paaljoachim, @streetlamp, @jnylen0, @loreleiaurora, @maximeculea
The requirements for the
/sites/ endpoint can be summed up with these assertions:
/sites/ endpoint should provide a useful set of data for each site without requiring the use of
- It should be possible to query
/sites/ for something other than ID, domain, and path.
In its current state, any
/sites/ endpoint is limited to the fields in the
wp_blogs table. Data such as a site’s name and description are stored in each individual site’s
Given a list of 20 sites,
switch_to_blog() will be used 20 times so that
get_option() can be used to retrieve things like
blogdescription. An example of how inefficient this is can be found in the generation of the My Sites menu. Caching has gotten better with the introduction of
WP_Site_Query, but there is an opportunity to change how the information is stored.
In #37923, @johnjamesjacoby suggests the introduction of a
wp_blogmeta table that provides access to some site information in a common table. After discussing this in the January 17 chat, @iamfriendly and @flixos90 agreed to each take a look at core’s default options stored in
wp_options and determine which made sense in a shared
wp_blogmeta table. Richard’s results can be found in a comment on the ticket and Felix’s in the Slack discussion.
After some discussion in the January 24 chat, that list can be pared down a bit more.
The creation of a new table,
wp_blogmeta, and migration of data for each site from
wp_#_options is something that needs feedback. Without this change, a
/sites/ endpoint is still possible, but may be limited. With the change, a
/sites/ endpoint is much more useful, but requires a careful migration process.