Usando transitórios do WordPress em vez de cookies?

Eu escrevi sobre o uso de cookies no WordPress antes, mas uma das coisas sobre fazer isso é que eles normalmente são disparados no contexto de um gancho de inicialização .

Ao trabalhar de forma orientada a objetos e tentar desacoplar certas partes da lógica de forma que você possa usá-las sem precisar depender de outros ganchos, é importante encontrar maneiras de lidar com isso.

Caso contrário, o código fica bem acoplado e você pode ter ganchos, chamadas do_action ou funções anônimas em todo lugar.

Para simular a natureza dos cookies e seu recurso de expiração, o uso de transientes do WordPress por meio da API Transients apropriadamente nomeada pode ser uma solução viável.

Usando transitórios do WordPress

Se você estiver familiarizado com qualquer uma das APIs de metadados que estão no WordPress, provavelmente está familiarizado com as funções que elas usam. Isso inclui operações padrão como adicionar, obter, atualizar e excluir.

E com o WordPress, você pode simplificá-lo em muitos lugares para atualizar, obter e excluir, porque a atualização primeiro verá se uma informação existe e, se não, a adicionará.

Projetando uma interface de classe

Assim, a interface para uma classe que envolve a API Transients pode ser reduzida para:

• definir,
• pegue,
• excluir.

Onde set substitui add e update. Além disso, é bom ter funções auxiliares como has que nos permitem escrever condicionais no código que chama a biblioteca.

Por exemplo, se você quiser fazer algo como "se isso não tiver valor, então retorne".

Assim, a interface para o código pode ser algo assim:

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

Há algumas ressalvas a serem consideradas ao trabalhar com código como esse também. Ou seja, e o caso de usuários autenticados e usuários não autenticados?

Quando isso acontece, há outra maneira pela qual os dados transitórios podem precisar ser tratados (dependendo do seu método de implementação acima).

Eu posso cobrir isso em um post de acompanhamento, no entanto.

Uma palavra de cautela

Aqui está uma coisa a ser lembrada: não é uma boa ideia poluir a tabela de opções do WordPress. E é precisamente aqui que os transientes são armazenados.

Portanto, se você for usar transientes do WordPress, certifique-se de não lançar uma tonelada de valores no banco de dados.

Apenas o que é necessário. E se muitos dados forem necessários, talvez você precise examinar a arquitetura do seu código ou considerar outro tipo de banco de dados.