Looking up a node by nodeByUri for a translated permalink

[williamjulianvicary]

We have hit an issue where some of our custom post types have translated permalinks/slugs, an example query is below, the URI being passed is the relative path on the current page (i.e ///).

Example that works (non-translated):

• /pagetype/pageslug

Examples that do not work:

• /pagetypetranslated/pageslugtranslated
• /locale/pagetypetranslated/pageslugtranslated
• https://example.com/locale/pagetypetranslated/pageslugtranslated
• pageslugtranslated
• etc

It's as if the WPGraphQL plugin is not aware of any translated URIs on any custom post types. It DOES work for translated page URIs but not for any custom post types.

I've looked through open issues but can't see anything that stands out currently but possibly some related issues - does anyone have any clever ideas of how we can query these pages? We're using FaustJS and it has a seed query which it uses to resolve the correct template and appropriate document ID for the given URI so at present this is a bit of a blocker!

GraphQL to reproduce (pass in a URI):

query MyQuery($uri: String!) {
  node: nodeByUri(uri: $uri) {
    ...NodeByUri
  }
}

fragment NodeByUri on UniformResourceIdentifiable {
  __typename
  uri
  id
}

[matthewtompkins]

@williamjulianvicary Just ran into this same issue. Curious if you came up with a viable solution. I'll look into it as well and let you know if I come across anything 👍

[williamjulianvicary]

We solved this by:

• Using a callback in Faust to ensure the // was in the URI passed to the seed query
• Updating the WPGraphQL lookup, using a hook on graphql_pre_resolve_uri that, custom code:

		add_filter( 'graphql_pre_resolve_uri', [ $this, 'resolve' ], 10, 5 );

public function resolve($node, $uri, $context, $wp_obj, $extra_query_vars)
	{
		global $sitepress;

		// avoids recursion
		if (self::$isRunning === true) {
			return $node;
		}

		self::$isRunning = true;

		$resolver = new NodeResolver( $context );

		$discovered_lang = $this->extract_language_from_uri($uri);
		if (!$discovered_lang) {
			return $node;
		}

		$new_uri = $this->strip_language_from_uri($uri);

		// Attempt to resolve the URI language
		$original_lang = apply_filters( 'wpml_current_language', NULL );
		$sitepress->switch_lang($discovered_lang);
		$node = $resolver->resolve_uri( $new_uri );
		$sitepress->switch_lang($original_lang);

		// If we didn't resolve the language, fallback and attempt the non-international version.
		// At this point the URI has been stripped of language, and WPML is set to the default lang
		if (!$node && self::SHOULD_FALLBACK) {
				$node = $resolver->resolve_uri( $new_uri );
		}

		self::$isRunning = false;
		return $node;
	}

	private function strip_language_from_uri( string $uri ): ?string
	{
		$uri = substr($uri, 3);
		return $uri ?: '/';
	}

	private function extract_language_from_uri( string $uri ): ?string
	{
		$pattern = '~^/(' . implode('|', self::ACCEPTED_LANGUAGES) . ')($|/)~i';

		if(! preg_match( $pattern, $uri, $matches) ) {
			return null;
		}

		return $matches[1];
	}

However WPML does now have a native GQL extension: https://wpml.org/documentation/related-projects/wpml-graphql/ so I presume this is solved in that extension?

[matthewtompkins]

Thanks so much for the response, this is really helpful. For our particular needs, I realized we can perform a post query and if that returns null, we can do a fallback page query with the uri.

You just blew my mind with the native WPML GQL extension. That's amazing news, thank you for passing that on. I look forward to digging into that - hopefully it will resolve some of the issues we've been running into.

[Knskan3]

Hi, was this issue resolved? I'm facing it now.