Tag: php

Możesz dziś przejąć swoją firmę hostingową

Zakładając, że nie zdążyła jeszcze zaktualizować Apache do wersji 2.4.39 (i nie używa FastCGI).

Mianowicie właśnie się okazało, żeod wersji 2.4.17 istnieje dziura pozwalająca każdemu, kto może umieścić na serwerze skrypt, w tym PHP (czyli na przykład zwykłym osobom mającym współdzielony hosting), podwyższyć swoje uprawnienia do roota.

0

2 kwietnia, 2019 Add Comment

Dopadła mnie nostalgia

Nagle przypomniał mi się adres pewnej strony – webesteem.pl – wszedłem i okazało się, że nadal działa i nadal wygląda jak przed laty. Kurcze, internet sprzed lat nie zniknął. On nadal jest, choć ja przestałem go odwiedzać. I w jednej chwili powróciły mi wspomnienia, które zaczęły się od modemu z numerem 0202122 (dobrze pamiętam?) i które kończyły mniej więcej na stronie wspomnianej wyżej. Pozwólcie, że wyleje je tu z siebie, napiszcie w komentarzach jak zaczęła się Wasza przygoda z siecią.

Choć jestem już dość stary, to z komputerami mam do czynienia od dość niedawna. Pierwszy dostałem jak poszedłem na studia, w roku 1999 roku. Rakieta średniego zasięgu: dysk twardy 6,4 GB, procesor chyba celeron 266MHz, 64 MB ramu i karta graficzna 2 MB ram. Miała być czteromegowa, ale jak się okazało w sklepie albo mnie oszukali, albo się pomylili, a ja dopiero po latach zorientowałem się. Cóż, pierwszy komputer.

Pierwszy komputer nie miał modemu, a tym bardziej karty sieciowej, ale miał za to od razu zainstalowanego windowsa, grę quake, grę abbys word i jeszcze kilka innych. Wszystko pirackie, choć o to nie prosiłem. Po latach przeczytałem w Porannym, że sklep, w którym kupiłem mój zestaw został zamknięty po nalocie policji. Widać ktoś zamiast usiąść i grać w bonusowego quake-a poszedł to zgłosić.

Pierwszy raz wszedłem w internet na studiach, w kawiarence internetowej. Kawiarenka oczywiście już nie istnieje, ale dobrze pamiętam, że pierwszą stroną, jaką odwiedziłem było Yahoo. Kupiłem szybko w empiku jakiś kieszonkowy przewodnik po internecie i odwiedzałem kolejne wymienione w nim strony.

Uzależniłem się od kawiarenek dość mocno, a miejscem w którym byłem najczęściej to był czat. Pamiętam, że w czasie jednej z takich wizyt usłyszałem od znajomych, że na świecie jest już taki internet, za który nie trzeba płacić za każdą minutę, a w miarę niską opłatę miesięczną. Nie mogłem uwierzyć.

W kawiarence internetowej spróbowałem pierwszy raz wejść w Usenet. Bez rezultatu. Wpisałem w pasek adresu przeglądarki pl.sci.cośtam, a ta stwierdziła, że nie można wyświetlić strony. Prawdę mówiąc nie mam się chyba teraz czego wstydzić, bo podejrzewam, że ten wpis czyta już też takie pokolenie, które nie wie co tu jest wstydliwego. Drogie dzieci, nie tak się wchodzi w Usenet 😉

Jakoś w międzyczasie dokupiłem do swojego domowego komputera modem, przez co rodzice zaczęli o wiele rzadziej rozmawiać przez telefon, za to o wiele więcej za niego płacić. Pamiętam, że sam siebie limitowałem. Na ścianie wisiała kartka, na której notowałem ile minut już siedziałem w sieci (drogie dzieci, kiedyś za internet płaciło się za każdą minutę) i starałem się nie przekraczać miesięcznego limitu.

Takie limitowanie rozwinęło we mnie żyłkę archiwisty. Strony szybko (“szybko”… dobre sobie) ściągałem na dysk, zapisywałem i czytałem po rozłączeniu. Wtedy ponownie podszedłem do usenetu i tym razem już z powodzeniem. Już wiedziałem, że usenet wymaga czytnika wiadomości i – co było najfajniejsze – wystarczyło połączyć się, zsynchronizować i rozłączyć.

Tak oto pobrałem między innymi chyba całe archiwum grupy pl.comp.www, przeczytałem na nim z tysiąc wiadomości (może i trzy tysiące, trwało to wiele dni) i zanim odważyłem się coś napisać, poszedłem szukać kursu tworzenia stron. Tu specjalne podziękowania dla Pawła Wimmera.

Long story short, świat ujrzał moją pierwszą stronę o mojej pasji – mrowisko.of.pl. Już teraz nie działa, traktowała o mrówkach. Ale przyznać muszę, że wtedy jeszcze bardzo wielką zasługę w jej powstaniu miał Microsoft Front Page.

Stron było jeszcze kilka, z tych ważniejszych muszę wspomnieć o VivaMozilla.civ.pl (też już jej oczywiście nie ma). Strona ważna z wielu powodów. Po pierwsze była to dość ważna strona fanowska – jak na tamte czasy. Mozilla dopiero raczkowała, a stronę moją, obok mozillapl.org (miałem ich koszulkę ze zlotu fanów Mozilli w Poznaniu!) polecali wszyscy w sieci. Uznanie było tak duże, że jeśli ktoś w Mozilli wszedł w menu Pomoc, tam wszedł w O autorach i doczekał do podziękowań (lista autorów przewijała się jak napisy końcowe w filmie) byłem tam wymieniony z imienia i nazwiska! Moje nazwisko w Mozilli. Fakt, że to była wersja 0.9 tego programu, że to było wieki temu i nikt nawet nie słyszał o Firebirdzie (potem przemianowanym na Firefoksa). ale zawsze coś. Pamiętam, że na VivaMozilla na górze miałem taki licznik, który wskazywał, że użytkowników Mozilli w Polsce jest już 40 tysięcy. Takie to były czasy.

VivaMozilla to też moja pierwsza strona napisana w PHP i to z autorskim systemem CMS, stworzonym przeze mnie. Głównym powodem stworzenia go był fakt, że nie umiałem zainstalować żadnego gotowego i że gotowe wymagały bazy danych MySQL, czego moje konto nie zapewniało – takie to były czasy. Napisałem więc system, który gromadził newsy w plikach tekstowych na serwerze. System któregoś dnia został zhakowany przez Turków, po kilku dniach znów został zhakowany, a ja strzeliłem focha, wrzuciłem newsa, że ja tu hobbistycznie żyły wypruwam i jak oni mnie tak, to ja stronę zamykam. I zamknąłem.

Równolegle bardzo intensywnie udzielałem się w Usenecie. Drogie dzieci, Usenet to takie miejsce, w którym wszyscy mogli zapytać o wszystko innych, wszyscy starali się nie dać sprowokować trollom, wszyscy pisali mniej lub bardziej anonimowo i mieli internetowych znajomych. Tak, coś jak Facebook, tylko ze zgaszonym światłem.

Aż dotarłem do grupy pl.pregierz – miejscu, o którym się mówiło, że jak się raz tam wejdzie to nie można wyjść. To prawda. Wiele osób próbowało przestać tam pisać, ale po kilku miesiącach wracali. pl.pregierz bardzo rzucał się na mózg. To było tak, że gdy jakaś ekspedientka w sklepie krzywo na ciebie spojrzała, już z myślach układałeś sobie “piętnuję sklep ABC za zatrudnianie leniwych, starych bab…” i po powrocie do domu tekst ten wrzucałeś na pręgierz. I zaczynała się dyskusja albo i nie.

pl.pregierz bardzo szybko z miejsca narzekania ogólnego zmienił się w miejsce sporów politycznych. Prawica mówiła lewicy (przepraszam, lewakom) jak ma żyć, a ci im odpowiadali by spier*lali. Takie to było miejsce i taki język. Upadek totalny zaczął się od zjawienia się na pręgierzu moona – jakiegoś już starszawego prawicowca, który nie wahał się wyjaśnić ci, że jeśli nie głosujesz na Giertycha, to jesteś chu*em.

I wtedy pojechałem do Afryki, do Rwandy i wszystko się zmieniło. Udało mi się wyjść z pręgierza i nigdy już tam nie wróciłem. Udało mi się zobaczyć, że poza internetem jest fajniej, a jak się weszło w jakieś internetowe bagno, da się z niego wyjść. Temu tak łatwo udało mi się opuścić wykop.pl – obecnie bardzo przypomina to, co kiedyś działo się na pręgierzu.

Strony jednak robię dalej. Jak wiecie już nie na autorskim CMSie 😉 a na solidnym WordPressie. Mam kilka swoich, co jakiś czas powstaje też kolejna robiona któremuś z moich klientów. Tylko usenet – niegdyś bardzo ważny (nie tylko pregierz odwiedzałem, ale wiele grup naukowych i tchnicznych), a teraz jak zaglądam wiejący pustkami – zastąpiłem Google Plusem i trochę facebookiem.

Kurcze, to tylko 13 lat, a czuję się jakbym opowiadał historie sprzed dziesięcioleci.

0

18 kwietnia, 2013 3 komentarze

O kurczaki, mój blog nie jest mój!

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 🙂

0

16 czerwca, 2010 2 komentarze

Zrób sobie własny cache w WordPressie

Pluginów do cache’owania stron stworzonych w WordPress jest wiele. I całe szczęście, bo niestety są sytuacje, w których WordPress ma spore problemy z prędkością. Niestety jak do tej pory nie udało mi się znaleźć rozwiązania idealnego. Dlatego też chcę przedstawić własne rozwiązanie, pomagające przyspieszyć generowanie stron unikając zbytniego mielenia funkcjami php i odpytywania bazy danych.

Podstawowym problemem wszystkich pluginów jest fakt, że cache’owania jest fakt, że strony są przechowywane w całości. Plugin raz na jakiś czas generuje całe strony i dopiero po określonym odstępie czasu generowanie się powtarza. To sprawia sporo problemów z choćby obsługą ciasteczek: nie można rozpoznawać użytkownika po ciasteczku i wysyłać mu spersonalizowanej strony, bo WordPress z takim pluginem do wszystkich wysyła takie same strony.

Oczywiście są metody na obejście tego, jednak każda ma jakieś wady. Można w ustawieniach pluginu zarządać aby nie cache’ował poszczególnych stron, nie działał gdy użytkownik jest zalogowany, można też w WP Super Cache użyć odpowiednich hacków. Jednak zawsze oznacza to całkowite wyłączenie cache’owania. Cała strona jest cache’owana lub niecache’owana.

A co jeśli by podejść do zagadnienia pregenerowania zawartości nieco inaczej? Czy na pewno musimy pregenerować całe strony od <html> do </html> ?

Odpowiedź brzmi: oczywiście nie. Skoro szablony i tak mamy rozbite na najczęściej 5 plików – header.php, index.php, sidebar.php, footer.php i style.css, index.php włącza w siebie pozostałe pliki wcześniej je generując (za wyjątkiem oczywiście pliku stylów, ten jest statyczny), czy na pewno na przykład header.php musi być generowany za każdym razem? Nawet jeśli musi (bo na przykład ma odwołania do plików JS zależnych od zawartości konkretnej strony): czy każdy fragment takiego pliku musi być generowany za każdym razem? Jestem niemal pewien, że obecny w chyba każdym pliku nagłówka kod bloginfo(‘charset’) generuje zawsze to samo od powstania blogu, aż do jego “śmierci”.

Można też znaleźć i dłuższe, bardziej złożone fragmenty kodu php, który tak naprawdę generuje zawsze to samo, a przynajmniej nic nie stoi na przeszkodzie aby wygenerowana zawartość odświeżała się powiedzmy raz na godzinę. Czy masz w sidebarze swojego bloga jakiś widget wstawiający zawsze te same reklamy? Dlaczego więc WP miałby przy każdej odsłonie strony odpytywać bazę danych co ma do tego widgetu wstawić?

Mam nadzieję, że już rozumiecie na czym polega problem. A rozwiązaniem jest: cache’owanie fragmentów strony, a nie całości.

Jak to zrobić?

1.

Do swojego pliku functions.php w katalogu skórki dodaj następujący kod:

function mincache($whatto, $howlong = '15', $work = TRUE) {
if ($whatto == '') {
exit ('Please specify name of cached code');
}

if ($howlong == '') $howlong = '15';

$folder = trim(parse_url(get_bloginfo('template_directory'), PHP_URL_PATH), '/');
$cachefile = $folder.'/mincache/'.$whatto.'-cached.html';
$cachetime = $howlong * 60;

if ($work == TRUE && file_exists($cachefile) && time() - $cachetime < filemtime($cachefile)) {
    include($cachefile);
    echo "\n";

}

else {
$includedFile = 'inc.'.$whatto.'.php';
ob_start();

include_once($includedFile);

$fp = fopen($cachefile, 'w');
fwrite($fp, ob_get_contents());
fclose($fp);
ob_end_flush(); 
}

}

2.

W katalogu skórki utwórz katalog o nazwie mincache i nadaj mu uprawnienia do odczytu i zapisu.

3.

Kod, jaki chcesz aby był cache’owany wytnij z pliku php i wklej do nowego pliku i nazwie stworzonej według struktury inc.nazwa.php. Pod nazwa wpisz co chcesz.

4.

W miejsce skąd wyciąłeś ów kod wklej:

mincache('nazwa')

I to wszystko. Teraz zawartość przeniesionego kodu do pliku inc.*.php będzie generowana tylko raz na 15 minut.

* * *

Nieco więcej o stworzonej właśnie funkcji mincache():

mincache($whatto, $howlong, $work)

Jak widać funkcja może przyjmować trzy parametry:

$whatto – nazwa fragmentu kodu który ma być szukany w pliku inc.*.php. Musi więc istnieć plik inc.{$whatto}.php, parametr ten jest bowiem obowiązkowy (inaczej funkcja nie będzie wiedziała co cache’uje.

$howlong – jak długie powinny być odstępy między kolejnymi generowaniami kodu statycznego, w minutach. Domyślnie: 15 minut.

$work – wartość logiczna true/false czy ma próbować pobrać kod z pliku statycznego (true, domyślnie ustawione) czy też za każdym razem generować go od nowa (false). Parametr ten dodałem abyście mogli w czasie prac nad stroną chwilowo wyłączać działanie cache (wartość FALSE).

* * *

I na koniec jeszcze raz konkretny przykład. Załóżmy, że chcemy aby sidebar generował się jedynie raz na pół godziny.

Wykonaj punkty 1 – 2 opisane powyżej.

Otwórz plik sidebar.php, wytnij jego całą zawartość i zastąp:

<?php mincache('sidebar', '30') ?>

Utwórz plik inc.sidebar.php w katalogu skórki i wklej do niego całą zawartość wyciętą przed chwilą z sidebar.php.

I to wszystko. Od teraz sidebar będzie się generował jedynie raz na pół godziny, co na pewno skróci czas ładowania strony.

0

11 stycznia, 2010 2 komentarze

Zaawansowana zabawa z szablonami podstron w WordPressie

Ten wpis jest kolejnym moim chwaleniem się jaką stronę wykonałem na bazie WordPressa, a zarazem chcę tutaj pokazać jak bardzo można zmodyfikować WordPressa (na pierwszy rzut oka nie widać, że to właśnie WordPress) i pokazać praktyczne zastosowanie dziedziczenia szablonów. Powiem szczerze, że jestem dumny z tego, co mi tutaj wyszło 🙂

Tutaj czyli na stronie Młodzi Twórcy wykonanej dla Urzędu Miejskiego w Białymstoku. Białystok ma program stypendialny dla ludzi uzdolnionych w różnych dziedzinach (ma zapewne jak i inne miasta, ale tylko Białystok jak widać chce się tym chwalić). Program działa już od jakiegoś czasu, ale teraz przyszła pora na stworzenie dla niego strony internetowej. I tutaj pojawiam się ja (jako podwykonawca dla  Man With The Plan).

Powyżej obrazek przedstawiający stronę główną. Wszystkie zrzuty ekranu w tym wpisie są klikalne więc jeśli chcecie, śmiało przechodźcie aby zobaczyć jak to wygląda u Was 🙂

Jak widać nie ma tutaj typowo blogowego układu. Mnie to nie dziwi, bo WordPress coraz bardziej staje się zwykłym CMSem zdolnym do tworzenia każdego rodzaju stron (choć blogi się w nim robi najłatwiej). Mechanizm bloga wykorzystałem tutaj w dziale Aktualności. Reszta to coś, co w panelu administracyjnym WordPressa nazywa się po prostu Strony.

Ale jakie strony! Poklikajcie na odnośniki w górnym panelu, a przekonacie się, że praktycznie każda z nich wygląda inaczej. Było to nie lada wyzwaniem ale się udało. Inny układ  kolumn na poszczególnych podstronach, co innego w sidebarach w zależności  od tego na jakiej stronie się właśnie znajdujemy, “podświetlenie” dla pozycji w górnym menu nie tylko gdy jesteśmy na tej właśnie stronie, ale także na stronie potomnej danej podstrony.

Nie było to łatwe, bo musiałem zrobić to jak najbardziej user friendly. Założyliśmy, że osoby w urzędzie nie znają WordPressa, więc sztuczki z Custom Fields, zastosowanie widget logic, custom themes trzeba unikać jak najbardziej. Osoba dodająca treści ma po prostu dodać kolejną stronę, określić, że jest ona “dzieckiem” takiej czy innej strony, a WordPress i jego funkcje same mają rozpoznać jaką właśnie stronę internauta chce wyświetlić i pokazać ją jak na obrazku powyżej (tak, to jest zwykła strona w WordPressie, stworzona we wbudwanym w nim edytorze stron; to ja, a nie osoba wprowadzająca tekst zadbałem by nagłówki miały inny wygląd, by każdy akapit był właściwie oddzielnym divem, a zawarty w nim odnośnik do pliku stał się przyciskiem wyrównanym do prawej) lub na przykład jak ta strona:

Jak widać wyżej mamy trzy sekcje: opis stypendysty, jego (czy w tym wypadku – jej) program stypendium i jego/jej zdjęcia. Tu także całość została zrobiona tak, aby pracownik urzędu nie musiał niczym się martwić: musi jedynie dodać treść, dodać zdjęcia (działa także dodawanie filmów), a to ja musiałem rozpoznać gdzie zaczyna się program stypendium czy właśnie zdjęcia lub filmy (i sprawić by miały inne tło). Co więcej powstały strony grupujące: gdy pracownik urzędu doda stronę konkretnego stypendysty, automatycznie pojawi się ona na stronie ich grupującej rocznikami:

Udało się? Przy “odrobinie” znajomości WordPressa i  umiejętności pisania dla niego funkcji, zabawy w dziedziczenie tematów graficznych, efekt jest chyba całkiem niezły, nie prawda? 😉

* * *

A może Ty też chcesz mieć taką stronę, szukasz kogoś kto zajmie się Twoim blogiem, albo znasz kogoś z takimi potrzebami? Zajrzyj na stronę O mnie i odezwij się do mnie w jeden z podanych tam sposobów, a na pewno uda nam sie razem wyczarować coś fajnego 🙂

0

23 grudnia, 2009 5 komentarzy

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ń. 🙂

0

27 listopada, 2009 Add Comment

Książkę będę czytał

Dawno chyba nie wybierałem podręcznika tak dokładnie 🙂 Ale inaczej nie  mogłem: podręcznik jest do nauki Java Script – języka do którego podchodziłem już kilka razy, ale nigdy jakoś mi się nie udało. Tym razem więc postanowiłem nie wtopić ą i dość dokładnie obejrzałem dookoła każdą z książek, aż zdecydowałem się na Head First JavaScript.

Od razu wtręt: nikt mi nie płaci za ten tekst ani za promowanie Heliona, książki czy czegokolwiek. Nawet od razu podpowiem, że nie kupiłem jej na Helion, a na Allegro gdzie nowy egzemplarz kupiłem o 30% taniej (książka tania nie jest, więc 30% to całkiem sporo złotówek).

Do zakupu przekonał mnie przykładowy rozdział zamieszczony na stronie Helionu. Przeczytajcie, a chyba sami zrozumiecie dlaczego 🙂 Świetnie napisane, jak dla debila (którym zapewne jestem, skoro od lat nie mogę zrobić w JS nic więcej niż zastosować gotowy skrypt, ewentualnie go przerobić czy skorzystać z któregoś z frameworków… nie, właśnie tak sobie pomyślałem, że może jednak to wcale nie takie debilne), sporo humoru (wciąż tęsknię za chyba już martwą serią książek “…for dummies”) i  niesztampowe podejście do nauczania. Przykładowy rozdział zrozumiałem, więc mam nadzieję, że i reszta okaże się prosta.

Spodziewajcie się zatem tu na moim blogu nieco skaczących literek, zegarka w rogu i wyskakujących alertów z prośbą o wpisanie imienia 😉 Z przyjemnością wpiszę sobie javascript na listę umiejętności 🙂

p.s. fajnie by było jakby pojawiło się też po polsku coś podobnego do Pythona, bo to kolejny język, który próbowałem ugryźć i mi nie wyszło. A może potraficie coś polecić? Ma być prosto i z humorem.

0

16 listopada, 2009 1 Comment

Plugin do WordPressa – dodawanie pustych linii do wpisów

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.

0

12 listopada, 2009 Add Comment

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

0

13 września, 2009 1 Comment