Handle 404 error

[boneus]

Hello. I have a question about handling 404 errors. For example, I have this setup:

add_action('cortex.groups', function(GroupCollectionInterface $groups) {
    $groups->addGroup(new Group(array(
        'id'       => 'archive-custom-post-type',
        'template' => 'archive-cpts.php',
    )));
});

add_action('cortex.routes', function(RouteCollectionInterface $routes) {
    $cpts = get_post_type_object( 'cpts' );
    $routes->addRoute(new QueryRoute(
        $cpts->has_archive . '/{meta_value:.+?}/',
        function(array $matches) {
          return array(
            'post_type'      => 'cpts',
            'meta_key' => 'cpts_meta_key',
                'meta_value' => $matches['meta_value'],
          );
        },
        array(
            'group' => 'archive-custom-post-type'
        )
    ));
});

When a custom post can't be found this still displays archive-cpts.php template instead of 404 page. I can see error404 class in body tag of the template though. Did I miss something? Could you point it out, please?

[gmazzap]

Hi @boneus

You did not miss anything.

Adding a QueryRoute means that when the URL you define is matched, WordPress will use the query arguments you define.

Adding a template property to a route (directly or via a group does not really change) means that Cortex will add a filter to template_include, which is a filter that is fired for all requests, including 404.

So what you described is the expected behavior:

1. your URL matches
2. the query is performed as required
3. the template_include filter is added as required
4. your template includes some body_class() call in it, which because the query was 404, includes error404.

What you want is to "filter the template only if not 404". which is not something that Cortex can do out of the box.

But you have at least two different possibilities to obtain that result.

The first and probably simplest way is to change your archive-cpts.php to contain on top of it something like this:

<?php
if (is_404()) {
    locate_template(['404.php', 'index.php'], true);
    return;
}

// rest of template here

This way when your template is loaded, in the case of a 404 request, it will look for a 404.php template in the child theme if any, and then in theme, and if not found it will fall back to index.php as WordPress would do.

An alternative would be to remove the filter added by Cortex when is a 404.

You can do that quite easily, because for 404 requests WordPress will trigger the 404_template filter so you could do:

add_filter('404_template', function () {
  remove_all_filters('404_template');     // Cortex adds a filter here as well
  remove_all_filters('template_include');
}, 1); // act early, before Cortex

I've not tested this, but I expect it to work.

[boneus]

Thank you for the explanation. I've actually already implemented something similar to the second approach but I wasn't sure if it's the right one :)