faustjs
faustjs copied to clipboard
Preview not working for CPT in draft
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
Steps to reproduce
- Create a new CPT (following the Faust doc)
- Go to WordPress back-office and add a new page for the new CPT
- 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
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.
I can replicate the issue as well with the vanilla faust example setup.
Anything new here to resolve this issue ?
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
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.
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!
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.
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!
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.
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.