One of the objectives for multisite 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 is to determine how sites can be managed with the REST 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/.. 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 Core is the set of software required to run WordPress. The Core Development Team builds WordPress.’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 Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. 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.