🎯 Tracking: Resolving nodes by URI
#2366
Labels
component: architecture
Relating to fundamental architectural decisions
component: query
Relating to GraphQL Queries
effort: high
More than a week
impact: high
Unblocks new use cases, substantial improvement to existing feature, fixes a major bug
status: in progress
Currently being worked on
type: bug
Issue that causes incorrect or unexpected behavior
Milestone
This is a tracker for all the issues with bad/missing results when resolving nodes by their URI.
The general problem stems from
NodeResolver
's attempt to replicateWP::parse_request
with a provideduri
. Assumingly, some of these are due to misordered conditionals, while others are missing edge cases.Proposed Work
As I see it, the ideal solve requires 3 steps:
NodeResolver
to make the code less complex, and easier to test/iterate on. ( chore: clean up and add comments to NodeResolver::resolve_uri() conditional logic. #2656 )wpunit
tests toNodeByUriTest
to bringNodeResolver::resolve_uri()
to 100%. ( test: backfillnodeByUri
query testing #2659 )Tracking:
/shop/
page by contentNode with uri argument when woocommerce is enabled (no wp-graphql-woocommerce required) #1910nodeByUri
queries #2191If I missed an issue or if you have a use case not referenced by an existing issue, please share and I'll add it to the tracker.
The text was updated successfully, but these errors were encountered: