Wiele lat temu stworzyłem WordPress Widget Boilerplate, który miał być następujący:
Zorganizowany, łatwy w utrzymaniu schemat do tworzenia widżetów przy użyciu najlepszych praktyk WordPressa.
Od tego czasu niewiele się zmieniło w odniesieniu do Widgets API (któremu przyjrzymy się w dalszej części tego postu), ale zmieniło się to, co uważam za „najlepsze praktyki". przykład wprowadzającego programowania obiektowego w WordPressie jest wysoki.
Nie dlatego, że używa wielu zasad zorientowanych obiektowo, nie dlatego, że używa nowoczesnych standardów (przynajmniej jeśli chodzi o współczesne PHP), ale dlatego, że używa kilku rzeczy, które pomagają nam rozpoznać kilka, powiedzmy, sygnały dotyczące programowania obiektowego w WordPressie.
I to jest coś, czego nie należy lekceważyć: jeśli szukasz przykładów programowania obiektowego w WordPressie, poszukaj interfejsów API, które go wykorzystują.
Co więcej, jeśli szukasz sposobów na ocenę własnego poziomu oceny fragmentu kodu (nie mówiąc już o bazie kodu) pod kątem użycia klas i niektórych bardziej zaawansowanych funkcji OOP, to dlaczego nie mieć jakiegoś papierku lakmusowego, aby zobaczyć, jak się masz?
A Widgets API właśnie to robi.
Widżety WordPress: wprowadzenie
Więc w mniejszej serii niż moja ostatnia, zamierzam przyjrzeć się API Widgets i zrobić kilka rzeczy:
- pokazać podstawowy szkielet widżetu i dlaczego jest zorientowany obiektowo,
- przedyskutuj, jakie rzeczy powinieneś być w stanie zauważyć i dlaczego,
- najpierw zaktualizuj Widget Boilerplate bezpośrednio na tej stronie, a następnie wyślij go do GitHub,
- zbuduj widget wykorzystując API z boilerplate jako fundament naszej pracy.
W tym poście zaczniemy od pierwszego punktu powyżej.
Ale najpierw…
Zanim przejdę do tego postu, polecam przeczytanie następujących postów:
- Dwa filary programowania obiektowego: część 1 z 2
- Dwa filary programowania obiektowego: część 2 z 2
- Klasy abstrakcyjne, część 1 – zachowanie abstrakcji
- Klasy abstrakcyjne, część 2 – Klasy abstrakcyjne i interfejsy
Po zakończeniu (lub jeśli czujesz, że już znasz tematy), jesteśmy gotowi do pracy.
[ogranicz płatne=”prawda”]
Podstawy API widżetów
Jeśli przeczytasz stronę podręcznika na temat widżetów, zobaczysz dużo treści. To dobra rzecz, ale nie zawsze jest to najlepszy ruch, gdy próbujesz destylować treść do odbiorców takich jak ty, gdy szukasz praktycznych, zorientowanych na przedmiot porady.
Wybiorę więc odpowiednie części z dokumentacji API, a następnie zastosuję je do dostarczonego przez nas kodu.
Co to jest widżet?
Myślę, że większość z nas, którzy pracują z WordPressem, wie, czym jest widżet, ale ważne jest, aby zdefiniować ten termin, więc wszyscy pracujemy nad tym samym pomysłem. W podręczniku czytamy:
Widżet to obiekt PHP, który generuje kod HTML. Ten sam rodzaj widżetu może być używany wielokrotnie na tej samej stronie (np. widżet tekstowy). Widgety mogą zapisywać dane w bazie danych (w tabeli opcji).
Mając to na miejscu, spójrzmy na kod niestandardowego widżetu, przynajmniej jego fragment, i zobaczmy, co możemy zebrać, jeśli chodzi o jego obiektową naturę.
Klasa widżetów
Zanim jeszcze spojrzymy na kod, wiemy, że będzie pewien poziom programowania obiektowego, ponieważ dokumentacja mówi nam, abyśmy zrobili trzy rzeczy:
- Utwórz klasę widżetu, rozszerzając standardową klasę WP_Widget i niektóre z jej funkcji.
- Zarejestruj widżet, aby był dostępny na ekranie Widżety.
- Upewnij się, że Twój motyw ma co najmniej jeden obszar widżetów, w którym można je dodać.
W tym poście skupię się na pierwszym punkcie (chociaż w końcu dowiemy się, jak wprowadzamy nasze widżety do motywu przed zakończeniem serii).
Ułóżmy więc kod tak, jak jest przedstawiony w dokumentacji i porozmawiajmy o tym, czego możemy się z niego nauczyć:
<?php
class AcmeWidget extends WP_Widget
{
public function __construct()
{
}
public function widget($args, $instance)
{
}
public function form($instance)
{
}
public function update($newInstance, $oldInstance)
{
}
}Po pierwsze, zauważamy, że chociaż zdefiniowaliśmy klasę (którą możemy nazwać jak tylko chcemy, na swój sposób), musi ona rozszerzać WP_Widget. Oznacza to, że w rdzeniu WordPressa znajduje się klasa WP_Widget. Na tej stronie możesz zobaczyć dobrze zorganizowany podział kodu źródłowego .
Po drugie, słowo kluczowe extends wskazuje, że używamy dziedziczenia PHP, które jest podstawowym filarem programowania obiektowego.
Po trzecie, są cztery funkcje, które musimy zaimplementować, z których dwie wymagają argumentów. Funkcje, które musimy zaimplementować to:
- __construct(), który jest podstawowym konstruktorem klasy. W tym miejscu musimy upewnić się, że wywołany zostanie konstruktor klasy nadrzędnej, jeśli taki istnieje, a następnie zainicjować wszystkie właściwości, które uznamy za niezbędne dla naszego widżetu. Przyjrzymy się temu w dalszej części serii.
- widget() odpowiada za wyświetlanie zawartości widżetu udostępnianego przez użytkownika za pomocą interfejsu w obszarze administracyjnym. Przyjmuje dwa parametry — $args i $instance. Parametr $args to informacje, które mają być renderowane na stronie, a $instance to odwołanie do instancji widżetu (ponieważ wiele widżetów może być renderowanych na stronie).
- form() wyświetla interfejs administracyjny, z którym użytkownik wchodzi w interakcję, aby kierować tym, co jest wyświetlane w interfejsie witryny. Wymaga również argumentu $instance, więc podane informacje dotyczą rzeczywistego widżetu, z którym pracuje użytkownik (w przeciwieństwie do wszystkich wystąpień widżetu).
- update() służy do zapisywania wartości w bieżącej instancji widżetu. Przyjmuje dwa argumenty. Pierwszym z nich jest nowa instancja widżetu z wartościami aktualizacji, które podał użytkownik (pomyśl o aktualizacji wartości aktywnego widżetu tekstowego), a drugim argumentem jest stara instancja widżetu lub może poprzednia instancja, a może „ instancja, która posiadała poprzednie wartości”.
Te cztery funkcje są wymagane do zaimplementowania jako część Widget API, jako część dziedziczenia funkcji z rozszerzonego interfejsu oraz do stworzenia podstawowej funkcjonalności widgetu.
Nie oznacza to, że nie można dodać więcej, ale w dobrym zorientowaniu obiektowym prawdopodobnie najlepiej byłoby przenieść to zachowanie do innych klas. Ale przyjrzymy się temu w dalszej części serii, kiedy tworzymy własny widżet.
Jakie są kluczowe dania na wynos?
Aby upewnić się, że mam jasność co do tego, co zostanie zrozumiane z tego postu, oto:
- Widgets API jest zorientowany obiektowo. Jest nie tylko zorientowany obiektowo, ponieważ używa klasy (choć jest to z pewnością dobry punkt wyjścia), ale także dlatego, że dziedziczy funkcjonalność wbudowanej w istniejącą wcześniej klasę bazową.
- Ilekroć dziedziczymy zachowanie z klasy bazowej lub klasy nadrzędnej, otrzymujemy wstępnie opracowaną funkcjonalność za darmo. To naprawdę świetna rzecz w programowaniu obiektowym, ponieważ pozwala nam skupić się konkretnie na logice programowania, którą chcemy zaimplementować.
Wyobraź sobie przez chwilę, że chcesz stworzyć widżet, ale za każdym razem, gdy to robisz, musisz napisać wszystkie funkcje, aby podpiąć się do WordPressa, aby wykonać tę samą, powtarzalną funkcjonalność szablonową.
W tym miejscu w grę wchodzi dziedziczenie i programowanie obiektowe. Powtarzający się kod jest abstrahowany do klasy bazowej, więc jest pisany tylko raz, a następnie kod, na którym chcemy się skupić, pozostawiamy do zaimplementowania.
Wszystko powyższe należy rozumieć, czytając ten wstępny fragment w kodzie źródłowym podstawowego, obiektowego interfejsu API w WordPress.
Co dalej?
W następnym poście z tej serii przyjrzymy się obiektowej naturze API widżetów i tym, jakie rzeczy powinieneś być w stanie natychmiast wykryć, czytając kod.
Dzieje się tak, ponieważ ważne jest, aby w praktyce rozpoznać pewne zasady zorientowane obiektowo i jest to dobry sposób, aby ocenić, czy jesteś w stanie to zrobić, czy nie. Jeśli tak, to świetnie! Wtedy będzie nadal pomagał rozwijać ten mięsień. Jeśli nie, nie martw się – to i tak pomaga ci rozwijać mięśnie.
I będzie ci to dobrze służyć, ponieważ nadal będziemy coraz bardziej angażować się w programowanie obiektowe WordPress za pomocą praktycznych środków.
Niezbędna teoria została omówiona. Zacznijmy więc od praktycznego zastosowania tego.