Utiliser des transitoires WordPress au lieu de cookies ?
J’ai déjà écrit sur l’utilisation des cookies dans WordPress, mais l’une des choses à faire est qu’ils se déclenchent généralement après dans le contexte d’un crochet d’ initialisation .
Lorsque vous travaillez de manière orientée objet et que vous essayez de découpler certains éléments de logique de manière à pouvoir les utiliser sans avoir à vous fier à d’autres crochets, il est important de trouver des moyens de gérer cela.
Sinon, le code devient étroitement couplé et vous pouvez avoir des crochets, des appels do_action ou des fonctions anonymes partout.
Pour simuler la nature des cookies et leur caractéristique d’expiration, l’utilisation des transitoires WordPress via l’ API Transients bien nommée peut être une solution viable.
Utilisation des transitoires WordPress
Si vous connaissez l’une des API de métadonnées présentes dans WordPress, vous connaissez probablement les fonctions qu’elles utilisent. Cela inclut les opérations standard telles que add, get, update et delete.
Et avec WordPress, vous pouvez le simplifier à de nombreux endroits pour mettre à jour, récupérer et supprimer car la mise à jour va d’abord voir si une information existe et, si ce n’est pas le cas, va l’ajouter.
Concevoir une interface de classe
Ainsi, l’interface d’une classe qui encapsule l’API Transients pourrait être réduite à :
- Positionner,
- obtenir,
- effacer.
Où set remplace add et update. De plus, il est agréable d’avoir des fonctions d’assistance comme has qui nous permettent d’écrire des conditions dans le code qui appelle la bibliothèque.
Par exemple, si vous voulez faire quelque chose comme "si cela n’a pas de valeur, alors retournez".
Ainsi, l’interface du code peut ressembler à ceci :
<?php
/**
* A wrapper for the Transients API. Because using `setcookie` only works in the `init`
* hook of WordPress, then we need a way to simulate it. That's what the purpose of this class
* does.
*
* It will use the ID of the user who is currently logged in (or the PHP's get_current_user value if
* they are not logged in).
*
* @author Tom McFarlin <tom@tommcfarlin.com>
*/
interface DataStore {
/**
* Determines if a transient value already exists identified with the incoming key.
*
* @param string $key The key used to identify the key in the database.
*
* @return bool True if a transient exists; otherwise, false.
*/
public function has( string $key );
/**
* Saves the specified value for 24 hours.
*
* @param string $key The key used to identify the key in the database.
* @param string $value The value to save for 24 hours.
*/
public function set( string $key, string $value );
/**
* Retrieves the transient value from the database.
*
* @param string $key The key used to identify the key in the database.
*
* @return string The value associated with the incoming transient.
*/
public function get( string $key );
/**
* Deletes the transient data.
*
* @param string $key The key used to identify the key in the database.
*/
public function delete( string $key );
}
Il y a aussi quelques mises en garde à prendre en compte lorsque vous travaillez avec du code comme celui-ci. Autrement dit, qu’en est-il du cas des utilisateurs authentifiés et des utilisateurs non authentifiés ?
Lorsque cela se produit, il existe une autre manière de gérer les données transitoires (selon votre méthode d’implémentation ci-dessus).
Je peux couvrir cela dans un post de suivi, cependant.
Un mot d’avertissement
Voici une chose à retenir, cependant: ce n’est pas une bonne idée de polluer le tableau des options de WordPress. Et c’est précisément là que les transitoires sont stockés.
Donc, si vous allez utiliser des transitoires WordPress, assurez-vous de ne pas jeter une tonne de valeurs dans la base de données.
Juste ce qu’il faut. Et si vous avez besoin de beaucoup de données, vous devrez peut-être examiner l’architecture de votre code ou envisager un autre type de base de données.
