Tipo de publicación jerárquica

6 minutos de lectura

avatar de usuario
usuario2320739

Tengo un problema, después de actualizar a wordpress 4.0, mi tipo de publicación personalizada ya no funciona, así es como registro mi tipo de publicación personalizada:

function my_post_type() {
    $labels = array(
        'name'               => 'Staff'
    );
    $args = array(
        'labels'              => $labels,
        'public'              => true,
        'exclude_from_search' => true,
        'publicly_queryable'  => true,
        'show_ui'             => true,
        'show_in_nav_menus'   => false,
        'show_in_menu'        => true,
        'show_in_admin_bar'   => true,
        'menu_position'       => 20,
        'menu_icon'           => null,
        'capability_type'     => 'post',
        'hierarchical'        => true,
        'supports'            => array('title','editor','thumbnail','custom-fields','page-attributes'),
        'has_archive'         => false,
        'rewrite'             => false,
        'query_var'           => true,
        'can_export'          => true
    );
    register_post_type('my_staff', $args);
}
add_action('init', 'my_post_type');

El problema es que el enlace permanente a este tipo de publicación da 404, si configuro ‘jerárquico’ en falso, todo funciona, pero la cosa es que necesito ‘jerárquico’ configurado en verdadero, ¿alguna solución a esto?

avatar de usuario
ericboles

Me encontré con este mismo problema después de actualizar a WP 4.0 el día de hoy: las vistas de publicaciones individuales de uno de mis tipos de publicaciones personalizadas jerárquicas mostraron 404 después de la actualización.

Investigué un poco en el núcleo de WP para ver qué cambio se hizo que podría estar causando el problema y descubrí esto:

https://core.trac.wordpress.org/changeset/28803

Volver al código anterior solucionó el problema 404 para mí. No puedo decir si esto es una indicación de mi propia implementación deficiente de CPT o un error imprevisto con este cambio en Core. Dicho esto, si otras personas con este problema quisieran probar esta solución, es un cambio relativamente simple.

Reemplace la línea 2558 en /wp-includes/query.php de esto:

if ( ! $ptype_obj->hierarchical ) {

a esto:

if ( ! $ptype_obj->hierarchical || strpos($q[ $ptype_obj->query_var ], "https://stackoverflow.com/") === false ) { 

  • Encontré lo mismo. ¿Se pregunta si esto debería clasificarse como un error?

    – Jahmic

    23 de abril de 2016 a las 13:33

Tuve el mismo problema y pude resolverlo configurando ‘jerárquico’ => falso en los argumentos register_post_type.

$args = array(
    'labels' => $labels,
    'public' => true,
    'publicly_queryable' => true,
    'show_ui' => true, 
    'query_var' => true,
    'has_archive' => true,
    'menu_icon' => '',
    'show_in_menu' => 'bcs-options',
    'rewrite' => array('slug' => 'stories'),
    'capability_type' => 'page',
    'hierarchical' => false,
    'menu_position' => null,
    'supports' => array('title','editor','thumbnail','excerpt','comments','revisions')
);

Todavía pude configurar el padre de la publicación personalizada manualmente en mi código y todo vuelve a funcionar como antes. No estoy seguro de por qué WordPress 4.0 rompió las cosas, pero supongo que tiene que ver con la forma en que la nueva versión maneja los enlaces permanentes para los tipos de publicaciones personalizadas donde la jerarquía se establece en verdadero. Alguien con un conocimiento más profundo de la base del código de WordPress podría elaborar esto.

Todo lo que necesita hacer es agregar $post_type=lo que sea a la línea

$children = wp_list_pages..

por lo que parece

$children = wp_list_pages("title_li=&child_of=".$post->post_parent."&echo=0$post_type=whatever");

Esto te ayudara http://codex.wordpress.org/Function_Reference/wp_list_pages#List_members_of_a_custom_post_type

El mismo problema aqui.

Desarrollamos tipos de publicaciones personalizadas para productos, categorías de productos y proveedores de productos en nuestro Complemento del carrito de compras de WordPress y también una regla de reescritura personalizada para que las URL de los productos puedan ser “bonitas” con los nombres de las categorías en ellas.

Después de la actualización de WordPress 4.0, estos tipos de publicaciones personalizadas jerárquicas se rompieron. La única solución rápida en este momento fue lanzar una actualización, estableciendo jerárquica en falso ya que los productos de todos nuestros clientes mostraban 404 Página no encontrada.

Algo debe haber cambiado en WordPress 4.0. Todavía estamos trabajando en una solución, tratando de encontrar la mejor manera de que vuelvan a ser como eran antes.

avatar de usuario
Pablo

Aunque me encontré exactamente con el mismo problema, no lo vinculé fácilmente con el cambio a WordPress 4.0. Tengo varios tipos de publicaciones personalizadas y solo algunas de ellas devolvían 404 páginas. Fue solo después de ver su pregunta original que me di cuenta de que el problema estaba en esos tipos de publicaciones personalizadas que estaban configuradas como ‘jerárquicas’ => verdaderas. Una vez que configuré ‘jerárquico’ => falso, pude ver la publicación personalizada “problemática”.

Sin embargo, eso también significó que perdí parte de la estructura de enlace permanente/URL que tenía cuando la jerarquía se estableció en verdadero. Entonces, “tipo de publicación personalizada\título principal\título de la publicación” se convirtió en “tipo de publicación personalizada\título de la publicación”.

Terminé configurando un filtro “post_type_link” para volver a agregar el padre al enlace. También tengo una configuración de regla de reescritura para esta estructura de enlace revisada.

Esa solución se inspiró en esta publicación: https://wordpress.stackexchange.com/questions/136786/parent-cpt-child-custom-post-type-url-permalink-relationship

Aunque no usé un parámetro “%” en el slug de reescritura en register_post_type. En cambio, en la función post_type_link, busco el slug y lo reemplazo con el slug original + cualquier prefijo requerido. Descubrí que de esa manera podía mantener el slug original en el enlace, que no está ‘contaminado’ con el parámetro “%”, lo que significa que el enlace sigue siendo útil para mostrar la página de archivo y también el parámetro “%” no aparecer en pan rallado.

Extracto de la registrarse_post_tipo:

'rewrite' => array(
                        'slug' => 'dresses'// 'dresses/%designer%'
                  ),

filtro post_type_link:

add_filter("post_type_link","rewrite_dress",10,2);

function rewrite_dress($link, $post) {
    if(get_post_type($post) === "dress") {
        $designer = get_post($post->post_parent);
        $designer = $designer->post_name . "https://stackoverflow.com/";
        if(!(check_not_empty($designer))) {
         $designer = "";
        }
        //$link     = str_replace("%designer%",$designer,$link);
        $link     = str_replace("dresses/","dresses/" . $designer,$link);
    }
    return $link;

    /*
    originally the slug had a reference in it e.g. %designer%
    we could then do a string replace on it to insert the designer
    but, if you used the breadcrumbs to view the root e.g. /dresses
    then it would actually appear as /dresses/%designer% which isn't wanted.
    */

}

Regla de reescritura:

function rewrite_dress_rules(){
    global $wp_rewrite;
    /* /dresses/designer/dress */
    $q = "dresses/(.*)/(.*)";
    $q = "dresses/([^/]*)/([^/]*)/?";
    add_rewrite_rule($q,'index.php?post_type=dress&designer=$matches[1]&dress=$matches[2]','top');
    // $wp_rewrite->flush_rules(); // !!!
}

add_action("init", 'rewrite_dress_rules' );

Que todo tipo de trabajos para mí. Al menos por el momento. Tendré que estar atento a las futuras actualizaciones de WordPress para ver si tienen algún impacto adicional.

¿Ha sido útil esta solución?