Support Multisite network-wide activation about wp-api

[rachelbaker]

I agree with @danielbachhuber that to make the best decision here we should list the pro/cons.

My current use-case is:
I am currently working with the WP-API plugin on a 30+ site multisite network. Ideally, I would like to "network enable" the WP-API functionality. Reasons being:

• The WP-API brings a whole new (and I might say BETTER way) of displaying and updating content data across sites in a Multisite environment.
• WordPress Multisite feels like the forgotten wicked step-child that never gets the love and attention given to the first-born WordPress core.
• I am lazy and don't want to have to activate the plugin on a per-site basis (that is what network activation is for).
• The plugin will automatically be enabled when new sites are added.
• I can keep the plugin "hidden" from the per-site plugin list, so a single site admin won't accidentally disable it.

I would love to hear how others are using or planning on using this plugin, and the cons against allowing the WP-API functionality to be network enabled.

[rmccue]

So, the question is, do we want a per-site API, or one for the whole network? I'm inclined to lean towards the latter, similar to how WP.com uses public-api.wordpress.com for all the sites. Once we have #40, it's then cheap and easy to point to the correct one.

[danielbachhuber]

You'll want to do a detailed list of the pros and cons for each approach. In my opinion, the biggest failing of the WPcom API is that it doesn't load the context of whatever blog the request is for. No custom endpoints, etc etc. It basically makes the API a non-starter for anyone who wants to hack on top of it

The advantage of a single endpoint for all blogs is for third-party services that don't want to deal with connecting to a bunch of domains.

[rmccue]

You'll want to do a detailed list of the pros and cons for each approach. In my opinion, the biggest failing of the WPcom API is that it doesn't load the context of whatever blog the request is for. No custom endpoints, etc etc. It basically makes the API a non-starter for anyone who wants to hack on top of it

The current multisite plugin uses switch_to_blog(), so it should be able to offer per-site custom endpoints. (The multisite plugin needs love, incidentally.)

The advantage of a single endpoint for all blogs is for third-party services that don't want to deal with connecting to a bunch of domains.

We're going to need that anyway, but #40 should make connecting easy. This is more about making it easier for network admins to manage, since bringing them altogether means that they can be centrally controlled easier. Whether this is really an issue or not, I don't know.

[danielbachhuber]

The current multisite plugin uses switch_to_blog(), so it should be able to offer per-site custom endpoints.

Sure, but switch_to_blog() doesn't load a plugin that Site B is running when the requests are proxied through Site A. It's fairly common to have a plugin (or theme) running on one site, but not another.

[jeremyfelt]

Registering an un-grokked opinion here. I'd be happier using a per site API rather than one attached to the primary site on a network (or primary network on a multi-network setup).

[rmccue]

@rachelbaker Is there anything else you'd like to add here? I noticed that in #49, you didn't say it fixed this issue, so left this open for now. :)

FWIW, after more indepth use of multisite recently, I'm +1 on per-site. Per-network is cool, but that's something that'll only be needed in specialised cases, from what I can see.

[rachelbaker]

@rmccue Let's close this issue for now, if there is anything else I would like to add I will open a new issue.

[jlambe]

Hi, not sure if this has been answered, but I'm also more on per-site API regarding multisite.