Additional site properties for multisite

[frankiejarrett]

New properties

When we are on a multisite install it would be good to expose additional properties for the site endpoint that can be fetched from the blogs table via get_blog_details().

• id
• network_id
• domain
• path
• registered
• last_updated
• attributes (public, archived, spam, deleted, mature) - possibly private?
• upload_space_quota - private
• post_count - private
• user_count - private

Property name changes

Multisite allows you to have not only multiple sites, but multiple networks of sites. However, the traditional name for a network is site, and the traditional name for a site is blog. Yay.

Since we are dubbing this REST endpoint as site it might be confusing to use the traditional site_id and blog_id names when we are in a multisite install.

I think we should consider renaming the site_id property to network_id and blog_id to id (since this endpoint is already in the site scope).

Additionally, I think we should rename the blog_upload_space property to upload_space_quota.

[frankiejarrett]

@rmccue @danielbachhuber Would we want to include this data too, or should there be a multisite-specific endpoint later to account for multiple networks? e.g. /network/1/site/1

[danielbachhuber]

Would we want to include this data too, or should there be a multisite-specific endpoint later to account for multiple networks?

I'd think the latter. @jeremyfelt?

[jeremyfelt]

I think we should consider renaming the site_id property to network_id and blog_id to id (since this endpoint is already in the site scope).

Definitely. This gives us a chance to stay sane with naming.

Would we want to include this data too, or should there be a multisite-specific endpoint later to account for multiple networks? e.g. /network/1/site/1

I thing a network endpoint makes sense. Not only for multiple networks but to manage the network level settings in a single network setup.

The site endpoint should provide its network_id though.

[rmccue]

Would we want to include this data too, or should there be a multisite-specific endpoint later to account for multiple networks? e.g. /network/1/site/1

I'd have /network/{id} and /site/{id} completely separate, as you can reassign sites to different networks. This means we can also enhance the API with the endpoints as they're needed; i.e. only have /site/{id} for multisite, and only have /network/{id} for multinetwork; as @jeremyfelt mentions though, we may want to have these around all the time, specifically for stuff like sitemeta/network options.

network_id should just be network; no need for the suffix if it's clear what the number means.

I'd also only offer these endpoints on the primary site (and the network endpoints only on the primary network) personally.

[felixarntz]

network_id should just be network; no need for the suffix if it's clear what the number means

I'm not sure about this. It would be clear what it means, but I would assume that a field called network would actually contain a "sub-object" for the network. Also by using network_id we'd have parity with the class naming.

I'd also only offer these endpoints on the primary site (and the network endpoints only on the primary network) personally.

+1, this certainly makes sense. It might be useful however to be able to find out from any site where to find the primary site.