Czyż to nie wspaniale? Aż się chce powiedzieć ‘wow’!

Oczywiście przesadzam z tą radością, ale nowość jest. Do tej pory wszyscy miłośnicy WordPressa mieli tylko możliwość skorzystania z jednej z licznych wtyczek do robienia sklepów, ale jedynie z obsługą płatności PayPal lub też w ogóle bez płatności online. Na polskim rynku nie było nic, co by umożliwiało klientom zapłacić na przykład za pomocą mTransferu, czy automatycznej płatności z innych banków. Teraz się to zmieniło!

Jest już wtyczka, dzięki której można zrobić z WordPressa sklep internetowy z prawdziwego zdarzenia. Dodajemy ile chcemy produktów, definiujemy dla nich ile chcemy sposobów dostawy różniących się rodzajem i kosztem. Odwiedzający klika sobie po naszym WordPressie, przegląda produkty, które na nim umieściliśmy, wrzuca do koszyka i idzie płacić.

Wtedy łączy się z Dotpay.pl. Płaci i wraca na naszą blogo-stronę. A my wszystko to widzimy w panelu administracyjnym strony i co więcej dostajemy jeszcze email z informacją o nowym zakupie. Klient też dostaje email, że zostaliśmy poinformowani o zakupie i już bierzemy się do wysyłki. A to wszystko w dużej mierze konfigurowalne!

Dlaczego ja się tym tak zachwycam i stawiam tyle wykrzykników? Cóż, nie będę ukrywał. Taa dam! To ja jestem autorem tej wtyczki

Tym razem nie jest to jakiś taki mini pluginek, a wtyka z prawdziwego zdarzenia. Szesnaście plików jak do tej pory, tysiące linii kodu, pięć czy sześć stron konfiguracyjnych. Kilka miesięcy pisania i testowania.

Pomyślałem, że to wszystko nie zasługuje na wrzucenie gdzieś jako podstrona na moim blogu. Pomyślałem, że taka wtyczka do sklepu internetowego zasługuje na swoją własną stronę internetową. Już nie trzymam dłużej w napięciu: ta strona to tradematik.pl.

A sama wtyczka nazywa się oczywiście TradeMatik

Na stronie możecie o niej poczytać więcej, możecie się o niej pouczyć albo nawet zajrzeć na forum wtyczki. I co więcej, a nawet przede wszystkim ją tam kupić. Kupić ” uznałem bowiem, że wtyczka i tak da Wam miliony złotych zarobku, więc nie jest grzechem pobieranie za nią opłaty, o ileż to niższej niż owe miliony

Ale wiecie co? Ja Was nawet lubię, więc przygotowałem dla Was sztuczkę: każdy, kto wejdzie na stronę wtyczki i dopisze po jej adresie /promo/muzungu będzie mógł kupić ją w promocyjnej cenie Żeby nie było zbyt pięknie, promocja taka trwa do niedzieli do północy. Super, nie?

I tylko nie mówcie nikomu, bo wszystkie paczki wykupią!

Niedługo na stronie WordCampu pojawią się wszystkie prezentacje, ale postanowiłem, że już teraz na swoim blogu zamieszczę tę, którą używałem podczas tłumaczenia w jaki sposób tworzy się wtyczki do WordPressa.

Dopiero o 23:00 ale wróciłem.

"Straciliśmy dwa z trzech silników" ” takie słowa padły całkiem na poważnie w czasie mojego powrotu z WordCampa. Całe szczęście, że wypowiedział je konduktor w pociągu, a nie pilot w samolocie i całe nieszczęście, że prze to jechaliśmy żółwim tempem.

Ale dojechaliśmy.

Wrażenia?

WordCamp uważam za udany. Największe rozczarowanie to chyba ilość uczestników ” na 200 zarejestrowanych zjawiło się około 60 osób. Nie dotarł także jeden prelegent, ale za to w ostatniej chwili zgłosił się nowy.

Byliśmy chwaleni jako organizatorzy za ogarnięcie wszystkiego, więc chyba tu było ok Uczestnicy, czego nie zapowiadaliśmy, dostali po kubku i koszulce, identyfikator, który właśnie wszyscy chwalą i torbę z castoramy Chciałem ogłosić, że casto nie było sponsorem campa.

Przeglądam wpisy innych uczestników, rozmawiałem z wieloma osobiście i co chwila pojawia się kwestia mniejszego lub większego rozczarowania poziomem prezentacji. Muszę przyznać rację; nie do końca się zrozumieliśmy kto na campie się zjawi. Praktycznie nie było treści do zupełnych nowicjuszy, przez to kilka osób wyszła już pierwszego dnia. Za to na sali byli praktycznie sami developerzy stron opartych o WordPress. Moja prezentacja o tworzeniu wtyczek okazała sie przez to dość niepotrzebna ” tłumaczyłem oczywiste oczywistości dla ludzi, którzy dawno ten etap mają za sobą. Śledziłem komentarze na blipie (flaker tu kompletnie nawalił; choć było wiele osób, które z flakera znam, na stronie wiało pustkami) i najlepszym przykładem złego dobrania treści do uczestników było zdziwienie oglądających, że we wtyczce nie użyłem MVC To ja może skorzystam z okazji i wyjaśnię:

Celem prezentacji było wyjaśnienie jak zrobić prostą wtyczkę pzez osobę, która dopiero raczkuje. Jeśli bym tam wplótł MVC rozmyłbym tylko główny przekaz (cały czas pamiętajcie, że zakładałem, że na sali są nowicjusze). A po drugie…: MVC dla jednego formularza? Poważnie? Jeśli poważnie w ten sposób piszecie swoje rzeczy, to ja się zastanawiam, gdzie tu jest miejsce na myślenie o wydajności

Onet

Dzięki onetowi mieliśmy na prezentacji swojego własnego Steve'a Jobsa prezentującego nowy gadżet Onet bowiem właśnie nasz camp wybrał na premierę swojego nowego pomysłu, jakim jest blogujacy.pl. To platforma blogowa dla zwykłych użytkowników oparta właśnie o WordPressa. Wypas

Ludzie

Fajnie było zobaczyć te wszystkie twarze, które znaliśmy do tej pory tylko z avatarów. I dobrym tu pomysłem było zamieszczenie owych avatarów na identyfikatorach, dzięki czemu szybko poznawało się kto jest kto. 

Dobra kończę. O WordCampie będę jeszcze pewnie pisał. Teraz tylko na szybko melduję się wróciłem i idę spać

No tak, to się jakoś mieści w ramach powiedzeń typu szewc bez butów chodzi.

11 i 12 grudnia 2010 w Łodzi odbędzie się WordCamp ” spotkanie osób, które w jakiś sposób mają coś wspólnego z WordPressem. Jeśli masz bloga opartego o tę platformę, jeśli tworzysz takie blogi czy strony, jeśli chcesz poznać inne osoby zainteresowane WordPressem a przy okazji dowiedzieć się czegoś nowego, zapraszam

Tak się składa, że jestem współorganizatorem tego wydarzenia, udzielę także dwóch krótkich wykładów. Tym bardziej wstyd, że choć całość się już organizuje od dawna, to nadal o tym nie napisałem na swoim blogu

Zatem: widzimy się w Łodzi?

Pisałem już o tym ” nic tak nie wstrzykuje do żył dopaminy jak znalezienie po wielu godzinach szukania rozwiązania jakiegoś problemu Zatem właśnie znów jestem pełen dopaminy

Tworząc kolejny WordPressowy plugin postanowiłem zrobić tym razem coś nieco inaczej niż zazwyczaj. Zamiast do tworzenia widgetów użyć wyraźnie oznaczonej jako przestarzała funkcji register_sidebar_widget, postanowiłem zrobić to obecnie polecanym sposobem, czyli przez rozszerzenie klasy WP_Widget.

Znalazłem na sieci tutorial, który niestety jak się okazało nie działa. Dodanie wywołania funkcji register_widget powodowało czystą stronę w oknie przeglądarki. Co ciekawe strona na kodeksie też podaje błędne (jak się okazuje rozwiązanie).

A jakie jest rozwiązanie prawidłowe? Banalne, ale musiałem nieźle się naszukać Zamiast wywoływać register_widget() bezpośrednio pakujemy ją w haka akcyjnego ‘widgets_init’. Czyli ” zakladając, że nasza klasa widgeta nazywa się ‘NaszWidget’, aktywujemy ją w ten sposób:

add_action('widgets_init', 'NaszInit');
function NaszInit() {
register_widget('NaszWidget');
}

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.

To będzie wpis o tym, że jak instalujesz mnóstwo pluginów i skórek do WordPressa, któregoś dnia może się okazać, że zostałeś zhakowany.

Niewiele osób wie jak wiele może zrobić twórca skórek czy pluginów do WordPressa (ale od razu mówię ” ten tekst mógłby być o dowolnym systemie CMS), w tym także jak wiele złych rzeczy może zrobić.

Wyobraź sobie, że znajdujesz w sieci rewelacyjny plugin, który sprawi, że ” wymyślam na poczekaniu ” pod twoimi wpisami będą pojawiać się wpisy z nim powiązane. Instalujesz go i faktycznie ” pod każdym wpisem pojawiają się odnośniki do innych wpisów z Twojego bloga. Plugin więc spełnia swoje działanie.

Tymczasem jednak twoja strona z dnia na dzień zostaje wyrzucona z indeksu Googla. Osoby, które zamieściły kiedykolwiek komentarz na Twoim blogu (a więc także podały swój adres email) codziennie z Twojej domeny dostają dziesiątki spamów. Któregoś dnia nie możesz zalogować się do panelu administracyjnego, a za kilka kolejnych dni znikają Twoje wszystkie wpisy, a zamiast nich blog jest pełen reklam viagry i podrabianych roleksów. Twój blog nie jest już twój.

Brzmi nieprawdopodobnie? Uwierzcie mi, że jest to jak najbardziej możliwe, a co więcej właściciel sam jest sobie winien doprowadzenia do takiej sytuacji. I to niezależnie od tego czy korzystamy z WordPressa, Joomli, Drupala czy czegokolwiek innego. Ja akurat piszę o WordPressie, bo nim się zajmuję.

Częścią z moich zadań jest właśnie ratowanie blogów z podobnych opresji jak te opisane wyżej. Widziałem już w kodach pluginów, skórek (skórka to tak naprawdę z grubsza także plugin) czy też innych dodatków wiele mniej lub bardziej zaevalowanych instrukcji, które mają za zadanie po cichu zrobić krzywdę właścicielowi strony (a właściwie raczej przynieść korzyść twórcy dodatku kosztem właściciela strony).

Dowolny plugin czy skórka poza robieniem tego, do czego zostały stworzone według opisu na stronie dodatku może w ukryciu robić dosłownie wszystko z Twoją stroną. Najczęściej ogranicza to się do z pozoru niewinnego dodawania odnośników pozycjonujących w stopce strony, jednak i takie działanie czasami może dla nas źle się skończyć ” Google potrafi wyrzucić ze swojego indeksu takie strony, zwłaszcza jeśli inne odnośniki w  stopce są serwowane dla czytelników strony, a inne dla robota google. Czy tak się właśnie dzieje, przeciętny użytkownik wordpressa jednak wiedzieć nie może.

Na szczęście jest kilka mniej lub bardziej prostych sposobów aby ustrzec się przed zhakowaniem naszej strony w ten sposób. Oto one.

• Nie instaluj wszystkiego co znajdziesz w sieci! Jeśli tak robisz, aż się prosisz o kłopoty. Ja jeśli znajduję jakiś nowy plugin najczęściej czytam jego kod aby zobaczyć co mniej więcej robi, potem instaluje na wordpressie testowym i dopiero wtedy ” jeśli zdecyduje, że jego funkcjonalności są mi przydatne ” ląduje on na muzungu.pl
• Jeśli szukasz pluginów lub skórek, szukaj ich w pierwszej kolejności w repozytorium WordPressa. Teoretycznie zanim autor wtyczki/pluginu doda go do owego repozytorium, administrator serwera przegląda jego kod w poszukiwaniu niebezpiecznych jego fragmentów, a zatem jesteśmy nieco bezpieczniejsi. (Niestety nie jest to zabezpieczenie doskonałe, bo złośliwy kod i w takiej sytuacji da się przemycić)
• Jeśli już musisz zainstalować coś spoza repozytorium, wybieraj skórki i pluginy bardziej popularne, których autor jawnie podpisuje się pod swoim dziełem. Taka osoba raczej nie odważy się na próbę wstrzyknięcia złośliwego kodu i utratę reputacji.
• Przynajmniej pobieżnie obejrzyj kod wszystkich plików składających się na skórkę lub plugin. Otwórz je przed instalacją choćby zwykłym notatnikiem i wyszukaj frazy ‘eval’ i ‘base64_decode’. Jeśli je znajdziesz, zrezygnuj z instalacji (jednak ich obecność nie musi oczywiście od razu oznaczać złych intencji twórcy).

Nie byłbym sobą, jeśli nie pozwoliłbym bym sobie na małą reklamę Jeśli nie jesteś pewien czy twoja skórka i zainstalowane już pluginy są bezpieczne, napisz do mnie a za opłatą zajmę się takim audytem. Jeśli nie chcesz mi tego zlecać, proponuję dodać takie ogłoszenie na WPzlecenia.pl ” na pewno ktoś się tym zajmie.

W jednym z kolejnych wpisów opiszę w jaki sposób ratować wordpressa gdy został już zarażony. Nie  jest to zadanie proste, jednak wykonalne. Nie zapomnij dodać do swojego czytnika mojego kanału RSS aby nie przegapić tego zapowiadanego wpisu

Plugin jest tak mały (plik readme jest dluzszy niż sam kod pluginu), że nie zasługuje na więcej niż kilka zdań.  Zrobiłem go w czasie pracy nad jedną ze stron, a że problem przewija się wiele razy w Google bez rozwiązań, postanowiłem wydać plugin dla wszystkich.

Strona pluginu. Niedługo będzie też na WordPress.org tutaj.

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

Stosując się do sugestii aby wziąć się też za marketing, a nie tylko programowanie zrobiłem filmik pokazujący jak zainstalować WP Sprzedawcę.

Film dotyczy wersjji 1.0, której jeszcze oficjalnie nie ma Niech będzie delikatną zachętą do zakupu jak już się pojawi (przy czym przypominam,  że każdy kto kupi wersje 0.x aktualizacje do 1.0 będzie miał za darmo), przy okazji widać pewne nowości, między innymi forum użytkowników i to, że nie trzeba już będzie ręcznie edytować plików konfiguracyjnych, a wszystko będzie dało się ładnie ustawić w sekcji administracyjnej WordPressa.

Film jest tutaj. Zatem kubeł pop-cornu w garść i zapraszam na seans