[contact-form-7 404 "Not Found"]

Nombre (requerido)

Correo electrónico (requerido)

Asunto

Mensaje

16 abril, 2016
By Proyd S.L wordpress

Eliminar el slug de la URL de un custom post type

Cuándo registramos un tipo de post personalizado (custom post type) la URL que genera WordPress para ver estos post en el front-end incluye el nombre del tipo post. Por ejemplo, si registramos “receta” como un tipo de post, las URL que genera WordPress serían del tipo “misitio.com/receta/una-receta-riquisima-cualquiera”.

Esta cadena que precede al nombre del post, en este ejemplo “receta”, se conoce como slug. Si no se dice nada, WordPress tomará el parámetro $post_type (vea register_post_type) y lo utilizará como slug pero durante el proceso de registro del tipo de post podemos definir un slug diferente a través del argumento rewrite. Por ejemplo, para tener URL tipo “misitio.com/comida/una-receta-riquisima-cualquiera” manteniendo “receta” como el tipo de post:

add_action( 'init', 'register_my_post_type' );
function register_my_post_type() {
    
    $post_type = "receta";
    $args = array(
            'rewrite'    => array(
                             'slug' => 'comida'
                             )
     );
     register_post_type( $post_type, $args );   
}

Definir slug=> ‘/’

add_action( 'init', 'register_receta_post_type' );
function register_receta_post_type() {
    
    $post_type = "receta";
    $args = array(
            'rewrite'    => array(
                             'slug' => '/'
                             )
     );
     register_post_type( $post_type, $args );   
}

Incluir el tipo post personalizado en el query principal

Las URL generadas mediante el paso anterior generan error 404 por que si no hay slug precedente al nombre del post, WordPress buscará únicamente entre las entradas y páginas (son los tipo de post post y page). Para solucionarlo tenemos que decirle a WordPress que incluya también nuestro custom post type.

El mejor momento para hacerlo es en el evento pre_get_posts, momento en el que todavía podemos modificar el query principal antes de que se ejecute la consulta a la base de datos:

add_action( 'pre_get_posts', 'cyb_include_custom_post_type_in_query' );
function cyb_include_custom_post_type_in_query( $query ) {

     // Si no es el query principal salir
     if ( ! $query->is_main_query() ) {
         return;
     }

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

      // Incluir custom post type en el query
     if ( ! empty( $query->query['name'] ) ) {
          $post_types = array( 'post', 'page', 'receta' );
          $query->set( 'post_type', $post_types );
     }
 }

Solucionar conflictos

En algunas situaciones, al introducir estos cambios que interfieren con el funcionamiento normal de WordPress, el sistema parece no distinguir si se está visualizando una página (page post type) o un tipo de post personalizado. Aunque estemos viendo el contenido correcto, pueden ocurrir otros errores debido a este conflicto. Para solucionarlo podemos comprobar si existe la página con el nombre solicitado y decirle a WordPress si existe o no:

add_action( 'parse_query', 'cyb_parse_query' );
function cyb_parse_query( $wp_query ) {

    if( get_page_by_path($wp_query->query_vars['name']) ) {
        $wp_query->is_single = false;
        $wp_query->is_page = true;
    }

}

NOTA: Si ya tienes registrado tu custom post type y haces los cambios mencionados aquí, es necesario que se reconstruyan las reglas “rewrite”. Para ello ve a la “administración de WordPress” → “Ajustes” → “Enlaces permanentes” y pulsa sobre “Guardar cambios

fuente: Cybmeta

Share:

Deja un comentario