Jak sprawić, by wtyczka WordPress była rozszerzalna?

Czy kiedykolwiek używałeś wtyczki i chciałeś, żeby robiła coś nieco inaczej? Być może potrzebujesz czegoś wyjątkowego, co wykraczałoby poza zakres strony ustawień wtyczki.

Osobiście się z tym spotkałem i założę się, że ty też. Jeśli jesteś programistą wtyczek WordPress, najprawdopodobniej niektórzy z Twoich użytkowników również napotkali to podczas korzystania z Twojej wtyczki.

Oto typowy scenariusz: w końcu znalazłeś wtyczkę, która robi wszystko, czego potrzebujesz — z wyjątkiem jednej małej ważnej rzeczy. Nie ma żadnego ustawienia ani opcji umożliwiającej włączenie tego drobiazgu, więc przeglądasz dokumentację i stwierdzasz, że nie możesz nic z tym zrobić. Żądasz tej funkcji na forum wsparcia wtyczki WordPress — ale bez kości. W końcu odinstalujesz go i kontynuujesz wyszukiwanie.

Wyobraź sobie, że jesteś twórcą tej wtyczki. Co byś zrobił, gdyby użytkownik poprosił o jakąś konkretną funkcjonalność?

Idealnie byłoby to wdrożyć. Ale gdyby ta funkcja była przeznaczona do bardzo specjalnego przypadku użycia, dodanie jej byłoby niepraktyczne. Nie byłoby dobrze mieć ustawienie wtyczki, z którego tylko 0,1% użytkowników skorzystałoby.

Chciałbyś tylko zaimplementować funkcje, które mają wpływ na większość Twoich użytkowników. W rzeczywistości 80% użytkowników korzysta z 20% funkcji (reguła 80/20). Upewnij się więc, że jakakolwiek nowa funkcja jest bardzo pożądana i że 80% użytkowników skorzysta z niej, zanim ją zaimplementujesz. Jeśli utworzysz ustawienie dla każdej żądanej funkcji, Twoja wtyczka stanie się skomplikowana i nadęta — i nikt tego nie chce.

Najlepszym rozwiązaniem jest sprawienie, aby wtyczka była rozszerzalna pod kątem kodu, tak aby inne osoby mogły ją ulepszać lub modyfikować zgodnie z własnymi potrzebami.

W tym artykule dowiesz się, dlaczego rozszerzanie wtyczki jest dobrym pomysłem. Podzielę się również kilkoma wskazówkami, jak się tego nauczyłem.

Co sprawia, że ​​wtyczka jest rozszerzalna?

W skrócie, rozszerzalna wtyczka oznacza, że ​​jest zgodna z częścią „O” zasad programowania obiektowego SOLID — mianowicie z zasadą open/closed.

Jeśli nie jesteś zaznajomiony z zasadą open/closed, oznacza to w zasadzie, że inni ludzie nie powinni być zmuszeni do edytowania twojego kodu, aby coś zmodyfikować .

Stosując tę ​​zasadę do wtyczki WordPress, oznaczałoby to, że wtyczka jest rozszerzalna, jeśli zawiera zapisy umożliwiające innym osobom modyfikację jej zachowania. To tak, jak WordPress pozwala ludziom „zahaczyć się” o różne obszary WordPressa, ale na poziomie wtyczki.

Typowy przykład wtyczki

Zobaczmy, jak możemy stworzyć rozszerzalną wtyczkę, zaczynając od przykładowej wtyczki, która nie jest.

Załóżmy, że mamy wtyczkę, która generuje widżet paska bocznego, który wyświetla tytuły trzech ostatnich postów. Sercem wtyczki jest funkcja, która po prostu zawija tytuły tych trzech postów w tagi listy:

 function get_some_post_titles() { $args = array( 'posts_per_page' => 3, ); $posts = get_posts( $args ); $output = '
 ';
  foreach ( $posty jako $post ) {
      $wyjście .= '
 '. $post->post_title . '
 ';
  }
  $wyjście .= '
 ';

  zwróć $wyjście;
}

Chociaż ten kod działa i wykonuje zadanie, nie jest całkiem rozszerzalny.

Czemu? Ponieważ funkcja jest ustawiana na swój własny sposób, nie ma możliwości zmiany jej zachowania bez bezpośredniej modyfikacji kodu.

Co by było, gdyby użytkownik chciał wyświetlić więcej niż trzy posty, a może dołączyć linki z tytułami postów? Nie da się tego zrobić z powyższym kodem. Użytkownik utknął z działaniem wtyczki i nie może nic zmienić.

W tym setki ustawień nie jest odpowiedzią

Istnieje wiele sposobów na ulepszenie powyższej wtyczki, aby umożliwić użytkownikom jej dostosowanie.

Jednym z takich sposobów byłoby dodanie wielu opcji w ustawieniach, ale nawet to może nie spełniać wszystkich możliwości, jakie użytkownicy chcieliby od wtyczki.

Co by było, gdyby użytkownik chciał wykonać jedną z poniższych czynności (scenariusze, do których wrócimy później):

• wyświetlać produkty lub posty WooCommerce z określonej kategorii;
• wyświetlać elementy w karuzeli dostarczonej przez inną wtyczkę, zamiast jako prostej listy;
• wykonaj niestandardowe zapytanie do bazy danych, a następnie użyj wpisów tego zapytania na liście.

Gdybyśmy dodali setki ustawień do naszego widżetu, moglibyśmy uwzględnić powyższe przypadki użycia. Ale co, jeśli jeden z tych scenariuszy ulegnie zmianie, a teraz użytkownik będzie chciał wyświetlać tylko produkty WooCommerce, które są aktualnie w magazynie? Widżet potrzebowałby jeszcze więcej ustawień, aby to dostosować. Wkrótce będziemy mieli setki tysięcy ustawień.

Ponadto wtyczka z ogromną listą ustawień nie jest zbyt przyjazna dla użytkownika. Jeśli to możliwe, omijaj tę trasę.

Jak więc podeszlibyśmy do rozwiązania tego problemu? Uczynilibyśmy wtyczkę rozszerzalną.

Dodawanie własnych haków, aby było rozszerzalne

Studiując powyższy kod wtyczki, widzimy kilka operacji, które wykonuje główna funkcja:

• Pobiera posty za pomocą get_posts .
• Generuje listę tytułów postów.
• Zwraca wygenerowaną listę.

Gdyby inne osoby zmodyfikowały zachowanie tej wtyczki, ich praca najprawdopodobniej obejmowałaby te trzy operacje. Aby nasza wtyczka była rozszerzalna, musielibyśmy dodać zaczepy wokół nich, aby otworzyć je dla innych programistów.

Ogólnie rzecz biorąc, są to dobre obszary do dodawania hooków do wtyczki:

• wokół i w obrębie głównych procesów,
• podczas budowania wyjściowego kodu HTML,
• do zmiany zapytań pocztowych lub do bazy danych,
• przed zwróceniem wartości z funkcji.

Typowy przykład rozszerzalnej wtyczki

Stosując się do tych zasad, możemy dodać następujące filtry, aby rozszerzyć naszą wtyczkę:

• dodaj myplugin_get_posts_args do modyfikacji argumentów get_posts ,
• dodaj myplugin_get_posts do nadpisywania wyników get_posts ,
• dodaj myplugin_list_item aby dostosować generowanie wpisu listy,
• dodaj myplugin_get_some_post_titles aby nadpisać zwróconą wygenerowaną listę.

Oto kod ponownie ze wszystkimi dodanymi haczykami:

 function get_some_post_titles() { $args = array( 'posts_per_page' => 3, ); // Let other people modify the arguments. $posts = get_posts( apply_filters( 'myplugin_get_posts_args', $args ) ); // Let other people modify the post array, which will be used for display. $posts = apply_filters( 'myplugin_get_posts', $posts, $args ); $output = '
 ';
  foreach ( $posty jako $post ) {

      // Pozwól innym modyfikować wpis na liście.
      $wyjście .= '
 '. apply_filters( 'myplugin_list_item', $post->post_title, $post ) . '
 ';
  }
  $wyjście .= '
 ';

  // Pozwól innym modyfikować naszą listę wyników.
  return apply_filters( 'myplugin_get_some_post_titles', $output, $args );
}

Możesz również pobrać powyższy kod w archiwum GitHub.

Dodaję tutaj wiele zaczepów, co może wydawać się niepraktyczne, ponieważ przykładowy kod jest dość prosty i mały, ale to ilustruje moją rację: dodając tylko cztery zaczepy, inni programiści mogą teraz dostosować zachowanie wtyczki na różne sposoby.

Przestrzenie nazw i kontekst dla hooków

Zanim przejdziesz dalej, zwróć uwagę na dwie ważne rzeczy dotyczące wdrożonych przez nas hooków:

• Rozmieszczamy haki w przestrzeni nazw za pomocą myplugin_ .
  Gwarantuje to, że nazwa podpięcia nie jest w konflikcie z podpięciem innej wtyczki. To po prostu dobra praktyka, ponieważ wywołanie innego hooka o tej samej nazwie może prowadzić do niepożądanych efektów.
• Przekazujemy również odwołanie do $args we wszystkich zaczepach kontekstowych.
  Robię to, aby jeśli inni używali tego filtra do zmiany czegoś w przepływie kodu, mogli użyć parametru $args jako odniesienia, aby zorientować się, dlaczego wywołano podpięcie, aby mogli odpowiednio wykonać swoje poprawki.

Efekty naszych haków

Pamiętasz wyjątkowe scenariusze, o których mówiłem wcześniej? Wróćmy do nich i zobaczmy, jak nasze haki je umożliwiły:

• Jeśli użytkownik chce wyświetlać produkty lub posty WooCommerce z określonej kategorii , może użyć filtru myplugin_get_posts_args , aby dodać własne argumenty, gdy wtyczka wysyła zapytanie o posty, lub użyć myplugin_get_posts , aby całkowicie zastąpić posty własną listą.
• Jeśli użytkownik chce wyświetlić elementy w karuzeli dostarczonej przez inną wtyczkę , zamiast jako prostej listy, może nadpisać całe wyjście funkcji myplugin_get_some_post_titles i zamiast tego wyprowadzić stamtąd karuzelę.
• Jeśli użytkownik chce wykonać niestandardowe zapytanie do bazy danych , a następnie użyć postów tego zapytania na liście, to podobnie jak w pierwszym scenariuszu, może użyć myplugin_get_posts , aby użyć własnego zapytania do bazy danych i zmienić tablicę postów.

Dużo lepiej!

Szybki przykład korzystania z naszych filtrów

Deweloperzy mogą użyć add_filter , aby podłączyć się do naszych filtrów powyżej (lub użyć add_action do działań).

Biorąc pod uwagę nasz pierwszy scenariusz powyżej, programista może po prostu wykonać następujące czynności, aby wyświetlić produkty WooCommerce za pomocą utworzonego przez nas filtra myplugin_get_posts_args :

 add_filter( 'myplugin_get_posts_args', 'show_only_woocommerce_products' ); function show_only_woocommerce_products( $args ) { $args['post_type'] = 'product'; return $args; }

Możemy również użyć haków akcji

Oprócz używania apply_filters , możemy również użyć do_action , aby nasz kod był rozszerzalny. Różnica między nimi polega na tym, że pierwsza pozwala innym zmienić zmienną, podczas gdy druga pozwala innym na wykonywanie dodatkowych funkcji w różnych częściach naszego kodu.

Korzystając z akcji, zasadniczo udostępniamy przepływ wtyczki innym programistom i pozwalamy im wykonywać inne czynności w tandemie.

Może to nie być przydatne w naszym przykładzie (ponieważ wyświetlamy tylko krótki kod), ale przydałoby się w innych. Na przykład, mając rozszerzalną wtyczkę do tworzenia kopii zapasowych, możemy utworzyć wtyczkę, która również przesyła plik kopii zapasowej do usługi innej firmy, takiej jak Dropbox.

"Świetnie! Ale dlaczego powinienem dbać o to, aby moja wtyczka była rozszerzalna?”

Cóż, jeśli nadal nie jesteś przekonany do tego pomysłu, oto kilka przemyśleń, dlaczego pozwalanie innym osobom na modyfikowanie zachowania wtyczki jest dobrym pomysłem.

Otwiera wtyczkę na większe możliwości dostosowywania

Każdy ma inne potrzeby. I jest duża szansa, że ​​twoja wtyczka nie zaspokoi ich wszystkich, ani nie możesz ich przewidzieć. Otwarcie wtyczki w celu umożliwienia modyfikacji kluczowych obszarów zachowania wtyczki może zdziałać cuda.

Pozwala ludziom wprowadzać modyfikacje bez dotykania kodu wtyczki

Inni programiści nie będą zmuszeni do bezpośredniej zmiany plików wtyczki. Jest to ogromna korzyść, ponieważ bezpośrednia modyfikacja pliku wtyczki jest generalnie złą praktyką. Jeśli wtyczka zostanie zaktualizowana, wszystkie twoje modyfikacje zostaną wyczyszczone.

Jeśli dodamy własne hooki do użycia przez inne osoby, to modyfikacje wtyczki można umieścić w zewnętrznej lokalizacji — powiedzmy w innej wtyczce. W ten sposób oryginalna wtyczka nie zostanie w ogóle dotknięta i można ją swobodnie aktualizować bez uszkadzania czegokolwiek, a wszystkie modyfikacje w drugiej wtyczce pozostaną nienaruszone.

Wniosek

Rozszerzalne wtyczki są naprawdę niesamowite i dają nam dużo możliwości dostosowywania. Jeśli sprawisz, że Twoja wtyczka będzie rozszerzalna, Twoi użytkownicy i inni programiści Cię za to pokochają.

Spójrz na wtyczki, takie jak WooCommerce, Easy Digital Downloads i ACF. Te wtyczki są rozszerzalne i można to łatwo stwierdzić, ponieważ wiele innych wtyczek w katalogu wtyczek WordPressa dodaje do nich funkcjonalność. Zapewniają również szeroką gamę haczyków akcji i filtrów, które modyfikują różne aspekty wtyczek. Zasady praktyczne, które wymieniłem powyżej, pojawiły się podczas moich studiów nad nimi.

Oto kilka wskazówek, dzięki którym Twoja wtyczka będzie rozszerzalna:

• Postępuj zgodnie z zasadą otwarte/zamknięte. Inni ludzie nie powinni być zmuszeni do edytowania twojego kodu, aby coś modyfikować.

• Aby Twoja wtyczka była rozszerzalna, dodaj haki w tych miejscach:

  • wokół i w ramach głównych procesów,
  • podczas budowania wyjściowego kodu HTML,
  • do zmiany zapytań pocztowych lub do bazy danych,
  • przed zwróceniem wartości z funkcji.

• Przestrzeń nazw swoich hooków z nazwą wtyczki, aby zapobiec konfliktom nazw.
• Spróbuj przekazać inne zmienne, które są powiązane z hakiem, aby inne osoby miały jakiś kontekst tego, co dzieje się w haczyku.
• Nie zapomnij udokumentować podpięć wtyczki, aby inni mogli się o nich dowiedzieć.

Dalsza lektura

Oto kilka zasobów, jeśli chcesz dowiedzieć się więcej o rozszerzaniu wtyczek:

• Jak sprawić, by Twoja wtyczka WordPress była rozszerzalna, GitHub
  Cały przykładowy kod w tym artykule.
• „Przydatne wskazówki, jak zacząć korzystać z haków WordPress”, Thomas Maier, Smashing Magazine
• „Jak stworzyć wtyczkę WordPress”, Daniel Pataki, Smashing Magazine
• „Haki”, Podręcznik wtyczek, WordPress.org