faustjs icon indicating copy to clipboard operation
faustjs copied to clipboard

Preview not working for CPT in draft

Open MKlblangenois opened this issue 1 year ago • 3 comments

Description

When I try to reach the preview page of a CPT in draft, I got the following error: The URL must contain the proper "previewPathname" query param for previews..

The URL returned from WP preview button when page isn't published: http://localhost:3000/preview?post_type=recrutement&p=20766&preview=true&_thumbnail_id=328

image

Steps to reproduce

  1. Create a new CPT (following the Faust doc)
  2. Go to WordPress back-office and add a new page for the new CPT
  3. Try to preview the link without publishing the page

Additional context

An issue was already opened in the past for a similar issue and get closed due to 2 PR's that was normally fix the issue: #1561

@faustwp/core Version

3.0.3

@faustwp/cli Version

3.0.2

FaustWP Plugin Version

1.3.2

WordPress Version

6.5.4

Additional environment details

No response

Please confirm that you have searched existing issues in the repo.

  • [X] Yes

MKlblangenois avatar Jul 08 '24 12:07 MKlblangenois

Hi!

I am experiencing the same issue. When a post of Custom Post Type has a status of "Draft," the preview link is missing essential arguments (appended in the preview_post_link hook located in faustwp/includes/replacement/callbacks.php:137), causing Faust to fail in generating a preview.

image

floretsky avatar Jul 22 '24 17:07 floretsky

I can replicate the issue as well with the vanilla faust example setup.

jan-clockworkwp avatar Aug 06 '24 07:08 jan-clockworkwp

Anything new here to resolve this issue ?

mediakod avatar Sep 18 '24 08:09 mediakod

Any updates here ? I'm experiencing the same issue. Or any workaround would be great ... For a CPT named actor for example, I've got the preview link : /preview/?post_type=actor&p=245&preview=true

Obviously this lends to this error

Uncaught (in promise) Error: The URL must contain the proper "previewPathname" query param for previews.

Thanks

cedricrabarijohn avatar Dec 06 '24 13:12 cedricrabarijohn

Well I think it's a problem on the cms plugin side, since the url is missing some query arguments. The workaround is not to preview from the edition page, but just go back to the CPT list in your cms, and use the previsualise button from there , it contains the right url.

cedricrabarijohn avatar Dec 13 '24 08:12 cedricrabarijohn

Hi, is there plan as to when a fix for this will be implemented?

We've got the workaround for now (clicking the preview link from a different location and the top right icon when in edit mode) but wanted to know the plan for getting this resolved and implemented? Thanks!

danlong-stq avatar Feb 24 '25 11:02 danlong-stq

Hey @MKlblangenois, @floretsky, @danlong-stq, @cedricrabarijohn,

I dug into this issue and found that the problem lies in the way the FaustWP plugin filters preview links. Specifically, the current implementation only applies the preview_link_in_rest_response function to post and page REST responses:

add_filter( 'rest_prepare_post', __NAMESPACE__ . '\\preview_link_in_rest_response', 10, 2 );
add_filter( 'rest_prepare_page', __NAMESPACE__ . '\\preview_link_in_rest_response', 10, 2 );

Since custom post types (CPTs) are not covered, their preview links are missing essential query parameters, leading to the error.

Temporary Solution

Until a proper fix is implemented in the plugin, you can manually extend preview support for your CPTs by adding a filter like this in your theme’s functions.php or a custom plugin:

add_filter( 'rest_prepare_YOUR_CPT', 'custom_preview_link_in_rest_response', 10, 2 );

function custom_preview_link_in_rest_response( $response, $post ) {
    if ( 'draft' === $post->post_status ) {
        $response->data['link'] = get_preview_post_link( $post->ID );
    }

    return $response;
}

Replace YOUR_CPT with the actual post type name. This ensures that CPTs receive the correct preview link in the REST response.

I'm not sure how we can generalize this one to cover any post type you create. Thats tricky. If anyone has suggestions, feel free to share.

theodesp avatar Feb 27 '25 13:02 theodesp

Thanks @theodesp - I've implemented this and it looks to be working!

Our post types (the post_type key) are defined in an array which we loop through to register them in separate classes etc. I was able to add the filter into the loop and replace YOUR_CPT with the current loops value so this should work for any new CPTs we make in the future too.

I know there is a get_post_types() function in WP which might help in getting this rolled into the plugin, but (and don't quote me on it) I don't think it shows CPTs unless the function itself is wrapped in an init hook - I don't know if that will then conflict with the filter. Anyway, maybe food for thought if your team haven't already found a way to implement it into the plugin.

$args = array(
   'public'   => true,
   '_builtin' => false
);
 
$custom_post_types = get_post_types( $args );

Thanks again for the fix!

danlong-stq avatar Feb 27 '25 17:02 danlong-stq

Thanks @danlong-stq 👍

We really appreciate the feedback and I am glad to hear it is working for you. Currently we are looking at some type of loop of post types and seeing if this is the. best possible solution for adding the filter to all of the post types as I cannot see any statis filter that we could use for previews to catch all post types.

colinmurphy avatar Feb 27 '25 17:02 colinmurphy

We have released a fix for this on version 1.8.0 this morning.

If anyone has any issues, please feel free to re-open or submit a new issue.

colinmurphy avatar Mar 03 '25 13:03 colinmurphy