Prędzej czy później przyjdzie taki czas, że będziemy musieli porzucić stary hosting, na którym trzymamy swój blog WordPress'a. O ile samo przeniesienie całego kontentu nie powinno sprawić trudności, bo to przecież zwykłe kopiowanie plików, to zmiana struktury strony, np. katalogu głównego lub też nazwy bloga (domeny), pociąga już za sobą pewne komplikacje. W tych bardziej zaawansowanych przypadkach, zwłaszcza jeśli posiadamy niestandardową konfigurację, będzie potrzebna edycja niektórych plików WordPress'a oraz trzeba będzie zmienić szereg wpisów w bazie danych. W tym artykule zostanie opisany proces przenoszenia instalacji WordPress'a na nowy serwer wliczając w to zmianę nazwy serwisu.

Przy umieszczaniu zdjęć czy też różnego rodzaju grafik na blogu, możemy zauważyć, że owe fotki nie są umieszczane w postach w oryginalnych rozmiarach. Zamiast nich są używane miniaturki, które mają konfigurowalny rozmiar. Naturalnie możemy nakazać WordPressowi by umieszczał obrazki w pełnym ich wymiarze, choć jednak ze względów estetycznych lepiej zachować określone ich rozmiary i jeśli jakaś grafika wychodzi po za nie, to powinna zostać przycięta. Taka miniaturka powinna linkować do obrazka pełnowymiarowego, gdzie można zobaczyć więcej szczegółów. Taki jest przynajmniej schemat tego działania w WordPressie. Problem jest jednak z jakością samych miniaturek.

Ciasteczka w WordPresie są bardzo ważne, bo wykorzystuje się je w procesie uwierzytelniania logujących się i powracających użytkowników. Domyślnie czas ważności generowanych ciasteczek to 2 dni, chyba, że człowiek zaznaczy opcję "Pamiętaj" w formularzu logowania, wtedy ten okres ważności ulega przedłużeniu do 14 dni. Chodzi o to, że w przypadku gdyby ciasteczka nie posiadały terminu ważności, to jeśli ktoś by wszedł w ich posiadanie, to mógłby się zalogować w serwisie bez większych problemów, a tego przecież nie chcemy. Są jednak sytuacje, w których 2 czy nawet 14 dni, to ździebko za mało (lub za dużo) i w tym wpisie postaramy się dostosować żywotność ciasteczek, tak by odpowiadała naszym upodobaniom.

Jest kilka rzeczy, które mogą zdradzić dane logowania do serwisu WordPressa. Nie będę tutaj opisywał tej najbardziej oczywistej, czyli posługiwania się loginem bezpośrednio na blogu, tylko skupię się na nieco bardziej chytrej opcji, która zakłada odpytywanie formularza logowania w celu ustalenia, które loginy są dostępne w bazie danych. To tak jak grać w statki i strzelać na oślep, aż w końcu się trafi w któryś z nich, a skąd wiemy, że trafiliśmy? Po zwracanej odpowiedzi od drugiego gracza. I podobnie jest w przypadku formularza logowania WordPressa, z tym, że jeśli chodzi o strony www, to mamy nieco zawężone pole strzału, bo administrator/użytkownik zwykle wybiera niezbyt skomplikowany login często kojarzący się z pewnymi elementami jego życia, a gdy potencjalny atakujący ustali taki login, to będzie w stanie dokonać ataku Brute Force na hasło do tego konta.

Mając już zainstalowanego i wstępnie skonfigurowanego WordPress'a, przydałoby się zadbać prawa dostępu do jego plików jak i również ograniczyć nieco dostęp do samej bazy danych, tak by możliwie najmniejsze uprawnienia zostały nadane, co poprawi znacznie bezpieczeństwo naszej witryny. Jeśli opanowaliśmy już operowanie na instalacji WordPress'a przy pomocy skryptu wp-cli , to możemy bez wahania dokręcić śrubę naszemu serwisowi. Jeśli nie zaznajomiliśmy się jeszcze z powyższym narzędziem, to ograniczenie praw może spowodować problemy z aktualizacją rdzennych plików WordPress'a, jak i instalacją/konfiguracją jego pluginów czy motywów.

WordPress stara się dbać o bezpieczeństwo swoich użytkowników najlepiej jak potrafi. Dowodem na to mogą być unikalne klucze i sole uwierzytelniające (Authentication Unique Keys and Salts) wprowadzone w wersji 2.5 oraz nieco rozbudowane w wersji 2.7. Ten mechanizm nie wykorzystuje sesji PHP do śledzenia np. statusu zalogowania, tylko zaprzęga do tego celu ciasteczka, by utrudnić (albo raczej uniemożliwić) potencjalnemu atakującemu dostęp do witryny. Bez tych kluczy i soli jesteśmy w stanie przewidzieć wszystkie składowe hasha danego ciasteczka, dlatego też powinniśmy pokusić się o ich implementację na swojej stronie. Niemniej jednak, na necie jest bardzo dużo niskiej jakości informacji na temat działania mechanizmu walidacji ciasteczek, a artykuły, które potrafią go opisać w szerszym stopniu, są już lekko nieaktualne, bo zmienia się on praktycznie z każdą nową wersją WordPressa. Zanim jednak przejdziemy do samych kluczy/soli, powinniśmy się zaznajomić ze sposobem w jaki WordPress generuje i sprawdza wspomniane ciasteczka, na podstawie których to autoryzowane są działania użytkowników naszego bloga.

Począwszy od wersji 4.2, WordPress wstawia pliki powiązane z Emoji bezpośrednio do nagłówka strony. Jest to porcja 1600 znaków, która ma służyć zamianie tekstowych emotikonek na ich graficzne odpowiedniki. Jeśli z nich nie korzystamy albo wolimy zamiast nich kilka znaków tekstowych, to ten kod jest dla nas kompletnie zbędny i zaśmieca tylko nagłówek, wobec czego powinniśmy się jak najszybciej pozbyć tego balastu.

Jeśli publikujemy posty na swoim blogu, to pierw musimy je gdzieś sporządzić. Możemy to robić w zwykłym notatniku lub też bezpośrednio w formularzu WordPressa dostępnego przy edycji postu. Istnieje też inna możliwość, mianowicie korzystanie ze specjalnie przeznaczonego do tego celu oprogramowania -- klientów blogowych działających w oparciu o protokół XML-RPC. Jest to mechanizm podobny tego znanego choćby z poczty internetowej, czyli mamy konto email, np. na gmailu ale do tworzenia i zarządzania wiadomościami wykorzystujemy np. Thunderbirda. Podobnie możemy postępować z treścią pojawiającą się na blogu i nawet nie musimy być w tym czasie online. Jednym z bardziej znanych klientów, przy pomocy którego możemy wrzucać posty na bloga, to Windows Live Writer (WLW). Poza tym, protokół XML-RPC wykorzystywany jest także przez część serwisów internetowych, np. Flickr , co umożliwia im zamieszczanie postów w naszej witrynie.

W chwili gdy zabierałem się za rozpracowywanie szeregu zagadnień związanych z oczyszczaniem nagłówka generowanego przez WordPress, nie miałem pojęcia, że niektóre opcje nie są dostępne w standardowej instalacji, którą każdy może sobie pobrać z ich strony i wgrać do siebie na serwer. Chodzi oczywiście o krótkie odnośniki (shortlinks). Ich głównym celem jest skracanie linków do paru znaków, tak by można je umieścić np. na Twitterze gdzie długość wiadomości jest znacznie ograniczona i raczej wklejanie tam linku, który by zjadł wszystkie dostępne znaki nie jest zbytnio pożądane.

Na necie widziałem wiele tutoriali na temat zmiany konfiguracji stylów czy motywów WordPressa i w większości z nich ludzie dokonywali poprawek w kodzie źródłowym bezpośrednio przez panel administracyjny. Ni to wygodne, ani bezpieczne. Prze wszystkim, jeśli jakiś robak uzyskałby dostęp do konta administracyjnego naszego bloga, to pierwsze co mu przyjdzie do głowy, to edycja plików właśnie za pomocą wbudowanego w WordPress edytora (Appearance => Editor). Dlatego ze względów bezpieczeństwa kluczowe jest wyłączenie tej opcji i jeśli potrzebujemy zmieniać określone pliki WordPressa, to róbmy to poza samym skryptem i najlepiej przy pomocy zwykłego notatnika co potrafi kolorować składnię, by uniknąć również ewentualnych literówek.