W sieci pojawiają się już wątki komunikacyjne* odnośnie dojazdu na WordCamp wspólnym samochodem. Pomyślałem, czemu by nie zapytać?  

Nie mam samochodu, ale jadę do Łodzi w piątek przez Warszawę z Białegostoku. Jeśli ktoś po tej trasie będzie także jechać i chce zabrać pasażera, to zapraszam do kontaktu kkarpieszuk@gmail.com

Jak się nikt nie zgłosi, jutro, tak jak planowałem, idę kupić bilet na pociąg.

*) Inne propozycje wspólnej jazdy, jakie widziałem:

Z Legnicy/Wrocławia jest tutaj: http://www.wordpress.org.pl/Dojazd-na-WordCamp-Polska-t11498.html

Z Krakowa jest tutaj: http://wordcamp-polska.pl/aktualnosci/program-konferencji/ oraz tutaj http://www.goldenline.pl/forum/1352018/spotkanie-fanow-wordpressa/s/3#38700380 

Obudził mnie dziś rano wpis na Facebooku, w którym Paweł Lipiec informuje nas – organizatorów WordCampa (to już ten weekend!) – że felernie wybraliśmy sobie datę, bo w tym samym czasie odbędzie  się Blog Forum Gdańsk A ja się zastanawiam, czy to my źle wybraliśmy datę, czy to ktoś inny jednak był tym drugim, kto postanowił zrobić forum w tym samym terminie co my będziemy mieli swoje. 

O Blog Forum Gdańsk dowiedziałem się dopiero dziś, na trzy dni przed nim. Albo jestem źle poinformowany, albo… nie wiem. Według mnie taka informacja raczej nie powinna sama z siebie mnie ominąć, bo staram się śledzić co się blogowym świecie dzieje. (Co więcej wrzuciłem informacje o tym na naszą listę mailingową organizatorów i także  nikt z nas wcześniej o tym nie wiedział). Czy ktoś z Was może wiedział o tym i może zdradzić od kiedy to jest w sieci?

Właśnie – strony internetowe Tutaj jestem niemal pewien, że  ktoś najpierw usłyszał o nas, a potem wpadł na pomysł by w tym samym czasie zrobić podobną imprezę. Spójrzcie na naszą stronę, na dział Materiały, a potem na stronę Blog Forum Gdańsk, ten sam dział Plagiat to oczywiście nie jest, ale przyznacie, że przynajmniej mogli zmienić kolejność obrazków do pobrania Albo jakoś bardziej inaczej podpisać. To nie może być przypadek, że dwie różne firmy zrobiły tak podobne strony i żadna wcześniej nie widziała poprzedniej. A że my jesteśmy czyści – w sensie, że nie ściągaliśmy od nich – jestem dość mocno przekonany

No nic. Do zobaczenia już w sobotę!

Zainstalowałem sobie właśnie wtyczkę ScribeFire dla Chrome i ten wpis pisze za jej pomocą. Jeśli wpis się pojawi i nie będzie żadnych z tym problemów, to chyba można powiedzieć, że ją polecam

Ze ScribeFire miałem do czynienia ostatni raz w 2008 roku, wtedy jako wtyczką do Firefoksa. Nie przypadł mi do gustu, bo działał kiepsko. Jeśli jednak od tamtej pory coś się zmieniło, mam nadzieję, że da się go używać.

Czym jest ScribeFire? To wtyczka umozliwiająca publikowanie wpisów na własnym blogu (nie tylko opartym na WordPress) bez konieczności logowania się do panelu administracyjnego, odnajdywania odpowiedniej strony itd. Klikamy guzik wtyczki i już mamy okno edycji wpisu. Jeśli przy wtyczce zostanę dlużej, spodziewajcie się tutaj więcej krótkich notek – do tej pory przed zamieszczaniem ich powstrzymywała mnie właśnie konieczność odbębnienia tego calego rytuału logowania – pisania – publikowania. 

Pisałem już Wam o moim serwisie wpzlecenia.pl, w którym każdy będzie mógł dodać za darmo zlecenie związane z WordPressem i każdy za darmo takie zlecenie będzie mógł przeczytać? Serwis działa, moje podejście do darmowości w nim się nie zmienia, jednak chce spróbować zarobić w nim przynajmniej na utrzymanie i motywację do dalszego rozwoju

Przygotowałem ofertę reklamową na WPzlecenia. Każdy kto chce wesprzeć tę stronę, a przy okazji wypromować się nieco może kupić jedno z trzech miejsc reklamowych (jedno z nich już zostało sprzedane). Zapraszam

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?

A więc  zainstalowałeś/łaś WordPressa, piszesz na nim już dziesiąty wpis i dziwisz się, że nikt nie chce komentować tego co napisałeś? Nie dziw się, zapomniałeś o jednej rzeczy.

Ja bardzo lubię komentować wpisy. Jest to jakiś tam rodzaj podziękowania za pisanie dobrych tekstów, a jako bloger wiem jak bardzo mobilizująco do pisania działa czytanie kilkunastu komentarzy pod jednym wpisem.

Tyle, że ostatnio coraz częściej odpuszczam sobie zostawianie komentarzy na cudzych blogach. Demobilizująco działa na mnie brak pola „Powiadom mnie o odpowiedziach na moje komentarze”.

Dziennie odwiedzam kilkanaście, jeśli nie kilkadziesiąt blogów. Jeśli miałbym choćby pod pięcioma zostawić komentarz, to w żadnym wypadku nie zapamiętam pod którymi to zrobiłem i na  100% nie wrócę na nie by sprawdzić czy ktoś skomentował mój komentarz. Po co więc mam włączać się do jakiejś dyskusji, jeśli zaraz sobie z niej pójdę? Zostawianie komentarza pod wpisem bez możliwości śledzenia odpowiedzi wygląda trochę jak zostawienie karteczki wsuniętej za wycieraczkę samochodu. Nie  bawi mnie to.

Natomiast jeśli gdzieś widzę pole „Powiadom o komentarzach” aż chce się włączyć do dyskusji.

Przyznam, że funkcja ta powinna być automatycznie zintegrowana z WordPressem i dziwię się, że jeszcze tak się nie stało. Na szczęście bardzo łatwo jest osiągnąć tę funkcjonalność:

• pobierz i zainstaluj tę wtyczkę
• jesli chcesz, tu znajdziesz do niej spolszczenie

I to wszystko. Pięć, dziesięć minut roboty, a zobaczysz, że nagle ludzie zaczną chętniej komentować Twoje wpisy, a jeśli pojawi się pierwszy komentarz, jest spora szansa, że posypią się kolejne.

Czas opisać kolejne rzeczy, które możemy zrobić z skórką-szablonem jakim jest Thematic. Dziś napiszemy bardzo mało kodu (czyż to nie wspaniale?), ale nieco się rozpiszę, po to, by wyjaśnić Wam dlaczego właśnie robi się to tak, a nie inaczej.

Domyślnie w Thematicu menu znajduje się pod tytułem bloga i jego jednozdaniowym opisem. Ja jednak postanowiłem sobie, że owo menu chce mieć na samej górze strony, tak jak to teraz widzicie na blogu. Jako, że blog będzie się zmieniał, a artykuł ten ktoś może przeczytać, gdy wygląd już będzie zupełnie inny, oto dwie ilustracje.

Tak wygląda blog przed zmianami:

A tak będzie wyglądał na koniec:

Teraz chyba wszystko jest jasne, co chcemy osiągnąć. A oto opis jak to zrobić.

Firebugiem sprawdziłem w jakim miejscu kodu HTML znajduje się menu. Wynik: jest to element wewnątrz diva o id „header” i jest ostatnim elementem w tym divie (jako element rozumiem zbiór tagów HTML tworzących te menu).

Intuicja mi podpowiedziała by zajrzeć do pliku header.php Thematica. Wszystko co tam znalazłem objęte divem „header” to ten fragment:

<div id="header">
 <?php
        // action hook creating the theme header
        thematic_header();
 ?>
</div><!-- #header-->

Jak widać wiele tam nie ma. Jedna php-owa funkcja thematic_header(), która w efekcie działania tworzy wszystkie elementy wewnątrz diva. Musimy więc znaleźć tę funkcję i zobaczyć jak wygląda.

Już wcześniej przejrzałem sobie strukturę plików i katalogów thematica i wiem, że wszystkie funkcje znajdują się w plikach zawartych w katalogu /library/extensions. Akurat pliki w tym katalogu są dość logicznie nazwane i wystarczy szybki rzut okiem by domyśleć się, że funkcje pliku skórki header.php znajdują się w wyżej wymienionym katalogu w pliku header-extensions.php. Po otworzeniu pliku okazuje się, że mam rację, definicja funkcji thematic_header() wygląda następująco:

// Used to hook in the HTML and PHP that creates the content of div id="header">
function thematic_header() {
    do_action('thematic_header');
} // end thematic_header

Króciutkie i na pierwszy rzut oka może nam niewiele mówić. Trzeba więc grzebać dalej. Przyznam, że to jest moment, w którym przychodzi do głowy aby chrzanić rozgrzebywanie tego i po prostu w naszej nowej skórce ‘szkicownik’ utworzyć własny plik header.php i napisać w nim wszystko od nowa.

Takie rozwiązanie byłoby jednak okropne. Po pierwsze musielibyśmy napisać cały kod typowy dla plików header.php od nowa. Wszystkie tagi HTML, wszystkie tagi PHP, wszystkie template tagi WordPressa. Kłóci się to kompletnie z ideą instalowania Thematica – zainstalowaliśmy go bowiem po to, by uniknąć właśnie pisania kodu.

Po drugie wyobraźmy sobie, że twórcy Thematica dodają w swojej skórce jakieś ulepszenie w pliku header.php. Jeśli stworzymy własny plik header.php z owego ulepszenia nie skorzystamy. Musielibyśmy w przyszłości śledzić zmiany w skórce thematic, analizować czy dane zmiany są istotne dla naszej skórki potomnej i ręcznie nanosić je (lub nie) w nadpisanych przez nas plikach. To niepotrzebna praca. Jeśli mamy tylko jeden blog to pół biedy. Jeśli jednak jesteśmy developerami stron opartych na WP i mamy ich wiele opartych na na Thematicu, będziemy musieli poświęcić naprawdę sporo czasu na wprowadzanie poprawek, na których raczej nie zarobimy (chyba, że ciężar wprowadzania poprawek w umowie przeniesiemy na klienta, ale wg mnie jest to rozwiązanie nieuczciwe).

OK, zatem skoro już korzystamy z Thematica korzystajmy z niego prawidłowo. Spójrzmy jeszcze raz na kod powyżej.

Co robi ta funkcja? Jej działanie można sprowadzić do takiego opisu:

„Odnajdź w kodzie skórki (oraz w kodzie skórki potomnej) wszystkie wywołania add_action odwołujących się do haka o nazwie ‘thematic_header’ i wykonaj je w tym miejscu”

Innymi słowy, jeśli w kodzie thematica lub skórki potomnej występuje przykładowo kod:

add_action('thematic_header', 'nasza_funkcja');

Zostanie w tym momencie wykonana funkcja nasza_funkcja() (którą musimy gdzieś zdefiniować, jeśli jeszcze takiej definicji nie ma).

Zatem kod z pliku header.php tak naprawdę wykonuje wszystkie znalezione akcje (add_action) odwołujące się do haka „thematic_header”. Wykona akcje zdefiniowane w samym thematicu, ale także akcje jakie samemu zdefiniujemy w naszej skórce potomnej w pliku functions.php (co ciekawe zostaną także przeskanowane aktywne pluginy w poszukiwaniu odwołania do tego haka, ale tym na razie się nie przejmujmy; nadmieniam to tylko aby dać znać, że także przez pluginy możemy modyfikować skórki).

Okej, znajdźmy więc akcję, która powoduje wykonanie funkcji tworzącej menu. Dalej w tym samym pliku header-extensions.php możemy znaleźć szereg linijek powodujących wykonanie kolejnych akcji skojarzonych z hakiem ‘thematic_header’, na interesuje ta, która powoduje stworzenie elementu HTML o id „access” (czyli naszego menu):

// Create #access
// In the header div
function thematic_access() { ?>
<div id="access">
<div class="skip-link"><a href="#content" title="<?php _e('Skip navigation to the content', 'thematic'); ?>"><?php _e('Skip to content', 'thematic'); ?></a></div>
<?php wp_page_menu('sort_column=menu_order') ?>
</div><!-- #access -->
<?php }
add_action('thematic_header','thematic_access',9);

Co tu mamy? Najpierw jest definicja funkcji thematic_access(), która w ostatniej linijce jest „podhaczana” za pomocą add_action do dobrze nam już znanego haka „thematic_header”. Dziewiątka na końcu oznacza, że akcja ta ma się wykonać jako dziewiąta: jeśli gdzieś są akcje odwołujące się do „thematic_header” o niższych liczbach (a są, przejrzyjcie plik header-extensions.php), mają się one wykonać najpierw.

Jak obejrzycie plik header-extensions.php, zobaczycie, że przed wyżej zacytowanym przeze mnie fragmentem kodu są inne funkcje podhaczone w ten sposób: jest funkcja powodująca dodanie tytuły bloga, opisu bloga, kilka pomniejszych…

OK, oglądanie kodu w tym momencie możemy uznać za zakończone. Wiemy już wszystko co powinniśmy wiedzieć. Jak teraz jednak dzięki tej wiedzy dodać menu nad tytułem bloga i jak usunąć menu pod tytułem bloga?

Pierwsze co przychodzi do głowy to pliku tym po prostu zmienić cyfrę ’9′ na mniejszą, tak aby tworzenie menu wykonało się jeszcze przed stworzeniem innych elementów (w tym tytułu naszego bloga). Kusi naprawdę, aż się chce zmienić cyferkę na ’1′.

Jednak nie. Znów przez to zepsulibyśmy ideę Thematica: gdy w przyszłości twórcy tej skórki wydadzą jej nowszą wersję, nasza zmiana zostałaby nadpisana. Po to właśnie stworzyliśmy w poprzedniej lekcji skórkę potomną, by właśnie w niej robić zmiany bez obawy o nadpisanie ich.

Otwórzmy więc katalog naszej skórki i utwórzmy tam plik functions.php. Wewnątrz dodajmy następujacy kod:

<?php
add_action('thematic_header', 'thematic_access',1);

Banalnie proste, prawda? Spowodowaliśmy, że funkcja thematic_access() tworząca menu wykona się jako pierwsza w ramach haka ‘thematic_header’.

Odśwież teraz stronę bloga. Zobaczysz taki widok:

To nie do końca to, co chcieliśmy osiągnąć. Co prawda menu pojawiło się nad nagłówkiem, ale wciąż znajduje się także pod nim. Dzieje się tak dlatego, że akcja z pliku header-extensions.php (ta z dziewiątką) nadal się wykonuje. Musimy ją więc odwołać, a robi się to za pomocą „antyhaka” remove_action(). Dodajemy następujący kod do naszego pliku functions.php:

add_action('init', 'usun_standardowe_menu');
function usun_standardowe_menu() {
 remove_action('thematic_header','thematic_access',9);
}

Za pomocą akcji ‘init’ wywołujemy własną funkcję usun_standardowe_menu(). Funkcja ta natomiast odwołuje wszystkie akcje ‘thematic_access’ odwołujące się do haka ‘thematic_header’ z priorytetem ’9′. W ten oto sposób powiedzieliśmy wordpresowi aby zignorował odpowiednią akcję z pliku header-extensions.php.

Proste? Oceńcie sami. Opis jaki zamieściłem jest bardzo długi, ale zauważcie, że ostatecznie piszemy tylko 4-5 linijek w naszym pliku functions.php. Najwięcej czasu zajmuje ustalenie „co gdzie i jak” jest robione w Thematicu, ale jeśli dobrze się pozna tę skórkę, w przyszłości zmiany takie jak wyżej zajmą nie więcej niż kilka minut.

Jak widzicie, tak jak zapowiedziałem kilka dni temu, zniknął temat graficzny jaki był do tej pory na tym blogu i zastąpiłem go tematem-frameworkiem o nazwie Thematic. Mam zamiar go rozbudowywać dzięki tematowi potomnemu, co już powoli się dzieje. Oto pierwszy z  wpisów opowiadających o moich przygodach podczas rozwoju skórki na bazie Thematica.

Odnośnie instalacji Thematica nie mam żadnych zastrzeżeń. Przebiegła bez problemu, jak zresztą każdej innej skórki.

Założeniem Thematica jest aby skórki tej nigdy bezpośrednio nie edytować. Jeśli chcemy zmienić wygląd naszego bloga, tworzymy nowy katalog i w nim umieszczamy pliki, które będą zmieniać zachowanie i wygląd  Thematica. W takim układzie Thematic nazywany jest tematem-rodzicem (parent theme) natomiast nasza skórka modyfikująca tematem potomnym/dzieckiem (child theme). Oto jak stworzyłem temat potomny.

W katalogu ze skórkami wp-content/themes utworzyłem nowy katalog i nazwałem go ‘szkicownik’ – taką bowiem na szybko wymyśliłem nazwę dla mojej skórki.

W katalogu tworzymy plik style.css, który rozpoczyna się od komentarza informacyjnego:

/*
Plugin Name: Szkicownik
Template: thematic
*/

Komentarz ten jak widać zawiera tylko dwie informacje (można oczywiście dodać więcej jak w zwykłej skórce):

Plugin Name – czyli informację o nazwie naszej skórki
Template – nazwę tematu rodzica. Tu ważna uwaga: pomimo tego co pisze w tutorialach w sieci, nazwa musi być podana z małej litery (a właściwie prawdopodobnie musi być taka sama jak nazwa katalogu, w którym temat-rodzic się znajduje).

Jeśli teraz włączymy naszą skórkę ‘szkicownik’, wyświetli nam się strona kompletnie bez stylów. Prawidłowo. Od tej pory WordPress wszystkie pliki szkieletu strony (index.php, header.php, sidebar.php, footer.php) bierze z katalogu skórki Thematic, natomiast style z katalogu skórki Szkicownik. Jako, że plik style.css w katalogu ‘szkicownik’ nie zawiera żadnych definicji, strona wyświetla się goła.

Możemy w tym momencie zacząć albo samemu definiować nowe style dla strony od początku, możemy także zaimportować style z katalogu Thematica i potem je modyfikować. Wybrałem to drugie rozwiązanie, tak aby bazować na gotowym, jako tako ładnym, choć bardzo skromnym wyglądzie.

Style importujemy przez CSSowe polecenie @import url(‘sciezka’). Thematic swoje style ma rozbite na wiele plików, każdy odpowiedzialny za co innego. Co więcej wiele plików jest w kilku wariantach i to my sami decydujemy, który z nich zechcemy użyć. Przykładowo w katalogu z Thematikiem znajdziemy plik layouts/2c-r-fixed.css, który daje nam layout z dwoma kolumnami, z których prawa ma określoną na sztywno szerokość, zaraz obok jest plik layouts/2c-l-fixed.css, który daje układ podobny, tyle, że sidebar o stałej szerokości znajduje się po stronie lewej. Sami wybieramy, który z tych (jak i kilku innych) layoutów wybierzemy.

Oto jakie pliki postanowiłem sobie zaimportować na początek:

@import url('../thematic/library/styles/reset.css');

Plik zawierający tak zwany ‘reset css’. Kto tworzy strony już zna tę metodę tworzenia CSS, a kto jeszcze nie zna, prędzej czy później pozna. Pliki reset css służą wykasowaniu wszystkich specyficznych ustawień, różnych dla różnych przeglądarek. Przykłądowo Opera inaczej niż inne przeglądarki podchodzi do problemu marginesów i paddingów elementu BODY. Zazwyczaj pisanie CSS zaczynało się właśnie od podania takiej definicji dla Opery, jak dla innych przeglądarek. I właśnie takie niwelacje przeglądarkowych niuansów gromadzi plik reset.css.

Warto tu jeszcze zwrócić uwagę na ścieżkę do pliku. Aby dostać się do katalogu Thematica, najpierw musimy wyjść z naszego katalogu ‘szkicowanik’, w którym znajduje się nasz plik style.css (stąd te dwie kropki, kłania się lekcja DOSu; ale chyba nikomu czytającemu ten tekst nie muszę tego tłumaczyć).

Kolejne importujące linijki:

@import url('../thematic/library/styles/typography.css');

Plik powyższy zawiera definicje czcionek.

@import url('../thematic/library/layouts/2c-r-fixed.css');

O tym pliku już było wyżej. To nasz dwukolumnowy layout.

@import url('../thematic/library/styles/images.css');

Plik dba o prawidłowe wyświetlanie się obrazków wstawionych do tekstu wpisu.

@import url('../thematic/library/styles/default.css');

Mało wyjaśniająca nazwa, więc wyjaśnię sam: w pliku tym mamy informacje o schemacie kolorystycznym naszej strony (czyli taki szaro-czarno-biały).

@import url('../thematic/library/styles/plugins.css');

I to plik z kilkoma definicjami stylów dla elementów HTML tworzonych najczęściej przez pluginy (np w widgetach).

I to tyle. Po dodaniu tych kilku linijek nasz temat potomny Szkicownik wygląda identycznie jak Thematic. Nic więc jeszcze tak naprawdę nie osignąlieśmy. Przygotowaliśmy jedynie szkielet tak aby w następnych krokach móc zacząć go modyfikować.

Ale o tym w kolejnych wpisach.

Obecna skórka na moim blogu – Paper – nie ma jeszcze roku, a już postanęowiłem ją zmienić. Już jakiś czas temu dostrzegłem to, co wyście dostrzegli już dawno, mianowicie, że najładniejsza ona nie jest Opatrzyła mi się.

Próbowałem od kilku miesięcy zrobić coś innego, projektowałem kilka skórek, kilka nawet pociąłem wstępnie ale nawał pracy nie pozwolił mi ich skończyć. Skórkę jednak chcę zmienić; wpadłem zatem na inny pomysł.

Postanowiłem, że zainstaluję sobie czystego Thematica i będę go dzień po dniu, po kawałeczku w wolnych chwilach rozwijał. Thematic bowiem jest tak zwaną „skórką frameworkiem” – daje po zainstalowaniu bardzo prosty wygląd, ale dzięki tematom potomnym można go dowolnie przerabiać – do tego właśnie został stworzony.

Zatem – jeśli nikt z Was  mnie nie powstrzyma – za kilka dni usunę obecną skórkę, zastąpi ją coś co będzie zwykłym czarnym tekstem na białym tle i będzie na Waszych oczach rozwijać się w kierunku jakiegoś designu. Jakiego  - jeszcze nie wiem, będzie to podróż w nieznane i ciekawi mnie co z tego może wyjść

Co Wy na to? Naprawdę bardzo proszę o wyrażenie swojego zdania w komentarzach o takim pomyśle. Jeśli wszyscy się skrzynką, że ta skórka ma zostać – zostawię. Z drugiej strony – choć bardzo chcę zrobić ten eksperyment – trochę mi brakuje odwagi, więc także słowa wsparcia są bardzo mile widziane

Wczoraj zapytałem o to samo na flakerze robiąc tam ankietę. 91% osób powiedziało, że to bardzo dobry pomysł, 9% że skórkę powinienem zmienić, ale na jakąś ostateczną, a calutkie 0 (zero) osób stwierdziło, że obecna skórka im się podoba To jednak Wy jesteście czytelnikami tego bloga, więc chcę wysłuchać Waszej opinii

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