This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

This issue has been automatically closed because it has not had recent activity. If you believe this issue is still valid, please open a new issue and mark this as a related issue.

Decided to give this a shot. I'm making some progress but need some clarification. Currently when querying comment authors on a comment, if the commenter wasn't a logged in user, the CommentAuthor=>databaseId will equal the Comment=>databaseId but the global id appears to be unique. Additionally if the comment user is logged in, the database ID becomes the User=>databaseId and not the Comment=>databaseId , Does this mean we are only allow the commentAuthor( id: $id ) { ... } entry point to use Global IDs and not database IDs? Or is this a bug that needs smoothing out?

@moonmeister great question!

I think we can support idType: DATABASE_ID with some conditional logic, since database ids are unique in the WP backend. I.e. check if the ID points to a valid user, and if not then use the comment to resolve instead (or vice versa).

edit: nope. Users and comments both have their own unique numbering. Would suggest a more specific idType to differentiate between which dataloader/model to fetch.

ok, so we have a few things to consider here.

CommentAuthor is treated as an author that's not a user.

So, querying a CommentAuthor by ID should use the comment->databaseId (see: https://github.com/wp-graphql/wp-graphql/blob/develop/src/Model/CommentAuthor.php#L51-L56)

We should be able to query like so:

{
  commentAuthor( id: 123 idType: DATABASE_ID ) { ... }
  commentAuthor( id: "comment_author:123 ) { ... } # would be base_64_encoded Id, of course
}

And under the hood that should query for the comment with databaseId 123, then use the comment object to return a CommentAuthor Model.

Now, if we wanted to be able to query for a commenter from the root, things would be different, as commenter is an Interface that can be a user or a comment_author, and in that case, commenter does not have unique IDs, as you could have a comment (and therefore CommentAuthor) with database id: 123 in the comments table, and also have a user (commenter) with id 123 in the user table.

so, querying for commentAuthor() yes, we should be able to support databaseId.

Querying for commentor (if we chose to add that as an entry point) would not. It would need to be something like:

{
  commenter( id: "user:123" ) { ... }
  commenter( id: "comment_author:123" ) { ... }
  commenter( id: 123 idType: USER_DATABASE_ID ) { ... }
  commenter( id: 123 idType: COMMENT_AUTHOR_DATABASE_ID { ... }
}

CommentAuthor is treated as an author that's not a user.

In theory yes, returning __typname shows this when resolving Comment=>author.
In practice, when using DataSource::resolve_comment_author() It will return a User as a CommentAuthor. This may be bug?

As far as CommentAuthor vs Commenter...Is there some background or examples on what inspired this feature that would help determine the need? What are the use cases for either or both?

This may be bug?

yes. Sounds like a bug. The resolve_comment_author method should probably be changed to require a type as well so it knows to load from the comment table or user table

As far as CommentAuthor vs Commenter...Is there some background or examples on what inspired this feature that would help determine the need? What are the use cases for either or both?

@moonmeister WordPress core functionality lets you show different data depending on whether the Author is a user or not.

And being a "graph" we expose that to users to consume as well.

If the Commenter is a User, you can enter the graph and get user data.

If the Commenter is not a user, you're limited in the information you can ask for.

For example, I can do something like:

{ 
  comment( id: 123 idType: DATABASE_ID ) {
    content
    author {
       id
       name
       ...on User {
         recentPosts: posts {
           nodes { 
              id
              title
            }
          }
       }
    }
  }
}

If the Author of the comment is a User, I could expose additional data about them, like recent posts they've authored, and could add it to the UI or whatever.

All sorts of use cases here!

Right, that makes sense. I guess the question is this top level entry point only include CommentAuthors or does it include Users as well? What's the use case, not of the individual types, but of the RootQuery entry point?

If I wanted to procedurally generate a list of commenters...I'd use this but would probably want Commenters not just CommentAuthors...is there a scenario where I explicitly wouldn't want Users? If there was a case would filter on that entry point suffice? or do we need to separate entry points? commenter and commentAuthor (I'm also assuming their corollaries of commenters and commentAuthors.

I think we have room to add both.

An entry point to get CommentAuthor by ID from the root (these would not be users)

Another entry point to get Commenter by ID from the root (these could be users or "guest" authors / CommentAuthor type).

The original ask was for the commentAuthor entry point, so let's start with that?

And we can work on commenter entry separately

Think of it like the different entry points for posts.

You could do:

{ post( id: "..." ) { ... } }

or

{ contentNode( id: "..." ) { ...on Post { ... } } }

Multiple ways to enter the graph!

is there a scenario where I explicitly wouldn't want Users?

Sure!

What if i had a list of comments that showed the author, and when I click the author a Modal or Drawer opens with information about the author.

If the Author is a User a UserCommentor component could be returned which queried data about the user to show in the Modal/Drawer.

If the Author is a CommentAuthor (guest author) a different component CommentAuthorBio or whatever, could be returned which queries for data available to that type.

psuedo code:

const UserCommentorBio = ( { databaseId } ) => { 
  const { data } = useQuery( `
    query GetUserBio( $id: ID! ) {
       user( id: $id idType: DATABASE_ID ) {
          id
          name
          recentPosts: posts { nodes { id, title, date } }
       }
    }
  `, { variables: { id: databaseId } }  )
  
  return (
    <div>
      <pre>{JSON.stringify( data, null, 2 )</pre>
    </div>
  )
}

const CommentAuthorBio = ( { databaseId } ) => {
  const { data } = useQuery( `
    query GetCommentAuthorBio( $id: ID! ) {
       commentAuthor( id: $id idType: DATABASE_ID ) {
          id
          name
       }
    }
  ` , { variables: { id: databaseId } } )
  
  return (
    <div>
      <pre>{JSON.stringify( data, null, 2 )</pre>
    </div>
  )
}

const Comment = ({ databaseId }) => {
  
  const { data } = useQuery( `
  query GetComment( $id: ID! ) {
    comment( id: $id ) { 
      content
      author {
        node {
          __typename
          databaseId
        }
      }
    }
  }
  `, { variables: { id: databaseId } } );
  
  const type = data?.comment?.author?.node?.__typename;
  
  if ( type === 'CommentAuthor ) { 
    return <CommentAuthorBio databaseId={ data?.comment?.author?.node?.databaseId } />
  }
  
   if ( type === 'User ) { 
    return <UserCommentorBio databaseId={ data?.comment?.author?.node?.databaseId } />
  }

 return null;
}

^ very contrived, pseudo code, but hope it conveys roughly a use case 🤷🏻‍♂️