Praca z WP_Query, zwłaszcza gdy wykonujesz niestandardową pracę poza zwykłym „zdobądź posty i wyświetl je w szablonie", może być potężna. Dotyczy to szczególnie niektórych zaawansowanych argumentów (takich jak na przykład używanie WP_Meta_Query) .
Fajnie jest też, że konfiguracja procesu ma standardowy sposób robienia rzeczy. Mianowicie:
- Zdefiniuj argumenty,
- Utwórz wystąpienie WP_Query,
- Sprawdź, czy są posty,
- Przejdź przez nie,
- Zakończ je.
Ale jeśli dojdziesz do miejsca, w którym wykonujesz zaawansowaną pracę, taką jak praca z niestandardowym typem posta z rozwiązania innej firmy, konieczność sideload nośnika, ustalenia, czy coś istnieje przed wykonaniem jakiejkolwiek pracy z tym, może to być trochę bardziej skomplikowana w pracy, prawda?
Odkryłem, że podobnie jak w przypadku wszystkiego w programowaniu, rozbicie go na znacznie bardziej czytelne moduły (lub funkcje, elementy lub jakkolwiek chcesz je nazwać) może znacznie ułatwić pracę.
Oto jeden ze sposobów, w jaki pracuję nad poprawą czytelności WP_Query w różnych rzeczach, które ostatnio zrobiłem.
Ulepszenia czytelności WP_Query
Zanim przejdziemy przez jakikolwiek przykład, warto wskazać, że są pewne rzeczy, w których konfiguracja WP_Query jest konfigurowana, a których nie możemy zrobić.
Na przykład po utworzeniu instancji zapytania możemy nie być w stanie zrobić z nim znacznie bardziej zaawansowanych rzeczy (mam na myśli, skonfigurowanie testów jednostkowych, które nie wymagają rdzenia WordPressa, będzie niemożliwe).
To jest twarz kogoś, kto nie może podążać za twoim kodem.
Mając to na uwadze, oto przykład tego, jak może wyglądać, gdy zaczynasz, a następnie jak można go zrefaktoryzować, aby mieć mniejsze funkcje, z których każda jest bardziej celowa niż jedna długa metoda.
Przykład
W przypadku tego posta, powiedzmy, że muszę przeszukać bazę danych dla wszystkich opublikowanych postów i postów i chcę je uporządkować według identyfikatora.
Następnie chcę ustalić, czy jakieś narzędzie innej firmy przypisało do niego pewne metadane, które odpowiadają szablonowi, który mogę później programowo przypisać do danego motywu, który mam.
Być może początkowa wersja kodu może wyglądać mniej więcej tak :
To dużo kodu do wykonania sporej ilości pracy dla jednej funkcji. Przynajmniej zawiera wszystko, co musi się wydarzyć, prawda?
Zanim zaczniesz czytać dalej, zauważ, że tablica mapowania jest tylko przykładem, ale klucze reprezentują klucz meta do mapowania, a to pomaga nam zmapować definicję wartości _wp_page_template, gdy nadejdzie czas na mapowanie jej do rzeczywistych plików szablonów WordPress.
Jak więc można to rozbić?
1 Wyrzuć całość
Pierwszą rzeczą, którą chcemy zrobić, to stworzyć funkcję, która wprawi całość w ruch. Możesz to zrobić na kilka sposobów.
Oto jak zdecydowałem się to zrobić :
Mówiąc najprościej, użyje kilku funkcji pomocniczych – wszystkie z nich udokumentuję poniżej – a następnie przypisze szablony, które mamy w tablicy mapowania zdefiniowanej powyżej.
2 Załaduj posty i strony
Oczywiście pierwszą rzeczą, którą chcemy zrobić, jest ustawienie funkcji do wywołania, która zwróci wyniki zapytania:
Zwraca wyniki zapytania. W ten sposób możemy określić, czy musimy wykonać dodatkową pracę, o której mówimy w sednie w poprzednim kroku:
Jeśli nie, to koniec. W przeciwnym razie oczywiście idziemy dalej.
3 Pobierz identyfikator szablonu innej firmy
Następnie pomysł przypisywania szablonów – jak pokazano w powyższym kodzie – wydaje się dość prosty, ale najpierw musimy zrobić kilka rzeczy:
- iterować przez posty,
- pobierz zewnętrzny identyfikator szablonu,
- pobierz nazwę szablonu innej firmy,
- przypisz szablon ze stałej mapowania zdefiniowanej wcześniej w klasie.
Początkowa iteracja funkcji może wyglądać tak :
Ale jak widać, nadal istnieją funkcje pomocnicze, które wymagają definicji. Rzeczy takie jak możliwość uzyskania identyfikatora szablonu, nazwy szablonu i ostatecznie przypisania szablonu.
Zauważ jednak, że jeśli któraś z funkcji pomocniczych nie zwróci użytecznej wartości, kontynuujemy pętlę. Jest to konieczne, chociażby nie z innego powodu niż po to, aby upewnić się, że nie próbujemy mapować szablonów, które nie istnieją (ale uważam, że jest to również nieco łatwiejsze do odczytania).
4 Znajdź plik, do którego mapowane są identyfikatory szablonu
Następnie można użyć niewielkiej funkcji do sprawdzenia identyfikatora szablonu innej firmy i określenia, czy możemy zmapować tę wartość na strony istniejące w naszej bazie danych.
Jeśli tak się nie stanie, możemy zwrócić pusty ciąg, a następnie wywołać funkcję, która wywołała to konkretne sprawdzenie, aby zobaczyć, czy warto kontynuować ze zdefiniowaną pętlą.
5 Chwyć nazwę szablonu
Zakładając, że mamy poprawny identyfikator posta, teraz musimy pobrać nazwę szablonu z tablicy mapowania zdefiniowanej wcześniej w poście:
Oto rzecz: albo zwrócimy nazwę szablonu, albo zwrócimy wartość null. Ponownie, jest to po to, abyśmy mogli określić, czy musimy kontynuować pętlę przypisywania szablonów, czy nie.
6 Przypisz szablon
Na koniec możemy pobrać identyfikator szablonu dostarczony przez stronę trzecią i użyć go do zmapowania do pliku, który dołączyliśmy do naszej pracy, jak opisano wcześniej w poście:
I to jest ostatecznie sposób, w jaki można stworzyć znacznie mniejszy, łatwiejszy do odczytania i łatwiejszy w użyciu kod i funkcje podczas pracy z nieco bardziej skomplikowanymi zapytaniami.
A zatem poprawa czytelności
Dla osób przyzwyczajonych do pisania długich metod czytania lub robienia rzeczy w sposób, w jaki większość samouczków w Internecie pokazuje, jak robić rzeczy w WordPressie, może to wyglądać na dużo bezsensownego kodu.
Ale rozważ to:
- Dłuższe metody są trudniejsze do odczytania,
- Mogą być trudniejsze do debugowania,
- I nie rozkładają problemu na łatwiejsze do opanowania części.
Jasne, chciałbym podzielić to na jeszcze więcej klas z ich obowiązkami i wierzę, że można to zrobić, ale biorąc pod uwagę naturę WP_Query, wymagałoby to trochę więcej pracy.
Więc starałem się znaleźć jak najwięcej środka.
Jeśli pracujesz z nawet nieco bardziej zaawansowanymi zastosowaniami WP_Query, polecam przynajmniej rozważenie podzielenia go na mniejsze części.
Pomaga to zadbać o czytelność, potencjalnie każdą łatwość konserwacji i pisać czystszy kod zamiast jednej długiej metody ze zbyt wieloma warunkami warunkowymi i poleganiem na różnych innych danych.