Eliminar el slug de las URLs de entradas de tipos de contenido personalizados

Al revisar las respuestas aquí, creo que hay espacio para una mejor solución que combine algunas cosas que aprendí anteriormente y agregue detección automática y prevención de slugs de publicaciones duplicados.

NOTA: Asegúrate de cambiar 'custom_post_type' por el nombre de tu propio CPT en todo mi ejemplo a continuación. Hay muchas ocurrencias, y un 'buscar/reemplazar' es una manera fácil de capturarlas todas. Todo este código puede ir en tu functions.php o en un plugin.

Paso 1: Deshabilita las reescrituras en tu tipo de publicación personalizado configurando rewrites a 'false' cuando registres el post:

register_post_type( 'custom_post_type',
    array(
        'rewrite' => false
    )
);

Paso 2: Agrega manualmente nuestras reescrituras personalizadas al final de las reescrituras de WordPress para nuestro custom_post_type

function custom_post_type_rewrites() {
    add_rewrite_rule( '[^/]+/attachment/([^/]+)/?$', 'index.php?attachment=$matches[1]', 'bottom');
    add_rewrite_rule( '[^/]+/attachment/([^/]+)/trackback/?$', 'index.php?attachment=$matches[1]&tb=1', 'bottom');
    add_rewrite_rule( '[^/]+/attachment/([^/]+)/feed/(feed|rdf|rss|rss2|atom)/?$', 'index.php?attachment=$matches[1]&feed=$matches[2]', 'bottom');
    add_rewrite_rule( '[^/]+/attachment/([^/]+)/(feed|rdf|rss|rss2|atom)/?$', 'index.php?attachment=$matches[1]&feed=$matches[2]', 'bottom');
    add_rewrite_rule( '[^/]+/attachment/([^/]+)/comment-page-([0-9]{1,})/?$', 'index.php?attachment=$matches[1]&cpage=$matches[2]', 'bottom');
    add_rewrite_rule( '[^/]+/attachment/([^/]+)/embed/?$', 'index.php?attachment=$matches[1]&embed=true', 'bottom');
    add_rewrite_rule( '([^/]+)/embed/?$', 'index.php?custom_post_type=$matches[1]&embed=true', 'bottom');
    add_rewrite_rule( '([^/]+)/trackback/?$', 'index.php?custom_post_type=$matches[1]&tb=1', 'bottom');
    add_rewrite_rule( '([^/]+)/page/?([0-9]{1,})/?$', 'index.php?custom_post_type=$matches[1]&paged=$matches[2]', 'bottom');
    add_rewrite_rule( '([^/]+)/comment-page-([0-9]{1,})/?$', 'index.php?custom_post_type=$matches[1]&cpage=$matches[2]', 'bottom');
    add_rewrite_rule( '([^/]+)(?:/([0-9]+))?/?$', 'index.php?custom_post_type=$matches[1]', 'bottom');
    add_rewrite_rule( '[^/]+/([^/]+)/?$', 'index.php?attachment=$matches[1]', 'bottom');
    add_rewrite_rule( '[^/]+/([^/]+)/trackback/?$', 'index.php?attachment=$matches[1]&tb=1', 'bottom');
    add_rewrite_rule( '[^/]+/([^/]+)/feed/(feed|rdf|rss|rss2|atom)/?$', 'index.php?attachment=$matches[1]&feed=$matches[2]', 'bottom');
    add_rewrite_rule( '[^/]+/([^/]+)/(feed|rdf|rss|rss2|atom)/?$', 'index.php?attachment=$matches[1]&feed=$matches[2]', 'bottom');
    add_rewrite_rule( '[^/]+/([^/]+)/comment-page-([0-9]{1,})/?$', 'index.php?attachment=$matches[1]&cpage=$matches[2]', 'bottom');
    add_rewrite_rule( '[^/]+/([^/]+)/embed/?$', 'index.php?attachment=$matches[1]&embed=true', 'bottom');
}
add_action( 'init', 'custom_post_type_rewrites' );

NOTA: Dependiendo de tus necesidades, es posible que desees modificar las reescrituras anteriores (¿deshabilitar trackbacks? ¿feeds?, etc.). Estas representan los tipos de reescrituras 'predeterminadas' que se habrían generado si no hubieras deshabilitado las reescrituras en el paso 1.

Paso 3: Vuelve a hacer que los enlaces permanentes a tu tipo de publicación personalizado sean 'bonitos'

function custom_post_type_permalinks( $post_link, $post, $leavename ) {
    if ( isset( $post->post_type ) && 'custom_post_type' == $post->post_type ) {
        $post_link = home_url( $post->post_name );
    }

    return $post_link;
}
add_filter( 'post_type_link', 'custom_post_type_permalinks', 10, 3 );

NOTA: Puedes detenerte aquí si no te preocupa que tus usuarios creen una publicación conflictiva (duplicada) en otro tipo de publicación que generará una situación en la que solo una de ellas podrá cargarse cuando se solicite la página.

Paso 4: Prevenir slugs de publicaciones duplicados

function prevent_slug_duplicates( $slug, $post_ID, $post_status, $post_type, $post_parent, $original_slug ) {
    $check_post_types = array(
        'post',
        'page',
        'custom_post_type'
    );
    
    if ( ! in_array( $post_type, $check_post_types ) ) {
        return $slug;
    }

    if ( 'custom_post_type' == $post_type ) {
        // Guardando una publicación de custom_post_type, verifica duplicados en los tipos de publicación POST o PAGE
        $post_match = get_page_by_path( $slug, 'OBJECT', 'post' );
        $page_match = get_page_by_path( $slug, 'OBJECT', 'page' );

        if ( $post_match || $page_match ) {
            $slug .= '-duplicado';
        }
    } else {
        // Guardando un POST o PAGE, verifica duplicados en el tipo de publicación custom_post_type
        $custom_post_type_match = get_page_by_path( $slug, 'OBJECT', 'custom_post_type' );

        if ( $custom_post_type_match ) {
            $slug .= '-duplicado';
        }
    }

    return $slug;
}
add_filter( 'wp_unique_post_slug', 'prevent_slug_duplicates', 10, 6 );

NOTA: Esto agregará la cadena '-duplicado' al final de cualquier slug duplicado. Este código no puede prevenir slugs duplicados si ya existen antes de implementar esta solución. Asegúrate de verificar primero si hay duplicados.

Me encantaría recibir comentarios de cualquier otra persona que pruebe esto para ver si también funcionó bien para ellos.

Escribe el siguiente código en el registro de la taxonomía.

'rewrite' => [
  'slug' => '/',
  'with_front' => false
]

Lo más importante que debes hacer después de cambiar el código

Después de haber modificado el documento de taxonomía de tu tipo de entrada personalizado, intenta ir a Ajustes > Enlaces permanentes y vuelve a guardar tus ajustes, de lo contrario obtendrás un error 404 página no encontrada.

Intenté resolver esto hace poco y la respuesta corta, por lo que sé, es no. Al menos no desde el argumento de reescritura (rewrite).

La explicación larga se hace evidente si miras el código real de register_post_type en wp-includes/post.php línea 1454:

add_permastruct( $post_type, "{$args->rewrite['slug']}/%$post_type%", $permastruct_args );

Puedes ver que antepone $args->rewrite['slug'] a la etiqueta de reescritura %$post_type%. Uno podría pensar "entonces simplemente establezcamos el slug como null", hasta que miras unas líneas más arriba:

if ( empty( $args->rewrite['slug'] ) )
    $args->rewrite['slug'] = $post_type;

Puedes ver que la función siempre espera un valor de slug que no esté vacío y, de lo contrario, usa el tipo de publicación (post type).

Resumen de Plugins

Estamos casi en 2020 y muchas de estas respuestas ya no funcionan. Aquí está mi propio resumen de las opciones actuales:

• La respuesta de Matt Keys parece ser la única en el camino correcto si buscas una solución de código personalizado. Ninguno de los plugins que encontré puede hacer todo lo listado aquí, especialmente la verificación de duplicados. Este enfoque parece una gran oportunidad para un plugin si alguien quisiera tomarlo.
• Permalink Manager Lite
  • El mejor de los plugins gratuitos que probé.
  • Ofrece control completo sobre toda la estructura de enlaces permanentes de Páginas/Posts/CPTs y permite que sean iguales. La interfaz gráfica es, con mucho, la más completa en funciones.
  • Permite anulación completa por cada post y también te permite ver cuál sería el enlace original/predeterminado y restablecerlo si es necesario.
  • Soporta multisitio.
  • No verifica duplicados entre tipos de post, lo cual es lamentable. Si una página y un CPT tienen la misma URL, la página se carga y el CPT es inaccesible. Sin advertencias ni errores, solo debes hacer tu propia verificación manual de duplicados.
  • Todas las funciones de taxonomía están en la versión PRO. Los recordatorios para actualizar son bastante intensos.
• Custom Permalinks
  • La versión gratuita hace mucho. Los enlaces permanentes de taxonomía y el soporte premium parecen ser las únicas cosas reservadas para la versión pro.
  • Permite cambiar el enlace permanente completo para cualquier página/post/CPT individual.
  • Soporta multisitio.
  • No permite cambiar la estructura predeterminada, por lo que tus Custom Post Types seguirán siendo ejemplo.com/cpt-slug/post-title pero puedes cambiarlos individualmente.
  • No verifica duplicados entre tipos de post, lo cual es lamentable.
• Custom Post Type Permalinks
  • Permite a usuarios no desarrolladores cambiar las cosas que ya son fáciles de cambiar con register_post_type
  • No permite cambiar el slug base del CPT, solo la parte que viene después, por lo que prácticamente inútil para desarrolladores y para el tema de esta pregunta.
• remove base slug... - muerto desde hace varios años... no usar.

En respuesta a mi respuesta anterior: por supuesto podrías establecer el parámetro rewrite como false al registrar un nuevo tipo de entrada y manejar las reglas de reescritura tú mismo de la siguiente manera

<?php
function wpsx203951_custom_init() {

    $post_type = 'event';
    $args = (object) array(
        'public'      => true,
        'label'       => 'Eventos',
        'rewrite'     => false, // siempre establece esto como false
        'has_archive' => true
    );
    register_post_type( $post_type, $args );

    // estos son tus argumentos reales de reescritura
    $args->rewrite = array(
        'slug' => 'calendario'
    );

    // todo lo que sigue es de la función register_post_type
    if ( is_admin() || '' != get_option( 'permalink_structure' ) ) {

        if ( ! is_array( $args->rewrite ) )
            $args->rewrite = array();
        if ( empty( $args->rewrite['slug'] ) )
            $args->rewrite['slug'] = $post_type;
        if ( ! isset( $args->rewrite['with_front'] ) )
            $args->rewrite['with_front'] = true;
        if ( ! isset( $args->rewrite['pages'] ) )
            $args->rewrite['pages'] = true;
        if ( ! isset( $args->rewrite['feeds'] ) || ! $args->has_archive )
            $args->rewrite['feeds'] = (bool) $args->has_archive;
        if ( ! isset( $args->rewrite['ep_mask'] ) ) {
            if ( isset( $args->permalink_epmask ) )
                $args->rewrite['ep_mask'] = $args->permalink_epmask;
            else
                $args->rewrite['ep_mask'] = EP_PERMALINK;
        }

        if ( $args->hierarchical )
            add_rewrite_tag( "%$post_type%", '(.+?)', $args->query_var ? "{$args->query_var}=" : "post_type=$post_type&pagename=" );
        else
            add_rewrite_tag( "%$post_type%", '([^/]+)', $args->query_var ? "{$args->query_var}=" : "post_type=$post_type&name=" );

        if ( $args->has_archive ) {
            $archive_slug = $args->has_archive === true ? $args->rewrite['slug'] : $args->has_archive;
            if ( $args->rewrite['with_front'] )
                $archive_slug = substr( $wp_rewrite->front, 1 ) . $archive_slug;
            else
                $archive_slug = $wp_rewrite->root . $archive_slug;

            add_rewrite_rule( "{$archive_slug}/?$", "index.php?post_type=$post_type", 'top' );
            if ( $args->rewrite['feeds'] && $wp_rewrite->feeds ) {
                $feeds = '(' . trim( implode( '|', $wp_rewrite->feeds ) ) . ')';
                add_rewrite_rule( "{$archive_slug}/feed/$feeds/?$", "index.php?post_type=$post_type" . '&feed=$matches[1]', 'top' );
                add_rewrite_rule( "{$archive_slug}/$feeds/?$", "index.php?post_type=$post_type" . '&feed=$matches[1]', 'top' );
            }
            if ( $args->rewrite['pages'] )
                add_rewrite_rule( "{$archive_slug}/{$wp_rewrite->pagination_base}/([0-9]{1,})/?$", "index.php?post_type=$post_type" . '&paged=$matches[1]', 'top' );
        }

        $permastruct_args = $args->rewrite;
        $permastruct_args['feed'] = $permastruct_args['feeds'];
        add_permastruct( $post_type, "%$post_type%", $permastruct_args );
    }
}
add_action( 'init', 'wpsx203951_custom_init' );

Puedes ver que la llamada a add_permastruct ya no incluye el slug. Probé dos escenarios:

1. Cuando creé una página con el slug "calendario", esa página fue sobreescrita por el archivo del tipo de entrada que también usa el slug "calendario".

2. Cuando creé una página con el slug "mi-evento" y un evento (CPT) con el slug "mi-evento", se muestra el tipo de entrada personalizado.

3. Otras páginas tampoco funcionan. Si miras la imagen de arriba queda claro por qué: la regla del tipo de entrada personalizado siempre coincidirá con un slug de página. Como WordPress no tiene forma de identificar si es una página o un tipo de entrada personalizado que no existe, devolverá un 404. Por eso necesitas un slug para identificar ya sea la página o el CPT. Una posible solución sería interceptar el error y buscar una página que pueda existir similar a esta respuesta.

Antecedentes

Incluso después de buscar por todas partes, no pude encontrar una solución adecuada para eliminar el slug de CPT de los enlaces permanentes que realmente funcione y sea consistente con la forma en que WordPress realmente analiza las solicitudes. Al parecer, todos los demás que buscan la misma solución están en la misma situación que yo.

Resulta que esto es en realidad una solución de dos partes.

1. Eliminar el slug de CPT de los enlaces permanentes
2. Indicar a WordPress cómo encontrar las publicaciones desde los nuevos enlaces permanentes

La primera parte es bastante sencilla y muchas respuestas existentes ya lo hacen correctamente. Esto es lo que parece:

// eliminar slug de CPT de los enlaces permanentes
function remove_cpt_slug( $post_link, $post, $leavename ) {

    if ( $post->post_type != 'custom_post_type' ) {
        return $post_link;
    } else {
        $post_link = str_replace( '/' . $post->post_type . '/', '/', $post_link );
        return $post_link;
    }
}
add_filter( 'post_type_link', 'remove_cpt_slug', 10, 3 );

Ahora, la segunda parte es donde las cosas se complican. Después de resolver la primera parte, tus enlaces permanentes de CPT ya no tienen slugs de CPT. Pero ahora, el problema es que WordPress no sabe cómo encontrar tus publicaciones desde esos nuevos enlaces permanentes porque todo lo que sabe es que los enlaces permanentes de CPT tienen slugs de CPT. Entonces, sin un slug de CPT en el enlace permanente, no puede encontrar tu publicación. Es por eso que cuando haces una solicitud para tus publicaciones en este punto, muestra un error 404 no encontrado.

Así que, todo lo que necesitas hacer ahora es indicar a WordPress cómo encontrar tus publicaciones utilizando los nuevos enlaces permanentes. Pero esta es la parte donde las respuestas existentes no funcionan muy bien. Veamos algunas de esas respuestas como ejemplo:

La siguiente función funciona bastante bien, pero solo funcionará si tu estructura de enlaces permanentes está configurada como Nombre de la publicación.

function parse_request_remove_cpt_slug( $query ) {

    if ( ! $query->is_main_query() || 2 != count( $query->query ) || ! isset( $query->query['page'] ) ) {
        return;
    }

    if ( ! empty( $query->query['name'] ) ) {
        global $wpdb;
        $cpt = $wpdb->get_var("SELECT post_type FROM $wpdb->posts WHERE post_name = '{$query->query['name']}'");

        // Agrega CPT a la lista de tipos de publicación que WP incluirá cuando consulte basado en el nombre de la publicación.
        $query->set( 'post_type', $cpt );
    }
}
add_action( 'pre_get_posts', 'parse_request_remove_cpt_slug' );

La siguiente función funciona bien para tu tipo de publicación personalizado independientemente de la estructura de enlaces permanentes, pero mostrará un error en todos los demás tipos de publicación.

function rewrite_rule_remove_cpt_slug() {

    add_rewrite_rule(
        '(.?.+?)(?:/([0-9]+))?/?$',
        'index.php?custom_post_type=$matches[1]/$matches[2]&post_type=custom_post_type',
        'bottom'
    );
}
add_action( 'init', 'rewrite_rule_remove_cpt_slug', 1, 1 );

Hay otra respuesta que se supone funciona como solución independiente, pero termina causando más problemas que soluciones, como mostrar errores en tus publicaciones de CPT así como en otras. Esta requiere modificar el argumento de reescritura en el registro de tu CPT de la siguiente manera:

'rewrite' => array( 'slug' => '/', 'with_front' => false )

Hasta ahora, todas las respuestas existentes que encontré son como las anteriores. O funcionan parcialmente o ya no funcionan. Esto probablemente se debe a que WordPress no ofrece una manera estandarizada de eliminar el slug de CPT de los enlaces permanentes de tipos de publicación personalizados y, por lo tanto, estas respuestas se basan en considerar escenarios particulares o en una forma poco elegante.

Respuesta

Esto es lo que he ideado al intentar crear una solución que funcione en la mayoría, si no en todos, los escenarios. Esto eliminará correctamente el slug de CPT de los enlaces permanentes de CPT y también indicará a WordPress cómo encontrar publicaciones de CPT desde esos nuevos enlaces permanentes. No reescribe reglas en la base de datos, por lo que no necesitarás volver a guardar tu estructura de enlaces permanentes. Además, esta solución es consistente con la forma en que WordPress realmente analiza las solicitudes para encontrar publicaciones desde enlaces permanentes, lo que ayuda a que sea una solución más aceptable.

Asegúrate de reemplazar custom_post_type con el nombre de tu propio tipo de publicación personalizado. Aparece una vez en cada función, por lo que dos ocurrencias en total.

// eliminar slug de CPT de los enlaces permanentes
function remove_cpt_slug( $post_link, $post, $leavename ) {

    if ( $post->post_type != 'custom_post_type' ) {
        return $post_link;
    } else {
        $post_link = str_replace( '/' . $post->post_type . '/', '/', $post_link );
        return $post_link;
    }
}
add_filter( 'post_type_link', 'remove_cpt_slug', 10, 3 );


// indicar a wordpress cómo encontrar publicaciones desde los nuevos enlaces permanentes
function parse_request_remove_cpt_slug( $query_vars ) {

    // regresar si es el panel de administración 
    if ( is_admin() ) {
        return $query_vars;
    }

    // regresar si los enlaces permanentes bonitos no están habilitados
    if ( ! get_option( 'permalink_structure' ) ) {
        return $query_vars;
    }

    $cpt = 'custom_post_type';

    // almacenar el valor del slug de publicación en una variable
    if ( isset( $query_vars['pagename'] ) ) {
        $slug = $query_vars['pagename'];
    } elseif ( isset( $query_vars['name'] ) ) {
        $slug = $query_vars['name'];
    } else {
        global $wp;
        
        $path = $wp->request;

        // usar la ruta de la URL como slug
        if ( $path && strpos( $path, '/' ) === false ) {
            $slug = $path;
        } else {
            $slug = false;
        }
    }

    if ( $slug ) {
        $post_match = get_page_by_path( $slug, 'OBJECT', $cpt );

        if ( ! is_admin() && $post_match ) {

            // eliminar cualquier elemento de error 404 no encontrado del array query_vars porque ya existe una coincidencia de publicación en CPT
            if ( isset( $query_vars['error'] ) && $query_vars['error'] == 404 ) {
                unset( $query_vars['error'] );
            }

            // eliminar elementos innecesarios del array query_vars original
            unset( $query_vars['pagename'] );
    
            // agregar elementos necesarios al array query_vars
            $query_vars['post_type'] = $cpt;
            $query_vars['name'] = $slug;
            $query_vars[$cpt] = $slug; // esto construye el elemento "cpt=>post_slug"
        }
    }

    return $query_vars;
}
add_filter( 'request', "parse_request_remove_cpt_slug" , 1, 1 );

Consideraciones:

1. Esta solución intencionalmente excluye la estructura de enlaces permanentes Simple de su alcance, ya que no es una de las estructuras de enlaces permanentes bonitos. Por lo tanto, funcionará con todas las estructuras de enlaces permanentes excepto con la Simple.

2. Como WordPress no evita automáticamente la creación de slugs duplicados en diferentes tipos de publicación, puedes encontrar problemas al acceder a publicaciones que tienen los mismos slugs de publicación debido a la pérdida de singularidad en los enlaces permanentes de CPT después de eliminar los slugs de CPT. Este código no incluye ninguna funcionalidad para evitar ese comportamiento, por lo que es posible que desees encontrar una solución separada para abordarlo.

3. En caso de que haya un enlace permanente duplicado, este código priorizará tu CPT sobre los demás y, por lo tanto, mostrará la publicación en tu CPT cuando se solicite.

y podemos hacer algunos cambios a la función mencionada anteriormente:

function na_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( 'post', 'events', 'page' ) );
}
}

a:

function na_parse_request( $query ) {

if ( ! $query->is_main_query() || 2 != count( $query->query ) || ! isset( $query->query['page'] ) ) {
    return;
}

if ( ! empty( $query->query['name'] ) ) {

    global $wpdb;
    $pt = $wpdb->get_var(
        "SELECT post_type FROM `{$wpdb->posts}` " .
        "WHERE post_name = '{$query->query['name']}'"
    );
    $query->set( 'post_type', $pt );
}
}

para establecer el valor correcto de post_type.

Esto funcionó para mí: 'rewrite' => array('slug' => '/')

Para cualquiera que esté leyendo esto y haya tenido problemas con posts hijos como yo, descubrí que la mejor manera era agregar tus propias reglas de reescritura.

El problema principal que tenía era que WordPress trata la redirección de páginas que tienen 2 niveles (posts hijos) de manera un poco diferente a cómo trata 3 niveles de profundidad (hijos de posts hijos).

Esto significa que cuando tengo /tipo-de-post/nombre-del-post/hijo-del-post/ puedo usar /nombre-del-post/hijo-del-post y me redirigirá al que tiene el tipo-de-post al principio. Pero si tengo tipo-de-post/nombre-del-post/hijo-del-post/nieto-del-post, entonces no puedo usar nombre-del-post/hijo-del-post/nieto-del-post.

Al revisar las reglas de reescritura, parece que coincide con cosas diferentes a pagename en el primer y segundo nivel (creo que el segundo nivel coincide con adjuntos) y luego hace algo ahí para redirigirte al post correcto. A tres niveles de profundidad no funciona.

Lo primero que necesitas hacer es eliminar el enlace del tipo de post también de los hijos. Esta lógica debería ocurrir aquí si miras la respuesta de Nate Allen mencionada arriba:

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

Yo usé una mezcla de diferentes condicionales para verificar si el post tenía hijos y cosas por el estilo para llegar al permalink correcto. Esta parte no es muy complicada y encontrarás ejemplos de personas haciéndolo en otros lugares.

El siguiente paso es donde las cosas cambian de la respuesta dada. En lugar de agregar cosas a la consulta principal (que funcionaba para posts personalizados y sus hijos pero no para hijos más profundos), agregué una regla de reescritura que iba al final de las reglas de WordPress para que si pagename no coincidía y estaba a punto de mostrar un 404, haría una última verificación para ver si una página dentro del tipo de post personalizado tenía el mismo nombre, de lo contrario mostraría el 404.

Aquí está la regla de reescritura que usé asumiendo que 'evento' es el nombre de tu CPT:

function rewrite_rules_for_removing_post_type_slug()
{
    add_rewrite_rule(
        '(.?.+?)(?:/([0-9]+))?/?$',
        'index.php?event=$matches[1]/$matches[2]&post_type=event',
        'bottom'
    );
}

add_action('init', 'rewrite_rules_for_removing_post_type_slug', 1, 1);

Espero que esto ayude a alguien más, no pude encontrar nada más que tuviera que ver con hijos de posts hijos y eliminar el slug de esos.

Tuve los mismos problemas aquí y parece que no hay movimiento en el sitio de WordPress. En mi caso particular, donde para publicaciones individuales de blog se necesitaba la estructura /blog/%postname%/, esta solución

https://kellenmace.com/remove-custom-post-type-slug-from-permalinks/

terminó en un montón de errores 404

Pero junto con este maravilloso enfoque, que no utiliza la estructura de enlaces permanentes del backend para las entradas del blog, finalmente funciona de maravilla. https://www.bobz.co/add-blog-prefix-permalink-structure-blog-posts/

Muchas gracias.

Para mí funcionó ahora:

'rewrite' => array( 
'slug' => '/',
'with_front' => false
)

Insertar dentro de la función register_post_type().

Esto es lo que funcionó para mí. Reemplaza podcast con el slug de tu CPT:

add_action('init', function () {
    register_post_type(
        'podcast',
        [
            'rewrite' => false,
        ]
    );
});

add_filter('post_type_link', function ($post_link, $post, $leavename) {
    if (isset($post->post_type) && $post->post_type === 'podcast') {
        $post_link = home_url($post->post_name);
    }

    return $post_link;
}, 10, 3);

add_action('init', function () {
    add_rewrite_rule('(.+?)/?$', 'index.php?podcast=$matches[1]', 'bottom');
});

El plugin "Remove CPT base" funciona correctamente.

https://wordpress.org/plugins/remove-cpt-base/

No necesitas tanto código duro. Simplemente usa un plugin ligero:

• Remove Base Slug From Custom Post

Tiene opciones personalizables.