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 ?