You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Sep 24, 2018. It is now read-only.
Repository navigation
This repository was archived by the owner on Sep 24, 2018. It is now read-only.
Ensure consistent contexts across controllers #1845
Most endpoints default to context=view, but GET /wp/v2/users/<id> defaults to embed: 2d4cdbc
Some endpoints only have view, the meta endpoint only has edit, and other endpoints have edit.
For a client trying to making requests, these inconsistencies are really confusing. We should make sure we have consistent default contexts across controllers, and each controller supports similar context names.
joehoyle [7:08 AM] hmm
[7:08] why is labels not part of the view context?
[7:09] for example, I'd want the search_items label it build view-only UI
danielbachhuber [7:10 AM] core doesn't expose search_items on the frontend
[7:10] historically, our distinction between view and edit is backend and frontend
joehoyle [7:10 AM] I thought it was "I want to get this data to perform an edit on it"
[7:10] that's how I've always thought about it anyway
[7:11] I'd expect a read-only admin user to be able to _see_ everything using context=view
danielbachhuber [7:12 AM] well, I suppose this is yet another problem with the context abstraction
[7:12] meta only has edit context
joehoyle [7:12 AM] interesting
[7:12] I don't know what that is. to me, context=edit implies authorization(edited)
danielbachhuber [7:14 AM] that is true, and in this pull request context=edit requires authorization
joehoyle [7:19 AM] so, for taxonomy labels, I don't think there's a private data issue, i think it should be in view
[7:19] infact, context=edit doesn't make any sense for taxonomies, as you can't edit them
[7:19] IMO
danielbachhuber [7:21 AM] ok. pretty sure that's different than how we've been operating
joehoyle [7:22 AM] hmm yeah sounds like we need to get on the same page with that context means - do we have docs written for it?
danielbachhuber [7:22 AM] nope
context=edit doesn't make any sense for taxonomies
I don't know that'd I'd agree with this necessarily; edit is just the context you're in right now, i.e. an editor. It doesn't necessarily mean you're editing that item.
I'd expect that editor contexts (i.e. desktop/mobile admin clients) would always send context=edit with requests, and that view contexts (i.e. the site, or mobile applications which view the data) would always send context=view (i.e. default).
Activity
danielbachhuber commentedon Dec 11, 2015
I put together a little script to audit our contexts: https://gist.github.com/danielbachhuber/cdc34b82b4a2815fb718
As of #1838, here's the result:
danielbachhuber commentedon Dec 15, 2015
@joehoyle and I discussed #1864 some:
rmccue commentedon Dec 17, 2015
I don't know that'd I'd agree with this necessarily;
editis just the context you're in right now, i.e. an editor. It doesn't necessarily mean you're editing that item.I'd expect that editor contexts (i.e. desktop/mobile admin clients) would always send
context=editwith requests, and that view contexts (i.e. the site, or mobile applications which view the data) would always sendcontext=view(i.e. default).danielbachhuber commentedon Jan 30, 2016
danielbachhuber commentedon Jan 30, 2016
Need to introduce
embed,view, orediton the contexts that don't have them.danielbachhuber commentedon Feb 4, 2016
So close!