yashke.com

Janu @ March 17th, 2007

Pisanie pluginu do Wordpressa

Pisałem już raz na ten temat, jednak wtedy moje podejście do tworzenia pluginu wordpressowego było ekstremalne - jako źródło informacji, jak tworzyć wordpressowe pluginy, brałem źródła standardowych pluginów. Biorąc się za pisanie yGigs, czyli naszego działu praca, stwierdziłem, że skoro już mam swobodny dostęp do internetu, to najpierw poczytam dokumentację, a dopiero potem wezmę się za robotę. Tak też zrobiłem - zacząłem od pobieżnej lektury strony Writing a Plugin. Znalazłem tam informacje, których już wcześniej się domyślałem - istnieje API wordpressowe, o całkiem sporych możliwościach, którego należy używać przy pisaniu pluginów.

Na początek warto zapoznać się z możliwościami klasy WPDB odpowiedzialnej za połączenie z bazą danych. Obiekt odpowiedzialny za bazę danych jest zdefiniowany globalnie - jest to zmienna $wpdb. Normą w pisaniu aplikacji z Wordpress jest używanie zmiennych globalnych wypisanych na początku przy użyciu instrukcji global. Obiekt ten posiada następujące metody (piszę o tych rzeczywiście istotnych):

  • query - wykonuje zapytanie SQLowe podane jako argument; przydatne przy różnych insertach i update’ach
  • get_results - pobiera jako argument zapytanie SQLowe oraz typ komórki tablicy, jaka ma zostać zwrócona - wybrać można między OBJECT (obiekt), ARRAY_N (tablica numerowana) a ARRAY_A (tablica asocjacyjna).
  • get_row - zwraca jeden wiersz znaleziony zapytaniem SQLowym, drugim argumentem jest typ zwróconej zmiennej, a opcjonalnym trzecim - numer wiersza, który ma być zwrócony
  • get_var - zwraca jedną wartość znalezioną zapytaniem SQLowym; opcjonalne dwa argumenty to numer kolumny oraz numer wiersza, w którym znajduje się żądana wartość

Dosyć ważne jest też pole prefix, które przechowuje prefiks nazw tabel z bazy danych. Zaleca się (a przynajmniej ja zalecam) używanie nazw tabel z takim prefiksem - wówczas struktura bazy blogaska jest bardziej spójna, jeśli chodzi o sam wygląd. Bardziej szczegółową specyfikację znaleźć można w dziale Function Reference/wpdb Class.

Zabierzmy się teraz za ogólną strukturę skryptu - Wordpress posiada haki akcji. Hak to miejsce przy wykonywaniu skryptu, które jest specjalnie oznaczone i przy którym można wywołać dodatkowy kod, jeśli został on gdzieś indziej (w domyśle - w pluginie) zdefiniowany. Zdefiniowany kod to akcje - przyjęto założenie, że kod musi być zawarty w funkcji, dzięki czemu można łatwo się do niego odnosić. Najpierw zajmijmy się czymś prostym - definiowaniem akcji dla danego haka - tworzymy sobie funkcję o jakiejś nazwie, a następnie wywołujemy funkcję add_action, której pierwszym argumentem jest nazwa haka, natomiast drugim nazwa funkcji, która ma być wywołana. Więcej o funkcji add_action przeczytać można w Function Reference/add_action, natomiast podstawowe haki w Plugin API.

Takie właśnie haki akcji pozwalają w ogóle na tworzenie pluginów. Dzięki nim możemy dodawać swoje operacje przy wszystkich najważniejszych działaniach skryptu - od generowania formularza dodającego posty do naszego bloga, po przetwarzanie dodawanych komentarzy. W prostych pluginach najbardziej jednak przyda nam się hak odpowiedzialny za instalację pluginu oraz hak od generowania menu panelu administratorskiego.

Pierwszy z nich nosi nazwę activate_(script_name), gdzie w miejsce (script_name) wstawiamy nazwę naszego pluginu. Wskazuje on funkcję, która służy do instalacji pluginu - może ona np. tworzyć odpowiednie tabele w bazie danych. I tutaj od razu przyda się kolejna uwaga - do instalacji tabel w bazie danych zaleca się używania funkcji dbDelta. Jest to funkcji dodatkowa, znajdująca się w pliku wp-admin/upgrade-functions.php, który należy includować (include_once). Przyjmuje ona jako argument SQL odpowiedzialny za instalację tabeli. W tym miejscu pragnę przypomnieć o polu $wpdb->prefix, które przechowuje prefiks nazw tabel - warto go stosować przy nazywaniu własnych.

Hak generujący menu panelu administratorskiego nosi nazwę admin_menu. By dodać nowy dział menu należy użyć funkcji add_menu_page, której argumentami są:

  • tytuł strony opcji
  • nazwa menu
  • poziom dostępności - jakie trzeba mieć uprawnienia, by oglądać tą stronę (więcej - User Levels)
  • plik, w którym przechowywany jest skrypt
  • nazwa funkcji odpowiedzialnej za stronę danego menu

Więcej o funkcji add_menu_page można poczytać w tekście Adding Administration Menus. Gdy już utworzymy menu warto również stworzyć submenu - służy do tego funkcja add_submenu_page - pierwszym jej argumentem jest nazwa rodzica, a następne są takie jak w add_menu_page. Oczywiście czasem tworzenie osobnego działu w menu Wordpressa jest głupotą - jeśli ma być on tylko odpowiedzialny za opcje. Wówczas stworzyć można osobną podstronę z opcjami przy użyciu funkcji add_options_page. Więcej informacji na temat tej funkcji oraz innych tworzących menu znaleźć można w wyżej wymienionym tekście Adding Administration Menus.

Czasem przyda się oszukać trochę Wordpressa jeśli chodzi o przetwarzanie URLi - np. gdy potrzebujemy przesyłać w adresie jakieś wartości - wówczas należy użyć haka parse_query. Podana mu funkcja jako akcja powinna przyjmować jeden argument - $wp_query, który jest obiektem klasy WP_Query. Klasę tę znaleźć można w katalogu wp-includes/classes.php i oczywiście jest ona domyślnie wpięta do Wordpressa. Więcej na temat WP_Query poczytać można w Function Reference/WP Query.

Na koniec warto wspomnieć o kilku konwencjach stosowanych przy pisaniu pluginów w Wordpressie. Po pierwsze - zalecane jest tworzenie dokumentacji inline, czego ja niestety nie czyniłem dotąd. Oprócz tego nawiasowanie bloków rozpoczyna się w tej samej linii co nazwa instrukcji, a kończy znakiem “}” po enterze. Powinniśmy także używać zwykłych znaków tabulacji przy wcięciach. Skrypty powinny być trzymane w znacznikach <?php ?>, a nie krótszych <? ?>. Należy używać spacji do oddzielania wyrażeń i operatorów. Każda funkcja powinna mieć globalnie unikalną nazwę - wiadomo przecież, że PHP nie obsługuje przeciążania funkcji. Więcej informacji na temat standardów kodowania znaleźć można w dokumencie Coding Standards.

To tyle, jak na razie, jeśli chodzi o pisanie pluginów dla Wordpressa. Mam nadzieję, że powyższy tekst przyda się komuś przy pracy - mi poznanie Wordpressa zajęło chwilkę, ale im bardziej poznawałem tę aplikację, tym bardziej podziwiałem kod, za ogromną elastyczność - dzięki temu Wordpressa używać można zarówno jako bloga, jak i dynamiczną wizytówkę z mnóstwem dodatków.

Tagi: ,

2 Komentarzy do “Pisanie pluginu do Wordpressa”

  1. Arkady_pl napisał:

    Witaj.
    Na Google jesteś jedyna stroną, na której znaleziono add_menu_page( w kategorii POLSKI.

    Odnośnie Twojego wpisu o pierwszysch dwóch identycznych parametrach, to znalazłem http://api.coffee.geek.nz/api/function/add_menu_page/wordpress

    Jest team rozpisana funkcja add_menu_page, na bazie ktorej mozna wyczaic ktory parametr co robi nie kopiąc w plikach WP.

    Aktualnie tez rozpracowuję jak pisać poprawnie pluginy aby robiły to co ja chce i abym wiedzial dlaczego takl to dziala a nie inaczej.

    Generalnie brakuje mi polskiej dokumentacji bo EN znam bardzie kiesko.
    Moze kiedys powstanie prawdziwe wsparcie dla WP, ktore bedzie bardziej dla deweloperow a nie tylko kopalnia gotowcow.

    Pozdrawiam….

  2. Arkady_pl napisał:

    Witaj.
    Chcę dodać do Twojej wypowiedzi, że w funkcji add_menu_page() jako czwarty parametr zamiast podawać jawnie nazwę zbioru to można podać __FILE__, co skutkuje wpisaniem pełnej ścieżki i zbudowaniem właściwego URLa gdy nasz plugin jest w folderze pluginów. Inaczej trzeba podac jawnie zarowno nazwe pliku jak i sciezke. Oczywiscie ma to zastosowanie gdy nasza funkcja leży w tym samym pliku.

Skomentuj ten wpis!