Querying CPTs without a slug with nodeByUri doesn't work

[Ririshi]

I removed the slugs from some of my CPTs with a filter and an action, hooking into post_type_link and pre_get_posts. However, this doesn't seem to affect the URIs as used by WPGraphQL. I have a post type named case for example. The only way to get any case posts through nodeByUri is to use the URI including the "original" slug, i.e. nodeByUri(uri: "/case/test-case/"), even though in the WordPress admin, the permalink is shown as /test-case/. I am also able to access the case post through the normal WordPress frontend on that URI.

How can I access my "slugless" CPTs with nodeByUri, using the slugless version of the URI?

Code to register the post type:

$labels = [
    // Omitted for brevity
];

$args = [
    'description' => __('Casussen', THEME_NAMESPACE),
    'labels' => $labels,
    'supports' => [
        'title',
        'editor',
        'revisions',
    ],
    'taxonomies' => ['category'],
    'hierarchical' => false,
    'public' => true,
    'show_ui' => true,
    'show_in_menu' => true,
    'show_in_nav_menus' => true,
    'show_in_admin_bar' => true,
    'menu_position' => 5,
    'menu_icon' => 'dashicons-media-document',
    'can_export' => true,
    'has_archive' => true,
    'exclude_from_search' => false,
    'publicly_queryable' => true,
    'capability_type' => 'page',
    'show_in_graphql' => true,
    'graphql_single_name' => 'case',
    'graphql_plural_name' => 'cases',
];

register_post_type('case', $args);

Code to remove the slugs:

const SLUGLESS_POST_TYPES = ['topic', 'branch', 'case'];

/**
 * Remove slug from the topic post type
 *
 * @param $post_link
 * @param $post
 * @param $leave_name
 * @return array|mixed|string|string[]
 */
function sm_slugless_post_types($post_link, $post, $leave_name)
{
    if (!in_array($post->post_type, SLUGLESS_POST_TYPES) || $post->post_status != 'publish') {
        return $post_link;
    }

    return str_replace('/' . $post->post_type . '/', '/', $post_link);
}

add_filter('post_type_link', 'sm_slugless_post_types', 10, 3);


/**
 * Ensure slugless post types are queried with regular posts and pages
 * Necessary because slugless CPTs lack a unique identifier
 *
 * @param $query
 * @return void
 */
function sm_parse_request($query)
{
    if (!$query->is_main_query() || 2 != count($query->query) || !isset($query->query['page'])) {
        return;
    }

    if (!empty($query->query['name'])) {
        $query->set('post_type', array_merge(['post', 'page'], SLUGLESS_POST_TYPES));
    }
}

add_action('pre_get_posts', 'sm_parse_request');

[justlevine]

(Sounds like something possibly addressed by #2680 )

[orthotypos]

(Sounds like something possibly addressed by #2680 )

@justlevine Just tested with 1.14.0 pre-release (including the patch from #2752) and unfortunately it doesn't work. Slugless CPTs are still not being matched:

What is confusing to me is why does resolver return correct uri (without slug), while nodeByUri can't match it then with that same uri.

[justlevine]

Reviewing the code you shared, it's because you're not actually changing the wp-rewrite rules, but overriding the result after the query has been parsed and set. You want to configure the rewrite rules in your post type args, not pre_get_posts.

Or you can follow the pre_get_posts pattern you're using and use one of the filters in the NodeResolver::resolve_uri() class and override the returned result.

[orthotypos]

Thanks @justlevine. v1.14.0 just landed, but it didn't help with this issue. Using post type args is not solution for our use case really because it still forces you to use CPT slug prefix, whereas we would like to be able to have different URL structure on a per post/page basis and not on a whole CPT basis.

How would we go about utilizing NodeResolver::resolve_uri() for this purpose?

[justlevine]

The graphql_pre_resolve_uri filter serves a similar purpose to pre_get_posts, as do others in the same method that may suite you better depending on your specific use case.

[orthotypos]

@justlevine Thanks so much! This is looking very promising. I'll follow up after I do more tests, but first results are looking good.