Pisałem już wcześniej o używaniu plików cookie w WordPressie, ale jedną z rzeczy związanych z robieniem tego jest to, że zazwyczaj uruchamiają się one w kontekście zaczepu init .
Pracując w sposób obiektowy i próbując rozdzielić pewne elementy logiki, aby można było ich używać bez konieczności polegania na innych haczykach, ważne jest, aby znaleźć sposoby na poradzenie sobie z tym.
W przeciwnym razie kod staje się ściśle powiązany i możesz mieć hooki, wywołania do_action lub funkcje anonimowe w każdym miejscu.
Aby zasymulować charakter plików cookie i ich funkcję wygaśnięcia, opłacalnym rozwiązaniem może być wykorzystanie transients WordPress za pośrednictwem odpowiednio nazwanego API Transients .
Korzystanie z przejściówek WordPress
Jeśli znasz któryś z interfejsów API metadanych, które są w WordPressie, prawdopodobnie znasz funkcje, z których korzystają. Obejmuje to standardowe operacje, takie jak dodawanie, pobieranie, aktualizowanie i usuwanie.
A dzięki WordPressowi możesz uprościć go w wielu miejscach, aby aktualizować, pobierać i usuwać, ponieważ aktualizacja najpierw sprawdzi, czy istnieje informacja, a jeśli nie, doda ją.
Projektowanie interfejsu klasy
W ten sposób interfejs dla klasy, która otacza API Transients, można by zredukować do:
- ustawić,
- Dostawać,
- kasować.
Gdzie zestaw zastępuje dodawanie i aktualizowanie. Co więcej, fajnie jest mieć funkcje pomocnicze, takie jak has, które pozwalają nam pisać warunki w kodzie, który wywołuje bibliotekę.
Na przykład, jeśli chcesz zrobić coś w stylu „jeśli to nie ma wartości, zwróć".
Tak więc interfejs kodu może wyglądać mniej więcej tak:
<?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 );
}
Podczas pracy z takim kodem należy wziąć pod uwagę pewne zastrzeżenia. To znaczy, co z przypadkiem użytkowników uwierzytelnionych i użytkowników nieuwierzytelnionych?
Kiedy tak się dzieje, istnieje inny sposób, w jaki dane przejściowe mogą wymagać obsługi (w zależności od powyższej metody implementacji).
Mogę to jednak opisać w kolejnym poście.
Słowo ostrzeżenia
Należy jednak pamiętać: zaśmiecanie tabeli opcji WordPressa nie jest dobrym pomysłem. I właśnie tam przechowywane są transjenty.
Więc jeśli zamierzasz używać transjentów WordPress, upewnij się, że nie wrzucasz tony wartości do bazy danych.
Tylko to, co jest potrzebne. A jeśli potrzebnych jest dużo danych, być może musisz przyjrzeć się architekturze swojego kodu lub rozważyć inny rodzaj bazy danych.