20 największych błędów programistów używających WordPressa

1. Modyfikowanie kodu WordPressa

Ręczne dłubanie w kodzie WordPressa to największa zbrodnia wordpressowego programisty. Są dwa bardzo ważne powody, żeby tego nie robić.

Po pierwsze tracisz w ten sposób możliwość szybkiej aktualizacji kiedy wyjdzie nowa wersja, czy to ze względu na nowe funkcjonalności, czy ze względu na dziury w bezpieczeństwie. Próba połączenia Twoich zmian i nowej wersji zawsze będzie pracochłonna i ryzykowna. Nowe wersje WordPressa testują tysiące ludzi i wyłapują wszelkie możliwe niekompatybilności w tył – Twoich poprawek nie testowali.

Po drugie jeśli Ci się wydaje, że musisz zmieniać kod WordPressa, niemal na pewno robisz coś źle, wykraczasz poza logikę systemu i spowoduje to prędzej czy później jakieś problemy. WordPress jest naprawdę bardzo elastyczny i napisany pragmatycznie. Umiejętnie stosując haki (akcje, filtry), przysłanianie funkcji (Pluggable Functions) oraz wordpressowe wrzutki (WordPress Dropins) możesz zmienić co tylko dusza zapragnie. Jeśli to niemożliwe, to widocznie tak ma być.

Jeśli znalazłeś błąd w kodzie WordPressa, zgłoś go do Traca, najlepiej od razu proponując rozwiązanie lub dołączając łatkę.

2. Bezpośrednia modyfikacja kodu motywów

WordPress posiada bardzo przyzwoitą logikę tworzenia motywów potomnych. Jeśli kupiłaś lub ściągnęłaś skądś  gotowy motyw i chcesz w nim coś zmienić, powinnaś z tego mechanizmu skorzystać. Dłubanie w oryginalnym motywie pozbawia Cię możliwości aktualizacji, a w tym wypadku dość często są to aktualizacje związane z bezpieczeństwem.

Tutaj sprawa nie jest jednak tak jednoznaczna.  Jeśli zmiany, które chcesz nanieść nie są małe, nie są tylko tuningiem, ale de facto robisz własny, nowy motyw, startując z jakiegoś istniejącego, to zanika sens korzystania z mechanizmu motywów potomnych. I tak w końcu skopiujesz i zmienisz większość plików PHP.

Wtedy jednak powinnaś najpierw skopiować cały motyw i zmienić mu nazwę, w przeciwnym wypadku możesz kiedyś niechcący zaktualizować motyw startowy, tracąc wszystkie dokonane zmiany.

Z mojego doświadczenia wynika jednak, że ta druga sytuacja jest bardzo rzadka – najczęściej lepiej jest zrobić motyw potomny albo zacząć zupełnie od zera lub od jakiegoś startera, czyli jednego z motywów specjalnie zbudowanych jako punkt wyjścia do nowych motywów. Najbardziej znane to: Underscores, Roots i Reverie.

3. Budowanie zamkniętych wtyczek

Napisaliśmy, że nie wolno modyfikować kodu WordPressa i motywów dlatego, że w obydwu przypadkach mamy bardzo dobre rozwiązania pozwalające tego uniknąć. WordPress i jego system motywów są otwarte. Niestety często nie można tego powiedzieć o wtyczkach. Bywa, że nie korzystają one z akcji i filtrów w takim zakresie jak mogłyby korzystać, przez co czasem nie pozostaje nam inne wyjście tylko dobranie się do ich kodu.

Przykładami wtyczek, które dobrze wykorzystują akcje i filtry są opisane przeze mnie jakiś czas temu Advanced Custom Fields i WordPress SEO by Yoast, fantastycznie jest to zrobione we wtyczce WooCommerce. Za to wtyczką, która ostatnio zaskoczyła mnie negatywnie pod tym względem jest Wisjia Newsletter. (pod każdym innym względem jest znakomita – łatwa w obsłudze nawet dla nietechnicznych redaktorów bloga, solidna, nie sprawiająca problemów).

Niestety próba zmodyfikowania tego co jest przez tę wtyczkę wysyłane (abstrahując od możliwości ręcznej edycji) nastręcza problemy. Dzieje się tak właśnie dlatego, że wtyczka nie wykorzystuje filtrów. Pobiera wskazane wpisy z bazy i umieszcza w newsletterze, a przecież mogłaby przepuścić każde z pól przez jakiś filtr, aby świadomy programista mógł coś dodać lub zmienić.

Cóż, niestety musiałem „dłubnąć” w jej kodzie i teraz mam dodatkową pracę przy każdej aktualizacji, na szczęście jest to bardzo niewielka zmiana – właśnie dodanie wywołanie filtra.

Właściwym podejściem w takiej sytuacji jest też przygotowanie kawałka kodu (patcha, albo po prostu ręcznie zrobionego wycinka) i wysłanie do autorów wtyczki z propozycją aby dodali nowa funkcjonalność do jednej z kolejnych wersji. Dzięki temu być może inni też będą mogli czerpać korzyści z naszych poprawek – dlatego tak właśnie zamierzam zrobić.

4. Nieprawidłowe korzystanie z akcji i filtrów

Fakt, że mamy do dyspozycji rozwiązania otwarte nie oznacza, że możemy robić bałagan. Znakomity mechanizm akcji i filtrów w WordPressie powinniśmy także wykorzystywać właściwie.

Naczelną zasadą jest to, że kategorycznie nie wolno wykorzystywać filtrów do niczego innego poza modyfikacją danych, które zostały do nich podane. Filtr nie może modyfikować bazy, wypisywać niczego na wyjście (!), zmieniać opcji, itd. Krótko mówiąc, nie może robić nic „na boku” oprócz, albo zamiast tego do czego został stworzony. Jego wywołanie nie może mieć efektów ubocznych.

Do tych wszystkich rzeczy służą akcje.  Filtry służą do przekształcania danych. Taka była intencja twórców , tak to ma działać, takiego działania się spodziewają inni, którzy będą wykorzystywać dany filtr. Jeśli na przykład usunę filtry dla haka wp_title spodziewam się, że po prostu dostanę wyjściowy, nie przekształcony przez nic tytuł wpisu, a nie że przestanie mi działać coś w serwise, albo jakieś zapytania zaczną zwracać dziwne wyniki.

5. Nie korzystanie z WP_DEBUG

Dość żenujące jest kiedy jakaś dość szeroko używana wtyczka po zainstalowaniu zaczyna sypać ostrzeżeniami o tym, że nie zostały zainicjowane jakieś zmienne, albo używana jest funkcja oznaczona jako deprecated. Tego typu ostrzeżenia nie muszą, ale mogą oznaczać coś złego –  na pewno oznaczają to, że autor wtyczki nie przyłożył się do pracy i na pewno nie kupuje w ten sposób mojego zaufania.

Zawsze sprawdzam jaki jest powód tych ostrzeżeń, zwłaszcza jeśli działanie wtyczki jest kluczowe dla funkcjonowania serwisu i zdarzało mi się znajdować całkiem poważne błędy. Mógł je zauważyć autor wtyczki, gdyby pracował z włączonym trybem diagnostycznym – ze stałą WP_DEBUG ustawiona na true.

Z drugiej strony mało profesjonalne jest kiedy działający serwis, napotkany w Internecie „wyświetla błędy, ostrzeżenia i informacje diagnostyczne użytkownikom – poza wszystkim, w ten sposób odsłania przed potencjalnymi włamywaczami swoje „miękkie podbrzusze”.

6. Modyfikacja tabel bazy WordPressa

Jeśli potrzebujesz coś zapisać w WordPressie, jakieś swoje, niestandardowe dane, masz do dyspozycji całą gamę możliwości (o różnej przydatności, w zależności od tego, co tak naprawdę potrzebujesz zapisać).

• Możesz zapisać coś do tabeli opcji (funkcje add_option(), get_option(), update_option()). Niektóre wtyczki przechowują w niej spore bloki danych.
• Możesz zapisać coś jako metadane do wpisu, lub użytkownika (post meta, user meta).
• Możesz utworzyć specjalny prywatny typ wpisów (custom post type) niewidoczny w adminie i korzystać z niego.
• Możesz utworzyć własne tabele bazodanowe w bazie WordPressa – dostajemy do tego wygodne narzędzia (klasę wpdb), nie musimy nic hakować.

Tak naprawdę jedyną rzeczą, której nie wolno robić, jest modyfikowanie tabel bazodanowych WordPressa, dodawanie do nich kolumn i przyjmowanie jakichś zależności między nimi.

To jest prawdziwe proszenie się o kłopoty – bardzo łatwo zderzyć się ze zmianami jakie robi w swoich tabelach sam WordPress w jednej z kolejnych wersji, albo z innym developerem o podobnie radosnym podejściu.

7. Elementy administracyjne dostępne po stronie frontowej

Interfejsy administracyjne wielu wtyczek są dość ciężkie. Ważniejsze jest to aby były  wygodne dla osoby, która z nich korzysta, wydajność ma zwykle nieco mniejsze znaczenie. Najczęściej korzysta z nich w danym momencie tylko jedna osoba, co generuje pojedyncze zapytania do serwera. Nawet jeśli dość poważnie obciążają bazę, ładują sporo danych i skryptów można z tym żyć, tak długo dopóki nie powoduje to błędów.

Niestety często autorzy wtyczek zapominają ograniczyć wykonywanie skryptów PHP albo ładowanie skryptów JS administracyjnych, tak aby nie były dołączane, wykonywane, czy przesyłane (w zależności od rodzaju skryptu i wtyczki) po stronie frontowej serwisu czyli na stronach, z których korzystają użytkownicy.

Jeśli serwis jest względnie popularny takich osób może być dużo, więc ładowanie i wykonywanie zbędnych skryptów obciąża serwer, wydłuża czas ładowania strony (co może mieć negatywny wpływ nawet na pozycję w wyszukiwarkach). W dodatku jest to dziura w bezpieczeństwie – nic złego nie musi się zdarzyć, ale rośnie prawdopodobieństwo problemów.

8. Ładowanie wszystkich skryptów JS i arkuszy CSS na wszystkich stronach

Nawet jeśli skrypty JS administracyjne ładujemy, tak jak trzeba,  tylko w adminie, pozostaje problem, na której konkretnie stronie ładować dany skrypt.  Przecież najczęściej potrzebujemy go tylko na stronie ustawień naszego motywu czy wtyczki. Bardzo często jednak autorzy wtyczek korzystają z haka admin_enqueue_scripts bez żadnych dodatkowych warunków. To oznacza, że skrypt załaduje się na wszystkich stronach admina.

Jeśli używasz 20 wtyczek, a przy większym serwisie to nie jest wcale jakaś wyjątkowa liczba, i każda z tych wtyczek ładowałaby w ten sposób średnio 3 skrypty, to na każdej stronie admina będzie ładowane 60 skryptów, prawie wszystkie niepotrzebnie. Jeśli podobne podejście autorzy wtyczek będą mieć do kodu PHP, na każdej stronie będą się inicjalizować dziesiątki niepotrzebnych obiektów, ładować jakieś niepotrzebne zupełnie dane z bazy itd. Tak – dobrze myślisz – z tego właśnie powodu po zainstalowaniu kilkunastu wtyczek admin WordPressa jest bardzo często koszmarnie wolny. Oczywiście zależy jakich wtyczek używasz, bo niektóre są napisane porządnie.

Te same zasady mają zastosowanie po stronie frontowej. Jeśli, na przykład, używasz na stronie głównej slidera ze zdjęciami, nie musisz jego skryptu i dodatkowego arkusza stylów ładować na każdej stronie serwisu. Przecież potrzebny jest tylko na stronie głównej, prawda? Jeśli masz stronę /kontakt/ i na niej  formularz kontaktowy, to nie musisz skryptów do niego ładować na pozostałych stronach, bo tam go nie ma. I tak dalej.

9. Sztywne kodowanie nazw katalogów i adresów URL.

Wszystkie dane i skrypty poza core WordPressa znajdują się w katalogu wp-content, wtyczki w podkatalogu plugins, motywy w podkatalogu themes, a wgrywane pliki (najczęściej obrazki) w podkatalogu uploads.

Prawda?

Nie, nie prawda!

Wszystkie te katalogi można zmienić, wystarczy kilka definicji w pliku wp-config.php i żaden z powyżej wymienionych katalogów nie będzie używany. Takie, inne konfiguracje możesz napotkać na specjalizowanych hostingach wordpressowych, inaczej te ścieżki mogą być poustawiane w instalacji WordPress multisite. Ponieważ można je zmienić, jest to przewidziane w systemie, każdy może to zrobić – dlatego nie wolno Ci kodować ich na sztywno.

Budując nazwy katalogów i adres URL plików w WordPressie zawsze korzystaj z funkcji w rodzaju content_url(), plugin_url(), wp_upload_dir(), g et_template_directory(), home_url() i podobnych oraz ewentualnie ze stałych w rodzaju WP_CONTENT_DIR, WP_CONTENT_URL, WP_PLUGIN_DIR, UPLOADS, itp.

10. Zaniedbywanie sanityzacji danych na wejściu i nie escapowanie danych na wyjściu

Zacząłem tę część tekstu od największej zbrodni, a kończę drugą w kolejności. Ze zrozumieniem jednak przyjmę argumenty, że ta jest większa, bo dotyczy nie tylko WordPressa – jest to po prostu bardzo groźne zaniedbanie niezależnie od tego co i w czym programujemy.

W każdym programie dane podane przez użytkownika należy traktować jako „skażone” – potencjalnie groźne. W serwisie internetowym dane takie mogą pochodzić z formularza, ze zmiennych przekazanych w adresie URL (przesłane przez GET) albo przesłanych np. AJAXem przez POST. W każdym z tych przypadków nie tylko użytkownik może wpisać groźne dane, ale ktoś o złych intencjach może podmienić np. treść zapytania AJAXowego. Użycie tych danych bez sprawdzenia, bez przepuszczenia przez jakąś funkcję, która je oczyści z potencjalnych zagrożeń jest poważną i prawdopodobnie najczęściej wykorzystywana dziurą  w bezpieczeństwie. Znakomicie ilustruje to legendarna już historyjka z xkcd.

Wszelkie dane, które wypisujemy na wyjściu powinniśmy escapować. Zapobiega to nie tylko rozsypywaniu się strony w wypadku gdy w wypisywanych danych znajdzie się coś, co zostanie zinterpretowane jako HTML, ale także przypadkowemu wykonaniu skryptów, które podsunęła nam jakaś dłoń o złych intencjach.

O wiele danych WordPress dba za nas. Jeśli na przykład poprawnie korzystamy z funkcji bazodanowych WordPressa możemy w tym obszarze czuć się bezpieczni. We wszystkich innych wypadkach mamy do dyspozycji spory zestaw funkcji zarówno w samym PHP jak i w WordPressie, które powinniśmy stosować. Polecam lekturę artykułu na ten temat w kodeksie WordPressa.

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)

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.

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.

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)

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.

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ść.

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.

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.

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.

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).

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ś.