Gutenberg: Custom Preview Links

[squibbleFish]

In the current Wordpress editor, you can currently filter the preview link to be your own custom link using preview_post_link. Its appears that Gutenberg does not currently support this and does not appear to offer a hook to change this. From what I can see it appears tied to this method in /store/selectors.js

export function getEditedPostPreviewLink( state ) {
    const link = state.currentPost.link;
    if ( ! link ) {
        return null;
    }

    return addQueryArgs( link, { preview: 'true' } );
}

If I am reading this correctly, this gets the current link from the state obj and appends the preview query arg.

It would be great if this value came from PHP or a JS hook was offered to override this selection. Since we are currently developing our new site using Gutenberg, I have no choice but to hack the JS.

If there is a hook, please drop me a line. #

[youknowriad]

Can I ask for details on why you'd want to use another preview link that the one generated by WordPress? Thanks for you help

[squibbleFish]

No worries. For our use case, we are using a front end React with server side rendering application. Our Wordpress install will be in a different directory than our front end. So Wordpress's API will respond at /some-content-svc/ our front end will be hit at /front-end/ as an example. We also want the ability to append query strings to the URL in order to shut off specific functionality on our front end.

Rather than try and work through our use case though, I think it's important to keep in mind that without this functionality, we do not have parity and backwards compatibility with the current existing editor. This is not the first time I have used this filter in order to change the preview link for other reasons besides the one given.

[mfolkeseth]

Glad to see that this issue is already getting some attention. We also need custom preview links. Wordpress is just part of our ecosystem and there will be a lot of stuff happening between Wordpress and the front end. We will need to render the preview in the front end app to show editors the final product.

[myleshyson]

Yea we have a Laravel app that is already built, and instead of building the blog functionality from scratch we just wanted to use WordPress on another server and consume the api from the Laravel app. The custom preview link would allow us to preview the post on the Laravel site rather than having to restyle the entire blog again on the WordPress side.

[danielbachhuber]

This is a backwards compatibility concern. I've used preview_post_link plenty of times.

[danielbachhuber]

Created https://core.trac.wordpress.org/ticket/44180 to ensure this ends up exposed in the REST API.

[yoadsn]

@danielbachhuber Thank you for this.
As you have noted - preview_post_link is useful and should be backward compatible using Gutenberg.
I believe the fix in https://core.trac.wordpress.org/ticket/44180 is not complete.

Here is the scenario I am facing and my analysis.

1. WP admin is accessed and used from domain A

2. WP frontend is on domain B using reverse proxy - this is very common when wanting to host WP on a sub folder of a TLD
   (But this senario I believe applies also to any case where home_url !== site_url or in fact anytime the preview url needs to be filterable)

3. Using Gutenberg for a draft post.

4. After an autosave - the autosave endpoint return a preview_url as you have mentioned above.
   The reducer here would take the preview_link as is and use that for the preview button.
   As you have shown on the screenshots of the PR #6682 - hovering over the "preview" button at this point would show the url as it was returned from the autosave endpoint.
   This URL was generated here and using the get_preview_post_link which makes the preview link filterable.

5. If now the "preview" button is clicked or the "save" link is clicked. The clien would hit the posts controller and get the payload which includes the post's link.
   This link is generated here and is using the get_permalink function.
   The permalink is filterable but in my scenario preview link need to work on site_url and not the home_url - permalinks should always be on home_url. (for the preview to work, all admin auth is against site_url).
   The reason this works is that the reducer mentioned above applies the { preview: true } query param on the client.
   This means there is an inconsistent behaviour between the way preview links are generated form the autosave controller and on the client.

Anyway - hovering over the button would now show a different URL (assuming site_url !== home_url).

I hope I analyzed the situation correctly - I'm jst a user of WP so first time looking at the source codes.

I might be able to work around this problem if I will filter the permalink and somehow know that it is going to be used on the "editor" and not on the frontend - but this is not possible since the posts controller does not identify itself to the call in anyway.

Thoughts?

[draganescu]

Hi @danielbachhuber I am reopening this because I am unsure if this Trac issue https://core.trac.wordpress.org/ticket/44180 shouldn't have continued instead of being closed as that would enable the use of the old filter for the preview link?

[danielbachhuber]

@draganescu This issue is resolved. The WP_REST_Autosaves_Controller class uses get_preview_post_link(), which is filterable: https://github.com/WordPress/WordPress/blob/fe73f310d4502c978650da998fe985c9c6f9dba0/wp-includes/rest-api/endpoints/class-wp-rest-autosaves-controller.php#L394

[yoadsn]

@danielbachhuber If you read my previous analysis of the situation - you can see I point at a problem with the existing solution.

The autosave endpoint allows filtering, as you explained of the preview link. (the response payload contains that filtered preview link).

But, if clicking "Save" or "preview" - another link is generated, coming from class-wp-rest-posts-controller.php->prepare_item_for_response which is using the get_permalink combined with (on the client) the { preview: true} query.
This means the link generated, is in fact not a preview link but a modified permalink.
So, if site_url !== home_url - this returned link from this endpoint cannot work on both.

What am I missing?

[danielbachhuber]

@yoadsn I see what you're talking about now. The client should be using the preview link from the autosaves controller, not appending a ?preview=true query parameter to the permalink.

Given the age of this existing ticket, can you open a new issue with a description of the problem? Thanks

[yoadsn]

@danielbachhuber Awesome - I did open #13998 for that purpose but it was closed to unify into this ticket.
Would you want me to open a new one? Would not want to span the issues on the repo.
I can also copy& paste the analysis I posted above which describe in details with core references the exact problem.
Would love to help with this as much as I can!

[danielbachhuber]

Would you want me to open a new one? Would not want to span the issues on the repo.

Yes, please, given this has already been closed against a closed milestone.

I can also copy& paste the analysis I posted above which describe in details with core references the exact problem.

That'd be very helpful.

[martinszeltins]

Hi, I also noticed that it's not possible to change the "Preview" button link. This issue is not resolved yet.

To clarify, when applying the "preview_post_link" it changes only the link at the top that says "View Post" but it doesn't change the "Preview" button link on the right side of Gutenberg.

[Morgunov-Vitaly]

+1
could somebody give a suggestion - how to change the link?