No use el post_date
campo para nada para lo que no esté hecho. Utilice un metacampo de publicación en su lugar. El post_date
está obligado apost_date_gmt
, se llega extraño efecto secundario, incluso se puede conseguir una fecha anterior a ese.
Por lo tanto, cree metacampos posteriores y consulte aquellos por consulta fiscal . Ignora el campo predeterminado.
En respuesta a su comentario: No use una taxonomía.
- Las taxonomías se crean para permitir múltiples términos por publicación (ignore los formatos de publicación aquí). El esquema no coincide con su caso de uso.
- Las consultas de taxonomía son caras, se ejecutan en tres tablas.
- Tendría que cambiar la interfaz predeterminada para evitar accidentes como asignaciones múltiples. Posible, pero no exactamente simple y quizás no compatible con versiones anteriores.
También comencé un plugin de administrador de libros una vez, desafortunadamente todavía está en estado de borrador ... pero tengo algunas recomendaciones con respecto a las fechas:
Utilice dos tipos de publicaciones: una para el opus, otra para las ediciones reales (el opus
tipo sería padre para varias ediciones). Por lo tanto, puede almacenar la fecha de creación en el opus, la fecha de publicación (el idioma, el editor, el traductor, etc.) en la edición.
Leer Hacer <time>
seguro para los historiadores . Las fechas anteriores a 1970 son difíciles.
Las funciones de fecha y hora de MySQL no pueden manejar todos los casos, usted termina con algunas rutinas personalizadas para ordenar, dependiendo de su solución para (2.).