Ta strona używa ciasteczek (cookies), dzięki którym nasz serwis może działać lepiej. Dowiedz się więcej OK, rozumiem
WebHelp.pl Blog Jak NIE pisać wtyczek i szablonów dla WordPressa

Blog

Jak NIE pisać wtyczek i szablonów dla WordPressa

Bartosz Romanowski 17 lipca 2012 komentarze ()

Tagi:programowanie WordPress

WordPressTak, to jest kolejny tekst o najpopularniejszych błędach popełnianych przez twórców wtyczek i szablonów dla WordPressa. Bo co z tego, że X osób już o tym pisało, skoro wciąż trafić można na takie cuda, że nóż się w kieszeni otwiera. Wydaje mi się, że zebrałem tu najczęściej popełniane wykroczenia, ale ponieważ inwencja niektórych autorów nie zna granic, to z całą pewnością pojawią się kolejne.

Dodawanie skryptów

Podstawowy i najczęstszy błąd twórców wtyczek i szablonów polega na nieprawidłowym dodawaniu skryptów JavaScript. O tym, jak to robić poprawnie, można przeczytać tutaj. A jak tego NIE robić?

Przede wszystkim nie wolno (serio, nie wolno, to zabronione, zakazane i w ogóle) dodawać skryptów pakując własne znaczniki <script> do nagłówka (obojętnie czy "na sztywno" do pliku header.php, czy "ładniej" poprzez własną funkcję odpalaną w akcji wp_head). Nie wolno i tyle. Jeśli jakiś skrypt JavaScript został dodany w ten właśnie sposób, to WordPress po prostu o tym skrypcie nie wie, a co za tym idzie pozwoli dodać go w poprawny sposób jeszcze raz (na przykład w innej wtyczce) - czyli skrypt zostanie załadowany dwa razy, czyli w większości przypadków się wysypie i pociągnie za sobą całą resztę skryptów. Najczęściej skończy się to tak, że większość skryptów po prostu przestanie działać.

Wszystko, co napisałem powyżej, dotyczy również arkuszy stylów, ale w tym przypadku szkody są zdecydowanie mniejsze.

Jeśli skrypt jest dodany w poprawny (z pozoru) sposób, czyli przy użyciu funkcji wp_enqueue_script (tak jak to opisałem tutaj), to musimy mu podać jakiś identyfikator (pierwszy parametr funkcji), poprzez który będzie on identyfikowany przez WordPressa. Nadając skryptowi identyfikator nie należy kombinować, tylko wymyślić taki, który z największym prawdopodobieństwem będzie oczywisty dla wszystkich innych autorów korzystających z tego samego skryptu. Na przykład, dodając skrypt Lightbox nadajmy mu identyfikator lightbox, a NIE moja-super-wtyczka-lightbox. Czyli poprawny kod powinien wyglądać na przykład tak:

Kod: Zaznacz cały

wp_enqueue_script('lightbox', plugins_url('/lightbox/jquery.lightbox.js', __FILE__), array('jquery'));

a NIE tak:

Kod: Zaznacz cały

wp_enqueue_script('moja-super-wtyczka-lightbox', plugins_url('/lightbox/jquery.lightbox.js', __FILE__), array('jquery'));

Warto przy okazji zwrócić uwagę na trzeci parametr, w którym określamy zależność dodawanego właśnie skryptu od innych skryptów (w tym przypadku od jQuery). Jest on opcjonalny, ale warto o nim pamiętać, żeby uniknąć takich niespodzianek jak w wersji 3.4 WordPressa, w której zmieniono sposób ładowania skryptów, w skutek czego kolejność ich dodawania przestała mieć znaczenie.

Równie irytującym błędem jest nie używanie przy dodawaniu skryptów i arkuszy stylów funkcji zwracających adres, pod jakim został zainstalowany WordPress. Wszystko działa w momencie gdy nasza strona znajduje się w katalogu głównym domeny, ale jeśli została zainstalowana na przykład w katalogu /blog/, to zaczynają się problemy. Niepoprawny sposób dodawania skryptu może wyglądać na przykład tak:

Kod: Zaznacz cały

wp_enqueue_script('lightbox', '/wp-content/plugins/lightbox/jquery.lightbox.js', array('jquery'));

Kolejnym, bardzo, ale to bardzo poważnym błędem, jest zastępowanie oryginalnych wersji bibliotek JavaScript swoimi własnymi. Najczęściej genialni autorzy robią tak z jQuery, wymuszając załadowanie jakiejś przedpotopowej wersji zamiast tej dołączonej do WordPressa. Nie, nie, i jeszcze raz nie! Jeśli Twoje skrypty nie działają z aktualną wersją jQuery, to napraw je, bo to one są problemem, a nie na odwrót. Jeśli nie potrafisz, usuń swoją wtyczkę z repozytorium, tak aby Twoje "dzieło" nie rozprzestrzeniało się po świecie.

Warto jednak dodać, że jeśli chcemy ładować jQuery (albo dowolną inną dołączoną do WordPressa bibliotekę) z zewnętrznego źródła (na przykład z serwerów Google), to jak najbardziej można to robić, pod warunkiem, że będziemy ładować tę samą wersję.

Generalnie powinniśmy kierować się zasadą: jeśli jakaś biblioteka, z której chcemy/musimy skorzystać, jest dołączana do WordPressa, to należy użyć dołączonej wersji. Koniec, kropka. To ułatwi życie zarówno autorom, jak i użytkownikom.

Brak wymaganych elementów motywu

Ta kategoria błędów nie dotyczy wtyczek, ale może mieć na nie wpływ. Podstawowym grzechem twórców motywów (na szczęście niezbyt częstym, co nie oznacza, że nie występującym) jest "zapominanie" o funkcjach wp_head() i wp_footer(). Za ich pomocą WordPress umieszcza w kodzie szablonu dodatkowy kod (między innymi wspomniane wcześniej skrypty oraz to, co autor sobie dodał we własnym zakresie) - pierwsza z nich powinna znaleźć się na samym końcu sekcji <head> szablonu (plik header.php, druga na końcu sekcji <body> (plik footer.php). Powiązanym (i niestety częstszym) błędem jest brak wywołania funkcji get_header() i get_footer() w każdym pliku szablonu. Funkcje te wstawiają gdzie trzeba nagłówek i stopkę motywu. I znowu, znacznie częściej zdarza się brak wywołania tej drugiej funkcji (pewnie dlatego, że efekty są mniej widoczne albo widoczne dopiero przy próbie instalacji czegoś, co korzysta ze stopki).

Droga na skróty, czyli niepoprawne wyświetlanie treści wpisów

Błędy z tej grupy występują w szablonach i wtyczkach bardzo często. Równie często nie są w ogóle zauważane przez użytkowników - do pewnego momentu.

WordPress posiada szereg funkcji zwracających elementy wpisów (takie jak tytuł czy treść). Jednak część autorów nie przejmuje się nimi zbytnio i z uporem maniaka korzysta z właściwości obiektu $post. Na przykład tak:

Kod: Zaznacz cały

<a href="<?php the_permalink(); ?>" title="<?php echo $post->post_title; ?>"><?php echo $post->post_title; ?></a>';

Na pierwszy rzut oka to działa i do pewnego momentu będzie działać. Momentem zwrotnym okaże się cudzysłów w tytule wpisu, który rozwali podany powyżej kod HTML. WordPress oferuje funkcję esc_attr, która odpowiednio przygotowuje dowolny tekst do umieszczenia go we wszelkiego rodzaju atrybutach, na przykład w pokazanym tu title. To jednak nie wszystko, bo akurat w tym przypadku korzystanie ze zmiennej $post->post_title jest po prostu błędem. Wyświetlając lub pobierając tytuł należy bezwzględnie korzystać z odpowiednich funkcji, takich jak the_title(), get_the_title() czy the_title_attribute(). A to dlatego, że niektóre wtyczki (na przykład popularny qTranslate) używają filtrów do modyfikacji tytułów wpisów przed ich wyświetleniem i po prostu nie będą działać. Tak więc poprawna wersja zamieszczonego powyżej kodu może wyglądać na przykład tak:

Kod: Zaznacz cały

<a href="<?php the_permalink(); ?>" title="<?php the_title_attribute(); ?>"><?php the_title(); ?></a>';

Przyzwyczajmy się do tych funkcji i używajmy ich zawsze i wszędzie - ułatwimy życie użytkownikom i autorom innych wtyczek.

Bałagan w kodzie

Kwestie formatowania kodu przemilczę, bo sporo zależy od przyjętej przez autora konwencji. Natomiast nie da się przemilczeć niechlujnych wcięć lub (o zgrozo!) zupełnego ich braku, pomieszania wcięć robionych za pomocą znaku tabulacji i czterech lub dwóch spacji, całej masy zbędnych pustych linii czy kompletnego braku komentarzy. Ale to wszystko jest kwestią estetyki - większość użytkowników nawet nie zajrzy do kodu używanych przez siebie wtyczek czy szablonów.

Problemem może być natomiast nazewnictwo funkcji. Jeśli nazwy funkcji są zbyt ogólne, zbyt proste lub (naprawdę to się zdarza) powtarzają się w kilku różnych wtyczkach, to prędzej czy później skończy się to katastrofą. Jeśli jeden autor tworzy dwie różne wtyczki, które współdzielą ten sam kod (na przykład jakiś zestaw uniwersalnych funkcji), to albo powinien przed deklaracją nowej funkcji sprawdzić czy taka funkcja przypadkiem już nie istnieje, albo opakować te funkcje w klasę (dzięki czemu nie wystąpi konflikt, mimo że ten sam kod wystąpi dwa razy).

Autorzy często zapominają również o tym, że nie każdy użytkownik ma serwer skonfigurowany tak samo jak oni. W konsekwencji jeśli wtyczka lub szablon wymaga instalacji jakiejś biblioteki, to po prostu przestaje działać zamiast grzecznie poinformować użytkownika o tym, czego mu brakuje i jak ten brak można uzupełnić. Tego typu błędy zdarzają się nawet największym - ot chociażby programistom Facebooka, którzy w pierwszej wersji swojej oficjalnej wtyczki niepoprawnie obsługiwali sytuację, w której na serwerze nie ma zainstalowanego rozszerzenia cURL (inna sprawa, że prawdopodobnie wystarczyło skorzystać z dostępnego w WordPressie HTTP API).

Mimo że nie jest to zalecane (ja bym tego wręcz zakazał), niektórzy autorzy integrują wtyczki ze swoimi szablonami. W praktyce wygląda to tak, że cały kod wtyczki jest wpakowany do pliku functions.php poprzez include lub (tragedia!) zwyczajne kopiuj-wklej. Poza opisanym wyżej problemem z konfliktami nazw funkcji (co jeśli użytkownik używa już wtyczki, z którą szablon jest zintegrowany?), to na dodatek nie ma możliwości aktualizacji takiej wpakowanej do kodu szablonu wtyczki, a nawet jeśli jest, to użytkownik nie jest w żaden sposób informowany o dostępnej aktualizacji. Pół biedy jeśli aktualizacja jest jedynie kosmetyczna lub dodaje jakieś nowe funkcje - problem pojawia się gdy konieczne jest załatanie jakiegoś błędu mającego wpływ na bezpieczeństwo. Tak więc, szanowni twórcy szablonów, nie dołączajcie do swoich motywów żadnych wtyczek - znacznie lepiej jest umieścić w widocznym dla użytkownika miejscu informację o konieczności instalacji jakichś rozszerzeń, wraz z wyjaśnieniem dlaczego taka konieczność w ogóle istnieje.

Tworzenie nowych tabel w bazie danych

Zawsze gdy widzę wtyczkę, która tworzy jakieś dodatkowe tabele w bazie danych, sprawdzam po co to w ogóle jest robione. W 99% przypadków jest to kompletnie bez sensu! Dane wtyczki, które są pakowane do nowej tabeli, z powodzeniem można byłoby umieścić w tabeli wp_options WordPressa (korzystając ze standardowego Options API) lub w dodatkowych polach wpisów. Dodatkowe tabele nie są domyślnie backupowane przez większość popularnych wtyczek do tworzenia kopii bezpieczeństwa, a mało zorientowany w temacie użytkownik może w ogóle nie zauważyć konieczności dodania nowej tabeli do kopii. To samo dotyczy przenoszenia serwisu na inny serwer.

Jeśli już wspomniałem o Options API, to warto dodać do i tak już długiej listy grzechów kolejne przewinienie: tworzenie dziesiątek nowych wpisów w tabeli wp_options, co gorsza z włączoną opcją autoload (czyli WordPress ładuje je zawsze, niezależnie od tego czy są w ogóle potrzebne). Jeśli wtyczka ma dużo różnych opcji, to albo dodajemy je z wyłączonym automatycznym ładowaniem, albo dodajemy jeden wpis zawierający zserializowaną tablicę (array) z wszystkimi używanymi przez wtyczkę opcjami. I nie chodzi tu o ilość zajmowanego w bazie miejsca, ale o szybkość ładowania i zużycie pamięci (przy włączonej opcji autoload). Oczywiście nie oznacza to, że autoload to zło - korzystajmy jednak z niego wtedy, kiedy jest to naprawdę potrzebne.

Wymyślanie koła od nowa

Błędy tego rodzaju (chociaż w sumie nie są to błędy - raczej wykonana niepotrzebnie praca) popełniane są głównie przez autorów, którzy dopiero rozpoczynają swoją przygodę z WordPressem. Albo przez takich, którzy naukę uznają za niepotrzebną stratę czasu. Po co tworzyć od podstaw coś, co już jest dostępne? Za przykład niech posłuży korzystanie z rozszerzenia cURL zamiast użycia WordPressowego HTTP API. Oczywiście, są przypadki, w których HTTP API okaże się niewystarczające, ale na pewno nie ma ich zbyt wiele.

Najbardziej ekstremalnym przykładem "błędów" tego typu jest wyciąganie danych z bazy WordPressa za pomocą własnych zapytań SQL. W 99% przypadków wystarczyłaby znajomość dostępnych funkcji.

Błędy drobne, aczkolwiek upierdliwe

Ta kategoria błędów nie spowoduje, że nasz blog rozsypie się w drobny mak, w ogóle przestanie działać albo spowoduje stopnienie lodu na Antarktydzie. Są to po prostu irytujące (i w większości łatwe do poprawienia) niedociągnięcia.

Rejestrowanie sidebarów bez ID i klasy

Brak tych atrybutów uniemożliwia odwołanie się w arkuszu stylów CSS do konkretnego widżetu lub do konkretnej instancji widżetu. Niby nic, ale jeśli ktoś chce na przykład zmienić kolor tła jednego wybranego widżetu tekstowego, to nie może.

Niepoprawnie:

Kod: Zaznacz cały

register_sidebar(array('name' => 'Sidebar',
	'before_widget' => '<div class="widget">',
	'after_widget' => '</div>',
	'before_title' => '<h4>',
	'after_title' => '</h4>',
));

Poprawnie (kluczowy jest tu parametr before widget:

Kod: Zaznacz cały

register_sidebar(array('name' => 'Sidebar',
	'before_widget' => '<div id="%1$s" class="widget %2$s">',
	'after_widget' => '</div>',
	'before_title' => '<h4>',
	'after_title' => '</h4>',
));

Brak funkcji inicjujących i deinstalujących wtyczkę

Funkcja inicjująca powinna dodać wszystkie wymagane opcje z wartościami domyślnymi, funkcja deinstalująca powinna posprzątać po sobie, czyli usunać wszystkei dodane opcje, dodatkowe pola wpisów itd., itp.. Nie jest to wymagane, ale na pewno jest eleganckie.

Umieszczanie skryptów wszędzie, a nie tylko tam, gdzie są potrzebne

Dotyczy to zarówno skryptów JavaScript, jak i PHP dołączanych przez include. Generalna zasada: jeśli na danej podstronie czegoś nie używamy, to nie powinno to być dołączane. Jeśli będzie, to nic się nie stanie, ale pamięć serwera nie jest z gumy, podobnie jak łącze użytkownika.

Bezpieczeństwo

Zagadnienie bezpieczeństwa jest bardzo szerokie i w tym tekście nie będę się nim zajmował (to temat na obszerny artykuł). Warto tylko wspomnieć, że trzeba pamiętać o sprawdzaniu uprawnień aktualnego użytkownika, o nonces w formularzach oraz o filtrowaniu danych przesyłanych przez użytkownika (szczególnie gdy mają one trafić do bazy danych).

Jestem pewien, że nie udało mi sie wymienić wszystkich (nawet tych najczęstszych) grzechów popełnianych przez autorów wtyczek i szablonów. Tych z was, którzy mają w tym temacie coś do dodania, zachęcam do podzielenia się swoimi doświadczeniami w komentarzach do tego wpisu.

Bartosz Romanowski

Programista, gadżeciarz, krytyczny miłośnik produktów Apple, fan ciężkich brzmień i niepoprawny pesymista.


Zobacz także

Komentarze

Tematy


Popularne wpisy

Autorzy bloga



HTML CSS JavaScript PHP bazy danych MySQL Flash grafika framework hosting domeny pozycjonowanie wordpress Facebook