¿Por qué un tipo de entrada personalizada necesita el ajuste 'hierarchical' en los argumentos?
Me cuesta entender algunos aspectos de los CPTs y necesito ayuda. Veo que las taxonomías a menudo necesitan ser jerárquicas, pero no entiendo cómo/cuándo un tipo de entrada personalizada lo sería.
Por ejemplo, tengo un CPT llamado 'proyectos'. Hay una taxonomía registrada para este tipo de entrada llamada 'campos'. Bajo 'campos' tengo muchos sub-elementos como:
- 'Documentales'
- 'Documentales' > 'Autoproducciones'
- 'Documentales' > 'Clásicos'
- 'Corporativos'
- 'Corporativos' > 'Marketing Digital'
- etc...
Para ver un proyecto en 'Documentales' > 'Clásicos' uso esta URL: midominio.com/campo/clasico/
Aquí es donde realmente tengo unas 30 preguntas :) pero solo haré las dos más urgentes:
- ¿Por qué y cómo el CPT 'proyectos' podría ser jerárquico?
- ¿Es posible ver elementos en el campo 'clásico' así: midominio.com/proyectos/clasico (midominio.com/proyectos muestra todos los elementos, pero al profundizar más se rompe)
Agradezco cualquier ayuda, ¡he pasado unas 3 horas probando esto y leyendo sin entenderlo!
¡Gracias!
Abajo está mi código (recortado) como referencia:
function register_cpt_projects() {
$labels = array(
'name' => _x('Proyectos', 'projects'),
// todas las demás etiquetas etc..
);
$args = array(
'labels' => $labels,
'hierarchical' => true,
'supports' => array('title', 'editor', 'author', 'thumbnail'),
'taxonomies' => array('field'),
'public' => true,
'show_ui' => true,
'show_in_menu' => true,
'show_in_nav_menus' => true,
'publicly_queryable' => true,
'exclude_from_search' => false,
'has_archive' => true,
'query_var' => true,
'can_export' => true,
'rewrite' => true,
'capability_type' => 'post'
);
register_post_type('projects', $args);
}
add_action('init', 'register_cpt_projects');
function create_projects_tax(){
register_taxonomy('field', 'projects', array(
'hierarchical' => true,
'label' => 'Campos'
));
}
add_action('init', 'create_projects_tax');

Cuando tienes dos objetos de contenido con una interfaz similar o propiedades compartidas, tienes un buen candidato para tipos de publicaciones jerárquicos.
Tomemos como ejemplo los lugares (ver esta respuesta):
- Asia
- Europa
- Alemania
- Berlín
- Austria
- Viena
- Alemania
Cada lugar tiene metadatos similares: población, coordenadas geográficas, idiomas hablados. Simplemente puedes reutilizar la misma interfaz.
Además, si creas un tipo de publicación personalizado separado para cada tipo de lugar, te encontrarás con la falta de tabla de relaciones entre publicaciones en WordPress.

Gracias, esto podría ser útil entonces. He leído el otro post e intenté averiguar cómo establecer un CPT como padre pero no pude. No veo el menú desplegable de padre en ninguna parte de la página de edición del CPT 'projects'. ¿Importa cuál es el 'capability_type' de mi CPT? Era 'post' pero lo cambié a 'page' y probé, pero aún no aparece el menú desplegable. Tengo varios posts de 'projects' añadidos, así que debería haber algo que pueda ser padre ahí dentro. Muchas gracias hasta ahora :)

Un tipo de entrada personalizada solo necesita el ajuste jerárquico si quieres que el tipo de entrada se comporte como páginas.
Si deseas poder elegir un padre y tener el metabox de orden de menú, también necesitas agregar 'page-attributes' al array de supports.
El argumento hierarchical también te permite tratar los tipos de entrada jerárquicos de manera diferente a otros usando la etiqueta condicional is_post_type_hierarchical()
. Soporta objeto de entrada, nombre del tipo de entrada o ID de entrada como su único parámetro.
¿Es posible ver items en el campo 'clásico' así: midominio.com/proyectos/clasico (midominio.com/proyectos muestra todos los items, pero al navegar más allá se rompe)
Puedes usar el argumento rewrite para definir cómo aparecen las URLs de entradas individuales del tipo de entrada:
slug: El slug con el que te gustaría prefijar tus entradas.
with_front: Si tu tipo de entrada debe usar la base frontal de tu configuración de enlaces permanentes.
'rewrite' => array( 'slug' => 'clasico', 'with_front' => false ),
haría que tus URLs para entradas individuales de proyectos se vean así:
tusitio.com/clasico/nombre-de-la-entrada
Si quieres que tus URLs de archivo sean: midominio.com/proyectos/clasico
necesitarás aplicar reglas de reescritura similares a los argumentos de register_taxonomy.
Tendrías que establecer el slug de reescritura a proyectos y with_front a false. También cabe destacar que el array de reescritura de register_taxonomy también soporta: 'hierarchical' - true o false permite URLs jerárquicas
Esto te permite usar la jerarquía completa en los términos de taxonomía en tus URLs:
