Fixer la date de publication avant 1970

10

J'ai un type de message personnalisé appelé livres. La date de publication des livres est comprise entre 1700 et 1900.

Je veux définir la date de publication à ces dates (afin que je puisse interroger les résultats triés par année) mais je ne semble pas avoir de date définie avant le 1er janvier 1970.

Est-il possible de faire cela d'une manière ou d'une autre?

passatgt
la source
Pour autant que je
Wyck
J'ai jeté un coup d'œil à cela et la post_datebase de données se règle correctement à n'importe quelle date que j'ai essayée. Cependant, il post_date_gmtest incorrectement défini comme le 1er janvier 1970 - le début du monde . N'essayez donc pas de coopter ce domaine. Faites ce que toscho suggère.
s_ha_dum
+1 belle question! La recherche de 1970 a des résultats intéressants ici et chez SO . Le plugin ne semble pas très bien codé, mais peut valoir le coup d' œil ...
brasofilo

Réponses:

10

N'utilisez le post_datechamp pour rien pour quoi il n'est pas fait. Utilisez plutôt un post-méta-champ. Le post_dateest lié àpost_date_gmt , vous obtiendriez un effet secondaire étrange, même si vous pouviez obtenir une date antérieure à ce sujet.

Créez donc des champs post-méta et interrogez-les par requête fiscale . Ignorez le champ par défaut.

En réponse à votre commentaire: N'utilisez pas de taxonomie.

  1. Les taxonomies sont conçues pour autoriser plusieurs termes par publication (ignorez les formats de publication ici). Le schéma ne correspond pas à votre cas d'utilisation.
  2. Les requêtes taxonomiques sont chères, elles se déroulent sur trois tables.
  3. Vous devrez changer l'interface par défaut pour éviter les accidents comme les affectations multiples. Possible, mais pas exactement simple et peut-être pas compatible en aval.

J'ai aussi lancé un plugin de gestionnaire de livres, malheureusement, il est encore à l'état de projet… mais j'ai quelques recommandations concernant les dates:

  1. Utilisez deux types de publication: un pour l'opus, un pour les éditions réelles (le opustype serait un parent pour plusieurs éditions). Ainsi, vous pouvez stocker la date de création dans l'opus, la date de publication (la langue, l'éditeur, le traducteur, etc.) dans l'édition.

  2. Lisez Rendre <time>les historiens plus sûrs . Les dates avant 1970 sont difficiles.

  3. Les fonctions de date et d'heure MySQL ne peuvent pas gérer tous les cas, vous vous retrouvez avec des routines personnalisées pour le tri, selon votre solution pour (2.).

fuxia
la source
Merci! Mon client m'a envoyé un fichier xml avec les livres et je l'ai importé dans wordpress. Je n'ai que les années pour les livres, j'ai donc décidé de créer une taxonomie personnalisée pour les années, mais j'ai découvert que je ne pouvais pas commander la requête en fonction de cela. Mais si je peux commander par champ personnalisé, je suppose que c'est bien aussi.
passatgt
Permettez-moi de vous demander, qu'en pensez-vous, est-ce une bonne solution pour utiliser une taxonomie personnalisée pour les années? Je pense que je peux créer une requête SQL personnalisée pour trier les résultats en fonction du nom du terme (car la structure de la base de données est également la même avec la solution post meta) et je pense que c'est un peu plus facile de gérer les années + les livres dans le backend .
passatgt
@passatgt Voir ma mise à jour. Bref: non, ne fais pas ça. :)
fuxia
Je l'ai. Il vaut la peine de mentionner que j'ai 25 000 livres :)
passatgt
1

Ce plugin utilise la bibliothèque de dates ADOdb de John Lim de PHP Everywhere, qui est - je cite - "faisant du formatage de date avec des dates antérieures à 1970 un charme".

diggy
la source
Ce plugin fait plus que l'OP demande et il n'est pas clair si le formatage de la date est utilisé en interne par le plugin ou s'il permet également le même formatage de la date pour les fonctions principales de WordPress. Connaissez-vous les réponses à l'une de ces questions?
s_ha_dum
Je voulais juste mettre en évidence la bibliothèque de Lim et comment elle est implémentée dans un plugin WP. Quant à votre deuxième question, les fonctions de base ne sont pas modifiées, le plugin stocke les dates dans une table de base de données personnalisée.
diggy