Discussion :

[laclac]

Bonjour à tous,

J’ai besoin de votre expertise sur WordPress.
Je possède une petite boutique en ligne et j’aimerais ajouter un compteur pour afficher le temps restant avant la fin de la promotion.
J’ai donc programmé un compteur en PHP en utilisant le timestamp de la fin de la promo et celui de l’heure du serveur (je ne voulais pas qu’il soit côté client).

Cela donnait brièvement (et de manière simplifiée) quelque chose comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
<script>
	var countPromo = parseInt("<?php echo $timestampPromo; ?>");
	var nowInUTCMinus6 = parseInt("<?php echo $timestampNow; ?>");
	var countdownfunction = setInterval(function () {
		var timer = countPromo - nowInUTCMinus6;
		document.getElementById("timer").innerHTML = timer;
		nowInUTCMinus6 = nowInUTCMinus6 + 1;
	}, 1000);
</script>

Cela fonctionnait très bien, sauf que… le cache a fait son apparition.
La page était mise en cache avec les valeurs statiques, et du coup, quand l’utilisateur revenait sur la page, le cache prenait le relais, affichant non plus le compteur mis à jour, mais celui à la date de sa mise en cache.
Catastrophe ! D’autant plus que le cache joue un rôle important dans la performance de mon site, et je ne souhaite pas le désactiver.

J’ai donc décidé de revoir la conception de ce compteur.
Je me suis dit que la page produit pouvait être mise en cache, mais que je devais « externaliser » les valeurs du compteur.
J’ai donc créé une API qui retourne les deux timestamps pour un produit donné.

J’ai modifié le fichier functions.php en ajoutant ce code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
add_action('rest_api_init', function () {
	register_rest_route('custom/v1', '/counter/(?P<product_id>\d+)', array(
		'methods' => 'GET',
		'permission_callback' => '__return_true',
		'callback' => function ($data) {
			$product_id = $data['product_id'];
			$date_expire = get_field('date_fin_promo', $product_id);
			$date = new DateTime($date_expire);
			$date->setTimezone(new DateTimeZone('UTC'));
			$countDownDate = $date->getTimestamp();
 
			$now = new DateTime('now', new DateTimeZone('UTC'));
			$nowInUTCMinus6 = $now->getTimestamp();
 
			return new WP_REST_Response([
				'countDownDate' => $countDownDate,
				'nowInUTCMinus6' => $nowInUTCMinus6,
			], 200);
		},
	));
});

La page produit effectue donc un appel AJAX vers l’API pour récupérer les données.
Bien que je n’aie pas encore effectué beaucoup de tests, cela semble fonctionner correctement !
J’aimerais avoir votre avis : pensez-vous que ma conception est judicieuse, ou voyez-vous une meilleure approche ?

Egalement, je rencontre un problème : c’est que mon hébergeur bloque par défaut les appels aux API WordPress sans authentification (pour les utilisateurs non connectés). Je suis donc obligé de désactiver la protection WordPress de mon hébergeur (o2switch), car il n’y a pas d’option spécifique pour cela, afin que l’appel fonctionne.
Je suis un peu hésitant, car je me demande si cela pourrait ouvrir la « porte de Pandore »…

Merci pour vos retours !

[mathieu]

je pense que vos soucis ne concernent pas le développement ou wordpress mais sont plutot du côté de l'hébergement.
si l'hébergeur vous oblige à utiliser un cache et bloque certaines fonctionnalités, cela vous fait perdre du temps en développement.

c'est peut-être le moment d'étudier si cela ne vaut pas la peine d'augmenter le budget hébergement et maintenance et trouver un autre hébergeur.

[laclac]

Non je me suis peut etre mal fait comprendre. Mon hébergeur m'oblige pas à activer mon cache.
C'est juste que le cache joue un role très important sur mon site pour améliorer les performances de mon site et dans le référencement.
Je ne souhaite donc pas désactiver le cache et dégrader mon site si c'est possible.
Et ca semble l'être.

Il serait donc dommage de désactiver le cache si en 2,3 lignes de code on peut externaliser les 2 variables qui posent probleme.
Et c'est ce que j'ai fait.

[BKaernel]

Pourquoi tu ne veux pas que le compteur soit coté client ?
En JS ce serait peut-être plus facile à gérer.

Tu vas la chercher où ta valeur $timestampPromo ? via get_field - Dans la base de donnée ?

Quand à O2Switch (je n'ai pas d'actions) ils n'obligent à pas grand chose. Au contraire !
Ils proposent même un cache objet REDIS ce que les autres ne font pas forcément (OVH notamment).

[laclac]

Pourquoi tu ne veux pas que le compteur soit coté client ?

Coté client ca n'est pas fiable car l'utilisateur pourra avoir n'importe quel heure et donc avoir un compteur faux.
Celà pourrait générer des réclamations clients indiquant qu'ils voyaient un tarif réduit alors qu'ils ont payé plein pot.
C'est donc pas envisageable de laisser un compteur coté client.

[BKaernel]

J'ai bien compris, mais ce n'est pas le chrono qui compte c'est la date de commande qui sera la preuve.
Ton timestamp est unique ($date_promo = 1733467853 (2024-12-06T06:57:43+0000) )
à partir de là... si date () < $date_promo la promo s'applique. Sinon, la promo ne s'applique pas. C'est binaire.

Le compteur c'est juste un affichage... Il est important mais ce n'est pas lui qui contrôle.
Quand au problème d'affichage de compteur, pourquoi serait il faux ?
Si tu as ta $date_promo qui est fixe, tu fait un décompte par rapport au temps universel.
Avec çà y'a pas tu as 2 références qui sont fixes. Je ne vois pas comment çà peut buguer.

C'est quoi le système ? Prestashop ?