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 office hours are held every Tuesday at 16:00 UTC in #core-multisite. The next will be Tuesday 16:00 UTC.
Creating a useful sites/ endpoint for 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/. and making WP_Site_Query more useful have been frequent topics over the last few weeks in #core-multisite. Quite a bit of discussion has been centered around the idea of a global wp_blogmeta table, whether it’s a good fit for core Core is the set of software required to run WordPress. The Core Development Team builds WordPress., and (if so) how to approach its introduction. See #37923 and the previous make/core post discussing a sites endpoint for additional background.
The intent of this post is to step back a bit and clarify the issues at hand to help identify the right solution(s).
The initial site information problem
A request to a global wp-json/wp/v2/sites/ endpoint on a network (versus site, blog) should return a set of site objects, similar to how wp-json/wp/v2/posts/ returns a set of post objects. A request to wp-json/wp/v2/sites/4 would return a single site object.
Written today each site object, represented as WP_Site in PHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher, would provide at least this data:
- ID
- domain
- path
- registered
- last_updated
- public
- archived
- mature
- spam
- deleted
- lang_id
The above fields all mirror what is available in the global wp_blogs database table installed with multisite. These are useful on their own, but additional data is frequently required.
Example: One piece of the admin (and super admin) that would be great to power with the REST API is the My Sites menu that multisite users see in the toolbar. To build this view, the home URL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org, admin URL, and site name are all necessary. In PHP, this data is made available through magic properties on the WP_Site object. When home, siteurl, blogname, or post_count is requested, the site uses switch_to_blog() and get_option() to populate the data from the individual site’s options table. If 25 sites are on the list, this generates 25 context switches and accesses 25 different tables.
There are at least a few approaches here:
- Mirror the existing PHP experience and ensure properties are populated before the REST API response is returned. Possibly introduce a lighter weight
switch_to_blog() option.
- Provide a basic site object as well as an option to _embed other data in the response.
- Migrate these properties into
wp_blogs from wp_#_options as additional columns.
- Migrate these properties into a global
wp_blogmeta table.
- Migrate these properties into another shared global space.
The querying sites problem
It’s currently possible to query for sites by the default fields listed above. This data is useful for querying, but it would also be nice to query by a site’s name, description, or other piece of data at a global level.
Example: In the list table that displays all the sites of a network, it’s possible to query by a site’s domain or path, but not by it’s actual name. In a large network, a user may find it difficult to find a site when many sites share similar domains or paths. The user may know the site’s title, but not the address itself.
There is no real workaround for this issue in core right now as each site’s name is stored individually in that site’s wp_#_options table and cannot be queried collectively.
Possible approaches:
- Migrate these properties into
wp_blogs() from wp_#_options as additional fields.
- Migrate these properties into a global
wp_blogmeta table.
- Migrate these properties into another shared global space.
Feedback please
Please leave any thoughts you have on possible approaches to these 2 problems. It would be especially helpful to identify some use cases that may not yet be clear, or approaches that are not listed above. All feedback is welcome. 🙂
Untrash<\/a><\/li><\/ul><\/nav>","mentions":[],"mentionContext":"","commentCreated":"1490688023","hasChildren":false,"userLogin":"thisisbrainy","userNicename":"thisisbrainy"},{"type":"comment","id":"32280","postID":"21723","postTitleRaw":"Approaches for a complete sites endpoint and an expanded WP_Site_Query","cssClasses":"comment byuser comment-author-spacedmonkey odd alt thread-odd thread-alt depth-1","parentID":"0","contentRaw":"I thing to mention is that wp_blogmeta table would be extremely useful for developers. Currently many multisite plugins create their own tables, as their is no way to easily store related to the blog object. The blogmeta table could used for domain mapping for example. A datastore to extend the blogs table is massive. As it will use the meta api, you get things like actions \/ filters and caching out of the box. \n\nAnother use of the blogmeta table, would mean we could remove the blogs_version table. Getting rid of a limited use table and replacing it with something great,","contentFiltered":"I thing to mention is that wp_blogmeta table would be extremely useful for developers. Currently many multisite
You must be logged in to post a comment.