Usare i transitori di WordPress invece dei cookie?

Ho già scritto sull’utilizzo dei cookie in WordPress in precedenza, ma una delle cose nel farlo è che in genere dopo si attivano nel contesto di un hook init .

Quando si lavora in modo orientato agli oggetti e si tenta di disaccoppiare alcuni elementi logici in modo da poterli utilizzare senza dover fare affidamento su altri hook, è importante trovare il modo di gestirlo.

Altrimenti, il codice diventa strettamente accoppiato e puoi avere hook, chiamate do_action o funzioni anonime dappertutto.

Per simulare la natura dei cookie e la loro caratteristica di scadenza, l’utilizzo dei transitori di WordPress tramite l’ API Transients opportunamente denominata può essere una soluzione praticabile.

Utilizzo dei transitori di WordPress

Se hai familiarità con una qualsiasi delle API di metadati presenti in WordPress, probabilmente hai familiarità con le funzioni che utilizzano. Ciò include operazioni standard come aggiungere, ottenere, aggiornare ed eliminare.

E con WordPress, puoi semplificarlo in molti posti per aggiornare, ottenere ed eliminare perché l’ aggiornamento prima vedrà se esiste un’informazione e, in caso contrario, la aggiungerà.

Progettazione di un’interfaccia di classe

Pertanto, l’interfaccia per una classe che esegue il wrapping dell’API Transient potrebbe essere ridotta a:

• impostare,
• ottenere,
• Elimina.

Dove set sostituisce aggiungi e aggiorna. Inoltre, è bello avere funzioni di supporto come has che ci consentono di scrivere condizionali nel codice che chiama nella libreria.

Ad esempio, se potresti voler fare qualcosa del tipo "se questo non ha valore, restituisci".

Pertanto, l’interfaccia per il codice potrebbe assomigliare a questa:

<?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 );
}

Ci sono anche alcuni avvertimenti da considerare quando si lavora con codice come questo. Cioè, che dire del caso degli utenti autenticati e degli utenti non autenticati?

Quando ciò accade, c’è un altro modo in cui potrebbe essere necessario gestire i dati transitori (a seconda del metodo di implementazione sopra).

Posso coprirlo in un post di follow-up, però.

Una parola di cautela

Ecco una cosa da ricordare, però: non è una buona idea inquinare la tabella delle opzioni di WordPress. Ed è proprio qui che vengono memorizzati i transitori.

Quindi, se hai intenzione di utilizzare i transitori di WordPress, assicurati di non gettare un sacco di valori nel database.

Proprio quello che serve. E se sono necessari molti dati, forse è necessario esaminare l’architettura del codice o considerare un altro tipo di database.