He revisado todas las preguntas aquí en enlaces permanentes de tipo de publicación personalizada, pero la mayoría parecen ser problemas con reescrituras de taxonomía personalizadas o la obvia falta de flush_rewrite_rules (). Pero en mi caso, solo estoy usando un tipo de publicación personalizado (sin taxonomía), configurado para ser jerárquico (para poder asignar relaciones padre-hijo), con el "soporte" adecuado para los metabox de atributos, etc., etc. He sonrojado reescribir las reglas de mil maneras diferentes. He probado diferentes estructuras de enlaces permanentes. ¡Pero las URL secundarias siempre resultan en 404!
Originalmente tenía tipos de publicaciones personalizadas independientes para los elementos "padre" e "hijo" (usando p2p), y probablemente no habría tenido problemas para usar una taxonomía para la agrupación "parental": sé que serían semánticamente más precisos. Pero para el cliente, es más fácil para ellos visualizar la jerarquía cuando las "publicaciones" se muestran en el administrador al igual que las páginas: un árbol simple donde los niños aparecen debajo del padre, con el prefijo "-", y en el orden apropiado. Además, se pueden usar varios métodos para asignar el orden mediante arrastrar y soltar. La agrupación a través de la taxonomía (o p2p) da como resultado una lista plana de "publicaciones" en las listas de administración, lo que simplemente no es tan visualmente obvio.
Entonces, lo que busco es literalmente el mismo comportamiento que las "páginas" principales, pero con mi tipo de publicación personalizada. He registrado el tipo de publicación tal como se esperaba, y en el administrador funciona perfectamente: puedo asignar un padre y un menú_orden para cada "publicación" del boletín, aparecen correctamente en las listas de edición:
Spring 2012
— First Article
— Second Article
Y sus enlaces permanentes parecen estar construidos correctamente. De hecho, si cambio algo sobre la estructura, o incluso modifico la ficha de reescritura al registrar el tipo de publicación, se actualizan automáticamente correctamente, por lo que sé que algo funciona:
http://mysite.com/parent-page/child-page/ /* works for pages! */
http://mysite.com/post-type/parent-post/child-post/ /* should work? */
http://mysite.com/newsletter/spring-2012/ /* works! */
http://mysite.com/newsletter/spring-2012/first-article/ /* 404 */
http://mysite.com/newsletter/spring-2012/second-article/ /* 404 */
También tengo "páginas" básicas estándar con relaciones jerárquicas creadas, y se ven igual en el administrador, pero en realidad también funcionan en el front-end (las URL principales y secundarias funcionan bien).
Mi estructura de enlace permanente está establecida en:
http://mysite.com/%postname%/
También intenté esto (solo porque muchas otras respuestas parecían indicar que era necesario, aunque no tenía sentido en mi caso):
http://mysite.com/%category%/%postname%/
Mis registros de CPT incluyen:
$args = array(
'public' => true,
'publicly_queryable' => true,
'show_ui' => true,
'has_archive' => 'newsletter',
'hierarchical' => true,
'query_var' => true,
'supports' => array( 'title', 'editor', 'thumbnail', 'page-attributes' ),
'rewrite' => array( 'slug' => 'newsletter', 'with_front' => false ),
La única diferencia visible entre mis hijos de tipo de publicación personalizada y los hijos de página normales , es que mi CPT tiene la babosa al comienzo de la estructura de enlace permanente, luego seguida de las babosas padre / hijo (donde las páginas solo comienzan con las babosas padre / hijo, sin "prefijo"). Por qué esto arruinaría las cosas, no lo sé. Muchos artículos parecen indicar que así es exactamente como deberían comportarse tales enlaces permanentes de CPT jerárquicos, pero los míos, aunque bien formados, no funcionan.
Lo que también me desconcierta es cuando examino los query_vars para esa página 404: parecen contener los valores correctos para que WP "encuentre" mis páginas secundarias, pero algo no funciona.
$wp_query object WP_Query {46}
public query_vars -> array (58)
'page' => integer 0
'newsletter' => string(25) "spring-2012/first-article"
'post_type' => string(10) "newsletter"
'name' => string(13) "first-article"
'error' => string(0) ""
'm' => integer 0
'p' => integer 0
'post_parent' => string(0) ""
'subpost' => string(0) ""
'subpost_id' => string(0) ""
'attachment' => string(0) ""
'attachment_id' => integer 0
'static' => string(0) ""
'pagename' => string(13) "first-article"
'page_id' => integer 0
[...]
He intentado esto con varios temas, incluyendo veintiocho, solo para asegurarme de que no falte alguna plantilla de mi parte.
Usando Rewrite Rules Inspector, esto es lo que aparece en la url: http://mysite.com/newsletter/spring-2012/first-article/
newsletter/(.+?)(/[0-9]+)?/?$
newsletter: spring-2012/first-article
page:
(.?.+?)(/[0-9]+)?/?$
pagename: newsletter/spring-2012/first-article
page:
cómo se muestra en otra página del inspector:
RULE:
newsletter/(.+?)(/[0-9]+)?/?$
REWRITE:
index.php?newsletter=$matches[1]&page=$matches[2]
SOURCE:
newsletter
Esta salida de reescritura me llevaría a creer que el siguiente enlace permanente "no bonito" funcionaría:
http://mysite.com/?newsletter=spring-2012&page=first-article
No es 404, pero muestra el "boletín" del elemento CPT principal, no el secundario. La solicitud se ve así:
Array
(
[page] => first-article
[newsletter] => spring-2012
[post_type] => newsletter
[name] => spring-2012
)
post_name
columna.