REST API: Autosaves entities should include preview_link

[aduth]

Related: #2544

In order to preview a published post, we need to create an autosave revision. The preview behavior in Gutenberg relies on the addition of a preview_link field to the post endpoint, which calls get_preview_post_link.

gutenberg/lib/rest-api.php

Lines 441 to 478 in 423dbed

	/**
	* Get the preview link for the post object.
	*
	* @see https://github.com/WordPress/gutenberg/issues/4555
	*
	* @param WP_Post $post Post object.
	* @return string
	*/
	function gutenberg_get_post_preview_link( $post ) {
	return get_preview_post_link( $post['id'] );
	}
	/**
	* Adds the 'preview_link' attribute to the REST API response of a post.
	*
	* @see https://github.com/WordPress/gutenberg/issues/4555
	*/
	function gutenberg_register_rest_api_post_preview_link() {
	foreach ( get_post_types( array( 'show_in_rest' => true ), 'names' ) as $post_type ) {
	if ( ! is_post_type_viewable( $post_type ) ) {
	continue;
	}
	register_rest_field( $post_type,
	'preview_link',
	array(
	'get_callback' => 'gutenberg_get_post_preview_link',
	'schema' => array(
	'description' => __( 'Preview link for the post.', 'gutenberg' ),
	'type' => 'string',
	'format' => 'uri',
	'context' => array( 'edit' ),
	'readonly' => true,
	),
	)
	);
	}
	}
	add_action( 'rest_api_init', 'gutenberg_register_rest_api_post_preview_link' );

This field is not included in the autosaves endpoint return value, however, so it can't be known where the user should be directed on a published post autosave.

Thus, we should:

• Make the preview link available on the autosaves endpoint response
• Consider whether this should be included as a _links field (not sure what the standard practice is here)

Alternatively, we could attempt to recreate this logic in the client, which relies on:

• Knowing that the post exists
  • Can be assumed when editing
• That the post type is visible
  • Would need something like visibility field added for taxonomies (Filters out private taxonomies from sidebar UI. #2654, Trac#42707)
• Filtering preview_post_link
  • Not possible to recreate in the client

[aduth]

Related Slack conversation with @danielbachhuber : https://wordpress.slack.com/archives/C02QB2JS7/p1528296764000836

Importantly, it's not as simple as just including the result of get_preview_post_link in an autosave response, as when previewing a published posts autosave, it's required for a preview_id and preview_nonce to be present.

For the classic editor, these are generated here: https://github.com/WordPress/WordPress/blob/6fd8080e7ee7599b36d4528f72a8ced612130b8c/wp-admin/includes/post.php#L1844-L1859

And verified in front-end display at: https://github.com/WordPress/WordPress/blob/6fd8080e7ee7599b36d4528f72a8ced612130b8c/wp-includes/revision.php#L542-L589

Presumably, we'd need to do the same as what's being done for the classic editor, or alternatively enhance the get_preview_post_link to be more aware of including these arguments automatically when a revision exists for a published post (begs the question whether this is a desirable default, or if the non-revisioned published post would want to be previewed directly as well).

[aduth]

The issue implies this is only needed for published posts, but if we use the autosaves endpoint for draft posts, even if those are processed by the server as "full save", it doesn't return preview_link and we as well have no way to know where to direct the user, e.g. for a new post the first time we hit "Preview".

Related: #7124

Edit (Correction): The auto-draft generated for the post when first loading the editor does include a valid preview_link (?p=123&preview=true), which can be used after the autosave completes. May be the case we want to use the preview link as returned by the autosaves endpoint anyways, both for consistency between published or draft posts, and for environments where we may not assume an auto-draft post is generated to initialize the editor (related: #6384)

[aduth]

Closed by #7130.