Querying Page by URI doest require correct URI field

[andremendonca03]

Description

When querying for pages or posts by URI, it returns any match of the uri even if it's incomplete. It turns out to be a problem when parent/child relationships are in place.
i.e. I've got a test page which URI is /about/test/ but it can still be queried just with a fraction of the URI like bout/test/ or even just /test/

Steps to reproduce

1. Query for any page/post/cpt using IdType: URI

Additional context

No response

WPGraphQL Version

1.21.0

WordPress Version

6.4.3

PHP Version

8.3.0

Additional environment details

No response

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

• Yes

Please confirm that you have disabled ALL plugins except for WPGraphQL.

• Yes
• My issue is with compatibility with a specific WordPress plugin, and I have listed all my installed plugins (and version info) above.

[jasonbahl]

@andremendonca03 if you visit /test/ in a the php-rendered wordpress front end of the site, what happens?

[justlevine]

@andremendonca03 if you visit /test/ in a the php-rendered wordpress front end of the site, what happens?

Per slack it 404s on the frontend.

[jasonbahl]

ah ok. Often times WordPress will attempt to find the best match and return the page still, or redirect to it.

[jasonbahl]

@andremendonca03 can you query for more fields? like __typename, id, etc?

Do you maybe have something under the /test/ permalink?

When I try and reproduce, I get a null when querying page(id:"/test/" idType:URI) { but successfully get the node returned when querying for /about/test/

[andremendonca03]

@jasonbahl Unfortunately I am still getting the page even if I query for more fields. When visiting the URI /test/ it 404s on wordpress' front-end.

Btw, when I used a wrong url with 2 slashes it somehow returned a post data (not page) alongside an error.

[jasonbahl]

Are you able to reproduce with no other plugins other than WPGraphQL?

I was not able to reproduce. Curious if there are specific permalink rules at play or something from a plugin possibly at play here.

[andremendonca03]

@jasonbahl Yes, I just spinned up a brand new wordpress, created the about page and test child page. Installed WPGraphQL and run the queries.

Querying by page /test/ it is still returning the page:

And this wrong URI is still retrieving the post:

[jasonbahl]

This seems like maybe a $global post thing. 🤔

What happens if you query for page first then nodeByUri in the same request?

[andremendonca03]

It's still returning the Page on page query and null for nodeByUri

[jasonbahl]

Attempt to reproduce:

• using LocalWP, create a fresh install
• install and activate WPGraphQL v1.21.0 (no other active plugins)

• delete the pages WordPress is scaffolded with (sample, privacy policy)

• create the following pages:

  • Home Page (set to front page)
  • About
    • Test
  • Draft (leave as draft)

• Ensure my permalinks are flushed:

• Open GraphiQL and execute the following query:

{
  nodeByUri(uri: "/test/") {
    __typename
    id
    uri
  }
  page(id: "/test/", idType: URI) {
    __typename
    id
    uri
  }
}

• see the following results:

• Visit the /test/ uri in the non-headless WordPress front-end (WordPress redirects automatically to /about/test/)

• Change permalinks to "Post Name"

• Query again:

Now I am able to see the "/about/test" node returned for the "page", but not the "nodeByUri", which is indeed interesting.

However, the node that is returned also returns a uri value of /about/test/ which a client should be able to use to determine that the actual uri of a node is different than the requested URI and then redirect the page to the correct /about/test/ location as we saw the WordPress front-end do in the GIF above.

I think at minimum we've identified an inconsistency with nodeByUri and page( id: $id idType: URI ) behavior.

If WordPress is able to accept a non-existing uri (/test/) and redirect it to another matching node (/about/test/) then WPGraphQL should be able to behave in that same way.

I would think the correct solution here would be to have the nodeByUri also return the /about/test/ node, and the client should be able to use that information to determine if the requesting uri and returned node's uri don't match, redirect to the node's correct uri, as WordPress's template layer does.

[jasonbahl]

I think the action here is to identify why page( id: $id idType: URI ) behaves differently than nodeByUri() and improve the consistency there.

Without looking, my hunch is that the RootQuery.page field passes some context to the resolver, identifying that the Node Resolver should resolve a page, but the RootQuery.nodeByUri resolver doesn't have that context, because it doesn't know that a page is the uri to look for (the uri can be ANY Node type) where the page field does know that a "Page" is expected and not another type.

[justlevine]

I would think the correct solution here would be to have the nodeByUri also return the /about/test/ node, and the client should be able to use that information to determine if the requesting uri and returned node's uri don't match, redirect to the node's correct uri, as WordPress's template layer does.

WP default behavior is to correctly return a 404, so nodeByUri is working correctly. I don't think we should deviate from this.

RootQuery.posts uses some manual args to try and efficiently prevent the NodeResolver from checking irrelevant node types, so that's where things are going wrong and need to be fixed.

[jasonbahl]

WP default behavior is to correctly return a 404

In a vanilla WordPress install, it redirected not returned a 404 though 🤔

[justlevine]

WP default behavior is to correctly return a 404

In a vanilla WordPress install, it redirected not returned a 404 though 🤔

It doesn't for me 🤔 Let me try again when I'm by my desk

[jasonbahl]

it did for me in a vanilla install with only WPGraphQL and whatever latest default theme.

[jasonbahl]

We should tackle this by handling it the same way as core WordPress.

if WordPress redirects, WPGraphQL should return the node, and the node should have the accurate uri as a field that can be used to redirect to by the client.

If WordPress 404s, WPGraphQL should return a null.