Trochę więcej bezpieczeństwa w WordPress

Każda co bardziej rozgarnięta osoba, wie, że pobieranie wtyczek i skórek do WordPressa z nieznanego źródła prędzej czy później skończy się zainfekowaniem naszej witryny kodem, który będzie nam w jakiś sposób szkodził. Najczęściej dodatek taki wstawi na naszą stronę spamerkie linki, w najciekawszych przypadkach ktoś zdalnie przejmie kontrolę nad naszym blogiem i będzie z nim robił, co chce.

Trafiłem właśnie na informację o dwóch ciekawych wtyczkach, które wyłapią na anszym blogu takie niebezpieczne dodatki. Jedna z nich to Theme Authenticity Checker, a druga to Exploit Scanner. Choć zapewne nie działają idealnie, ale można je traktować jak coś w rodzaju oprogramowania antywirusowe dla naszej witryny. 

Informajcę wrzucam także ku pamięci swojej. A skąd o tych wtyczkach wiem? A stąd. Polecam ten ciekawy artykuł o tym, dlaczego nie powinniśmy szukać w Google darmowych skórek do WordPressa (ale także i do innych systemów CMS)

Wykluczenie strony z menu – WordPress

Chyba będę raz na jakiś czas wrzucał tutaj tip&tricks do zastosowania przy zabawach z api WordPressa. Blogów na ten temat jest wiele i nie mam zamiaru z nimi konkurować. Dlatego kryterium wrzucania będzie takie: jeśli długo szukałem jakiegoś rozwiązania i nie mogłem znaleźć, jeśli znalazłem, czuję, że mi się jeszcze przyda, a boję się, że szybko to zapomnę – wyląduje to tutaj. Taki publiczny notes ze snippetami, który być może pomoże i części z Was.

Pracuję obecnie nad pluginem do tworzenia sklepów internetowych. Wiem, że mam już WP Sprzedawcę. Ten plugin będzie sobie istniał, ale jako właśnie taki skromny, do szczególnych zastosowań. Równolegle mam zamiar wydać duży plugin, który pozwoli tworzyć sklepy internetowe na bazie WordPressa, dostosowany do polskich realiów. Ale do rzeczy.

Plugin instalując się tworzy specjalne strony: na koszyk, na wprowadzenie danych odnośnie wysyłki przez klienta… Tej ostatniej lepiej, żeby nie było w menu na stronie. Jak tego dokonać?

Domyślnie menu jest produkowane przez funkcje wp_list_pages() umieszczoną w skórce. Można do niej przekazać parametr exclude=3 co wykluczy z menu stronę o ID równym ‚3’. Czy jest jednak sposób by wp_list_pages() zawsze wykluczało jakąś stronę, tak byśmy w instrukcji instalacji naszego plugina nie musieli pisać „po zainstalowaniu otwórz wszystkie pliki skórki i zamień każde wystąpienie funkcji wp_list_pages() na …”? Takie podejście trzeba przyznać nie byłoby rzeczą wspaniałą, nie zmuszajmy użytkownika systemu CMS do grzebania w jego kodzie!

Długo szukałem i znalazłem. Niestety nie ma żadnego filter haka czy action haka na tę funkcję. wp_list_pages korzysta jednak do pobrania listy stron z funkcji get_pages(), którą już z kolei filtrować możemy.

Zatem wszystko co musimy zrobić to przefiltrować funkcję get_pages() i ze zwracanej przez nią tablicy wyciąć ten element, który zawiera obiekt o ID równym ‚3’ (brzmi złożonie, ale przeczytajcie opis funkcji, aby zrozumieć jaki rodzaj danych zwraca; jest to tablica obiektów, każdy obiekt ma pola odpowiadające nazwom kolumn z tabeli stron w bazie danych).

Na nasze nieszczęście (ale niewielkie) funkcja get_pages() używana jest nie tylko przy tworzeniu menu stron, ale na przykład także w panelu admina. Szkoda by było jakby także tam zniknęła nam nasza strona. Zatem musimy do naszej funkcji, zanim jeszcze tablica pozbawiana wykluczanej strony, dodać warunek aby pozbawianie to nie odbywało się, jeśli funkcja wywoływana jest w panelu administracyjnym WordPressa.

OK, wiemy już wszystko.

Najpierw dodajemy filtr.

add_filter('get_pages', 'usun_strone');

Następnie tworzymy naszą funkcję usun_strone(), która jako parametr otrzymuje tablice stron.

function usun_strone($pages) {

}

W bloku funkcji wstawiamy najpierw warunek sprawdzający czy to panel administracyjny i jeśli tak – przerywamy działanie funkcji zwracając tablicę stron z powrotem w niezmienionej postaci.

$to_wp_admin = ( ( defined( 'WP_ADMIN' ) && WP_ADMIN == true ) 
|| ( strpos( $_SERVER[ 'PHP_SELF' ], 'wp-admin' ) !== false ) );
if ( $to_wp_admin ) return $pages;

Jeśli jednak nie jest to Kokpit, zróbmy pętle na tablicy stron, sprawdźmy czy ID jest równe trzy i jeśli nie, dodajmy element tablicy do nowej tablicy, a potem ją zwróćmy.

$new_pages = array();
foreach ($pages as $page) {
 if ($page->ID == '3') {
  continue;
  }
 else {
  $new_pages[] = $page;
  }
 }

return $new_pages;

To wszystko.

Przy okazji mam pytanie do Was: czy jest jakiś sposób aby w bloku funkcji sprawdzić przez jaką funkcję jest dana funkcja wywołana? Ja niestety nie znam takiego, ale pomyślałem, że fajnie by było, gdyby taka możliwość była. W powyższym kodzie nie musielibyśmy sprawdzać czy get_pages() jest wywoływane w panelu admina, czy jeszcze jakoś inaczej, a zrobilibyśmy warunek „jeśli funkcja ta jest wywoływana przez wp_list_pages(), tylko wtedy usuń stronę o ID równym 3”.

Zna ktoś taki sposób? Czekam na Wasze komentarze.

WWF używa WordPressa, musicie mi wierzyć na słowo

Dziś rano w telewizorni widziałem reklamę społecznej akcji ratowania fok szarych organizowaną przez WWF Polska. Może więc się kolejny raz pochwalę zrobioną już jakiś czas temu stroną. Choć „pochwalę” to za duże słowo, bo nic Wam raczej pokazać nie mogę 🙂 Musicie mi wierzyć na słowo, że to co tu piszę, to prawda.

Blog wolontariuszy WWF, tak wyglądał projekt graficzny

Blog wolontariuszy WWF, tak wyglądał projekt graficzny

Jakoś we wrześniu ktoś szukał kogoś, kto by znał się co nieco na WordPressie, więc się zgłosiłem. Okazało się, że trzeba uruchomić blog towarzyszący społecznej akcji ratowania fok w Polsce. Coś w rodzaju małego serwisu społecznościowego, w której osoby biorące udział w ratowaniu fok będą mogli się zarejestrować, blogować (stąd więc od razu przyszedł pomysł WordPressa), dodać swoje zdjęcia z pracy i wrzucić filmy. Napisać kilka słów o sobie, zaznaczyć swoją pozycję na mapie Google Maps tak aby, gdy ktoś szuka pomocy przy fokach w okolicy Helu mógł szybko odnaleźć patrolowiczów w pobliżu.

Strona jest już wykonana, działa od dawna (i z tego co widzę działa bez zarzutu, bo nikt nie zgłasza mi żadnych problemów). Niestety linka do strony podawać nie będę, bo tylko zalogowani ludzie w WWF mogą ją zobaczyć. Ale i tak się chwalę 😉

Powyżej znajduje się design na bazie jakiego miałem wykonać stronę. Praca na początku była prosta: pociąć wszystko do HTML zgodnego z jak największą ilością przeglądarek, zrobić z tego szablon do WordPressa. Potem zaczęły się schody.

Zleceniodawca wymagał bardzo precyzyjnego dopasowania się do zaleceń. Wskutek tego najpierw sporo czasu spędziłem na poszukiwaniu odpowiednich pluginów, by ostatecznie przegonać się, że każdemu coś brakuje lub robi to w nie taki sposób, jak było to opisane w zleceniu. I wtedy rozpisałem się podczas pisania kodu nowych pluginów, ściśle dopasowanych do wymagań. (Pamiętacie moje wpisy dotyczące publikacji nowych wtyczek i tutoriale jak wtyczki się pisze? To wtedy mniej więcej robiłem tą stronę).

Pluginów napisanych było kilka. Wspomnę o dwóch.

Jeden z nich to Youtube Add Video, który zamieściłem publicznie w internecie, tak by i inni mogli z niego skorzystać i przy okazji opisałem jak powstawał. W dostępnych pluginach brakowało możliwości określenia kto dodał film (nic dziwnego, przeważnie blog prowadzi jedna osoba, a tutaj WordPress działał niemal jako platforma blogowa) i możliwości wyciągnięcia informacji o ostatnio dodanym filmie i umieszczenia jej w sidebarze. Napisanie takiego pluginu okazało się wykonalne 🙂

Drugi plugin aż szkoda, że nie udostępniłem go nigdzie bo jestem z niego dumny (teraz nie mam już niestety dostępu do jego kodu). Plugin bazował na Google Maps API  i pozwałał:

  • wyświetlić mapę w sidebarze
  • pokazać zaznaczonych na niej wszystkich wolontariuszy lub konkretnego (jeśli akurat przeglądaliśmy stronę użytkownika)
  • w panelu administracyjnym pozwalał użytkownikowi dodać swoją pozycję na mapie.

Plugin działa wyśmienicie, a przynajmniej działał w momencie oddawania strony zleceniodawcy 😉 Ale jak wspomniałem, żadnych reklamacji nie dostałem.

* * *

Było jeszcze kilka innych wtyczek, ale zdecydowanie mniejszych i mniej ciekawych. Z projektu jestem dość zadowolony bo rozruszał mnie po długien przerwie, od czasu gdy wykonałem stronę WildPoland. Obecnie  zleceń mam całkiem sporo, w poprzednim tygodniu kilku osobom musiałem odmówić podjęcia się zadania, bo zwyczajnie nie wyrabiałem się w 24 godzinach na dobę 🙂 I teraz gdy to piszę, jestem właśnie w czasie krótkiej przerwy w programowaniu kolejnego wordpressowego wdrożenia.

Nie zmienia to faktu, że jeśli ktoś z Was właśnie potrzebuje uruchomić jakąś stronę i wierzy, że WordPress jako CMS sprawdzi się tutaj bardzo dobrze (w tym tygodniu to właśnie WordPress zwyciężył w konkursie na najlepszy system CMS open source), może śmiało do mnie pisać. Obecnie wykonywane przeze mnie zadania prędzej czy później będą musiały się skończyć i chętnie podejmę się kolejnych wyzwań. 🙂

Tworzenie pluginów do WordPressa – cz. 3 – zabawa z pseudo-cronem i grzebanie w krwistych bebechach

Oook… Powiedzmy, że mam wolną chwilę, więc wrócę do niesłychanie fantastycznego zajęcia, jakim jest uczenie Was jak stać się moją konkurencją i tworzyć bombowe pluginy do WordPressa 😉 Ups, po napisaniu tego zdania nieco przeszła mi ochota na pisanie dalszej części, ale mówi się trudno. Lecimy.

Wszystkim nowicjuszom na naszym kursie przypominam, że jest to już trzecia lekcja. Więc jeśli ktoś wagarował, niech szybko leci najpierw przeczytać notatki z lekcji pierwszej i lekcji drugiej. Niestety znajomość lekcji poprzednich jest raczej bardzo wskazana, gdyż założyłem sobie, że każda kolejna część nie będzie omawiać dokładnie rzeczy już wcześniej omówionych. Założenie chyba logiczne?

Zaczynamy

Co dzisiaj mamy? Może zajmijmy się moim ulubionym darmowym pluginem (bo oczywiście najbardziej ulubiony jest płatny WP Sprzedawca), jakim jest Upgrade Notification by Email. Plugin jest bardzo króciutki ale nie dajcie się zwieść jego mikroskopijnym rozmiarom.

Przede wszystkim jego mikroskopijność to oznaka dość zaawansowanego programowania. W pierwszej wersji plugin był o wiele (wiele) dłuższy. Jednak z biegiem czasu nauczyłem się jak unikać tworzenia funkcji, które robią to samo co już robi jakaś ukryta funkcja WordPressa. I dlatego coś, co wcześniej potrzebowało napisania kilkunastolinijkowej funkcji, teraz zostało zastąpione prze odwołanie się do już istniejących funkcji w silniku tego systemu blogowego.

Założenia

Plugin w założeniach jest bardzo prosty: ma wysyłać na maila informację do administratora strony gdy pojawiła się nowsza wersja WordPressa. Ma tą informację wysyłać tylko i wyłącznie jeśli admin nie dokonał jeszcze aktualizacji. I tyle.

Proste? Proste. Zatem…

Zaczynamy (ponownie)

Czynność jest tutaj tylko jedna: wysłanie maila do administratora, więc i funkcja będzie tylko jedna. Funkcja ta ma się wykonać tylko i wyłącznie, jeśli zainstalowana wersja WordPressa jest starsza niż najnowsza, zatem funkcja na pewno jakoś sprawdzi instrukcją if czy ten warunek jest spełniony.

Pojawia się też kolejna zagadka: kiedy funkcja ma zostać uruchomiona? Do tej pory poznaliśmy dwa sposoby odwoływania się do naszych pluginowych funkcji:

– poprzez hak filtrujący wypluwaną treść
– poprzez hak reagujący na jakąś akcję na blogu

Od razu mówię, że nie zastosujemy tu żadnego z nich. Choć moglibyśmy. Na przykład hakiem filtrującym moglibyśmy w momencie wyświetlania użytkownikowi treści wpisu po kryjomu wywołać naszą funkcję i wysłać adminowi maila z powiadomieniem o konieczności instalacji nowszej wersji. Albo hakiem reagującym na jakąś akcję (na przykład dodanie komentarza do wpisu) zrobić to samo.

Da się, ale ma to w naszym wypadku dość sporą wadę: admin miałby na swojej skrzynce kilkadziesiąt maili (jeśli nie tysiące w przypadku gdy admin administruje popularnym blogiem) z upomnieniem o aktualizacje. Co prawda moglibyśmy dalej się upierać przy taki zastosowaniu, dodając do kodu rodzaj łatki, który by sprawdzał czy admin już dostał maila, ale… ale nie brnijmy w tym kierunku. Po pierwsze, że nie będzie to wydajne (tak czy owak nasza funkcja wywoływała by się setki razy dziennie), a po drugie jest gotowe rozwiązanie w samym wordpressie przygotowane specjalnie na takie okazje, a nazywa się ono

wp-cron

Tak. WordPress ma wbudowany mechanizm pseudo cronu czyli narzędzie do planowania wykonywania funkcji. Dzięki niemu możemy sobie zaplanować by dana funkcja wykonywała się raz na godzinę, raz na dzień itd.

Dobra, koniec z tymi teoretycznymi rozważaniami. Wszystko co chciałem wyjaśnić do tej pory, już wyjaśniłem. Czas zobaczyć kawałek kodu i krok po kroku zobaczyć jak nasz plugin działa.

(tradycyjnie pomijam nagłówek pliku plugina – to już poznaliście dawno)

register_activation_hook(__FILE__, 'wpu_my_activation');

function wpu_my_activation() {
wp_schedule_event(time(), 'daily', 'wpu_my_daily_event');
}

add_action('wpu_my_daily_event', 'wpu_do_this_daily');

Część rzeczy już znacie, część dopiero poznacie.

Linijka 28 jest już Wam znana z poprzedniej lekcji: tworzymy tutaj hak, jaki ma się wykonać w czasie instalacji pluginu. Informujemy tutaj aby w czasie instalacji została wykonana funkcja wpu_my_activation().

Owa funkcja znajduje się w linijce 30 i zawiera w sobie dwie funkcje wbudowane w WordPressa.

Pierwsza funkcja – wp_schedule_event() – służy do zanotowania przez WordPress funkcji, jaka ma się wykonywać cyklicznie (to ten właśnie pseudo-cron). Jako pierwszy argument pobiera czas w postaci uniksowego znacznika kiedy rejestrowana funkcja ma zostać wykonana po raz pierwszy (użyłem tu funkcji time() gdyż chciałem aby pierwsze wykonanie wysłania – lub nie wysłania – maila do admina nastąpiło od razu przy instalacji plugina). Drugi argument informuje wordpressa co ile czasu funkcja ma być powtarzana (niestety na razie może przyjmować tylko dwie wartości: daily i hourly). Trzeci argument to nazwa haka jaki ma zostać zarejestrowany.

W linii 34. widzimy dobrze nam znane już add_action(). Tutaj wiąże ono właśnie zarejestrowanego co dobowego haka wpu_my_daily_event z funkcją właściwą wpu_do_this_daily().

Do funkcji jeszcze dojdziemy, zobaczmy co teraz mamy:

register_deactivation_hook(__FILE__, 'wpu_my_deactivation');

function wpu_my_deactivation() {
wp_clear_scheduled_hook('wpu_my_daily_event');
}

Oho, tego chyba jeszcze nie było. Poznaliśmy już rejestrowanie haka aktywacyjnego, który się wykonuje gdy plugin jest aktywowany przez admina, czasem jednak trzeba też wykonać jakieś funkcje podczas odinstalowywania plugina. Służy do tego hak deaktywacyjny register_deactivation_hook, który podobnie do haka aktywacyjnego ma dwie zmienne: nazwę odinstalowywanego pliku z pluginem oraz nazwę funkcji, która ma się wykonać w czasie odinstalowywania.

Akurat tutaj trzeba coś wykonać w czasie deaktywacji plugina. Musimy wyłączyć codzienne zadanie sprawdzania aktualizacji i wysyłania maila. Służy do tego funkcja wp_clear_scheduled_hook() przyjmująca jako argument nazwę haka, który ma przestać działać.

Co by się stało gdybyśmy nie deaktywowali naszego haka? WordPress nadal by miał w swojej bazie zadań polecenie uruchomienia raz na dobę zadania wpu_my_daily_event. Zadanie to znajduje się w naszym pliku z pluginem, a plugin jest przecież odinstalowany… oj byłby problem.

Wyślij w końcu tego maila!

Ok, wszystko jest już porejestrowane i plugin jest już gotowy na ewentualne odrejestrowanie zadania. Czas napisać naszą ostateczną funkcję czyli wpu_do_this_daily()

function wpu_do_this_daily() {
$taken_transient = get_transient('update_core');
$za = $taken_transient->updates;
$zb = $za[0];
$zm = $zb->response;
if ($zm == "upgrade") {
$wpsender = get_option('admin_email');
$forwhom = get_option('admin_email');
$subject = "Your blog " . wp_specialchars( get_option('blogname') ) . " should be upgraded";
$headers = "From: " . wp_specialchars( get_option('blogname') ) . " <$wpsender>\n";
$headers .= "Content-Type: text/html\n";
$headers .= "Content-Transfer-Encoding: 8bit\n";
$mailtext = "The plugin Upgrade Notification by Email noticed that at WordPress server is available newer version of blogging software than this, which is installed at " . wp_specialchars( get_option('blogname') ) . ". Please upgrade it in your admin panel. You have ".$taken_transient->version_checked." and newest is " . $zb->current . ". You can download WordPress directly from " . $zb->package;
wp_mail($forwhom, $subject, $mailtext, $headers);
}
}

?>

Długie? Bywało dłuższe. Zobaczmy, może od końca, co ta funkcja robi.

Wysyłanie maila następuje po pozytywnym wykonaniu instrukcji if w linijce 47. Jeśli if zostanie spełniony (o nim za chwilę), to zostaną przygotowane dane do maila i zostanie wysłany ów mail. Dane do maila to:

Linijka 48.: adres email jaki ma się pojawić w polu ‚From:’ maila. Jest on wyciągany jak widać z mechanizmu opcji wordpressa (czy ja już o tym pisałem? Chyba coś było na ten temat w części drugiej).

Linijka 49.: w podobny sposób pobierany jest adres email pod jaki mail ma zostać wysłany (tak, adres jest ten sam).

Linijka 50. to temat listu, linijki 51-53 to niezbędne nagłówki listu, a linijka 54. to jego treść.

I w linijce 51. mamy wordpressową funkcję do wysyłania maili – wp_mail(). Składnia jej jest taka sama jak wbudowanej w PHP funkcji mail().

Wróćmy do naszego if-a, który ma powstrzymać wordpress przed wysłaniem maila lub kazać go wysłać. If musi sprawdzić czy wersja zainstalowana jest starsza niż aktualnie dostępna na serwerze.

Wcześniej w tym celu napisałem własną funkcję, która pobierała z $wp_version informację o zainstalowanej wersji wordpressa, łączyła się za pomocą curl z serwerem wordpressa, sprawdzała jaka jest nazwa najnowszej wersji pliku z wordpressem, wynajdowała w tej nazwie ciąg zawierający w sumie numer wersji i porównywała ze sobą. Działało to dość dobrze, ale coś mi nie grało.

Po pierwsze WordPress przecież sam w panelu admina wyświetla na górze informację o konieczności aktualizacji, zatem musi mieć gdzieś wbudowaną funkcję robiącą to samo co ja właśnie chcę zrobić. Po drugie takie korzystanie z curl i wyciąganie fragmentów urla może być zawodne, jeśli na przykład zmieni się schemat nazywania pliku z instalką wordpressa.

Oczywiście okazało się, że funkcja sprawdzająca wersję wordpressa faktycznie istnieje i nazywa się dość intuicyjnie bo wp_version_check().

Nie możemy się jednak do niej odwołać bezpośrednio, bo funkcja ta nie zwraca żadnej wartości, a jedynie wywołuje funkcje kolejne (tutaj akurat interesuje nas funkcja tworząca wartość ulotną (ang. transient) o nazwie ‚update_core’). Nie wgłębiajmy się za bardzo w te krwiste bebechy, najważniejsze jest, że musimy:

– pobrać do zmiennej obiektowej wartość przelotną ‚update_core’ za pomocą fukcji get_transient() (linijka 43.)

– z owej zmiennej obiektowej wyciągnąć wartość pola ‚updates’ (linijka 44.)

– i w kolejnych linijkach dojść do tego co odpowiedział serwer na pytanie o konieczność aktualizacji.

I teraz jeśli odpowiedział słowem ‚upgrade’, posłuchajmy go i wyślijmy wyżej opisany list do administratora.

Skomplikowane? Przyznaję, że tak. Na tyle skomplikowane, że nie chcę wnikać dokładnie w powyższy kod. Jak dokładnie przebiegło wyłuskiwanie słowa ‚upgrade’, jakie inne słowa zostałyby wysłuskane, może się przekonać każdy z Was po wnikliwej analizie kodu funkcji wp_version_check(). (przy okazji zwróćcie też uwagę, że w samej treści maila są odwołania do obiektu $zb przechowującego nieco informacji o aktualnej weresji WordPressa)

W każdym razie zapewniam Was, że to działa, o czym każdy może się przekonać pobierając opisany wyżej plugin ze strony WordPressa 🙂

To był mały plugin dla mnie…

…a wielki plugin dla ludzkości.

Oczywiście przesadzam. Ale faktem jest, że mój napisany w pół godziny plugin do powiadamiania na email o konieczności aktualizacji WordPressa do nowszej wersji wywołał nieco dyskusji. Co więcej dyskusje wywołane zostały też na blogach twórców WordPressa i na liście mailingowej ‚wp-hackers’.

Dyskusje opierają się na pytaniu „dlaczego tej funkcji nie ma jeszcze w samym WordPressie” i raczej nikt nie neguje konieczności wbudowania takich powiadomień w silnik, a wszyscy zastanawiają się jak to zrobić. Tzn jak to ma dokładnie funkcjonować: czy ma sprawdzać tylko rdzeń, czy też pluginy. Czy ma być obligatoryjne, czy fakultatywne itp itd. Jest już nawet wątek na trac-u.

No cóż… być może niedługo mój plugin umrze tak samo szybko jak powstał. Ale nie miałbym nic przeciwko temu 😉 Fajnie by było mieć świadomość, że się przyczyniło do rozwoju WordPressa 😉

Tworzenie pluginów do WordPressa – cz. 2 – instalator, bazy danych i Custom Fields

To jest druga część mojego nibykursu tworzenia pluginów do WordPressa. Część poprzednia znajduje się tutaj.

W ostatnim tygodniu zrobiłem chyba z cztery pluginy, nie wszystkie opublikowałem, ale jak obiecałem, drugą część kursu oprę na moim małym pluginie do dodawania filmów z YouTube do naszych wpisów. Nawiasem mówić zdziwiłem się, że jest tak popularny. Bo jakby nie było podobnych pluginów jest całkiem sporo. Ale nic, sukces mnie cieszy (prawie 700 pobrań w niecały tydzień) i właśnie wczoraj opublikowałem jego drugą wersję.

* * *

Wtrącenie reklamowe: być może na ten wpis trafią osoby, które potrzebują jakiegoś plugina, chcą go zrobić, ale się poddadzą, bo uznają, że jest to dla nich za trudne. W takim wypadku uprzejmie zawiadamiam, że za opłatą chętnie zrobię taki plugin 😉 Jak się ze mną można skontaktować opisane jest tutaj.

* * *

No to lecimy. Najpierw założęnia:

  • Plugin ma umożliwiać dodanie filmu z YT do wpisu. W tym celu osoba pisząca wpis będzie musiała dodać pod wpisem Custem Field (Pole Własne) o nazwie video i w pole wartości mające wpisane odnośnik do filmu na YouTube
  • Plugin ma wyświetlać pod wpisem film, jeśli w pole Custom Field wpisane są powyższe wartości.
  • Plugin ma umożliwiać wyświetlenie w dowolnym miejscu ostatnio dodany film. Ma też umożliwiać wyświetlenie ostatnio dodany film konkretnego użytkownika WordPressa. W tym celu stworzymy odpowiednią funkcję ( u mnie będzie się nazywać show_LastYT() ) która jako parametr może przyjąć ID użytkownika, którego film chcemy zobaczyć.
  • Plugin ma do wpisów zawierających film dodawać automatycznie tag video.

I tyle. Informację o filmie będziemy trzymać w polu Custom Field. Dzięki temu silnik WordPressa w odpowiednim momencie sam włoży i sam wyjmie z bazy danych potrzebne nam informacje.

Natomiast aby przyspieszyć działanie, sami stworzymy tabelę w bazie MySQL przechowującą informację o ostatnim filmie. Można to oczywiście zrobić inaczej: wystarczy tak stworzyć funkcje show_LastYT(), że przy jej wywołaniu będzie przeglądać wszystkie wpisy, szukać tych zawierających odpowiednie Custom Field, sortować by najnowsze były na górze, wybierać ID usera… Uh, będzie to pewnie trwało długo, jeśli wpisów będziemy mieli setki lub tysiące. Lepiej jednak faktycznie stwórzmy osobną tabelę zawierającą tylko dwie kolumny: ID pozycji w tabeli (po tym będziemy sortować) i ciąg składający się z ID usera, który dodał film do bazy, dwukropka (jako rozdzielnika) i kodu filmu po nim. (przykładowo: 6:vxsz0fgds).

Co musimy umieścić w naszym pluginie?

  • Nagłówek opisujący plugin – nie będę tego już opisywał, bo opisałem w poprzedniej części.
  • Funkcję instalującą plugin (i odpowiedni do niej hook), która zostanie wywołana tylko raz, jak plugin będzie instalowany i stworzy odpowiednią tabelę w bazie danych.
  • Funkcję dodającą pozycję do bazy danych i tag video do wpisu, w momencie gdy user publikuje lub aktualizuje wpis zawierający odnośnik do filmu (tu zatem też będzie potrzebny odpowiedni hook)
  • Wreszcie funkcję wyświetlającą film na końcu wpisu, jeśli film jest w Custom Field (i znowu będzie potrzebny odpowiedni hook).
  • Na końcu funkcję show_LastYT() bez hooka wyświetlającą kod ostatnio dodanego filmu. Hook nie jest potrzebny bo to autor bloga sam w skórce graficznej zdecyduje gdzie ta funkcja ma być wywołana (np w sidebarze).

Kod będzie wyglądał następująco (pomijając nagłówek).

Funkcja instalująca:

function yt_install () {
	global $wpdb;
	$prefix = $wpdb->prefix;
	$yt_tablename = $prefix."yt_videos";
	
	$yt_db_version = "1.0";
	
	if ($wpdb->get_var("SHOW TABLES LIKE '".$yt_tablename."'") != $yt_tablename) {
		$zapytanie = "CREATE TABLE ".$yt_tablename." (
		id mediumint(9) NOT NULL AUTO_INCREMENT,
		video_id varchar(120) NOT NULL,
		PRIMARY KEY  (id)
		);";
		
		$wpdb->query($zapytanie);
		
		add_option("yt_db_version", $yt_db_version);
		
		}
	}

Co się stało się? Najpierw globalizujemy zmienną klasową $wpdb. Klasa ta dostarcza bardzo wiele funkcji służących do obsługi bazy danych.

W kolejnej linijce widzimy sposób jej wykorzystania: $wpdb->prefix pobiera przedrostek jakim są poprzedzone nazwy tabel w bazie danych. Domyślnie przedrostek ten to „wp_”, ale każdy może sobie go przecież zmienić (ja na przykład tak robię, dzięki czemu w jednej bazie danych mogę trzymać kilka instalacji WordPressa), więc odwołujmy się do niego właśnie w ten sposób jak powyżej.

Następnie tworzymy nazwę naszej tabeli, w której będziemy trzymać informacje o ostatnio dodanym filmie. Nazwa ta to ma być przedrostek_yt_videos zatem tworzymy ją jako $prefix.”yt_videos”.

Dalej definiujemy numer wersji naszej tabeli. Nie jest to konieczne, ale wyobraź sobie sytuację, gdy w przyszłych wersjach pluginu będziesz chciał przekonstruować tabelę, by zawierała więcej informacji (np nowe kolumny). Dlatego warto teraz podać informację, że obecna tabela została przez Ciebie oznaczona jako wersja 1.0, a jeśli w przyszłości będziesz zmieniać strukturę tej tabeli, nadamy jej kolejny numer i odpowiednio to obsłużymy (na razie nie będę pisał jak to się robi).

Okej, teraz przyszła kolej na dodanie tabeli do bazy danych. Ale uwaga, najpierw musimy sprawdzić czy tabela już nie istnieje. Bo co jeśli ktoś poużywa naszego pluginu, odinstaluje go i zainstaluje jeszcze raz? Ponowne tworzenie tabeli o tej samej nazwie na pewno nie skończy się niczym dobrym.

Dlatego tworzenie tabeli zaczynamy od sprawdzenia (warunek if) czy nie ma już takiej tabeli. W tym celu wykorzystujemy kolejną metodę $wpdb->get_var(). get_var() pobiera z bazy jedną konkretną wartość i jako parametr przyjmuj zapytanie. Pytamy więc bazę czy potrafi nam pokazać tabelę, której nazwa jest taka sama jak nasza tabela, którą chcemy utworzyć. Jeśli jest już, get_var() zwróci nam w tym przypadku nazwę naszej tabeli, jeśli nie ma, zwróci pusty string (albo NULL, dokładnie nie wiem). Porównujemy zwróconą wartość ze zdefiniowaną nazwą tabeli i jeśli są różne, możemy dodać naszą tabelę bez obaw.

Konstruujemy więc zapytanie (jako $zapytanie) i w metodzie $wpdb->query() przekazujemy je do bazy danych. Zapytanie utworzy nam tabelę.

Nie zapomnijmy też przy instalacji pluginu poinformować WordPressa co mamy w zmiennej $yt_db_version. W tym celu korzystamy z mechanizmu opcji, konkretnie z funkcji dodającej opcję do bazy danych add_option(), która jako pierwszy parametr przyjmuje nazwę opcji pod jaką nasza dodana wartość ma się znaleźć w mechanizmie WordPressa, a jako drugi ową wartość. Krócej można więc to było zapisać add_option(„yt_db_version”, „1.0”).

Funkcja jest już gotowa. Musimy teraz nauczyć WordPressa kiedy jej ma używać. Użyć ma jej tylko raz, tylko przy instalacji pluginu. W tym celu wpisujemy hooka:

register_activation_hook(__FILE__, 'yt_install');

Na ludzki język hak ten mówi: „zarejestruj hak aktywacyjny, który przy instalacji pliku z tym pluginem (__FILE__) wywoła funkcję „yt_install”. Zwróć uwagę na podwójne znaki podkreślenia przed i po FILE.

OK, tabelę w bazie mamy już stworzoną, możemy więc zająć się napisaniem funkcji dodającej odpowiedni wpis do bazy, gdy ktoś zamieści nowy wpis z Custom Field. Funkcję taką nazwijmy yt_database() i będzie ona wyglądała tak:

function yt_database ($post_id) {
	global $post;
	$czy_maVideo = get_post_meta($post_id, "video", true);
	
	if ($czy_maVideo != "") {
		global $wpdb;
		$prefix = $wpdb->prefix;
		$yt_tablename = $prefix."yt_videos";
		
		/* $url = explode("?", $czy_maVideo);
		$url = $url[1];
		$url = explode("&", $url);
		$url = $url[0];
		$url = explode("=", $url);
		$video_id = $url[1]; */
		
		$url = parse_url($czy_maVideo, PHP_URL_QUERY);
		$url = explode("&", $url);
		foreach ($url as $parka) {
			if (substr($parka, 0, 2) == "v=") {
				$konkretnaParka = explode("=", $parka);
				$video_id = $konkretnaParka[1];
				break;
				}
			}
		
		
		$poscik = get_post($post_id);
		
		$ktododal = $poscik->post_author;
		
		$wstawka = $ktododal.":".$video_id;
		
		$zapisz_video = "INSERT INTO ".$yt_tablename." (video_id) VALUES ('".$wstawka."');";
		
		$rezultat = $wpdb->query($zapisz_video);
		
		wp_add_post_tags($post_id, 'video');
		
		}
	
	}

Całkiem długa, więc zobaczmy co takiego robi. Jak widać funkcja pobiera argument, którym jest ID wpisu, na którym ma być wykonana. Zglobalizujmy więc najpierw zmienną $post, którą poznaliśmy już w poprzedniej części kursu, by móc do niej się odnieść.

W następnej linijce sprawdzamy czy wpis, który jest właśnie publikowany zawiera pole Custom Field o wartości „video”. Odpowiada za to funkcja $get_post_meta(), która jako pierwszy argument pobiera ID wpisu, który ma sprawdzić, w drugim argumencie wpisujemy jak ma się nazywać pole Custom Field, którego szukamy i trzeci argument ustawiamy na TRUE jeśli chcemy aby funkcja zwróciła nam zawartość tego pola Custom Field. Może i skomplikowane, ale teraz mamy już w zmiennej $czy_maVideo zapamiętany URL do YouTube jaki autor wpisu wpisał w pole Custom Field. Zaraz będziemy go obrabiać.

O właśnie teraz. Sprawdźmy czy zmienna z URLem nie jest przypadkiem pusta i jeśli nie jest wyciągnijmy z niej identyfikator filmu w serwisie youtube. Pierwsze trzy linijki if-a już znamy – ponownie dobieramy się do $wpdb i ustawiamy nazwę tabeli, bo przecież w naszej tabeli będziemy chcieli zapisać wartość „id_usera:_id_filmu”.

Następnie musimy wyciągnąć z wpisanego URL-a fragment zawierający identyfikator filmu. Przypominam, że cały url do filmu w YT wygląda mniej więcej tak:

http://www.youtube.com/?v=id_filmu&kolejny=parametr&…

Czyli musimy wygrzebać co jest po „v=”

Specjalnie w kodzie zostawiłem zakomentowaną sekcję. Zawiera ona fragment kodu, którym wyciągałem id filmu na początku. Działało, pod warunkiem, że parametr v pojawiał się jako pierwszy parametr w URLu. Tak jest chyba zawsze, no ale właśnie: „chyba”. Jakby ktoś wkleił jakiś przekonstruowany URL, mogłoby to nie zadziałać.

Zatem napisałem całość od nowa, oparte o funkcje parse_url i dwie eksplozje. Mam nadzieję, że jest to dla Was zrozumiałe, bo to zwykły kod produkujący zmienną $video_id korzystając z podstawowych funkcji języka PHP. A zakładam, że kurs czytają osoby, które przynajmniej podstawy PHP znają 🙂

OK, mamy już identyfikator filmu, potrzeba nam jeszcze ID autora, który właśnie dodał ten film. W tym celu pobieramy zaczep do postu, który właśnie obrabiamy (funkcja get_post() przyjmująca jako parametr id owego postu). Mając już utworzony obiekt postu możemy dobrać się do jego zawartości. Zawiera on między innymi ID autora zapisany pod zmienną $post_author.

No i wyciągania danych już koniec. Mamy id filmu i mamy id autora wpisu. Sklejamy to w zmiennej $wstawka i następnie wstawiamy do naszej tabeli. Tu oczywiście korzystamy z $wpdb i jego poznanej już metody query().

Ostatnia linijka to automatyczne dodawanie tagu „video” do wpisu. Odpowiada za to kolejna wordpressowa funkcja wp_add_post_tags() pobierająca jako argumenty id postu, do którego ma dokleić tag oraz tagi (można wpisać kilka rozdzielonych przecinkami) jakie mają do posta zostać dodane. Warto tu nadmienić, że jak większość funkcji wordpressa i ta jest w miarę inteligentna: jeśli wpis już zawiera dany tag, funkcja go nie doda ponownie.

Koniec funkcji. Teraz musimy powiedzieć wordpressowi kiedy funkcja ma zostać wykonana. Oczywiście funkcja musi zostać wykonana gdy WordPress będzie wykonywał akcję polegającą na publikacji nowo utworzonego wpisu. Odpowiada za to hook add_action o następującej treści:

add_action('publish_post', 'yt_database');

Mówi on: WordPressie – gdy wykonujesz akcję polegającą na publikacji wpisu, wykonaj funkcję yt_database(). Warto tu nadmienić, że akcja „publish_post” oznacza nie tylko publikację posta, ale także jego aktualizację.

(Tu od razu wychodzi niedociągnięcie mojego pluginu, polegające na tym, że jak ktoś zaktualizuje wpis, to plugin ponownie zapisze w bazie danych id_usera:id_filmu. Ale uznałem, że skoro to wersja 0.2, poprawię to w przyszłości dodając funkcje sprawdzające czy już dany wpis w bazie nie istnieje)

OK, co nam jeszcze zostało? Dwie rzeczy: wyświetlanie filmu we wpisie (do tej pory nie poinformowaliśmy wordpressa, że ma to robić, a sam z siebie nie jest na tyle inteligentny by wiedzieć, że jak post ma Custom Field wpisany url do YT to na pewno ten film trzeba wyświetlić) oraz wyświetlanie ostatnio dodanego filmu.

Niepotrzebnie rozbiłem to na dwie funkcje, ale skoro już tak jest, to na razie o zostawmy. Lecimy z pierwszą funkcją, czyli doklejaniem filmu na końcu wpisu.

function add_ytVideo ($content) {
	global $post;
	$czy_maVideo = get_post_meta($post->ID, "video", true);
	
	if ($czy_maVideo != "") {
		
		/* $url = explode("?", $czy_maVideo);
		$url = $url[1];
		$url = explode("&", $url);
		$url = $url[0];
		$url = explode("=", $url);
		$video_id = $url[1]; */
		
		$url = parse_url($czy_maVideo, PHP_URL_QUERY);
		$url = explode("&", $url);
		foreach ($url as $parka) {
			if (substr($parka, 0, 2) == "v=") {
				$konkretnaParka = explode("=", $parka);
				$video_id = $konkretnaParka[1];
				break;
				}
			}

	
			return $content.'
			<object width="425" height="344">
			 <param name="movie" 
			  value="http://www.youtube.com/v/'.$video_id.'&hl=pl&fs=1&">
			 </param>
			 <param name="allowFullScreen" 
			  value="true"></param>
			 <param name="allowscriptaccess" value="always"></param>
			 <embed 
			  src="http://www.youtube.com/v/'.$video_id.'&hl=pl&fs=1&" 
			  type="application/x-shockwave-flash" 
			  allowscriptaccess="always" allowfullscreen="true" 
			  width="425" height="344"></embed>
			</object>';
		
		}
	
	
	else return $content;
	
	}

Funkcja ta jest bardzo podobna do poprzedniej. Szczerze, to aż za podobna. Różni się tylko tym, że jako parametr pobiera $content w którym będzie przekazana standardowa zawartość wpisu, a na końcu zwróci albo samą zawartość wpisu (jeśli wpis nie zawiera odpowiedniego Custom Field) albo zawartość wpisu z doklejonym kodem youtubowej flashki, wcześniej w odpowiednie miejsca podstawiając $video_id filmu.

Jak widać reszta jest bardzo podobna, a nawet – jak się spojrzy na powtórne parsowanie URLa – od razu przychodzi na myśl, że nigdy nie słyszałem o osuszaniu kodu 😉 Oj słyszalem, tyle, że jestem bardziej guerilla developerem niż kimś poukładanym 🙂 Najpierw tworzę kod, a potem biorę się za jego optymalizację i czyszczenie.

OK, dość tego filozofowania. Powiedzmy wordpressowi by naszą funkcję wykonał w momencie wyświetlania wpisu. Za to odpowiada znany już nam z poprzedniej części hook polegający na przefiltrowaniu wypluwanej zawartości wpisu:

add_filter('the_content', 'add_ytVideo');

No i końcówka: tworzymy funkcję show_LastYT() pokazującą ostatni film dodany do bazy.

function show_LastYT ($user='')  {
	
	// shows last YT video added to post
	global $wpdb;
	$prefix = $wpdb->prefix;
	$yt_tablename = $prefix."yt_videos";
	
	if ($user == '') {
	
	$zapytanie = "SELECT video_id FROM  ".$yt_tablename." ORDER BY id DESC LIMIT 0, 1;";
	
	$wynik = $wpdb->get_var($zapytanie);
	
	if ($wynik != "") {
		
	$wynik = explode(":", $wynik);
	
	$wynik = $wynik[1];
	
	}
	}
	
	else {
		$zapytanie = "SELECT video_id FROM  ".$yt_tablename." ORDER BY id DESC;";
		$wyniki = $wpdb->get_results($zapytanie, ARRAY_A);
		
		foreach ($wyniki as $wynik) {
			$wynik = explode(":", $wynik['video_id']);
			$czyTenUser = $wynik[0];
			$wynik = $wynik[1];
			if ($czyTenUser == $user) {
				break;
				}
			}
		
		}
	
	
	
	echo '
	<object width="378" height="305">
	 <param name="movie" value="http://www.youtube.com/v/'.$wynik.'&hl=pl&fs=1&">
	 </param>
	 <param name="allowFullScreen" value="true">
	 </param>
	 <param name="allowscriptaccess" value="always">
	 </param>
	 <embed src="http://www.youtube.com/v/'.$wynik.'&hl=pl&fs=1&" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="378" height="305">
	 </embed>
	</object>
	';
	
		}

Funkcji tej nie będę tłumaczył, bo nie zawiera nic nowego odnośnie API wordpressa. W skrócie: pobiera parametr w postaci ID usera, którego chcemy przeszukać (domyślnie szuka we wszystkich filmach) i wypluwa kod odpowiedzialny za wyświetlenie flashki ze znalezionym ostatnim filmem.

Funkcji nie hookujemy, bo to autor bloga ma sam zdecydować gdzie chce aby była wykonana. Np jeśli chce aby filmik pokazywał się w sidebarze, musi w temacie graficznym w pliku sidebar.php wpisać:

<?php show_LastYT(); ?>

Ewentualnie podając jako parametr ID usera, którego chce wyświetlić.

No i tyle. Plugin już powinien działać. A jeśli ktoś nie wierzy, zapraszam do pobierania 🙂

Ciąg dalszy

Zobacz trzecią część kursu