Kiedy mówię ludziom, że żyję ze zleceń z WordPressa, spotykam się zwykle z dwoma rodzajami reakcji. Pierwsza to zdziwienie, że tak w ogóle się da. Drugi rodzaj reakcji to zalanie pytaniami, bazujące na założeniu, że moja praca polega na robieniu stron z wykorzystaniem WordPressa. Takich od A do Z. I że muszę na tym nieźle zarabiać, bo przecież dzisiaj każdy chce zaistnieć w internecie.
Prawda jest jednak inna. Rzeczywiście projekty tworzone od podstaw są najciekawsze, dają najwięcej satysfakcji, jednak mało kogo na nie stać. W końcu zrobienie większej witryny „od zera” to kilkadziesiąt godzin pracy doświadczonego grafika, drugie tyle zabierze przełożenie tego na WordPressa. Na tego typu zlecenia pozwalają sobie raczej duże firmy i takich zleceń wpada kilka w roku.
Wśród „codziennych” zapytań od klientów więcej jest tak zwanej drobnicy: różnego rodzaju dostosowania gotowych motywów do wymagań klienta, dodanie jakiejś funkcjonalności, i – co ostatnio wpada do mnie coraz częściej – załatanie błędów. Kiedyś nie lubiłam tych ostatnich, potrafiłam odmówić ich realizacji jeszcze przed wgryzieniem się w problem. Ostatnio jednak kilka takich przyjęłam. I doszłam do zadziwiających mnie samą wniosków.
Na pogotowiu WordPressa można zarobić. I to całkiem dobrze w porównaniu z poświęconym czasem.
Czym się charakteryzują takie zlecenia:
- Są konkretne, dotyczą specyficznego problemu.
- Zleceniodawca jest zdesperowany i zmęczony bezowocnym szukaniem przyczyny błędu. Co oznacza naszą przewagę negocjacyjną. „Zapłacę. Byle tylko działało Pani Agnieszko”.
- Stanowią zamkniętą całość. Jak już naprawimy problem, temat zostaje zamknięty, w przeciwieństwie do oddania nowo tworzonej strony, gdzie błędy wychodzą dopiero w trakcie jej „życia”.
W dzisiejszym wpisie postanowiłam przeprowadzić case study trzech wybranych zleceń.
Zlecenie nr 1 – strona wyświetla tylko nagłówek
Problem
Dzwoni klient i mówi, że w dwóch jego witrynach wystąpił nagle ten sam problem. Na wszystkich podstronach pokazywany jest tylko nagłówek, mimo że do tej pory wszystko działało poprawnie.
Analiza problemu
Krok 1. Od czego zacząć analizę?
Proszę o namiar na stronę i dostęp do serwera ftp. Odpalam stronę w przeglądarce, włączam podgląd źródła i widzę, że strona faktycznie urywa się mniej więcej w miejscu, gdzie kończy się header. Dalej jest tylko nicość.
Zwykle za wygenerowanie części nagłówkowej w WordPressie odpowiada plik header.php motywu. Wchodzę więc do jego źródła, w polu „szukaj” edytora wpisuję frazę pozwalającą mi namierzyć ostatni widoczny na stronie fragment. Fraza zostaje znaleziona, a zaraz za nią widać bardzo dziwny fragment kodu. Atak, myślę sobie, bo wiem, że normalny kod tak nie wygląda.
<?php @error_reporting(0); if (!isset($eva1fYlbakBcVSir)) ... = $eva1tYlbakBcVSir;} ?>
Krok 2. Więc jednak atak…
Wrzucam powyższy fragment kodu w google’a. W odpowiedzi dostaję dziesiątki stron potwierdzających moje przypuszczenie. Obecność tego rodzaju kodu na stronie jest wynikiem infekcji. Wykorzystano lukę w programie timthumb.php, dostarczanym wraz z niektórymi motywami WordPressa i wtyczkami.
Usuwam feralny fragment, strona natychmiast wstaje do życia. Podejrzanego kodu szukam jeszcze w innych plikach danej witryny. Ostatecznie okazuje się, że zainfekowanych zostało kilkanaście źródeł php. Czyszczę wszystkie.
Krok 3. Jak zabezpieczyć się na przyszłość
Witryna wprawdzie wróciła do życia, ale skoro dziura jest, atak w każdej chwili może się powtórzyć. Problem został usunięty w którymś z kolejnych releasów programu timthumb. Trzeba zatem zrobić jego aktualizację.
Tutaj pomocna okazuje się gotowa wtyczka do WordPressa Timthumb Vulnerability Scanner. Skanuje ona katalog wp-content WordPressa w celu znalezienie niechlubnej wersji timthumb’a i daje możliwość wykonania jej aktualizacji do wersji bezpiecznej. Więcej o tej wtyczce przeczytasz na blogu u Oli.
Krok 4. Jak wycenić usługę?
No właśnie. Znalezienie problemu i usunięcie przyczyny błędu zajęło mi jakąś godzinkę. Średnia stawka godzinowa programisty WordPressa to podobno 60zł – zobacz wyniki ankiety, którą Konrad prezentował na WordCampie. Na tym samym WordCampie nauczyłam się innej ważnej rzeczy (tu oczko leci do Wojtka. Chociaż nie wiem, czy Wojtek je zauważy, bo on podobno tego bloga nie czyta, tylko skanuje):
Sprzedajesz wiedzę, nie czas.
Wyceniam usługę na 300zł netto. Klientowi sporządzam raport z przeprowadzonej akcji. Zadowolony jest i klient i ja.
Zlecenie nr 2 – newsy z feeda RSS nie odświeżają się
Problem
Klient ma dwa, powiązane ze sobą portale. Pierwszy informacyjny, drugi ogłoszeniowy, na którym zarabia. Żeby ściągnąć ruch na portal zarobkowy, na portalu informacyjnym (który oglądany jest częściej) wyświetlane są ostatnio dodane ogłoszenia z portalu ogłoszeniowego. W tym celu wykorzystywany jest feed RSS. Portal ogłoszeniowy udostępnia nowe wpisy w postaci feed’a RSS, a portal informacyjny korzysta z widgetu RSS, żeby je odczytać i automatycznie wyświetlać.
Na czym polega problem: mimo dodawania nowych ogłoszeń, nie zostają one wyświetlone w portalu informacyjnym. Co dziwniejsze, nie ma tu reguły. Klient twierdzi, że czasami nowe ogłoszenia się pojawiają, czasami nie.
Analiza problemu
Krok 1. Od czego zacząć analizę?
Dodaję nowe ogłoszenie, sprawdzam, czy pojawia się ono w feedzie RSS (w tym celu zwykle wystarczy do adresu bloga dodać końcówkę /feed np. dla tego bloga będzie to https://webfaces.pl/blog/feed/)
Tak. Podgląd źródła XML feeda portalu ogłoszeniowego przekonuje mnie, że nowe ogłoszenie trafiło do niego.
Krok 2. Zatem problem jest po stronie odbiorcy
Wchodzę na portal informacyjny. Upewniam się, że strona jest świeżo wygenerowana, żeby mieć pewność, że problem nie leży w cache’owaniu prezentowanego contentu. Okazuje się, że świeżutka, nie zcache’owana (jak to się pisze?) strona nadal nie widzi najnowszych wpisów pochodzących z feeda RSS.
Krok 3. Klucz tkwi w zadaniu odpowiedniego pytania
No to idę po radę do google’a. Tylko jak nazwać problem? Czyli jakie słowa kluczowe wpisać w wyszukiwarkę. Wiem, że używam widgetu RSS, problem polega na braku odświeżania. Decyduję się więc na taką oto frazę:
wordpress rss feed not refreshing
Kilka pierwszych wyników w SERP’ach okazuje się ścieżką donikąd. Niektórzy sugerują konflikty z wtyczkami. Podchodzę do tego sceptycznie, ale próbuję. Wyłączenie wszystkich wtyczek nie rozwiązuje problemu. Szukam dalej. W końcu wpadam na wpis o zachęcająco brzmiącym tytule Change WordPress RSS Widget refresh interval – jest coś o interwale odświeżania. Autor pisze, że domyślny czas odświeżania się widgetu RSS to 12 godzin. No to jesteśmy w domu!
Wystarczy go zmienić za pomocą prostego filtru dodanego do pliku funcions.php:
add_filter( 'wp_feed_cache_transient_lifetime', create_function('$a', 'return 900;') );
Czas podawany jest w sekundach. Powyższy przykład wymusi zatem odświeżanie treści odczytywanych przez WordPressowy widget RSS co 15 minut. No to nie musimy już czekać pół doby. I wyjaśniło się, dlaczego czasami ogłoszenia się pojawiały. One pojawiały się zawsze, niekiedy przypadkiem udało nam się wstrzelić w pobliże momentu odświeżenia.
Zlecenie nr 3 – a miało być tak pięknie
Problem
Klient zakupił profesjonalny szablon na ThemeForest. Wcześniej obejrzał jego wersję demo, która zapowiadała się naprawdę obiecująco. Po aktywacji motywu na swoim serwerze przychodzi rozczarowanie. To nie tak miało wyglądać. Strona raczej w ogóle nie wygląda (przykłady niżej). Klient zdaje sobie wprawdzie sprawę, że witryna nabierze wigoru po wypełnieniu zdjęciami i treścią, pozostaje jednak pytanie: jak to zrobić?
Po kilku godzinach prób przebicia się przez short code’y, znalezienia i zrozumienia dokumentacji technicznej, klient poddaje się, zwracając do mnie i zalewając morzem pytań z serii jak uzyskać ten efekt? „Pani Agnieszko, może zrobi Pani jakiś przykład, ja już potem polecę analogicznie. Zapłacę.”.
Porównanie wyglądu motywu typu premium widocznego w stronie demo (rys. 1) i po instalacji u klienta (rys. 2)
Analiza problemu
Krok 1. Jak podejść do problemu?
Rozwiązanie jest dużo prostsze niż można by przypuszczać. Motywy premium zakupione na stockach typu Theme Forest zwykle dostarczane są w pakiecie, w którym znajdziemy tzw. Sample Data. Czyli dane przykładowe, przygotowane przez autora motywu z myślą o jego wstępnym wypełnieniu. Najczęściej ich wykorzystanie da nam efekt identyczny jak ten, który widzimy na stronie demo.
Okazuje się, że mało kto z kupujących o tym wie. A jeśli nawet wie, to już wielką zagadką pozostaje, jak dane te wykorzystać.
Krok 2. A więc Sample Data, tylko co dalej?
Przykładowe dane, którymi szybko zasilimy naszą witrynę znajdują się w pliku z rozszerzeniem xml (dostarczonym w pakiecie motywu premium). Plik ten zwykle nazywa się nazwaMotywu.wordpress.sample.xml lub nazwaMotywu.wordpress.2012-04-19.xml.
Pierwszych kilka linijek źródła tego pliku zawiera instrukcję, w jaki sposób można zaczytać go do WordPressa. Sposób postępowania jest zawsze ten sam.
Jak wypełnić WordPressa przykładowymi danymi
- Zaloguj się do panelu WordPressa jako admin.
- Z menu po lewej wybierz Narzędzia, następnie Import.
- W tabelce kliknij ostatnią pozycję z hasłem WordPress: Zainstaluj importer z WordPressa, aby zaimportować wpisy, strony… .
- Zainstaluj Importera.
- Załaduj plik xml (znajdziesz go wśród plików pakietu zakupionego motywu premium).
- WordPress poprosi o wskazanie autora wpisów, a następnie zaimportuje dane przygotowane przez autora motywu.
Krok 3. Ucz się na przykładach
Analizując przykładowe dane szybko zrozumiesz specyfikę działania danego motywu.
Prawda że tego typu zlecenia mogą być ciekawą odskocznią od monotonii codziennej pracy? Już nie jeżę się na tego typu zapytania. A jeśli przy okazji okaże się, że prezentacja tego rodzaju studium przypadków na blogu zostanie dobrze przyjęta przez czytelników, będę mieć dodatkową motywację, żeby chętniej podejmować takie wyzwania i dzielić się zdobytą wiedzą. Nawet wówczas, gdy na początku nie mam zielonego pojęcia, jak ugryźć problem i jakie frazy w google wpisać. Bo przecież każdy problem już ktoś wcześniej miał, kwestia tylko jak znaleźć w necie jego rozwiązanie…
