Zéro : c’est le nombre de dépendances JavaScript nécessaires pour calculer un temps restant fiable avant la fermeture d’une collecte de dons. Cette précision a son importance, car la première version du compte à rebours livrée à une association avait été codée entièrement côté navigateur, avec l’heure locale du visiteur comparée à une date de fin codée en dur dans le HTML — et un visiteur qui avance l’horloge de son téléphone d’une journée voyait alors un compte à rebours totalement faux.
Le correctif ne consistait pas à ajouter plus de JavaScript, mais à en retirer : déplacer le calcul côté serveur, où l’heure du visiteur n’a strictement aucune influence sur le résultat affiché.
Le problème d’un calcul entièrement côté client
Un compte à rebours calculé uniquement en JavaScript dépend de l’horloge système du visiteur pour connaître l’heure actuelle. Cette horloge peut être fausse pour de multiples raisons : fuseau horaire mal configuré, horloge volontairement modifiée, appareil sans synchronisation automatique. Sur une collecte de dons où le compte à rebours sert d’argument d’urgence, afficher une valeur incohérente nuit à la crédibilité de l’association bien plus qu’un compte à rebours absent.
Calculer la différence côté PHP
La date de fin de la collecte est un champ personnalisé date_fin_collecte sur l’article de la campagne. Le calcul du temps restant s’appuie sur l’heure du serveur, systématiquement réglée sur UTC et exploitée via les fonctions natives de dates de WordPress :
function wpm_temps_restant_collecte( $post_id ) {
$date_fin = get_post_meta( $post_id, 'date_fin_collecte', true );
$timestamp_fin = strtotime( $date_fin );
$maintenant = current_time( 'timestamp', true );
$secondes_restantes = max( 0, $timestamp_fin - $maintenant );
return array(
'jours' => floor( $secondes_restantes / DAY_IN_SECONDS ),
'heures' => floor( ( $secondes_restantes % DAY_IN_SECONDS ) / HOUR_IN_SECONDS ),
'termine' => 0 === $secondes_restantes,
);
}current_time( 'timestamp', true ) renvoie l’heure serveur en UTC, cohérente avec un strtotime() appliqué à une date elle-même stockée sans fuseau horaire ambigu. Mélanger heure locale et heure UTC dans ce genre de calcul est une source d’erreurs fréquente, souvent invisible tant que le site ne change pas d’heure d’été à heure d’hiver.
Afficher le résultat sans JavaScript de calcul
Le gabarit affiche directement les valeurs calculées côté serveur, sans recalcul côté navigateur :
- « Il reste 4 jours et 12 heures avant la fin de cette collecte. »
- Une variante « Collecte terminée » remplace l’affichage quand
terminevaut vrai - La page se régénère à chaque visite via le cache habituel, avec une durée de vie courte (quelques minutes) pour garder l’affichage à jour
Un compte à rebours qui s’anime en temps réel à la seconde près nécessiterait malgré tout un peu de JavaScript pour l’aspect visuel — mais dans ce cas, la valeur de départ transmise au script provient toujours du calcul serveur, jamais d’une date codée en dur côté client.
Distinguer ce compteur de la barre de progression du montant
Ce compte à rebours ne renseigne en rien sur le montant déjà collecté par rapport à l’objectif : c’est une information strictement temporelle, indépendante du module de paiement Stripe utilisé par ailleurs pour encaisser les dons. La barre de progression du montant collecté, qui pose ses propres questions de confidentialité avant l’atteinte d’un seuil, reste un sujet à traiter séparément.
Le cas d’une collecte prolongée en cours de route
L’association a, à deux reprises, décidé de prolonger une collecte au-delà de sa date de fin initiale pour atteindre un objectif tout juste manqué. Comme le calcul repose entièrement sur le champ date_fin_collecte, une simple modification de ce champ dans l’article suffit à recalculer immédiatement un nouveau temps restant cohérent, sans intervention technique ni redéploiement — un avantage direct de garder toute la logique côté serveur plutôt que figée dans un script chargé une fois pour toutes.
En résumé
Un compte à rebours fiable pour une collecte de dons se calcule côté serveur, à partir de l’heure UTC du serveur lui-même, jamais de l’horloge du visiteur. Le gain en robustesse dépasse largement l’effort de migration depuis une version entièrement JavaScript.
