Pracowałem nad małym projektem, bardziej aplikacji internetowej niż witryny, który wymagał opracowania zarówno niestandardowego motywu, jak i ściśle powiązanej, ale bardzo specyficznej funkcjonalności.
Jest to bardzo wąsko skoncentrowany projekt (o którym prawdopodobnie opowiem w przyszłości), ale pracując nad nim, zmusiło mnie to do powrotu do aspektu tworzenia motywów w programowaniu WordPress.
Nie, nie robię żadnego projektu – na szczęście – ale muszę pracować nad dostosowaniami motywów z funkcjonalnej perspektywy. Robiąc to, musiałem jednak ponownie przejrzeć wymagane functions.phpi pewne rozważania, których nigdy wcześniej nie miałem.
Co więcej, spowodowało to, że przyjrzałem się głębiej użyciu mu-pluginsi zapytałem, kiedy są one konieczne i dlaczego nie używałem ich więcej w przeszłości (lub nawet kiedy naprawdę trzeba by ich używać).
Więc zamierzam trochę poetycko o tym mówić.
TL;DRKiedy robiłem tworzenie motywów, functions.phpbył używany do dwóch rzeczy (co samo w sobie jest problematyczne), ale nadal:
- włączyć lub wyłączyć funkcje w motywach,
- aby zdefiniować funkcjonalność specyficzną dla motywu.
W podręczniku dla programistów motywów czytamy:
Plik
functions.phpto miejsce, w którym dodajesz unikalne funkcje do swojego motywu WordPress. Może być używany do łączenia się z podstawowymi funkcjami WordPressa, aby Twój motyw był bardziej modułowy, rozszerzalny i funkcjonalny.Funkcje motywu, Podręcznik dla programistów motywów
Rozumiem to, ale z mojej perspektywy i wraz z ewolucją WordPressa, myślę, że functions.phppowinno to być poświęcone funkcjonalności specyficznej dla motywu, jeśli chodzi o rzeczy, które łączą się bezpośrednio z rdzeniem, takie jak:
- funkcjonalność konfiguratora,
- funkcjonalność menu,
- rejestracja skryptu i stylu,
- i tak dalej.
Ale jeśli jest coś, co musi działać podczas jednego z zaczepów i jest bardziej zgodne z logiką specyficzną dla domeny, to nie należy do tego pliku.
Rodzi to jednak pytanie: gdzie znajdują się funkcje specyficzne dla domeny?
Wprowadź wtyczki, których należy używać
Wiem, że rzeczy takie jak inckatalogi stają się coraz bardziej powszechne, ale nie przejmuję się nimi, gdy mówię o tworzeniu motywów, zwłaszcza gdy nie skupiam się na opracowywaniu motywów i ta konkretna struktura katalogów nie jest w moim stylu.
Zresztą, jeśli chodzi o rozwiązania wysokospecjalistyczne (gdzie rozwiązanie jest połączeniem prezentacji i ściśle skoncentrowanej funkcjonalności), zaczynam myśleć o mu-plugins.
A powodem, dla którego nie myślę o standardowej wtyczce WordPress, jest to, że są one ogólnie zaprojektowane do pracy z dowolnym motywem i dodawania funkcjonalności. Nie tak z mu-plugins.
Wtyczki, których należy używać (aka mu-plugins) to wtyczki instalowane w specjalnym katalogu w folderze zawartości i które są automatycznie włączane we wszystkich witrynach instalacji.
Niezbędne wtyczki, WordPress.org
Oto mój proces myślowy:
- Tematy są do prezentacji
- Wtyczki służą funkcjonalności.
- Wtyczki są zaprojektowane do użytku niezależnie od motywu i w całej witrynie.
- Niezbędne wtyczki to wtyczki, które są domyślnie włączone i używane
- Dlatego logika specyficzna dla domeny dla specjalistycznego rozwiązania powinna znajdować się w niezbędnej wtyczce.
Jasne, można założyć, że niektóre motywy mogą wymagać funkcjonalności, której trzeba użyć, ale czy to nadal nie pasuje do idei, że funkcjonalność powinna znajdować się we wtyczce, której należy używać?
Niezależnie od tego, podejście, które stosuję, jest następujące:
- Funkcjonalność, która konkretnie łączy funkcje motywu z rdzeniem WordPress, wchodzi w
functions.php. - Funkcjonalność, która jest oparta na logice domeny, ale wymaga do działania całego rozwiązania, znajduje się w
mu-plugin.
W tym momencie mojej kariery nie wykonuję zbyt wiele pracy, skupiając się na czymkolwiek poza backendem, ale w rzadkich okazjach, w których muszę poszerzyć pracę, którą robię, stwierdzam, że nadal staram się być jako analityczny i przemyślany na temat sposobu, w jaki buduję projekt.