Expose featured_media property on post resources in "embed" context

[kadamwhite]

When you create a link relation that allows you to embed a post in a separate response, the "featured_media" property is omitted from that embedded post. This means that the only way to know the featured media item for an embedded post is to either re-request the embedded resource using the "view" or "edit" context, or else to use the _link to wp:featuredmedia (which _is_ present in the embedded resource, despite the omission of the featured_media property) to deduce the ID of the embedded post's associated media item.

It would be more consistent and straightforward for the ID of the featured media for a post to be included in that post object when the post is embedded. To clarify, this is not suggesting the media item is recursively embedded: just that featured_media: 4168 is included in that embedded post object.

Thanks to @westonruter for raising this inconsistency.

[kadamwhite]

A simple patch permitting featured_media to display in "embed" context

[westonruter]

The situation in particular that I had this problem is I created a related field that links one post to another. This related field is an integer post ID and its link is added as embeddable. When I made a request with _embed for the items having related posts, I was unable to obtain the featured_media via getFeaturedMedia() in the Backbone client.

In other words, if the post is hydrated with data that has _embedded:

post.getRelatedPost().done( function( relatedPost ){
    relatedPost.getFeaturedMedia(); // => Will always fail.
} );

[kadamwhite]

Add unit tests to previous patch

[kadamwhite]

There may be a more elegant way to handle testing this, but I added three test cases to assert which properties a post has in view, edit and embed contexts.

[jnylen0]

I wonder why the embed context is such a small subset of data compared to view? There are other elements which could potentially be useful.

Some feedback on the tests - I would test that there are no extra keys, rather than just no missing keys:

<?php
$expected_keys = array( ... );
$actual_keys = array_keys( $data );
sort( $actual_keys );
$this->assertEquals( $expected_keys, $actual_keys );

It may also be worth using a ​data provider here to cut down on boilerplate.

[kadamwhite]

Adjust unit tests per patch feedback

[jnylen0]

This particular change looks fine to me, though I would still like to see an answer to this larger question:

I wonder why the embed context is such a small subset of data compared to view? There are other elements which could potentially be useful.

[joehoyle]

I wonder why the embed context is such a small subset of data compared to view? There are other elements which could potentially be useful.

This was intended to save bandwidth I believe.

[rmccue]

Replying to jnylen0:

I wonder why the embed context is such a small subset of data compared to view? There are other elements which could potentially be useful.

The embed context was intended for data you'd want if embedding the object on a page (such as an oEmbed item, sidebar widget, search result, etc). Makes sense to include the featured media for that.

[rmccue]

In 40602:

REST API: Include featured_media in embed responses.

Props kadamwhite, jnylen0, westonruter.
Fixes #39805.