New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Preview: get "parent" post ID for non-hierarchical posts when using asPreview
#2876
Comments
@renatonascalves you have the id in the input already, eh? edit: ah, you call this out already 🤦 |
@jasonbahl I do! And keeping as is and leaving API consumers to handle it in their apps is a valid approach as well. I just think the current approach is not obvious. And the example shared shows people has expectations it will return the right |
@renatonascalves I think perhaps the solution is maybe clients changing from querying This way you pass the ID of something, you get that something, then you specify you want the connected preview of it. It's a bit more explicit that the client wants 2 nodes, the published node and the preview of the node. I believe the Perhaps in the same way we have a That way we could query the node that a preview is the preview of. For example: {
post(id: 3192, idType: DATABASE_ID) {
...PostTemplateData
preview { ## The preview node (contains unpublished data )
node {
...PostTemplateData
previewOf { ## the origin node the preview is a preview of
node {
...PostTemplateData
}
}
}
}
}
}
fragment PostTemplateData on Post {
id
databaseId
title
content
isPreview
} Here's the code to register the connection if you want to play with it and see what you think. add_action( 'graphql_register_types', function() {
$post_types = WPGraphQL::get_allowed_post_types( 'objects' );
foreach ( $post_types as $post_type ) {
// only define the connection for public/publicly_queryable post types
if ( true !== $post_type->publicly_queryable && true !== $post_type->public ) {
continue;
}
register_graphql_connection( [
'fromType' => ucfirst( $post_type->graphql_single_name ),
'toType' => ucfirst( $post_type->graphql_single_name ),
'description' => __( 'The published node the revision is associated with', 'wp-graphql' ),
'fromFieldName' => 'previewOf',
'oneToOne' => true,
'resolve' => function( \WPGraphQL\Model\Post $preview, $args, $context, $info ) {
// if the current node is not a preview, return null.
// this connection is intended to return the published node
// of the preview
if ( ! $preview->isPreview ) {
return null;
}
$resolver = new \WPGraphQL\Data\Connection\PostObjectConnectionResolver( $preview, $args, $context, $info );
// resolve the connection using the preview's parentDatabaseId
$resolver->set_query_arg( 'p', $preview->parentDatabaseId );
// return the connection as a one to one connection
return $resolver->one_to_one()->get_connection();
}
] );
}
} ); Let me know what you think and we can include a connection like this in the core WPGraphQL Schema! |
I'll play around with it. But a quick look tells me that a I do wonder however what can be done to avoid this mistake from consumers. It was not obvious to me at first, and others apparently, that using
And I agree! It is not a bug per se. The issue is the change in the response is not obvious. |
Ya, perhaps more clarity on the description of the Right now it says:
|
@jasonbahl Tks for improving the description of the argument. 💪🏾 I liked the suggestions here. And it'd be great to have them in the core plugin. |
Just chiming in on this off the back of a related ticket #3001 (any context for my below thoughts can be found there) I raised the other day. In short here are the thoughts I had regarding the current behaviour of the I've managed to find a work-around using the
|
So, in a nutshell, WordPress saves revision post types in different post ids. So when a user uses the So having access to the "parent" post via |
My understanding of the underlying source of contention is that we don't have a With that in mind, the discrepancy becomes a lot more clear: The As such, IMO the bug is that when previewed, (I do see the benefit of adding |
What problem does this address?
Currently, if you try to preview a non-hierarchical post, the
Previewable
interface does not return the post ID of the "parent" post.What is your proposed solution?
There are a few options here:
Previewable
interface, exposing the "parent" post ID;What alternatives have you considered?
Currently, API consumers need to circumvent this by getting the id in the params and swap for the one in the response in their apps.
But it is my understanding tools are not doing that and exposing a broken experience. (See the additional context below).
Additional Context
This is particularly helpful in a toolbar. See this Github issue, wpengine/faustjs#1515, for an example where this problem reflects.
The text was updated successfully, but these errors were encountered: