Archivos de Tipos de Publicación Personalizados por Año y Mes
¿Cómo se muestran los archivos de un Tipo de Publicación Personalizado (Custom Post Type) por Año y Mes?
Sí, puedes hacerlo.
Todo lo que necesitas es crear un filtro para wp_get_archives();
para que acepte el parámetro post_type
:
function my_custom_post_type_archive_where($where,$args){
$post_type = isset($args['post_type']) ? $args['post_type'] : 'post';
$where = "WHERE post_type = '$post_type' AND post_status = 'publish'";
return $where;
}
luego llama esto:
add_filter( 'getarchives_where','my_custom_post_type_archive_where',10,2);
Cuando quieras mostrar archivos por tipo de entrada personalizado, simplemente pasa los argumentos post_type:
$args = array(
'post_type' => 'your_custom_post_type',
'type' => 'monthly',
'echo' => 0
);
echo '<ul>'.wp_get_archives($args).'</ul>';

¿Probaste esta solución? Correctamente obtiene la lista de meses con una publicación de tu CPT y el número de publicaciones, pero los enlaces son inútiles. Al hacer clic te lleva al mes para todo el sitio, no para el CPT.

Después de investigar un poco (ver la respuesta de Tom Nowell más abajo), abandoné los archivos mensuales para tipos de contenido personalizados. En su lugar, utilicé una categoría de publicación y cambié mi estructura de enlaces permanentes a /%category%/%year%/%monthnum%/%postname%/
. Luego, podría ser posible usando un hook similar al anterior, modificar los enlaces para que comiencen con /%category%/
en lugar de solo la fecha.

Pregunta sobre esto. Esto crea URLs como: misitio.com/2013/04
pero esto lleva a un 404. El tipo de contenido personalizado está disponible en: misitio.com/gatos
lo que me hace pensar que misitio.com/gatos/2013/04
debería ser el enlace correcto, pero esto también resulta en un 404. ¿Cómo hacer que funcionen los enlaces de archivo?

Mejor aún, finalmente existe un plugin para solucionar esta funcionalidad faltante en WordPress. Fue creado por un colaborador principal que intentó resolver este problema en el núcleo. El plugin se proporciona como solución temporal hasta que el problema se aborde adecuadamente en el núcleo. https://wordpress.org/plugins/archives-for-custom-post-types/

No deberías hacerlo, la postura oficial de los desarrolladores de WordPress es que los tipos de entradas personalizadas (custom post types) no estaban destinados a reemplazar las entradas normales, y que si necesitas archivos de entradas por fechas, etc., entonces no estás haciendo las cosas correctamente, y sería mejor que uses formatos de entrada, etc.
Los tipos de entradas personalizadas están diseñados para aplicaciones web, etc., mientras que configurar un tipo de entrada personalizada que actúe como un blog secundario o paralelo con un nombre diferente, por ejemplo blog vs noticias, con las mismas capacidades, no es para lo que fue diseñada esta función, y podría generar otros problemas técnicos derivados de su implementación.
Si aún insistes en esto, y simplemente usar taxonomías personalizadas y formatos de entrada no es suficiente, podrías agregar reglas de reescritura (rewrite rules) en functions.php y redirigir los archivos por año/mes en ciertas URLs a la página de archivo de entradas, y luego verificar en la página de archivo de entradas personalizadas si has especificado variables en tus reglas de reescritura y cargar una plantilla diferente, asegurándote de establecer los valores apropiados en tus reglas de reescritura.

Parece un poco extraño que solo hayan llegado hasta cierto punto con esta funcionalidad. ¿Puedes darme un ejemplo de cómo deberían usarse las publicaciones personalizadas?

Las publicaciones personalizadas deberían usarse para cualquier cosa que no esté cubierta por el alcance de las páginas y las entradas del blog (o entradas del blog con un nombre diferente pero que funcionen igual, como artículos/noticias/diarios/etc.)
Ejemplos de usos correctos de publicaciones personalizadas incluyen: eventos, menús, ubicaciones, formularios, registros, etc.

Las publicaciones personalizadas son básicamente el medio para producir aplicaciones web, no son el medio para duplicar el menú de publicaciones en el backend para facilitar la edición (y tal uso haría que WordPress fuera mucho más lento y sería una tarea más complicada de lo que crees)

UUUUUf. Esta es trágicamente la respuesta correcta a la pregunta. No puedo creer que la explicación anterior se base en "no deberíamos tener URLs con fechas para CPTs", es casi seguro que "las URLs con fechas para CPTs son demasiado complicadas" es lo que realmente motiva la decisión de no implementarlo. CLARAMENTE hay casos en los que la gente querría archivos por fecha para un tipo de contenido personalizado, no puedes hacer desaparecer ese deseo obvio señalando los formatos de entrada.

Tengo que disentir firmemente. Los tipos de contenido personalizados están diseñados para usarse para lo que quieras usarlos, en ninguna parte del Codex dice que son para "aplicaciones web". Además, podrías necesitar perfectamente una sección de "noticias" que tenga su propia taxonomía personalizada y quisieras archivos para esas. O incluso el sugerido tipo "eventos", que estoy de acuerdo son un uso perfecto para CPTs, pero de nuevo esos podrían fácilmente necesitar archivos basados en fechas.

Una sección de noticias sugiere o un formato de entrada o una taxonomía que indique que has clasificado una entrada como noticia. Un tipo de contenido personalizado no es necesario para algo así. De cualquier manera, siento que tu definición de aplicación web puede no ser la misma que la mía, simplemente definiré mi interpretación en este contexto como cualquier cosa que no sea una página estática, o una entrada de blog, que requiera una representación de contenido similar a una entrada, y te remitiría al desarrollador principal de WordPress que originalmente dijo esto (probablemente Otto o Nacin).

Sin duda definimos las aplicaciones web de manera diferente. La buena noticia es que Jack Lenox de Automattic tiene un plugin que ahora permitirá archivos para CPTs, mira mi respuesta abajo. Así que ahora finalmente podemos crear fácilmente archivos por fecha para cosas como "Eventos" que realmente podrían usar esta funcionalidad.

EDITADO -> aunque esta respuesta todavía funciona para versiones anteriores a WP 4.4, desde la versión 4.4 el soporte para Custom Post Types ahora está incluido en wp_get_archives()
¡Finalmente existe una solución simple, rápida y fácil para los archivos basados en fecha de Custom Post Types en WordPress! Este ha sido un problema de larga data que está registrado aquí en el Trac del núcleo de WP.
Aún no se ha resuelto, pero uno de los contribuidores del Trac ha publicado un plugin simple en GitHub que te permitirá tener archivos basados en fecha para CPTs.
Después de instalar este plugin, o agregar el código manualmente en tus funciones, puedes usar archivos para CPTs de la siguiente manera:
<?php wp_get_archives_cpt( 'post_type=custom_post_type' ); ?>
Nota: esta nueva función wp_get_archives_cpt
funciona igual que la estándar wp_get_archives
, por lo que puedes usar cualquiera de los argumentos regulares que acepta. Sin embargo, simplemente añade la capacidad de incluir un argumento con el nombre del custom post type.

No tengo suficiente reputación para agregar esto a la respuesta de taiken, lo siento.
Sin embargo, quería agregar que su respuesta funcionó para mí, pero los enlaces estaban en el formato 'localhost/date/2010'. Mientras que yo necesitaba el formato 'localhost/postslug/2010'. Pude solucionarlo usando un reemplazo de cadena en la salida de wp_get_archives.
Así que dependiendo de cómo tengas configurados tus enlaces permanentes, este código solucionará el problema 404 y redirigirá los enlaces a la estructura de enlaces permanentes del tipo de publicación personalizado:
$yearly_archive = wp_get_archives(array( 'type' => 'yearly', 'post_type' => '<tu nombre de tipo de publicación>', 'echo' => '0') );
$blog_url = get_bloginfo('url');
echo str_replace(($blog_url . '/date'), ($blog_url . '<tu slug de tipo de publicación>'),$yearly_archive);

No pude agregar al post de takien, así que aquí está lo que terminé teniendo que hacer:
functions.php
add_action('init', 'my_year_archive_rewrites');
function my_year_archive_rewrites() {
add_rewrite_rule('recurso/noticias/([0-9]{4})/pagina/?([0-9]{1,})/?', 'index.php?post_type=news&year=$matches[1]&paged=$matches[2]', 'top');
add_rewrite_rule('recurso/noticias/([0-9]{4})/?', 'index.php?post_type=news&year=$matches[1]', 'top');
}
add_filter('getarchives_where', 'my_custom_post_type_archive_where', 10, 2);
function my_custom_post_type_archive_where($where,$args){
$post_type = isset($args['post_type']) ? $args['post_type'] : 'post';
return "WHERE post_type = '$post_type' AND post_status = 'publish'";
}
add_filter('year_link', 'my_year_link');
function my_year_link($link) {
global $wp_rewrite;
if(true) { // como sea que determines qué archivo quieres
$link = str_replace($wp_rewrite->front, '/recurso/noticias/', $link);
}
return $link;
}
Llamando a wp_get_archives()
wp_get_archives(array('post_type'=>'news', 'type'=>'yearly'));

Esta es tu primera respuesta. Solo un consejo al responder preguntas: no solo agregues código o enlaces. Aunque tu código pueda funcionar, siempre es bueno saber qué hace tu código y por qué debería funcionar. Aparte de eso, tu respuesta está bien formateada. +1 por eso
