Limit the Users response fields in the embed context

[rachelbaker]

Changed the following fields to only display in the view or edit contexts:
- first_name
- last_name
- slug
- nickname

Includes test coverage.

The embed context now only includes the following response fields:

avatar_url
id
link
name
url
description

[rachelbaker]

Fixes #417

@WP-API/amigos #reviewmerge

[danielbachhuber]

Why are you removing url and description ?

[rachelbaker]

Why are you removing url and description ?

@danielbachhuber because those details aren't always publically available. Some themes expose them, but we shouldn't assume all sites want that data public.

[danielbachhuber]

Some themes expose them, but we shouldn't assume all sites want that data public.

I thought we decided in NYC that we'd be exposing the data?

[rachelbaker]

@danielbachhuber You are right, confirmed with the logic laid out in #417 and corrected in dbfe9e7

[danielbachhuber]

Isn't slug exposed in the URL?

[danielbachhuber]

And by URL I mean link

[rachelbaker]

@danielbachhuber It is exposed in the author url. slug also defaults to the user_login so I don't see a reason to expose it in the embedded response.

[danielbachhuber]

slug also defaults to the user_login so I don't see a reason to expose it in the embedded response.

Why not? Most other resources all have slug: Post, Term

[rachelbaker]

@danielbachhuber Is there a use case for having the Users slug without authentication? Keeping in mind that get_author_posts_url() is filterable to not use user_nicename (or slug)

[danielbachhuber]

Is there a use case for having the Users slug without authentication?

Consistency.

[rachelbaker]

I feel very strongly that slug is a User field I would not expect to be available in the embed context. The field is available in the view and edit context.

Is there a reason besides consistency?

[danielbachhuber]

Is there a reason besides consistency?

Not at the top of my head, but I'm sleep deprived.

We can just see if it comes up again.