✅ Nowości, motywy, wtyczki WEB i WordPress. Tutaj dzielimy się wskazówkami i najlepszymi rozwiązaniami dla stron internetowych.

Widżety WordPress: Refaktoryzacja, część 7

3

W ostatnich kilku postach wykonaliśmy dużo pracy, aby doprowadzić kod do punktu refaktoryzacji, który zostanie omówiony w tym artykule.

W szczególności omówiliśmy:

Wszystko to odegra pewną rolę w tym, co zrobimy dzisiaj.

WordPress Widget Boilerplate: Refaktoryzacja, część 7

Ci, którzy są zaznajomieni z API WordPress Widgets, prawdopodobnie wiedzą, że nie zmienił się on zbytnio w ciągu ostatnich kilku lat.

Co więcej, tak naprawdę składa się tylko z czterech funkcji (z których jedną jest konstruktor):

  1. Konstruktor odpowiada za ustawienie kilku właściwości widżetu, najczęściej jego nazwy i opisu.
  2. Funkcja widżetu odpowiada za renderowanie zawartości widżetu.
  3. Funkcja formularza odpowiada za wyświetlanie formularza w obszarze administracyjnym WordPressa podczas pracy z widżetem.
  4. Funkcja aktualizacji odpowiada za aktualizację opcji, które są zapisane w bazie danych (lub zainicjowane, a następnie zapisanie opcji, które mogą jeszcze nie istnieć w bazie danych).

Miłą rzeczą jest to, że to szczególne podejście jest osiągane poprzez dziedziczenie funkcjonalności klasy WP_Widget.

Problem polega jednak na tym, że jedna klasa to dużo pracy.

Zamiast tego powinniśmy rozdzielić każdą z funkcji na jej własny obszar funkcjonalności.

Podobnie jak w przypadku wszystkiego w programowaniu, będą sposoby, w których pewne rzeczy będą jasne, jak można je wykonać, a także będą pewne rzeczy, które można zrobić na wiele sposobów.

Zaprezentuję, jak do tego podchodzę na razie. Może się to zmienić w przyszłości, a może nie, a inni mogą mieć na to inne podejście.

Niezależnie od tego implementacja będzie znacznie bardziej zorientowana obiektowo i da każdej klasie własny zestaw obowiązków.

Pierwsze pytanie brzmi jednak, jak podzielić klasę z czterema funkcjami, która dziedziczy po klasie nadrzędnej?

Aktualizacja Bootstrapa

Po pierwsze, jest kilka rzeczy, które musimy dostosować w programie startowym wtyczki. Mianowicie musimy wykonać następujące czynności:

  1. utworzyć instancję Rejestru i udostępnić go poprzez projekt,
  2. zaktualizować klasę Plugin tak, aby akceptowała rejestr i ładowała subskrybentów,
  3. przejrzyj bootstrap

Oto spojrzenie na wszystkie trzy z powyższych.

1 Utwórz instancję rejestru

Ponieważ omówiliśmy to już wcześniej w serii, powinno być jasne, jak to zrobić.

Najpierw zobacz następujący kod :

Następnie zauważ, że tworzymy instancję Rejestru (za chwilę porozmawiamy o jego przestrzeni nazw), a następnie podłączamy go do niestandardowego filtra, który umożliwia nam dostęp do niego przez całą wtyczkę, kiedy tylko chcemy.

2 Zaktualizuj klasę wtyczki

Następnie musimy zaktualizować podstawową klasę wtyczki (znajdującą się w  katalogu src ), aby odwoływała się do rejestru i ładowała wszystkich zarejestrowanych subskrybentów :

Pamiętaj jednak, że tak naprawdę nie skonfigurowaliśmy jeszcze żadnych subskrybentów. Zaczęliśmy to wcześniej w serii i teraz nadszedł czas, aby do tego wrócić, ale zrobimy to później.

Musimy jednak dodać funkcję – nawet tymczasową – abyśmy mogli dodać klasy, które nie są jawnymi subskrybentami zdarzeń:

Zostanie to przerobione później, ponieważ później będziemy przekształcać podstawowe klasy w subskrybentów.

3 Przejrzyj Bootstrap

Zanim przejdziemy dalej, myślę, że ważne jest, aby przejrzeć bootstrap. Chociaż Twój nagłówek i dokumentacja mogą się różnić, ważne jest, aby pamiętać, że wykonujemy następujące czynności:

  • nazwanie bootstrapu,
  • uniemożliwienie dostępu do pliku,
  • wywołanie autoloadera,
  • założenie rejestru,
  • i uruchomienie wtyczki.

Brzmi to dużo, ale kod jest dość krótki :

W tym momencie jednak nadszedł czas, aby przyjrzeć się, jak to jest podzielić klasę potomną ze standardowego interfejsu API widżetów na coś, co pasuje do modelu kodu, z którym pracujemy.

Dzielenie klasy dziecka

Ta część prawdopodobnie obejmie kilka postów, ponieważ jest trochę pracy do wykonania, ale zaczniemy od stworzenia własnej klasy widżetów, która będzie dziedziczyć po podstawowej klasie widżetów.

Najpierw stwórz  katalog API w katalogu src i dodaj plik o nazwie Widget.php. Tutaj będą znajdować się podstawy widżetu. W następnym poście zajmiemy się administracyjnymi i publicznymi arkuszami stylów oraz plikami JavaScript.

W tym momencie podstawy pliku powinny wyglądać tak :

Zauważ, że zajmuje jeden argument. Użyłem nazwy widżetu, ale możesz użyć tego, co chcesz, o ile reprezentuje twój widżet.

Ma to na celu pokazanie, że klasa jest poprawnie tworzona i ładowana, gdy wtyczka jest aktywowana. Jeśli tego nie widzisz, oznacza to, że coś jest nie tak (co za chwilę sprawdzimy).

Następnie ważne jest, aby upewnić się, że ta klasa została dodana do Rejestru. Dodaj więc następujące wiersze kodu w bootstrapie:

A teraz, kiedy aktywujesz wtyczkę, powinieneś zobaczyć:

Widżety WordPress: Refaktoryzacja, część 7

Jeśli nie, sprawdź kod w gałęzi deweloperskiej, aby upewnić się, że masz wszystko, co jest opisane w tym poście.

Wdrażanie subskrybentów

W nadchodzących postach przyjrzymy się, jak możemy zaimplementować subskrybentów dla publicznej strony witryny (czyli tam, gdzie wyświetlana jest treść widżetu). I zrobimy to samo dla obszaru administracyjnego witryny.

Na koniec zwrócimy uwagę na kod odpowiedzialny za zabezpieczenie i serializację danych (czytaj: aktualizacja naszego widżetu), a następnie zobaczymy, jak wygląda finalna wersja zaktualizowanego boilerplate’u.

Jednak w tym poście podstawową strategią, którą stosujemy, jest podzielenie klasy potomnej tak, aby nadal mogła być używana z innymi klasami przy użyciu interfejsów i klas bazowych, które są już zdefiniowane w kodzie bazowym.

Źródło nagrywania: tommcfarlin.com

Ta strona korzysta z plików cookie, aby poprawić Twoje wrażenia. Zakładamy, że nie masz nic przeciwko, ale możesz zrezygnować, jeśli chcesz. Akceptuję Więcej szczegółów