WordPress - motywy, wtyczki, informacje, programowanie

Pat i Mat

20 największych błędów programistów używających WordPressa, część 2/2

Wiele błędów programistów WordPressowych wynika z ich ścieżki uczenia się. Poznają system wyrywkowo, nie mają pełnej świadomości tego, jak działa, które rzeczy są kosztowne, które zalecane, które bezpieczne. Nie maja świadomości całości. Używają pierwszego narzędzia jakie im wpadnie w rękę. Pragmatyzm WordPressa sprawia, że większość rzeczy można zrobić na wiele sposobów, jednak to nie oznacza, że wszystkie te sposoby są dobre.
Przez skorzystaniem z tego poradnika przeczytaj jego część pierwszą opisującą typowe błędy (1-10)

11. Niewłaściwe dołączanie skryptów JS i arkuszy CSS

Nie wchodząc w szczególne przypadki możemy przyjąć, że mamy w WordPressie trzy sposoby na załadowanie zewnętrznych skryptów JS i arkuszy CSS:

  1. Umieszczenie odpowiedniego kodu bezpośrednio w pliku header.php (tylko jeśli tworzymy motyw, w wypadku wtyczki nie ma to zastosowania)
  2. Wykorzystanie haka wp_head. Wszystko co w nim wypiszemy na wyjście pojawi się przed zamknięciem taga < /head> strony (mamy też hak wp_admin_head dla stron admina).
  3. Skorzystanie z funkcji wp_enqueue_script() i wp_enqueue_style() oraz innych funkcji z tej grupy (są też odpowiedniki dla stron admina)

Z wyjątkiem szczególnych zastosowań, pierwsze dwie metody są wystarczające (co nie znaczy, że lepsze) tylko wtedy, gdy skrypt lub arkusz, który ładujemy, nie ma żadnych zależności (niczego nie wymaga) i powinien być dostępny na wszystkich stronach serwisu.

Jednak, praktycznie zawsze powinniśmy korzystać z trzeciej metody, czyli z funkcji kolejkujących skrypty i arkusze. Jest po temu kilka dobrych powodów:

  • Unikamy wielokrotnego ładowania tego samego skryptu. Pomijając przypadek, że sami się pogubimy i załadujemy coś dwukrotnie, musimy pamiętać, że serwis w WordPressie korzysta zwykle co najmniej z kilkunastu wtyczek. Łatwo sobie wyobrazić sytuację, w której przy wykorzystaniu metody z hakiem wp_head jakaś popularna biblioteka w JS zostanie załadowana kilka razy.
  • WordPress dba o zachowanie zależności. Jeśli zdeklarujemy, że nasz skrypt wymaga jakiejś wtyczki jQuery, zostanie ona automatycznie załadowana, albo dostaniemy informacje o błędzie jeśli nie będzie dostępna.
  • Odpowiednie użycie funkcji wp_register_script(), wp_localize_script() i wp_enqueue_script() pozwala nam wykonać lokalizację (tłumaczenie) plików JS w sposób spójny z lokalizacją plików PHP w WordPressie.
  • Dzięki powyższym trzem funkcjom możemy też „magicznie” przekazywać parametry z PHP do skryptów JS (co jest szczególnie użyteczne, gdy strona ma działać w oparciu o AJAX)
  • Funkcje pozwalają na wersjonowanie skryptów. Przeglądarki agresywnie cachują pliki JS i CSS. Jeśli nie będziemy zmieniać ich nazw (a najłatwiejsze jest dodanie po pytajniku numeru wersji), będzie się zdarzało, że użytkownik otworzy nową wersję strony ze starymi stylami i skryptami, a to może powodować jej złe działanie.
  • Funkcje te ułatwiają nam ładowanie skryptów tylko na tych stronach, gdzie naprawdę są potrzebne. Ładowanie skrypty możemy mieć w kodzie w pobliżu miejsca gdzie z nich korzystamy, dzięki czemu łatwiej nad tym zapanować.
  • Korzystając z funkcji kolejkujących ułatwiamy też zadanie wtyczkom optymalizującym skrypty (minifikującym, łączącym wiele skryptów jeden)

Zawsze kiedy dołączasz skrypty JS i arkusze CSS korzystaj z funkcji kolejkujących  wp_enqueue_script() i wp_enqueue_style()

12. Lekkomyślne wywołanie funkcji flush_rules()

Zdefiniowałeś swoje typy wpisów (Custom Post Types), lub swoją taksonomię, albo kombinujesz z adresami URL stron w Twoim serwisie i dodałeś nowe reguły rewrite (zapewne korzystając z haka generate_rewrite_rules). Dowiedziałeś się, że zaczną działać kiedy wywołasz funkcję flush_rules(). Pośpiesznie dodajesz jej wywołanie na haku  init

To ogromny błąd.

Funkcja flush_rules() może być przy dużym serwisie niesłychanie kosztowna, ponieważ proces zapisania reguł rewrite do bazy danych jest złożony. Wywołanie jej przy każdej odsłonie strony w serwisie (a tak się skończy wywołanie na haku init albo w podobny sposób) jest poza tym zupełnie niepotrzebne.

Powinieneś wywołać tę funkcje tylko raz i nie dotykać dopóki znowu czegoś nie zmienisz w regułach rewrite, włączając w to definicje nowych typów wpisów i taksonomii. Jeśli piszesz wtyczkę, która to robi, wywołaj funkcję flush_rules() tylko podczas aktywacji wtyczki ( register_activation_hook())

Tak naprawdę, najczęściej w ogóle nie musisz z niej korzystać. Wystarczy przejść w adminie WordPressa do sekcji Ustawienia/Bezpośrednie odnośniki i kliknąć przycisk Zapisz. To najlepszy sposób na jednokrotne wygenerowanie reguł rewrite.

Nigdy nie wywołuj funkcji flush_rules() przy każdej odsłonie serwisu. Wywołaj ją tylko raz po każdej zmianie reguł rewrite.

13. Ignorowanie problemu wydajności

Wydajność jest jak najsprytniejszy złodziej. Nic Ci nie zrobi kiedy nic nie masz, kiedy Twój serwis jest mały, nie ma wielkiego ruchu, prawie nikt go nie czyta i właściwie wszystko jedno czy działa, czy nie. Dopadnie Cię wtedy, kiedy odniesiesz sukces, kiedy Twoja strona stanie się hitem, kiedy przyjdzie dużo odwiedzających, kiedy będzie Ci na niej zależeć, zaczniesz zacierać ręce i cieszyć się sukcesem – wtedy wszystko nagle zgaśnie. Strona przestanie się otwierać.

Wtedy w panice i pod presją będziesz szukać rozwiązania, a może to być trudne, bo nie będziesz już wszystkiego pamiętać, umkną Ci szczegóły implementacji.

Naprawdę, lepiej zadbać o to wcześniej.

Goluteńki zainstalowany WordPress wykonuje około 40 zapytań do bazy danych. Przy niezbyt złożonym motywie będzie ich 90, na bardzo złożonej (lub źle napisanej) stronie może być nawet 200 i to już jest naprawdę dużo. Żeby w ogóle wiedzieć co się dzieje, ile jest tych zapytań i jak są kosztowne, musimy mieć jakieś narzędzia. Nieoceniona w tym jest wtyczka Debug Bar. Szczerze mówiąc nie bardzo rozumiem jak można w ogóle bez niej programować serwisy w WordPressie.

Debug Bar

Niektóre z informacji udostępnianych przez wtyczkę Debug Bar

Jeśli widzimy, że wykonanie naszej strony jest kosztowne, możemy napisać ją lepiej, albo zadbać o to, żeby przynajmniej niektóre jej elementy były cachowane. Można do tego użyć wtyczki „wrzutki” object-cache.php, a najlepiej zainstalować jedną z dużych wtyczek cachujących. Ja osobiście używam W3 Total Cache.

Ktoś może powiedzieć, że po co to zamieszanie skoro W3 Total Cache potrafi cachować całe kompletne strony. Owszem, to prawda, ale przy każdym dodaniu wpisu, albo nawet komentarza, niektóre lub wszystkie strony muszą wygenerować się na nowo. Nie jest tak, że generują się tylko te strony, które zawierają zmieniony wpis – WordPress nie wie gdzie tak naprawdę go umieściliśmy, z cacha wyrzucane jest dużo więcej niż trzeba. Oznacza to, że po dodaniu nowego wpisu, Twój serwis przez pewien czas działa tak, jakby nie był w pełni cachowany (pomimo tego, że wtyczki cachujące starają się to robić  sprytnie i najczęściej nie odbudowują wszystkich stron jednocześnie)

Nie ignoruj problemu wydajności. Dbaj o to aby Twój kod był efektywny, sprawdzaj jak wiele zapytań generuje Twoja strona, Używaj wtyczek cachujących.

14. Złe wyważenie, które rzeczy programować samemu, a do czego użyć wtyczek

Jeśli ktoś nie potrafi programować, nie ma wyboru. Musi korzystać z wtyczek kiedy chce zrobić coś nietypowego. Jednak programista powinien zawsze świadomie korzystać z narzędzi i rozważać zyski i straty wynikające z przyjętego rozwiązania.

Każda wtyczka, to oprócz zysków również koszt – zwykle duża ilość kodu po stronie admina, skrypty JS, często wykorzystany jest jakiś kod innych wtyczek WordPressa lub jQuery. Te elementy najczęściej generują dodatkowe obciążenie, ale też trzeba pamiętać, że każdy zbędny plik PHP czy JS na serwerze to potencjalna dziura w bezpieczeństwie.

Są wtyczki, które robią bardzo dużo, wykorzystujemy znaczną część ich funkcjonalności i są potrzebne cały czas. Dobrym przykładem jest WordPress SEO by Yoast. Właściwie ciężko sobie wyobrazić, żeby zastąpić jej funkcjonalności własnym programowaniem – byłoby to bardzo kosztowne.

Z drugiej strony mamy na przykład wtyczkę Types. Ma ona wiele funkcji, ale jeśli potrzebujemy ją tylko po to, żeby zdefiniować typy wpisów i taksonomie, to można tego uniknąć, jeśli potrafimy programować. Definicja typu wpisów, czy definicja taksonomii to wywołanie dosłownie jednej funkcji, dość złożone, ale i tak musimy rozumieć co znaczą jej parametry, jeśli chcemy skorzystać z Types. Raz napisane wywołania kilku funkcji umieszczamy w pliku functions.php i zapominamy o nich na wieki. Robią dokładnie to co trzeba i nic ponad to. Dołączanie zamiast tego ogromnej wielofunkcyjnej wtyczki z wielkim interfejsem jest moim zdaniem zupełnie zbędne jeśli nie korzystamy z jej innych funkcji i znamy abecadło PHP.

Czasami wtyczka daje nam bardzo niewielką funkcjonalność, ale nie jest to związane z żadnymi dodatkowymi narzutami. Dobrym przykładem jest Confirm Publishing Actions. Teoretycznie możemy z niej zrezygnować, i napisać ten kawałek kodu sami, ale jeśli będziemy chcieli go zrobić dobrze, napiszemy mniej więcej to samo.

Zawsze dobrze przemyśl, czy chcesz użyć wtyczki, czy powinieneś sam oprogramować daną funkcjonalność. Zaglądaj do kodu wtyczki. Sprawdzaj czy autor jest godny zaufania.

15. Niepoprawny podział zadań  między motyw i wtyczki

Ten błąd popełniają nie tylko niedoświadczeni programiści, ale też duże firmy. Zbyt wiele funkcjonalności upychają do motywu, zamiast wyodrębnić je w osobą wtyczkę lub wtyczki.  Z takiej polityki na szczęście wycofało się wielu dużych twórców motywów, np. WooThemes. Na czym polega problem?

Z założenia kod motywu powinien zawierać jedynie elementy kodujące wygląd serwisu, a właściwie to, co w tym wyglądzie jest unikatowe. Najprościej tłumacząc, nie powinien zawierać tych elementów, które wprost moglibyśmy użyć z zupełnie innym motywem, albo w ogóle ich nie zmieniając, albo dokonując jedynie drobnych korekt w CSS.

Wszystkie pozostałe funkcjonalności powinny być wydzielone do wtyczek. Warto się trzymać tej zasady tak ściśle, jak to tylko możliwe. Do wtyczek powinniśmy wydzielić nawet kawałki kodu odpowiadające za wygląd o ile są na tyle uniwersalne, że mogą być wykorzystane w innych motywach (np. kod wyświetlający pokaz slajów)

Powód jest bardzo prosty – jeśli kiedyś będziemy chcieli zmienić motyw, wszystko jedno czy na jakiś gotowy, czy będziemy sami robić od nowa wygląd serwisu, przeniesienie funkcjonalności będzie znacznie prostsze. Jeśli będziemy bardzo porządni, zmiana motywu może być zupełnie bezbolesna. Wygląd się zmieni, funkcjonalności pozostaną.

Kiedy kupujemy gotowy motyw, który ma wszyte wszystkie funkcjonalności, jesteśmy już potem na niego skazani. Ewentualnie możemy go zmienić na inny motyw tej samej firmy. Zmieniając go na inny tracimy całą logikę.

Jest jeszcze jeden powód – zwykłe utrzymanie porządku. Oddzielenie logiki od wyglądu to jeden z podstawowych postulatów porządnego programowania. Kiedy będziemy w tym dłubać pół roku po odpaleniu serwisu minimalizujemy w ten sposób szanse, że podmieniając jakiś drobiazg w wyglądzie zepsujemy kluczową funkcjonalność.

Pozostawiaj w kodzie motywu tylko rzeczy ściśle związane z jego wyglądem. Wszystkie inne funkcjonalności przenoś do wtyczek.

16. Nie stosowanie funkcji function_exists() i class_exists() 

Często zdarza się, że w kodzie motywu korzystamy z funkcji lub klasy jakiejś wtyczki, zupełnie ignorując fakt, że w pewnych okolicznościach ta wtyczka może być wyłączona – przypadkiem, wskutek błędu (np. podczas aktualizacji) albo podczas jakichś zmian w konfiguracji. W takim wypadku dość często dostajemy „biały ekran śmierci”, czyli serwis elegancko znika, albo w najlepszym przypadku, niekompletną stronę.

Fajnie, jeśli od razu skojarzymy co się stało i mamy pomysł co zrobić, ale jeśli np. podczas aktualizacji wtyczki coś poszło nie tak i jej kod nie zostanie uruchomiony, zostajemy z pustym ekranem i zagadką. Wszystko dlatego, że nie chciało nam się porządnie programować i tam gdzie to jest konieczne sprawdzić czy wtyczka, z której korzystamy jest zainstalowana i działa.

Jeśli wywołujemy funkcje w bardzo wielu miejscach powinniśmy ją zbramkować przez naszą funkcję, która albo zwróci sensowną wartość domyślna, albo przynajmniej zapewni nam sensowną diagnostykę. Jeśli nie mamy dostępu do loga błędów, co się zdarza na niektórych hostingach, jedynym wyjściem jest wypisać jakiś tekst diagnostyczny na stronie. Nie wygląda to dobrze, ale przynajmniej dzięki temu możemy szybko rozwiązać problem, zamiast szukać po omacku.

Jeśli używasz funkcji lub klasy dostarczanej przez wtyczkę, sprawdzaj zawsze czy jest ona dostępna poprzez function_exists() lub class_exists()

Dostępna jest też funkcja  is_plugin_active() zwracająca informację czy dana wtyczka jest aktywna, ale mamy do niej dostęp tylko w adminie, dlatego jej zastosowanie jest ograniczone.

17. Brak ograniczenia dostępu do funkcjonalności dla użytkowników o niskich uprawnieniach.

Kiedy dodajecie nowy ekran w adminie, albo opcję na pasku admina trzeba zawsze się zastanowić kto może mieć do tego dostęp. Nawet jeśli w danej chwili do serwisu może wejść tylko administrator, w przyszłości już tak być nie musi. Za pół roku nie będziesz pamiętać, że gdzieś tam, była dość groźna opcja, która powinna być niewidoczna dla redaktorów. Nawet jeśli to będą zaufane osoby, mogą nie mieć odpowiedniej wiedzy i mogą zepsuć coś niechcący.

Jeśli na przykład używasz wtyczki Social Login (a to nie jedyny przypadek) nowi, komentujący użytkownicy logujący się Facebookiem czy Googlem, trafiają do serwisu jako subskrybenci. Jeśli tego specjalnie nie wyłączysz mogą wejść do admina, żeby edytować swój profil. Nie chcesz, naprawdę nie chcesz, żeby przy okazji znaleźli zapomniane opcje administracyjne.

Role użytkowników i związane z nimi możliwości są dość dokładnie wyjaśnione na stronach codexu WordPressa.

Programując interfejsy administracyjne zawsze sprawdzaj kto może mieć do nich dostęp.

18. Ignorowanie RWD

W wypadku większości serwisów w tej chwili 10-30% ruchu pochodzi ze smartfonów i tabletów i ten procent dynamicznie rośnie. Tymczasem korzystanie na komórce czy nawet na tablecie z serwisu przygotowanego dla dużego monitora to najczęściej męka. Owszem da się, ale user experience jest fatalny. A dzisiaj w sieci zawsze można znaleźć jakiś podobny serwis, po co się męczyć z takim, z którego korzysta się niewygodnie.

Najtańszym sposobem na zbudowanie strony, która będzie wygodna na wszystkich urządzeniach jest skorzystanie z Responsive Web Design (RWD), warto pamiętać, że oprócz urządzeń o mniejszej rozdzielczości RWD pozwala nam dać więcej i poprawić użyteczność serwisu na monitorach full HD, gdzie możemy wykorzystać większość szerokości ekranu.

Tymczasem RWD najlepiej zaplanować od początku. Jeśli będziemy go chcieli dodać, gdy serwis będzie już gotowy, możemy być zmuszeni do przebudowy HTML’a, często będziemy musieli skorzystać z JavaScriptu, aby zmienić strukturę strony, a tego  należy unikać jeśli nie jest absolutnie konieczne.

Planuj układ serwisu na różnych rozdzielczościach od samego początku i zastanawiaj się czy założony layout będzie mógł się adaptować przy pomocy czystego CSS.

19. Nie dbanie o SEO

Może to się kiedyś zmieni, ale na razie w Internecie jest jeden bóg i nazywa się Google. Nawet jeśli na jakimś rynku radzi sobie Bing czy Yandex, światowy standard tego co potrafi wyszukiwarka, jak analizuje strony, w jaki sposób porządkuje wyniki, są narzucane przez Google. W dużej części zaś przez od zawsze znane zasady wykorzystania poszczególnych tagów HTML, mikroformatów, microdata, protokołu Open Graph, itd.

Nie wystarczy, że po zakończeniu pracy nad serwisem zainstalujemy i uruchomimy wtyczkę-kombajn w rodzaju WordPress SEO by Yoast. Wtyczka nie zmieni niepoprawnie użytego taga H2 na H1, nie wymyśli jakich powinniśmy użyć mikroformatów, nie wymyśli altów do obrazków, nie potrafi mądrze wyeliminować zduplikowanych treści, powtarzających się tytułów, itp.

Zobacz: Podstawy SEO – jak to działa.

Konsekwencje są proste – serwis będzie miał znacznie mniejszą oglądalność niż mógłby mieć. Jeśli to blogasek kuzynki, świat się nie zawali, ale jeśli jest to jest poważny biznes, to Twoje niedbalstwo, w długiej perspektywie będzie właściciela bardzo dużo  kosztować. W pewnych wypadkach, to może być różnica między sukcesem, a bankructwem.

W dodatku, naprawdę, zadbanie aby strona była zrobiona w miarę poprawnie, nie koniecznie idealnie, ale dostatecznie dobrze, najczęściej nie jest wielkim problemem. To pestka w porównaniu do długich godzin wysiedzianych nad wyglądem. Na pewno najgłębiej i najpilniej trzeba się pochylić nad SEO serwisów ecommercowych. Na szczęście, jeśli to jest klasyczny sklep, większość załatwia za nas dobra wtyczka (np. WooCommerce).

Nie traktuj SEO jako detalu na koniec pracy, który można zrobić albo nie. Dla sukcesu tworzonej strony SEO ma często większe znaczenie niż wygląd, czy nawet użyteczność.

20. Tworzenie zbyt złożonych rozwiązań dla redaktorów serwisu

Serwis, który tworzysz będzie często prowadzony przez osoby nietechniczne. WordPress sam z siebie jest już dość złożony, jeśli do tego dorzucisz skomplikowany interfejs, prowadzenie serwisu będzie męką. Nie chodzi tyko o dyskomfort, ale też o koszt.

Zamiast, na przykład, kodować na kategoriach jednocześnie: podział tematyczny, miejsce wyświetlenia postów i kolejność oraz kto ma do czego dostęp (a naprawdę widziałem już takie sztuki), dodaj jakieś osobne taksonomie. Fakt, że coś jest wykonalne informatycznie i wymaga jednej funkcji mniej w kodzie, nie oznacza, że jest rozwiązaniem do ogarnięcia przez normalnego człowieka. Jedna taksonomia powinna wprowadzać jeden podział, jedną klasę pojęć, a nie pomieszane kilka.

Posprzątaj ekran edycji wpisu. Jeśli korzystasz Advanced Custom Fields lub innej wtyczki pozwalającej na definicję własnych pól, wprowadź ich opisy, podaj wartości domyślne, poukrywaj niepotrzebne pola, a te, które zostaną, poukładaj w sensownej, wygodnej kolejności.

Jeśli przez miesiąc nie potrafisz nauczyć klienta jak wprowadzać dane, albo musiałeś napisać trzytomową instrukcję obsługi do serwisu, to znaczy, że nie klient jest ciemny, ani WordPress trudny, tylko Ty się nie postarałeś.

Pamiętaj, że nie wszyscy ludzie mają doświadczenie techniczne, a osoby wprowadzające dane do serwisu kosztują. Staraj się ułatwić życie osobom wprowadzającym dane. Pamiętaj, oni nie siedzieli w Twojej głowie kiedy wymyślałeś swoje tricki 🙂

Podsumowanie

Mam nadzieję, że te zebrane 20 zagadnień pomoże Wam lepiej zorganizować prace, uniknąć głupich błędów i kosztownych ślepych uliczek. Nie sposób zawsze trzymać się kurczowo wszystkich takich zaleceń – bo terminy gonią, bo się nie chce, i tak dalej. Nikt nie jest bez grzechu. Jednak, jeśli się łamie zasady, dobrze jest mieć świadomość co się łamie i czym to grozi.

Jeśli macie jakieś uwagi, pomysły, uzupełnienia, zapraszam do dyskusji w komentarzach.

Powiadomimy Cię o nowych artykułach

Komentarzy: 3

  1. Witam i bardzo dziękuję za ten artykuł. Bawię się WordPressem amatorsko od dłuższego czasu i myślałem , że sporo już wiem. A tu popełniłeś kilka bardzo przydatnych informacji, tak naprawdę dla każdego. Co najważniejsze forma przekazu jest na tyle zrozumiała, że nawet taki amator jak ja radzę sobie ze zrozumieniem treści. Wiele blogerów niestety pisze tak, jakby dodawała w pamięci. Mówią o jakimś zagadnieniu i w pewnym momencie piszą coś w rodzaju ” potem dodajemy ten kod do pliku i gotowe”. Zapominają dodać gdzie i do jakiego pliku – oni wiedzą ale większość czytających -nie. A przecież czytali cały artykuł właśnie po to.
    Raz jeszcze dziękuję .
    Jacek
    p.s
    To a pro po tytułu tego wpisu. To pierwszy i najważniejszy błąd osób piszących porady.

  2. Pod większością podpisuję się rękoma i nogami. Przede wszystkim nie dbanie o wydajność, po drugie seo, ale tylko dlatego że to zboczenie zawodowe 🙂

  3. Cześć tych błędów jest poprawiona, inne pozostały w ostatniej wersji WP.