No uses el campo post_date
para nada para lo que no está hecho. Utilice un campo de meta meta en su lugar. El post_date
es vinculado a post_date_gmt
, obtendrías efectos secundarios extraños incluso si pudieras obtener una fecha anterior en eso.
Así que cree los campos de metadatos de la publicación y consulte aquellos por consulta de impuestos . Ignora el campo predeterminado.
En respuesta a tu comentario: No uses una taxonomía.
- Las taxonomías se crean para permitir múltiples términos por publicación (ignore post-format 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 tal vez no compatible con el avance.
También inicié un complemento de administrador de libros una vez, desafortunadamente todavía está en estado de borrador ... pero tengo algunas recomendaciones con respecto a las fechas:
-
Use dos tipos de publicaciones: una para el opus, una para las ediciones reales (el tipo opus
sería un 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.
-
Lea Cómo hacer que <time>
sea seguro para los historiadores . Las fechas anteriores a 1970 son difíciles.
-
Las Funciones de fecha y hora de MySQL no puede manejar todos los casos, termina con algunas rutinas personalizadas para ordenar, dependiendo de su solución para (2).