Każdy, kto próbował znaleźć w oficjalnym repozytorium wtyczkę oferującą jakąś konkretną funkcję, wie jak trudne i czasochłonne jest to zadanie. Najpierw trzeba znaleźć rozszerzenia, które teoretycznie mogą nam pasować, a potem przetestować je i sprawdzić, czy naprawdę spełniają nasze wymagania i działają tak jak trzeba.

Projekt Addendio ma na celu ułatwienie nam tego zadania. Pozwala on na stworzenie za pomocą kilku kliknięć działającej instalacji WordPressa, na której możemy testować wtyczki i motywy. Co więcej, w ten sposób możemy również bawić się testowymi wersjami samego WordPressa (w tej chwili dostępna jest na przykład beta wersji 4.4).

Dodatkowo strona projektu oferuje dość rozbudowaną wyszukiwarkę rozszerzeń i motywów, która (co ciekawe) dostępna jest również w formie bezpłatnej wtyczki.

Nasza testowa strona jest tworzona na serwerach Addendio, a cały proces jest bardzo szybki – już po kilkudziesięciu sekundach możemy zalogować się do panelu administracyjnego i robić tam co tylko nam się żywnie podoba. Możemy nawet instalować motywy i wtyczki nie znajdujące się w oficjalnym repozytorium. Jedynym ograniczeniem jest czas życia takiej testowej instalacji, który wynosi 60 minut – po upływie tego czasu całość jest usuwana z serwera.

Aby utworzyć naszą własną testową instancję WordPressa wystarczy wybrać z menu serwisu opcję WP Sandbox, a następnie wpisać adres e-mail (zostaną na niego wysłane dane do logowania) i wybrać wersję WordPressa oraz jego wersję językową. Kliknięcie przycisku Lanuch Sandbox Now! uruchomi proces instalacji, który w moim przypadku trwał mniej niż minutę.

Osobiście projekt ten traktuję raczej jako ciekawostkę, niż naprawdę przydatne narzędzie, aczkolwiek mam świadomość, że istnieje grupa osób, której może się on spodobać. Co ciekawe, usługa pozwala również na instalację starszych wersji WordPressa – na liście znajduje się nawet pierwsza publiczna wersja 0.7, ale niestety nie udało mi się jej uruchomić.

Wpis Addendio – testuj wtyczki i motywy bez instalowania WordPressa pochodzi z bloga WPzen.

Na pewno każdy, kto stworzył już co najmniej kilka stron na WordPressie, musiał zmierzyć się z tym problemem: strona na lokalnym lub testowym serwerze działała dobrze, a po udostępnieniu jej szerszej publiczności okazała się po prostu wolna. Jeśli najprostsze metody na poprawę wydajności nie zdały egzaminu, a zastosowanie cache również nie do końca pomaga (cache musi się w końcu raz na jakiś czas odbudować), to pora na znalezienie elementu strony, który odpowiada za nasze problemy z wydajnością. Oczywiście najlepiej jest wykonać takie rozeznanie jeszcze na etapie budowy serwisu, ale nie zawsze da się to zrobić (na przykład gdy nie dysponujemy taką ilością danych, jaka będzie znajdować się w finalnej wersji strony).

Narzędzi, które mogą pomóc w poszukiwaniu przyczyn problemu, jest sporo, ale jednym z moich ulubionych jest darmowa wtyczka Query Monitor, która szczegółowo pokazuje co dzieje się „pod maską” naszego serwisu.

Query Monitor służy nie tylko do identyfikacji problemów związanych z wydajnością, ale osobiście wykorzystuję ją głównie właśnie do tego celu i na tym skupię się w dalszej części wpisu. Jak łatwo zauważyć, zwracam uwagę głównie na zapytania do bazy danych, a to dlatego, że w znacznej większości przypadków to właśnie one są przyczyną wolnego działania strony.

Po instalacji i aktywacji wtyczki na górnym pasku narzędzi pojawi się dodatkowa sekcja, która zawiera cztery tajemniczo wyglądające ciągi znaków (widoczne u góry zamieszczonego obok zrzutu ekranu). Pierwszy z nich pokazuje całkowity czas generowania strony, wyrażony w sekundach. Drugi to maksymalna ilość pamięci, jaką nasz WordPress zarezerwował w trakcie generowania strony. Trzeci pokazuje sumaryczny czas wykonania wszystkich zapytań do bazy danych, a czwarty to liczba tych zapytań.

W tym momencie nasuwa się pytanie: jakie wartości tych parametrów powinny budzić niepokój, a jakie są całkowicie normalne? Na to pytanie nie ma niestety prostej i jednoznacznej odpowiedzi, bo wszystko zależy od wielu czynników. Jedno zapytanie SQL potrafi przy odpowiednio dużym ruchu „dobić” serwer. Z drugiej strony, kilkadziesiąt szybkich zapytań może nie sprawiać żadnego problemu.

Zasady typu „100 zapytań na stronę to maksimum” są zdecydowanie zbyt daleko idącym uproszczeniem sprawy, aczkolwiek nie twierdzę, że są całkowicie pozbawione sensu.

Na szczęście Query Monitor podaje bardzo dużo dodatkowych informacji, które mogą pomóc nam w zlokalizowaniu tych elementów naszej strony, które są przyczyną problemów z wydajnością serwisu.

Widoczna na zamieszczonym powyżej obrazku lista sekcji może nieco przytłaczać, ale nas tak naprawdę interesuje tylko kilka znajdujących się na niej pozycji.

Jedną z najważniejszych jest sekcja Slow Queries. Zawiera ona informacje o wykonujących się zbyt długo (czyli powyżej 0,05 sekundy) zapytaniach.

W kolumnie Component znajdziemy informację o komponencie, który wykonał dane zapytanie. Core to sam WordPress, Parent Theme to motyw główny, a Child Theme to motyw potomny. Na liście znajdują się również wtyczki, dzięki czemu bardzo łatwo możemy zidentyfikować (i w razie potrzeby wyłączyć) problematyczne rozszerzenie.

Kłopot pojawia się, gdy problematyczne zapytanie znajduje się w komponencie Core. Taki właśnie przypadek widać na zamieszczonym wyżej zrzucie ekranu. Jak nietrudno zauważyć, wolne (bo wykonujące się ponad 0,1 sekundy) zapytanie pobiera wszystkie rekordy z tabeli wp_options. Niestety, nie jesteśmy w stanie z tym wiele zrobić, ponieważ tabela ta zawiera wszystkie ustawienia WordPressa, wtyczek i motywów.

Muszę jednak uczciwie przyznać, że ten przykład jest nietypowy. W kolumnie Affected Rows widać liczbę zwróconych przez zapytanie rekordów, która wynosi 1497 – żadna normalna strona nie ma tylu danych w tabeli wp_options. To, co widać na obrazku, to dane z mojej testowej instalacji WordPressa, przez którą przewinęło się kilkaset wtyczek i kilkadziesiąt motywów.

Jeśli jednak jakimś cudem trafimy na taki przypadek, to jedynym wyjściem jest odchudzenie tabeli wp_options przez usunięcie z niej zbędnych rekordów, co nie jest niestety prostym zadaniem.

Warto dodać, że na wolne zapytania SQL w WordPressie możemy trafić jeszcze w kilku sytuacjach, na przykład przy wpisach posiadających bardzo dużą liczbę komentarzy lub przy pobieraniu wpisów według skomplikowanych warunków.

Zobaczmy więc trochę bardziej życiowy przykład, w którym dzięki Query Monitor uzyskamy przydatne informacje i bez większego trudu będziemy w stanie wyeliminować przyczynę problemów z wydajnością naszej strony.

Na powyższym zrzucie ekranu widzimy drugą bardzo przydatną sekcję wtyczki – Queries by Component. Zawiera ona liczbę zapytań (z podziałem na ich rodzaj – SELECT, INSERT, DELETE, UPDATE, SHOW) wraz z łącznym czasem ich wykonania. Są to po prostu zsumowane dane z sekcji Queries, pogrupowane według komponentu. Jak widać na przykładzie, wtyczka Widget Visibility wykonała ponad 100 zapytań SQL, które łącznie trwały prawie 0,13 sekundy. Pozornie to nie dużo, ale pamiętajmy, że to tylko jeden z elementów strony, na dodatek wcale nie największy ani najważniejszy.

Warto zauważyć, że wtyczka ta nie pojawiła się w sekcji Slow Queries, ponieważ żadne z ponad stu wykonanych przez nią zapytań nie trwało dłużej, niż 0,05 sekundy. Sumarycznie jednak to właśnie ona zajęła bazie danych najwięcej czasu.

Wiemy już co obciąża naszą stronę – pora więc na rozwiązanie problemu. Z grubsza rzecz ujmując, mamy trzy wyjścia. Możemy po prostu wyłączyć problematyczną wtyczkę i (jeśli to konieczne) poszukać dla niej zamiennika. Możemy zastosować mechanizm cache, który w sporej części przypadków (ale nie zawsze) załatwi sprawę. Możemy również spróbować poprawić wtyczkę, co jednak wymaga wiedzy technicznej i nie zawsze jest możliwe (czasem jedynym wyjściem jest napisanie jej od nowa).

W niektórych (nie oszukujmy się – nielicznych) przypadkach możemy nieco poprawić wydajność zapytań SQL poprzez zrobienie porządków w bazie danych. Mniejsza ilość danych w połączeniu z przebudowaniem indeksów po usunięciu zbędnych rekordów z bazy nie zdziała wprawdzie cudów, ale na pewno nie zaszkodzi. Do takiego sprzątania można skorzystać z wtyczek WP-Sweep lub WP-Optimize – pierwszą z nich opisywałem już na WPzen.

Na marginesie dodam, że wspomniana wtyczka Widget Visibility w specyficznych przypadkach potrafi wykonać na jednej podstronie nawet kilkaset zapytań do bazy danych, które w sumie mogą trwać nawet kilka sekund i skutecznie obciążyć nasz serwer. Zdecydowanie odradzam korzystanie z tej wtyczki.

Query Monitor posiada jeszcze jedną interesującą z punktu widzenia szybkości działania strony sekcję – HTTP Requests. Pokazuje ona wszystkie wykonane żądania HTTP, najczęściej związane z komunikacją z zewnętrznymi usługami.

Na przykładzie widać żądanie wykonane przez wbudowany w WordPressa mechanizm automatycznych aktualizacji. Sekcja ta pokaże nam również wszystkie żądania wysyłane przez używane przez nas wtyczki i motyw. I tu czasami pojawiają się problemy. Autorzy rozszerzeń (dotyczy to praktycznie tylko produktów spoza oficjalnego repozytorium) często implementują własne mechanizmy aktualizacji lub pobierania danych z zewnętrznych źródeł (na przykład listy fontów z Google Fonts czy wpisów z serwisów społecznościowych). Mechanizmy te mogą działać nieprawidłowo, a usługi, z którymi się łączą, mogą być chwilowo lub całkowicie niedostępne. W obu przypadkach może się zdarzyć, że zanim strona się załaduje będziemy musieli poczekać na zakończenie takiego żądania – a to (zależnie od wartości parametru timeout) może trwać od kilku do kilkudziesięciu sekund. Takie problematyczne żądanie pojawi się w sekcji HTTP Requests wraz z informacją o pliku i numerze linii, w której zostało ono zainicjowane – dzięki temu możemy łatwo je odnaleźć i poprawić lub usunąć (albo po prostu przekazać odpowiednią informację autorowi).

Warto dodać, że sekcja HTTP Requests zawiera tylko żądania wykonane za pomocą HTTP API.

Zdaję sobie sprawę, że wpis ten może pozostawiać lekki niedosyt: pokazałem jak znaleźć przyczynę problemów, ale nie pokazałem jak ją usunąć. Rzecz w tym, że nie ma uniwersalnej metody i do każdego przypadku trzeba podejść indywidualnie. Jeśli problemem jest konkretna wtyczka (a dzięki Query Monitor już wiecie jak ją zidentyfikować), to trzeba się jej po prostu pozbyć – nie wiadomo jakie jeszcze niespodzianki przed nami kryje, a ta metoda rozwiązania problemu jest najszybsza i najskuteczniejsza. Gdy jednak za naszymi problemami z wydajnością stoi sam WordPress, to będziemy potrzebować wiedzy i doświadczenia, aby znaleźć odpowiednie rozwiązanie.

Wpis Query Monitor – sprawdź co spowalnia twoją stronę pochodzi z bloga WPzen.

WordPress 4.4 wprowadził funkcję pozwalającą na łatwe osadzanie wpisów w zewnętrznych serwisach za pośrednictwem oEmbed. Wystarczy wkleić w edytorze link do wpisu, a po publikacji zostanie on zamieniony na ramkę z fragmentem treści, linkiem do źródła oraz liczbą komentarzy. Nie zawsze jednak chcemy, aby zewnętrzne serwisy osadzały w ten sposób nasze wpisy. Na szczęście wspomnianą funkcję bardzo łatwo wyłączyć.

Najprostszą metodą na zablokowanie osadzania wpisów z naszej strony jest użycie wtyczki Disable Embeds. Wystarczy ją zainstalować i aktywować – żadna konfiguracja nie jest wymagana.

Trzeba pamiętać, że wtyczka wyłącza całkowicie mechanizm osadzania wpisów, w związku z czym my również nie będziemy mogli osadzać treści z zewnętrznych serwisów w naszych wpisach. Można jednak obejść to ograniczenie – wystarczy ze znajdującego się w katalogu wtyczki pliku disable-embeds.php usunąć tę linię:

remove_action( 'wp_head', 'wp_oembed_add_host_js' );

Oczywiście nie polecam modyfikowania w ten sposób wtyczek, ponieważ nasze zmiany zostaną nadpisane przy kolejnej automatycznej aktualizacji rozszerzenia. Nic nie stoi jednak na przeszkodzie, aby stworzyć na bazie tej wtyczki własną i w niej dokonać odpowiednich modyfikacji.

Wpis Jak wyłączyć osadzanie wpisów z naszej strony pochodzi z bloga WPzen.

Nową stronę tworzymy zwykle na własnym komputerze lub na jakimś serwerze testowym. Gdy uznamy, że prace dobiegły końca, musimy przenieść cały serwis na docelowy serwer. WordPress nie posiada sensownego mechanizmu, który ułatwiałby taką operację. Wbudowany system eksportu danych nie nadaje się do przenoszenia całych serwisów – nie uwzględnia on bowiem ustawień strony, szablonu, wtyczek, menu i widgetów. Operację przenoszenia WordPressa na inny serwer można wykonać ręcznie, kopiując wszystkie pliki i bazę danych, a następnie modyfikując adresy URL, ale ponieważ zawsze staram się opisywać rozwiązania najprostsze, to zrobimy to za pomocą darmowej wtyczki Duplicator.

Aktualizacja – 18.01.2016: wpis został dostosowany do aktualnej wersji wtyczki (1.1.0).

Duplicator to narzędzie, które czyni cały proces przenoszenia zbudowanej na WordPressie strony pomiędzy serwerami tak prostym, że nie jestem w stanie wyobrazić sobie, jak można byłoby zrobić to jeszcze łatwiej. Rozszerzenie to można również wykorzystać do klonowanie serwisów lub wykonywania kopii bezpieczeństwa.

Po aktywacji wtyczki w menu panelu administracyjnego pojawi się nowe menu Duplicator. Znajduje się w niej sześć sekcji. Główna i najważniejsza to Packages, gdzie dzieje się cała magia. Settings zawiera ustawienia wtyczki. Tools to kilka narzędzi, które mogą pomóc w znalezieniu przyczyn ewentualnych błędów oraz generujące dane diagnostyczne, które w razie problemów należy przesłać autorowi wtyczki. Sekcja Help zawiera odnośniki do dokumentacji, a About – informacje o autorze.

Duplicator pozwala na utworzenie paczki instalacyjnej (plik ZIP), która zawiera wszystkie pliki naszej strony (włącznie z plikami WordPressa) i specjalnego instalatora (skrypt PHP), za pomocą którego automatycznie odtworzymy cały serwis znajdujący się w paczce na drugim serwerze. Instalator ten wykonuje również wszystkie operacje niezbędne do prawidłowego działania strony w nowym miejscu, takie jak zmiana informacji o bazie danych (login, hasło i nazwa) czy zmiana domeny we wszystkich adresach URL (zarówno tych znajdujących się we wpisach, jak i przechowywanych w konfiguracji WordPressa, wtyczek i szablonu).

Konfiguracja wtyczki

Zacznijmy od przejrzenia ustawień wtyczki. Znajdziemy je w menu Settings. Strona ustawień jest podzielona na dwie sekcje.

Sekcja Plugin zawiera kilka ustawień samej wtyczki. Poza numerem jej wersji znajdziemy tutaj opcje pozwalające na automatyczne usunięcie podczas dezinstalacji ustawień wtyczki i katalogu, w którym przechowywane są utworzone paczki. Poznamy także pełną ścieżkę katalogu, do którego zapisywane są wszystkie pliki. Opcja Disable .htaccess File In Storage Directory usuwa plik htaccess z katalogu, do którego wtyczka zapisuje pliki. Opcję tę należy włączyć tylko gdy napotkamy na problemy z pobieraniem utworzonych plików.

Sekcja Package zawiera kilka opcji związanych z procesem tworzenia paczek. Opcja Attempt Network Keep Alive pomaga w przypadku problemów z tworzeniem dużych archiwów. Opcja Database Build określa metodę tworzenia zrzutu bazy danych, z jakiej korzysta wtyczka. W większości przypadków sprawdzi się opcje Use PHP. Opcja Query Limit Size pozwala na określenie liczby rekordów zapisywanych w jednym zapytaniu SQL. Im wyższa wartość, tym szybciej zostanie wykonany zrzut bazy danych, ale zużycie pamięci będzie większe. Metoda Use mysqldump korzysta z narzędzia mysqldump, jest szybsza i powinna być włączana dla dużych baz danych. Może się jednak zdarzyć, że na niektórych serwerach współdzielonych nie będzie ona działać. Jeśli nie wiemy, z której metody skorzystać, zostańmy przy ustawieniach domyślnych.

Ostatnia opcja Package Debug pozwala na włączenie wyświetlania dodatkowych informacji technicznych na liście wygenerowanych paczek. Przydać się to może w przypadku problemów z wygenerowaniem paczki.

Tworzenie paczki instalacyjnej

W zakładce Packages znajdziemy przycisk Create New, który pozwala na utworzenie nowej paczki instalacyjnej. Po jego kliknięciu pojawi się strona z ustawieniami procesu generowania plików, podzielona na kilka sekcji.

W sekcji Requirements znajdziemy informacje na temat wymagań wtyczki odnośnie naszego serwera. Wymagania te nie są zbyt wygórowane i na większości serwerów nie będzie z nimi problemów. Zielone komunikaty Pass oznaczają, że dane wymaganie jest spełnione. Wtyczka sprawdza, czy posiadamy odpowiednią wersję PHP (wymagana jest wersja 5.2.9 lub nowsza), czy mamy zainstalowane moduły ZipArchive i MySQLi (jeśli ich nie ma, należy skontaktować się z administratorem serwera), czy dostępne są wymagane przez wtyczkę funkcje PHP oraz czy tryb Safe Mode jest wyłączony. Sprawdzane są również uprawnienia zapisu do katalogów, w których wtyczka tworzy swoje pliki, wersja bazy danych MySQL (5.0 lub nowsza), a także obecność pozostałości po nieudanych procesach tworzenia paczki instalacyjnej (Reserved Files).

W kolejnej sekcji możemy wprowadzić nazwę naszej nowej paczki instalacyjnej (pole Name), a także opcjonalnie dodać do niej opis (przycisk Notes). Sekcja Storage wyświetla informację o katalogu, do którego zostanie zapisana paczka. W płatnej wersji Pro mamy możliwość przesłania wygenerowanych plików do wybranej chmury (Dropbox, Google Drive lub Amazon S3), a także na dowolny serwer za pośrednictwem FTP.

Sekcja Archive zawiera dwie zakładki. W pierwszej z nich (Files) możemy wprowadzić katalogi (Directories), które nie zostaną dołączone do paczki instalacyjnej. Warto dodać tu katalog cache (o ile taki posiadamy). Jeśli na przykład tworzymy kopie bezpieczeństwa, które są zapisywane również na naszym serwerze, to warto wykluczyć katalog, do którego one trafiają. Możemy także wykluczyć pliki o konkretnych rozszerzeniach (File extensions), które nie mają trafić do paczki. Można tu na przykład wprowadzić rozszerzenie tmp, a w niektórych przypadkach dobrym pomysłem będzie wykluczenie wszelkiego rodzaju archiwów (pliki zip, rar, tag.gz i tym podobne). Należy jednak uważać, aby nie wykluczyć czegoś istotnego.

W zakładce Database możemy wykluczyć tabele bazy danych. Opcja ta będzie przydatna w sytuacji, gdy w jednej bazie mamy dane kilku serwisów.

Sekcja Installer pozwala na wprowadzenie danych serwera docelowego, na którym mamy zamiar zainstalować naszą paczkę instalacyjną. Jeśli pozostawimy wszystkie pola puste, instalator pozwoli nam na wprowadzenie wymaganych informacji w momencie instalacji.

W części MySQL Server wprowadzamy dane serwera baz danych – host, port (zwykle domyślny będzie OK), nazwę bazy danych i nazwę użytkownika. Warto zwrócić uwagę, że nie ma pola do wprowadzenia hasła – będziemy musieli podać je podczas instalacji.

W części Advanced Options znajdziemy opcje Enforce on Admin i Enforce on Login, które dotyczą tylko stron z cetyfikatem SSL. Pozwalają one na wymuszenie dostępu do panelu administracyjnego i ekranu logowania przez połączenie szyfrowane (https). Domyślnie Duplicator wyłącza wsparcie dla SSL. Opcje związane z cache (Keep Enabled i Keep Home Path) pozwalają na zachowanie ustawień cache (domyślnie cache jest wyłączany).

W polu New URL możemy podać adres URL, jaki ma mieć serwis po zainstalowaniu. Instalator automatycznie zamieni w całej bazie danych stary (aktualny) adres na nowy.

Po wprowadzeniu wszystkich informacji możemy przejść dalej klikając przycisk Next.

Następnym krokiem jest skanowanie naszego serwisu. Na tym etapie nie jest jeszcze tworzona paczka instalacyjna – wtyczka zbiera jedynie informacje o plikach i bazie danych. Proces ten może trwać od kilku do kilkudziesięciu sekund – zależy do od ilości plików, wielkości bazy danych i wydajności serwera.

Po zakończeniu skanowania zobaczymy ekran podsumowania, podzielony na dwie sekcje.

Pierwsza sekcja zawiera wynik diagnostyki serwera, ustawień PHP i WordPressa. Wtyczka obsługuje praktycznie wszystkie najpopularniejsze serwery, tak więc nie powinno tu być żadnych problemów. Jedynym problemem, który może pojawić się podczas diagnostyki konfiguracji PHP, jest zbyt krótki maksymalny czas wykonywania skryptów. Jeśli otrzymamy taki komunikat, a nasza firma hostingowa nie będzie chciała zwiększyć tego limitu, to jedynym wyjściem będzie wykluczenie większych katalogów, tak aby generacja paczki trwała krócej. Diagostyka WordPressa sprowadza się do sprawdzenia jego wersji (wtyczka wymaga wersji 3.7 lub nowszej), pliku wp-config.php oraz katalogu cache (który warto wykluczyć).

Sekcja Archive zawiera wyniki skanowania plików naszej strony oraz bazy danych. Jak widać na zamieszczonym wyżej zrzucie ekranu, najczęstszym problemem są ostrzeżenia związane ze zbyt dużym rozmiarem plików lub bazy. W tym konkretnym przypadku występuje też problem z nazwami niektórych plików (Name Checks), które zawierają niedozwolone znaki. Szczegółowe informacje dotyczące tych ostrzeżeń możemy zobaczyć klikając linki ze strzałką.

Jeśli przejrzeliśmy wszystkie ostrzeżenia i chcemy kontynuować proces generowania paczki instalacyjnej, należy zaznaczyć opcję A warning status was detected, are you sure you want to continue? i kliknąć przycisk Build.

Proces tworzenia paczki instalacyjnej może chwilę potrwać. Wtyczka zrzuca zawartość bazy danych, tworzy skompresowane archiwum wszystkich plików i generuje skrypt instalatora. W trakcie generacji paczki nie wolno zamykać okna przeglądarki.

Po zakończeniu procesu pojawi się strona informująca, że wszystko poszło dobrze, wraz z nazwą paczki, czasem jej tworzenia oraz linkami do pobrania instalatora (Installer) i paczki instalacyjnej (Archive). Nowa paczka pojawi się również na liście dostępnych paczek (sekcja Packages). Lista ta zawiera między innymi informacje o czasie wykonania i rozmiarze paczki, a także o wersji wtyczki, jaką była wykonana. Klikając link View uzyskamy dostęp do pliku ze zrzutem bazy danych (nie będzie nam on potrzebny, ale dobrze wiedzieć, że tam jest) oraz logu procesu generowania paczki (może się przydać do rozwiązywania ewentualnych problemów).

Po prawej stronie znajdują się przyciski Installer i Archive, za pomocą których możemy pobrać na dysk odpowiednio instalatora i paczkę instalacyjną. Warto zwrócić uwagę, że nazwa paczki zawiera tajemniczo wyglądającym ciągiem znaków – jest tam on dlatego, aby nikt nieuprawniony nie był w stanie odgadnąć nazwy pliku paczki i pobrać go z naszego serwera.

Instalacja paczki na serwerze

Po pobraniu instalatora i paczki musimy przesłać oba pliki na docelowy serwer. Cały serwis zostanie zainstalowany w katalogu, w którym umieścimy pliki. Miejsce, do którego powinniśmy przesłać pliki, zależy od naszego serwera – najczęściej będzie to katalog public_html, ale nasza domena może być przypisana do innego katalogu. Jeśli mamy wątpliwości gdzie powinien zostać zainstalowany WordPress, skontaktujmy się z firmą hostingową utrzymującą nasz serwer.

Po przesłaniu plików musimy otworzyć skrypt instalatora w przeglądarce. Aby to zrobić musimy wpisać adres naszej docelowej strony, dodając do niego installer.php, na przykład http://nowa-domena.pl/installer.php. Jeśli wszystko poszło dobrze, powinniśmy zobaczyć stronę z pierwszym krokiem instalacji.

W pierwszym kroku możemy sprawdzić, czy serwer, na którym chcemy zainstalować naszą paczkę, spełnia minimalne wymagania skryptu (sekcja Requirements) oraz uzupełnić dane bazy danych. W polu Host należy wpisać nazwę serwera baz danych (w większości przypadków będzie to localhost), w polu User – nazwę użytkownika bazy danych, w polu Password – hasło, a polu Name – nazwę naszej bazy danych.

Instalator wymaga pustej bazy danych, tak więc jeśli w naszej coś już jest, możemy wybrać opcję Connect and Remove All Data, która usunie wszystkie tabele ze wskazanej bazy. Alternatywnie możemy wybrać opcję Create New Database, która utworzy nową bazę danych (o ile taka jeszcze nie istnieje, a wprowadzony użytkownik bazy danych ma do tego uprawnienia). Klikając przycisk Test Connection możemy sprawdzić poprawność wpisanych danych.

W sekcji Advanced Options możemy wybrać dodatkowe opcje instalacji. Opcja Manual package extraction spowoduje, że instalator załaduje tylko dane do bazy danych i nie rozpakuje archiwum z plikami. Ta opcja może być przydatna gdy z jakiegoś powodu (na przykład zbyt dużego pliku) automatyczne rozpakowanie archiwum nie powiedzie się. Opcja Fix non-breaking space characters powoduje zamianę problematycznych znaków UTF8 na spacje. Z tej opcji można skorzystać tylko jeśli po imporcie widzimy w treści wpisów dziwne znaczki lub znaki zapytania. Pozostałe opcje zostały omówione przy okazji tworzenia paczki instalacyjnej.

Jeśli nasz serwer spełnia wymagania skryptu, a test połączenia z bazą danych zakończył się pomyślnie, możemy zaznaczyć opcję I have read all warnings & notices i rozpocząć automatyczne rozpakowanie paczki i import danych do bazy klikając przycisk Run Deployment.

Po zakończeniu instalacji paczki zostaniemy przeniesieni do kroku drugiego, który wykona zamianę starych adresów URL i ścieżek na nowe. Jest to konieczne, ponieważ w ustawieniach WordPressa oraz treści naszych wpisów mogą się znajdować pełne adresy, wraz z nazwą domeny z poprzedniego serwera. Musimy więc zamienić stary adres serwisu na nowy.

W sekcji Old Settings znajdują się stary adres strony oraz ścieżka katalogu, w którym był zainstalowany WordPress. W sekcji New Settings znajdują się analogiczne dane dla nowego serwera. W większości przypadków pola te będą już wypełnione, więc musimy się tylko upewnić, że wszystkie informacje są poprawne.

W sekcji New Admin Account możemy utworzyć nowe konto administratora. Jeśli konto, które próbujemy stworzyć, już istnieje, to nie zostanie ono nadpisane ani usunięte.

Przejdźmy do sekcji ustawień zaawansowanych (Advanced settings). Na liście Scan Tables znajdują się wszystkie zaimportowane do bazy danych tabele. Jeśli mamy pewność, że któreś z nich nie zawierają adresów URL serwisu (na przykład tabele, które nie mają nic wspólnego z naszą stroną), to możemy je wykluczyć ze skanowania.

Lista Activate Plugins zawiera listę wtyczek znajdujących się w paczce instalacyjnej. Domyślnie wszystkie te rozszerzenia zostaną aktywowane, ale możemy aktywować tylko wybrane z nich.

Opcja Enable Full Search włącza pełne skanowanie tabel w bazie danych. Domyślnie instalator skanuje i modyfikuje ścieżki i adresy URL tylko w polach typu tekstowego (co w znacznej większości przypadków jest wystarczające). Pełne skanowanie powoduje, że pod uwagę brane są również pola innych typów, co znacznie spowalnia cały proces.

Na koniec została nam opcja Keep Post GUID unchanged?. GUID to unikalny identyfikator wpisu, który ogólnie rzecz biorąc nie powinien się nigdy zmienić. Opcję tę należy włączyć tylko wtedy, gdy przenosimy stronę na inny serwer bez zmiany jej adresu URL.

Kliknięcie przycisku Run Update spowoduje zaktualizowanie bazy danych naszego serwisu i zakończenie procesu instalacji paczki.

Ostatni, trzeci krok instalacji zawiera listę kilku czynności, które musimy wykonać ręcznie. Przede wszystkim należy usunąć pliki instalatora (installer.php, installer-data.sql,installer-log.txt,installer-backup.php) i paczkę instalacyjną z serwera. Możemy to zrobić automatycznie, za pomocą narzędzia Cleanup (zostaniemy do niego przeniesieni po kliknięciu linku Security Cleanup). Następnie należy zaktualizować ustawienia linków – aby to zrobić wystarczy w panelu administracyjnym WordPressa przejść do sekcji Ustawienia → Bezpośrednie odnośniki i kliknąć przycisk Zapisz zmiany. Oczywiście nie wolno zapomnieć o przetestowaniu naszej strony, szczególnie pod kątem poprawności linków. Warto też zapoznać się z raportem z instalacji (link Review Install Report), który poza ogólnymi informacjami na temat ilości zaimportowanych i zmodyfikowanych danych, zawiera również informacje o błędach i ostrzeżeniach, jakie wystąpiły podczas instalacji paczki.

Wpis Przenoszenie strony na inny serwer pochodzi z bloga WPzen.

Strony WWW są nieustannie atakowane przez boty, które próbują wykorzystać luki w popularnych skryptach używanych do budowy witryn internetowych. Jednym z najpopularniejszych celów takich ataków jest WordPress, głównie przez swoją popularność, ale również przez sporą liczbę dostępnych wtyczek i motywów, z których niektóre są niestety pełne błędów.

Istnieje mnóstwo narzędzi i wtyczek służących do zabezpieczania stron opartych na WordPressie przed tego rodzaju atakami. Zawsze jednak warto rozglądać się za dodatkowymi lub lepszymi od aktualnie używanych sposobami na powstrzymywanie złośliwych skryptów. Jednym z wartych uwagi narzędzi jest 6G Firewall.

Jak działa 6G Firewall?

6G Firewall to tak naprawdę zestaw reguł dla serwera Apache, które filtrują przychodzące żądania i blokują te, które wyglądają podejrzanie. Jak sama nazwa wskazuje, jest to już szósta wersja zestawu, który jest rozwijany od ponad trzech lat i bazuje na doświadczeniach autora oraz uwagach użytkowników.

Reguły blokują większość żądań związanych z atakami wykorzystującymi luki w skryptach, a także różnego rodzaju boty, które skanują serwisy internetowe, a których możemy nie chcieć wpuszczać na naszą stronę (bo nie są nam do niczego potrzebne). Nawet jeśli nasz serwis jest bezpieczny (używane przez nas wtyczki i motyw nie mają żadnych luk związanych z bezpieczeństwem), to złośliwe skrypty mogą generować duży ruch, przez co niepotrzebnie obciążają nasz serwer, co w najgorszym przypadku może prowadzić do spowolnienia działania naszej strony. 6G Firewall blokuje takie żądania na poziomie serwera Apache, co oznacza, że do ich obsługi w ogóle nie są angażowane interpreter PHP i baza danych.

6G Firewall nie jest w żaden sposób związany z WordPressem, przez co sprawdzi się również w przypadku witryn korzystających z innych CMSów lub zbudowanych z wykorzystaniem autorskiego oprogramowania.

Czego nie robi 6G Firewall?

6G Firewall nie jest uniwersalną receptą na wszystkie problemy związane z bezpieczeństwem. Nie zabezpiecza nas na przykład przed atakami typu brute force skierowanymi na pliki wp-login.php czy xmlrpc.php – tutaj wciąż konieczne będzie zastosowanie innych rozwiązań, na przykład opisanych przeze mnie w tym wpisie. Jest on jednak świetnym uzupełnieniem wszelkiego rodzaju wtyczek zabezpieczających WordPressa, takich jak iThemes Security czy Wordfence, którym odbierze trochę pracy i odciąży nieco serwer.

Jak zainstalować 6G Firewall?

Wystarczy na samym początku pliku .htaccess (znajduje się on w katalogu głównym naszej strony) dodać kod znajdujący się w sekcji 6G Firewall na tej stronie. Nie wklejam tutaj tego kodu, ponieważ autor co jakiś czas go modyfikuje i wprowadza w nim kolejne ulepszenia, przez co najlepiej korzystać z wersji znajdującej się na oficjalnej stronie.

Oczywiście korzystanie z 6G Firewall jest całkowicie darmowe.

Wtyczka BBQ: Block Bad Queries

Jeśli z jakiegoś powodu nie możemy zmodyfikować naszego pliku .htaccess, to alternatywą może być wtyczka BBQ: Block Bad Queries, która zawiera w sobie część filtrów wchodzących w skład w 6G Firewall. Nie działa ona jednak na poziomie serwera Apache, ale na poziomie interpretera PHP, tak więc nie spowoduje aż tak znaczącego spadku obciążenia serwera. O ile to możliwe, sugeruję korzystać z oryginalnego rozwiązania, czyli zestawu reguł wklejonego do pliku .htaccess.

Wtyczka nie wymaga żadnej konfiguracji – wystarczy ją zainstalować i aktywować.

Wpis 6G Firewall – prosty sposób na zabezpieczenie strony przed atakami pochodzi z bloga WPzen.

Google PageSpeed Insights to narzędzie, które dla wielu osób jest (często jedynym słusznym) wyznacznikiem jakości i szybkości działania strony internetowej. Nie jest to do końca prawda, ale faktem jest, że przedstawiany na stupunktowej skali wynik daje obraz tego, jak szybka jest nasza strona i co można zrobić, aby była szybsza.

Maksymalny wynik 100 punktów w teście PageSpeed Insights to marzenie niejednego właściciela serwisu internetowego. I mimo że jest to tylko „sztuka dla sztuki”, to w tym wpisie na konkretnym przykładzie pokażę, jak można taki wynik osiągnąć.

Wynik testu PageSpeed Insights zależy od bardzo wielu czynników, z których większość omawiam w tym wpisie. Nie gwarantuję jednak, że wykonanie wszystkich opisanych tu czynności odniesie dokładnie taki sam skutek w każdym przypadku i będzie wystarczające do uzyskania podobnego wyniku.

Czym jest PageSpeed Insights?

PageSpeed Insights to stworzone przez firmę Google narzędzie do mierzenia wydajności stron internetowych. Bada ono każdą stronę dwukrotnie: pod kątem urządzeń mobilnych (mobile) i pod kątem „zwykłych” komputerów (desktop). Wynik obu tych testów jest przedstawiany na 100-punktowej skali – im wyższy wynik, tym lepiej.

Badanie wydajności jest wykonywane za pomocą zestawu specjalnych reguł. Niektóre z nich są ważniejsze od innych, przez co ich spełnienie daje naszej stronie więcej punktów. Mimo że wspomniane reguły są dość dobrze opisane w dokumentacji narzędzia, to nie wszyscy wiedzą co należy zrobić, aby daną regułę spełnić.

Raport, jaki otrzymujemy wraz z liczbowym wynikiem testu, pokazuje reguły, które są przestrzegane na naszej stronie oraz listę problemów, które na niej występują (nieprzestrzegane reguły). Czerwonym wykrzyknikiem oznaczono najistotniejsze problemy, których usunięcie może mieć duży wpływ na szybkość naszej strony (a więc i na wynik testu). Żółty wykrzyknik oznacza problemy, które warto usunąć – nie spodziewajmy się po nich wielkiego skoku wyniku testu, ale jeśli chcemy wycisnąć komplet punktów, to i nimi powinniśmy się zająć.

Warto dodać, że PageSpeed Insights nie bierze pod uwagę aspektów działania strony, które są zależne od wydajności sieci, głównie dlatego, że praktycznie nigdy nie jest ona stała. Brane są natomiast pod uwagę takie czynniki, jak konfiguracja i wydajność serwera, na którym działa nasza strona, struktura kodu HTML oraz sposób, w jaki strona korzysta z zasobów zewnętrznych, takich jak pliki graficzne, skrypty JavaScript czy arkusze stylów CSS.

Więcej informacji na temat PageSpeed Insights znaleźć można w oficjalnej dokumentacji.

Jaki wynik PageSpeed Insights jest dobry?

Stronę można uznać za działającą dobrze, gdy w obu testach osiągnie co najmniej 85 punktów. Wbrew pozorom nie jest to wynik trudny do osiągnięcia. Test dla urządzeń mobilnych jest nieco bardziej wymagający, tak więc zwykle to właśnie w nim ciężej jest osiągnąć dobry wynik.

Przygotowanie strony testowej

Ponieważ wpis ten chciałem oprzeć na konkretnym przykładzie, stworzyłem (oczywiście korzystając z WordPressa) stronę testową pagespeed.wpzen.pl, na której wykonywałem wszystkie modyfikacje. Można więc samemu sprawdzić, czy rzeczywiście osiąga ona wynik 100 punktów w obu testach (dla urządzeń mobilnych i komputerów).

Jeśli wynik będzie niższy niż 100 punktów, to prawdopodobnie wystąpił problem z czasem odpowiedzi serwera (tak to niestety na tym serwerze bywa). W takim przypadku wystarczy odczekać 30 sekund i wykonać test ponownie.

Testy wykonywałem tylko dla strony głównej serwisu. Większość z wykonanych przeze mnie działań będzie miała oczywiście pozytywny wpływ również na podstrony, ale może się zdarzyć, że optymalizacja poszczególnych typów podstron będzie wymagać dodatkowych zabiegów. Kilka zdań na ten temat napisałem w podsumowaniu, które znajduje się na końcu wpisu.

Prace zacząłem od instalacji najnowszej wersji WordPressa (w chwili pisania tego wpisu była nią wersja 4.4.2) i na aktywowaniu najnowszej wersji aktualnego domyślnego motywu Twenty Sixteen. Aby strona nie była pusta, zaimportowałem oficjalne dane testowe wraz z obrazkami – nie są one idealne, ale lepszych w tej chwili chyba nie ma.

Pora na pierwszy test narzędziem PageSpeed Insights. Wynik zaskoczył mnie nieco – pozytywnie, bo wcale nie był taki zły. 71 punktów w teście dla urządzeń mobilnych i 83 punkty w teście dla komputerów.

Oczywiście nikt nie kończy w tym miejscu budowy swojej strony – zawsze instalowane są dodatkowe wtyczki, które często dokładają własne skrypty JavaScript i arkusze stylów CSS, a czasem także kod HTML. Zainstalowałem więc następujące rozszerzenia:

• Yoast SEO – popularna wtyczka wspomagająca optymalizację stron pod kątem SEO
• Google Analytics by Yoast – wtyczka ułatwiająca instalację i konfigurację kodów śledzących dla Google Analytics
• Contact Form 7 – rozszerzenie pozwalające na tworzenie formularzy; stworzyłem jeden formularz, który umieściłem w panelu bocznym
• WP Retina – wtyczka dodająca obsługę ekranów Retina do zdjęć wstawianych do wpisów
• Jetpack – znany kombajn z wieloma modułami (aktywowane najpopularniejsze moduły: Carousel, Custom CSS, Enhanced Distribution, Extra Sidebar Widgets, Omnisearch, Protect, Publicize, Related Posts, Sharing, Tiled Galleries i Widget Visibility)

Do pierwszego wpisu wstawiłem dodatkowo film z serwisu YouTube w taki sposób, aby był widoczny na stronie głównej mojego testowego serwisu. Za chwilę wyjaśnię dlaczego to zrobiłem.

Jak widać, wynik znacznie się pogorszył – 58 punktów w wersji mobilnej i 74 punkty w wersji desktopowej. To już jest coś, nad czym można pracować. Stwierdziłem, że taki stan strony jest wystarczający i uznałem go za punkt wyjściowy do optymalizacji pod kątem uzyskania jak najlepszego wyniku w teście PageSpeed Insights.

Optymalizacja strony

Po wykonaniu testu PageSpeed Insights należy odczekać 30 sekund przed wykonaniem kolejnego.

Skróć czas odpowiedzi serwera

Na pierwszy ogień wybrałem regułę, która jest stosunkowo łatwa do spełnienia – najczęściej wystarczy skorzystać z wtyczki cache. Ja (jak praktycznie zawsze) wybrałem WP Super Cache i skonfigurowałem ją zgodnie z własnym poradnikiem. Zgodnie z moimi oczekiwaniami, reguła została spełniona i zniknęła z listy „Warto poprawić”, ale wynik poprawił się o zaledwie jeden punkt.

Wykorzystaj pamięć podręczną przeglądarki

Ta reguła oznaczona jest jako bardzo ważna dla urządzeń mobilnych. Rzecz polega na ustawieniu odpowiednich nagłówków HTTP dla plików (Expires), które powinny być trzymane przez dłuższy czas w cache przeglądarki użytkownika. Niektóre wtyczki cache (np. W3 Total Cache czy Zencache) posiadają wbudowaną odpowiednią funkcję, którą wystarczy po prostu włączyć. Poza tym większość firm hostingowych domyślnie ustawia odpowiednie nagłówki, tak więc nie musimy się w ogóle o to martwić.

Najprostszą metodą na dodanie nagłówków Expires jest dodanie do pliku .htaccess następującego kodu:

<IfModule mod_expires.c>
	ExpiresActive On
	ExpiresDefault "access plus 1 month"
	ExpiresByType text/html "access plus 1 seconds"
	ExpiresByType image/gif "access plus 30 days"
	ExpiresByType image/jpeg "access plus 30 days"
	ExpiresByType image/png "access plus 30 days"
	ExpiresByType image/jpg "access plus 30 days"
	ExpiresByType image/svg+xml "access plus 30 days"
	ExpiresByType text/css "access plus 30 days"
	ExpiresByType text/javascript "access plus 30 days"
	ExpiresByType application/javascript "access plus 30 days"
	ExpiresByType application/x-javascript "access plus 30 days"
	ExpiresByType text/xml "access plus 60 minutes"
</IfModule>

Dodanie nagłówków Expires poprawiło wynik PageSpeed Insights o jeden punkt w teście dla urządzeń mobilnych i o dwa punkty w teście dla komputerów.

Jednak żeby nie było zbyt pięknie, na liście zasobów, które nie mają odpowiednich nagłówków lub mają ustawiony zbyt krótki „czas życia”, pozostało kilka pozycji:

Trzy pierwsze to pliki z serwisu Gravatar, czwarty to skrypt zarządzający reklamami w filmach z YouTube, a ostatni to znany wszystkim skrypt Google Analytics. Co możemy z tym zrobić, skoro wszystkie te pliki znajdują się na zewnętrznych serwerach i nie mamy żadnego wpływu na ich nagłówki?

Zacznijmy od Gravatara. Możemy oczywiście wyłączyć obsługę awatarów z tego serwisu, ale nie tędy droga. Najlepszym rozwiązaniem jest pobieranie awatarów na nasz serwer, dzięki czemu zostaną do nich dodane takie nagłówki, jak do wszystkich innych plików graficznych. Oczywiście nie będziemy robić tego ręcznie – z pomocą przyjdzie nam wtyczka Harrys Gravatar Cache, która automatycznie zapisze na naszym serwerze wszystkie awatary i podmieni odpowiednie adresy URL plików. Rozszerzenie ma kilka opcji (Ustawienia → Harrys Gravatar Cache Settings), ale domyślna konfiguracja powinna działać bez problemów. Jedyną opcją, którą warto się zainteresować, jest Current Copy Option, którą w razie problemów z pobieraniem awatarów warto ustawić na WordPress Filesystem.

Trick z Gravatarem poprawił wynik w teście dla urządzeń mobilnych o kolejne dwa punkty, a w teście dla komputerów o jeden punkt.

Na drugi ogień wziąłem skrypt Google Analytics. Podobnie jak w przypadku plików z serwisu Gravatar, jedyną możliwością usunięcia tego problemu, jest trzymanie skryptu analytics.js na naszym serwerze. Teoretycznie nie powinniśmy tego robić, bo Google modyfikuje go bez ostrzeżenia, ale w praktyce nie dzieje się to aż tak często. Z pomocą przyszła wtyczka Cache External Scripts, która automatycznie pobiera plik analytics.js, zapisuje go na naszym serwerze i podmienia odpowiedni adres URL w kodzie śledzenia Google Analytics. Problem rozwiązany.

Gorzej wygląda jednak kwestia skryptu ad_status.js, który jest powiązany z osadzonym na naszej stronie filmem z YouTube. Nie możemy zastosować takiego samego sposobu, co w przypadku skryptu analytics.js, ponieważ ten skrypt jest ładowany z wewnątrz ramki iframe, w której znajduje się film. Wpadłem więc na pomysł, aby skorzystać z techniki lazy loading, czyli w tym przypadku z ładowania filmu dopiero po kliknięciu w niego. Na coś takiego pozwala na przykład wtyczka Lazy Load for Videos, która obsługuje filmy z serwisów YouTube i Vimeo. I rzeczywiście – problem ze skryptem ad_status.js zniknął, ale za to… pojawił się analogiczny problem z miniaturą filmu, pobieraną z domeny ytimg.com. Teoretycznie dałoby się pobierać obrazki z tej domeny na nasz serwer i ładować nasze kopie, ale wymagałoby to dość dużych modyfikacji wtyczki. Dałem sobie więc z tym spokój i zastosowałem metodę, która od początku mi się nie podobała, ale którą jednocześnie uważałem za jedyną, która się sprawdzi – czyli przeniosłem film za znacznik <!--more-->, dzięki czemu nie jest on widoczny na stronie głównej, a dopiero na stronie wpisu. Natomiast w normalnej sytuacji po prostu zignorowałbym ten problem.

Innym sposobem na pozbycie się problemu ładowania obrazków z zewnętrznych serwerów jest skorzystanie z lazy loadingu dla obrazków, dzięki czemu ładowane będą tylko te obrazki, które są widoczne. To jednak nie załatwi problemu tych obrazków, które są umieszczone u góry strony, przez co są cały czas widoczne, ponieważ zostaną one załadowane od razu.

Tak na marginesie: używanie wspomnianej wtyczki Lazy Load for Videos jest dobrym pomysłem, bo znacząco skraca ona czas ładowania stron z osadzonymi filmami.

Zabiegi związane ze skryptami analytics.js i ad_status.js poprawiły wynik PageSpeed Insights o osiem punktów w teście dla urządzeń mobilnych i o pięć punktów w teście dla komputerów. Warto dodać, że pozbycie się filmu YouTube z widocznego po załadowaniu strony obszaru (above the fold) rozwiązało również problem z regułą Nadaj priorytet widocznej treści.

Wszystkie wykonane do tej pory prace zaowocowały podniesieniem wyniku do 70 punktów w teście dla urządzeń mobilnych i 84 punktów w teście dla komputerów.

Włącz kompresję

Kolejny łatwy do usunięcia problem i kolejne zaskoczenie, jakie mnie spotkało. Podobnie jak w przypadku nagłówków Expires, większość firm hostingowych domyślnie kompresuje pliki po stronie serwera. Jeśli jednak nasza firma tego nie robi, wystarczy do pliku .htaccess dodać kilka linii:

AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE application/x-httpd-php
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE font/otf
AddOutputFilterByType DEFLATE font/ttf

Włączamy w ten sposób kompresję plików tekstowych za pomocą modułu mod_deflate. Nie ma sensu włączać kompresji dla innych typów plików, na przykład obrazków czy filmów, bo nic nam to nie da, a tylko obciąży niepotrzebnie serwer. Jeśli nasz serwer nie ma zainstalowanego modułu mod_deflate, możemy skorzystać z kompresji gzip:

<ifModule mod_gzip.c>
	mod_gzip_on Yes
	mod_gzip_dechunk Yes
	mod_gzip_item_include file .(html?|txt|css|js|php|pl)$
	mod_gzip_item_include handler ^cgi-script$
	mod_gzip_item_include mime ^text/.*
	mod_gzip_item_include mime ^application/x-javascript.*
	mod_gzip_item_exclude mime ^image/.*
	mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
</ifModule>

I teraz wspomniane na początku zaskoczenie. Firma hostingowa, z której usług korzystam (nie napiszę jaka – zainteresowani sami sobie znajdą) ma włączoną na swoich serwera kompresję gzip dla plików tekstowych, ale nie dla plików SVG, które tak naprawdę również są plikami tekstowymi (zawierają kod XML). Problem w tym, że zarówno wybrany przeze mnie motyw (Twenty Sixteen), jak i wtyczka Jetpack, korzystają z icon fonta Genericons, który ładuje spory, bo ważący 77 kB, plik Genericons.svg. I był to jedyny powód, dla którego reguła Włącz kompresję nie była spełniona. Niestety, samodzielne włączenie kompresji przy użyciu jednego z pokazanych wyżej sposobów, okazło się niemożliwe – konfiguracja serwera na to nie pozwalała.

Po krótkiej korespondencji ze wsparciem firmy otrzymałem zapewnienie, że temat został przekazany administratorom i pliki SVG będą kompresowane. Ja jednak nie miałem czasu na czekanie, więc postanowiłem obejść jakoś ten problem.

Napisałem krótki skrypt, który otwiera plik, pobiera jego zawartość, kompresuje ją za pomocą gzip i zwraca do przeglądarki. Kod skryptu zapisałem w pliku /wp-content/compress.php:

<?php
ob_start('ob_gzhandler');
$file = isset($_REQUEST['file']) ? $_REQUEST['file'] : null;
if(!empty($file)) {
	$file = $_SERVER['DOCUMENT_ROOT'].'/'.$file;
	if(pathinfo($file, PATHINFO_EXTENSION) == 'svg' && file_exists($file) && mime_content_type($file) == 'image/svg+xml') {
		$content = file_get_contents($file);
		echo $content;
	}
}
ob_flush();

Następnie do .htaccess dodałem regułę przekierowującą do skryptu wszystkie żądania odwołujące się do plików SVG:

RewriteCond %{REQUEST_URI} \.(svg)$
RewriteRule ^(.*) "/wp-content/compress.php?file=$1" [L]

Tym sposobem reguła Włącz kompresję została spełniona, a wynik PageSpeed Insights podskoczył do 75 punktów w teście dla urządzeń mobilnych i do 88 punktów w teście dla komputerów.

Na koniec proszę: nie róbcie tego na własnych stronach. Poczekajcie na pomoc firmy hostingowej. Ten sposób działa, ale to tylko tymczasowe obejście, a nie rozwiązanie problemu. A na pewno nie próbujcie kompresować w ten sposób plików innych niż tekstowe – to łatwy sposób na obciążenie serwera, które w skrajnych przypadkach może skończyć się blokadą strony.

Zoptymalizuj obrazy

Następny łatwy do usunięcia problem. Wystarczy skorzystać z wtyczki WP Smush, która automatycznie wykona bezstratną optymalizację obrazków znajdujących się w bibliotece mediów. Warto ją zainstalować jeszcze zanim zaczniemy ładować obrazki, ponieważ wtyczka działa „w tle” i optymalizuje obrazki podczas ich przesyłania do WordPressa. Jeśli zainstalujemy ją później, będziemy musieli wykonać masową optymalizację, która jest możliwa, ale w darmowej wersji wtyczki ograniczona do 50 obrazków na raz.

Kiedyś polecałem działającą na podobnej zasadzie wtyczkę Prizm Image, ale przez pewien czas serwery, z których korzysta, działały tak niestabilnie, że byłem zmuszony przesiąść się na alternatywne rozwiązanie.

Jeśli okaże się, że po optymalizacji PageSpeed Insights wciąż wskazuje jakieś obrazki jako niezoptymalizowane, można pobrać zoptymalizowane przez Google wersje plików i przesłać je przez SFTP na nasz serwer. Aby to zrobić wystarczy kliknąć znajdujący się pod raportem z testu link Pobierz zoptymalizowane obrazy oraz zasoby JavaScript i CSS dla tej strony.

Co ciekawe, optymalizacja obrazków nie przyniosła w moim przypadku żadnej zmiany w wyniku PageSpeed Insights. Stało się tak prawdopodobnie dlatego, że zysk z optymalizacji był niewielki (7%), a na stronie znajduje się niewiele obrazków.

Zmniejsz CSS, Zmniejsz JavaScript i Zmniejsz HTML

Kolejną czynnością, którą wypada zrobić nie tylko podczas walki o każdy punkt w PageSpeed Insights, jest kompresja (minifikacja) i złączenie w jeden plik skryptów JavaScript oraz arkuszy stylów CSS, a także kompresja samego dokumentu HTML (czyli właściwego kodu naszej strony). Wtyczek, które to umożliwiają, jest sporo, ale ja wybrałem Autoptimize, ponieważ ma ona wszystkie opcje, jakich potrzebowałem. Wtyczka spełnia swoje zadanie już przy domyślnych ustawieniach, ale warto pogrzebać chwilę w jej konfiguracji (Ustawienia → Autoptimize).

Włączyłem tylko następujące opcje:

• Optymalizuj kod HTML
• Optymalizuj kod JavaScript
• Wymuś JavaScript w <head>
• Optymalizuj kod CSS
• Zapisz połączony skrypt/CSS jako plik statyczny

W moim przypadku wszystko poszło bezboleśnie, ale może się zdarzyć, że coś na stronie przestanie działać. Wtedy najczęściej wystarczy wykluczyć skrypt JavaScript, który po złączeniu z innymi przestał działać, w konfiguracji Autoptimize (opcja Skrypty wyłączone z Autoptimize).

Niektórzy polecają wykluczyć ze złączania bibliotekę jQuery, ale w tym konkretnym przypadku nie był to dobry pomysł (jQuery ładowała się później, niż plik ze złączonymi skryptami, tak więc wszystko przestawało działać). Może to być jednak konieczne, jeśli jakieś używamy wtyczek, które wstawiają własny kod JavaScript do kodu HTML strony.

Warto zwrócić uwagę, że ta kompresja (minifikacja) nie ma nic wspólnego z kompresją, którą włączaliśmy przy okazji reguły Włącz kompresję. Minifikacja polega na usunięciu z kodu strony zbędnych rzeczy, takich jak komentarze czy znaki końca linii.

Co ciekawe, ten krok nie przyniósł żadnej zmiany w wyniku PageSpeed Insights dla urządzeń mobilnych, ale za to w teście dla komputerów strona dostała kolejne trzy punkty.

Wyeliminuj blokujący renderowanie kod JavaScript i CSS z części strony widocznej na ekranie

To jedna z dwóch reguł, która sprawia najwięcej kłopotów. Przede wszystkim dlatego, że jej opis jest nieco enigmatyczny i na początku nie bardzo wiadomo co należy zrobić, aby pozbyć się tego problemu.

Na liście problematycznych (blokujących renderowanie strony) skryptów JavaScript i arkuszy stylów CSS znajdziemy pliki złączone przez Autoptimize oraz (co gorsze) fonty z Google Fonts, których używa motyw Twenty Sixteen. Niestety, aby to wszystko naprawić będziemy musieli pogrzebać trochę w kodzie. Zakładam, że korzystamy z motywu potomnego i nie dotykamy w ogóle plików motywu głównego. Wszystkie modyfikacje wrzucamy do pliku functions.php znajdującego się w katalogu motywu potomnego.

Zaczniemy od pliku ze złączonymi skryptami JavaScript. Aby przestał on blokować renderowanie strony wystarczy załadować go asynchronicznie, czyli w taki sposób, aby przeglądarka nie czekała z wyświetleniem strony na jego załadowanie. Możemy to zrobić dodając do znacznika <script> atrybut async. Oczywiście nie będziemy robili tego ręcznie w kodzie HTML, bo tak się w WordPressie po prostu nie da. Na szczęście Autoptimize oferuje filtr, za pomocą którego możemy dodać ten atrybut do znacznika ładującego plik ze złączonymi skryptami JavaScript. Robimy to w ten sposób (trzeba pamiętać o spacji po ciągu „async”):

function wpzen_defer() {
	return 'async ';
}
add_filter('autoptimize_filter_js_defer', 'wpzen_defer');

Niestety, takie asynchroniczne ładowanie skryptów JavaScript ma też swoje wady. Najczęściej problemy występują na stronach, gdzie skrypty JavaScript są niezbędne do ich działania. Często możemy też zaobserwować niezbyt dobrze wyglądające opóźnienie w inicjalizacji skryptów, które wynika z tego, że strona (kod HTML) jest już wyświetlona, a skrypty JS jeszcze się nie załadowały, więc nie zrobiły swojej roboty. Wszystko tu zależy od konkretnego przypadku, ale dobrze stworzona strona nie powinna się całkowicie od tego rozsypać.

Teraz trzeba zrobić coś z fontami Google Fonts. Ponieważ są one ładowane jako arkusze stylów CSS, nie możemy ich załadować asynchronicznie (tak jak to zrobiliśmy ze skryptami JavaScript). W ustawieniach Autoptimize możemy globalnie (dla całej strony) wyłączyć ładowanie Google Fonts – wystarczy zaznaczyć opcję Usunąć Google Fonts. Tyle że w tym momencie nasza piękna typografia przestaje być taka piękna i wszystkie teksty są wyświetlane przy użyciu domyślnych fontów. Na szczęście istnieje biblioteka Web Font Loader, która potrafi między innymi ładować fonty w sposób nie blokujący renderowania strony.

Najpierw musimy sprawdzić jakich fontów używa nasz motyw. Najprościej jest zajrzeć do narzędzi deweloperskich w przeglądarce i skopiować adres URL ładowanego z domeny fonts.googleapis.com arkusza stylów. W przypadku motywu Twenty Sixteen URL ten wygląda tak:

https://fonts.googleapis.com/css?family=Merriweather%3A400%2C700%2C900%2C400italic%2C700italic%2C900italic%7CMontserrat%3A400%2C700%7CInconsolata%3A400&subset=latin%2Clatin-ext

a po „zdekodowaniu” tak:

https://fonts.googleapis.com/css?family=Merriweather:400,700,900,400italic,700italic,900italic|Montserrat:400,700|Inconsolata:400&subset=latin,latin-ext

Teraz łatwo możemy wyciągnąć z niego nazwy i warianty fontów, które musimy samodzielnie załadować przy użyciu Web Font Loadera.

Aby skorzystać z biblioteki wystarczy do pliku functions.php wstawić taki kod:

function wpzen_load_google_fonts_script() {
	wp_enqueue_script('webfont-loader', '//ajax.googleapis.com/ajax/libs/webfont/1.5.18/webfont.js');
}
add_action('wp_enqueue_scripts', 'wpzen_load_google_fonts_script');

function wpzen_load_google_fonts_footer() {
?>
	<script type="text/javascript">
		WebFont.load({
			google: {
				families: ['Merriweather:400,700,900,400italic,700italic,900italic:latin,latin-ext',
						   'Montserrat:400,700:latin,latin-ext',
						   'Inconsolata:400:latin,latin-ext']
			}
		});
	</script>
<?php
}
add_action('wp_footer', 'wpzen_load_google_fonts_footer');

Funkcja wpzen_load_google_fonts_script() ładuje bibliotekę, a funkcja wpzen_load_google_fonts_footer() ładuje trzy wybrane przez nas fonty. Koniecznie trzeba zwrócić uwagę na format parametrów dla każdego z fontów – brak dwukropka czy przecinka spowoduje, że nic nie będzie działać. Oczywiście możemy tam sobie dodać dowolne inne fonty – biblioteka obsługuje również fonty z serwisów Typekit, Fontdeck i Fonts.com, a także własne fonty.

Na koniec powinniśmy wymusić asynchroniczne ładowanie biblioteki Web Font Loader – można to zrobić za pomocą takiej prostej funkcji:

function wpzen_async_scripts($tag, $handle, $src) {
	$async_scripts = array('webfont-loader');

	if(in_array($handle, $async_scripts)) {
		return '<script type="text/javascript" src="'.$src.'" async="async"></script>'."\n";
	}

	return $tag;
}
add_filter('script_loader_tag', 'wpzen_async_scripts', 10, 3);

Funkcja ta może nam się jeszcze kiedyś przydać, na przykład gdy dodamy do strony kolejne zewnętrzne skrypty – wtedy wystarczy do tablicy $acyns_scripts dodać kolejną nazwę.

Wadą korzystania z tego sposobu ładowania zewnętrznych fontów jest możliwość występowania zjawiska zwanego Flash of Unstyled Text (FOUT), czyli pojawienia się na krótką chwilę tekstu wyświetlanego domyślnym fontem. Efekt ten jest spowodowany tym, że strona może być wyrenderowana przez przeglądarkę jeszcze zanim fonty zostaną załadowane. Nie jest to jednak wielki problem, szczególnie że występuje tylko przy pierwszym otwarciu naszej strony przez użytkownika – przy kolejnych odsłonach pliki są pobierane z cache jego przeglądarki. Warto jednak dodać, że to zjawisko może występować również przy ładowaniu zewnętrznych fontów w „tradycyjny” sposób.

Został nam więc już tylko arkusz stylów CSS blokujący renderowanie strony. Podobnie jak w przypadku fontów, nie mamy możliwości załadowania go w sposób asynchroniczny. Teoretycznie da się to zrobić za pomocą JavaScript (np. korzystając z loadCSS), ale nie jest to zalecane dla krytycznych arkuszy stylów (a nasz taki właśnie jest – to w końcu złączone wszystkie pliki CSS). Moim pierwszym pomysłem było wykorzystanie wtyczki Autoptimize i jej opcji Także łączyć razem CSS z treści strony?, która wstawia całą zawartość plików CSS bezpośrednio do kodu HTML. Efekt na pierwszy rzut oka był pozytywny: problem zniknął z raportu PageSpeed Insights. Niestety, w jego miejsce pojawił się inny – Nadaj priorytet widocznej treści. No i oczywiście rozmiar dokumentu HTML powiększył się o mniej więcej 40 kB.

Warto jednak zauważyć, że wyniki testów poszybowały w górę (100 punktów w teście dla urządzeń mobilnych i 97 w teście dla komputerów).

W normalnych warunkach uznałbym te wyniki za świetne i nie drążył dalej tematu. Jak już wspomniałem na wstępie, wynik powyżej 85 punktów jest uznawany za dobry. Ale moim celem nie było osiągnięcie dobrego wyniku, ale 100 punktów w obu testach.

Poza tym bardzo nie podobało mi się włączenie całego arkusza stylów CSS do kodu HTML.

Nadaj priorytet widocznej treści

Ta reguła mówi nam, że powinniśmy umożliwić przeglądarce jak najszybsze wyświetenie tej części strony, która jest zaraz po załadowaniu widoczna w oknie przeglądarki (tzw. above the fold). U mnie ten problem pojawił się gdy wrzuciłem cały arkusz stylów do kodu HTML strony, a to dlatego, że kodu CSS było tam po prostu o wiele za dużo.

Priorytetyzacja widocznej treści to dość szerokie zagadnienie, związane zarówno ze strukturą kodu HTML, jak i stylów CSS. Ale na szczęście istnieje coś, co pozwala w stosunkowo łatwy sposób osiągnąć cel – a jest to Critical Path CSS. W skrócie chodzi o umieszczenie na początku nagłówka strony (w sekcji <head>) tych stylów CSS, które są potrzebne do wyświetlenia widocznego fragmentu strony (są krytyczne dla naszego serwisu). Oczywiście ręczne wyodrębnianie takich stylów byłoby dość czasochłonne, dlatego powstały do tego specjalne narzędzia. Najprostsze w obsłudze są narzędzia online: Critical Path CSS Generator i jego płatna, prostsza w obsłudze wersja – Critical CSS.

Critical Path CSS Generator wymaga od nas podania adresu naszej strony i wklejenia całej zawartości arkusza stylów CSS. Po kliknięciu przycisku Create Critical Path CSS wygenerowany zostanie kod CSS, który trzeba umieścić na naszej stronie. Można to zrobić korzystając (znowu) z wtyczki Autoptimize – w jej ustawieniach znajdziemy opcję Włączyć CSS w treść strony i opóźnić jego ładowanie?, której zaznaczenie spowoduje pojawienie się pola do wprowadzenia wygenerowanych stylów CSS. Jednocześnie główny arkusz stylów (połączenie wszystkich plików CSS) zostanie załadowany asynchronicznie za pomocą skryptu JavaScript.

Efekt? 100/100 w obu testach!

Narzędzie Critical CSS jest o tyle prostsze, że wystarczy podać mu adres naszej strony – samo pobiera sobie arkusze stylów CSS.

Trzeba pamiętać, że taki krytyczny arkusz stylów CSS może wyglądać różnie w zależności od struktury danej podstrony – prawie na pewno ten ze strony głównej nie będzie „pasował” do podstrony z treścią wpisu. Dlatego uważam, że ta zabawa to w większości przypadków tylko „sztuka dla sztuki” – korzyści są zdecydowanie zbyt małe w stosunku do nakładu pracy (szczególnie w przypadku bardziej rozbudowanych stron).

Bonus: Wygoda użytkowników

W raporcie z testu dla urządzeń mobilnych znajduje się sekcja zatytułowana Wygoda użytkowników, w której znajdziemy zalecenia dotyczące usprawnień strony pod kątem komfortu korzystania z niej na małych ekranach urządzeń mobilnych.

Najczęściej pojawiającymi się problemami są Dobierz odpowiedni rozmiar elementów dotykowych i Używaj czytelnych rozmiarów czcionek. Pierwsza reguła wymaga od nas powiększenia rozmiaru elementów dotykowych (np. linków) i zwiększenia odstępu pomiędzy nimi (wysokość linii i marginesy). Druga reguła mówi z kolei, że gdzieś zastosowaliśmy zbyt mały rozmiar tekstu. Nie ma w tym nic skomplikowanego i bardzo łatwo jest wprowadzić odpowiednie poprawki.

Oczywiście reguły z tej sekcji nie mają nic wspólnego z prędkością naszej strony.

Podsumowanie

Wynik PageSpeed Insights zależy od bardzo wielu czynników. Każda strona może wymagać innych zabiegów optymalizacyjnych, jednak część z opisanych przeze mnie działań sprawdzi się w każdym przypadku. Moim celem było pokazanie, jak można spełnić poszczególne reguły PageSpeed Insights, bo ich opisy często są niewystarczające, szczególnie dla mniej zaawansowanych użytkowników.

Jak już wcześniej napisałem, dążenie za wszelką cenę do osiągnięcia maksymalnego wyniku w teście Google PageSpeed Insights nie ma większego sensu. Niektóre z wykonanych przeze mnie zabiegów mogą spowodować problemy ze skryptami JavaScript, a inne (jak na przykład generowanie Critical Path CSS) są dość skomplikowane. Nie należy traktować wyniku PageSpeed Insights jako jedynego słusznego wyznacznika szybkości strony. To oczywiście bardzo ważny wskaźnik, ale nie zapominajmy, że poświęcony na optymalizacje czas musi się nam w jakiś sposób zwrócić i dać jakieś wymierne korzyści. Jeśli osiągnęliśmy wynik na poziomie co najmniej 85 punktów, to możemy sobie pogratulować i zająć się czymś pożyteczniejszym.

Pamiętajmy też, że PageSpeed Insights nie jest jedynym testem sprawdzającym wydajność stron internetowych – warto wspomnieć jeszcze o YSlow, Pingdom Website Speed Test, WebPageTest i GTmetrix (który korzysta m. in. z YSlow). Każde z tych narzędzi ma własny zestaw reguł weryfikujących szybkość strony, dlatego też osiągnięcie maksymalnego wyniku w jednym z nich wcale nie gwarantuje tego samego w innym.

Reguły, za pomocą których wszystkie te narzędzia weryfikują wydajność naszej strony, mają nam przede wszystkim pomóc w jak najlepszym zoptymalizowaniu naszej witryny. Sami możemy zdecydować, że dana reguła nas nie interesuje – tak jak na przykład sugerowałem przy okazji problemów z osadzonymi filmami z YouTube. Zachęcam do samodzielnych eksperymentów i do korzystania z moich porad w innej kolejności – może się okazać, że pominięcie któregoś z etapów nie odbije się w znaczący sposób na wyniku testu. Warto też sprawdzać (na przykład za pomocą jednego z alternatywnych narzędzi) czas ładowania strony i jej rozmiar – są to parametry, których PageSpeed Insights nie pokazuje wprost, a które są istotne z punktu widzenia wygody użytkowników.

Wpis Jak uzyskać 100/100 punktów w Google PageSpeed Insights pochodzi z bloga WPzen.

W ostatnim czasie nacisk na udostępnianie stron internetowych za pośrednictwem szyfrowanego protokołu HTTPS jest coraz większy. Oczywiście w przypadku witryn, na których użytkownicy wprowadzają swoje dane (loginy, hasła, dane osobowe), szyfrowanie to podstawa, ale coraz więcej „zwykłych” stron WWW również przechodzi na protokół HTTPS.

Ja również dałem się w to wciągnąć i od kilku dni WPzen jest dostępny tylko przez HTTPS. Niestety, natknąłem się przy tej okazji na chyba wszystkie możliwe problemy, o których opowiem w dalszej części wpisu.

Jakiś czas temu Google ogłosił, że strony korzystające z połączenia szyfrowanego HTTPS będą (w niewielkim stopniu, ale jednak) faworyzowane przez wyszukiwarkę – aczkolwiek ja bym tego nie traktował jako głównego argumentu za przejściem na HTTPS. Mozilla również wykonuje ruchy, które mają na celu zachęcenie właścicieli witryn internetowych do korzystania z szyfrowania. W kampanię informacyjną angażuje się coraz więcej dużych firm i organizacji zajmujących się ogólnie pojętym bezpieczeństwem w internecie – aczkolwiek część z nich ma w tym oczywiście swój interes.

Udostępnienie szyfrowanego połączenia z naszą stroną nie jest ani jakoś szczególnie skomplikowane, ani specjalnie drogie. Większość firm hostingowych już dawno wprowadziła w swoich panelach administracyjnych wygodne narzędzia do instalacji certyfikatów SSL, a koszt zakupu najtańszego certyfikatu jest niewiele wyższy od ceny dobrej kawy.

Co to jest certyfikat SSL?

Certyfikat SSL to specjalnie przygotowany zestaw informacji, który pozwala jednoznacznie stwierdzić, że serwer, z którym się łączymy, jest dokładnie tym serwerem, z którym chcemy się połączyć. Jednocześnie poświadcza on wiarygodność domeny, a także zapewnia bezpieczeństwo danych przesyłanych pomiędzy użytkownikiem (przeglądarką) a serwerem.

Certyfikaty SSL są wystawiane przez zaufane firmy, takie jak Comodo, Symantec, GeoTrust czy GlobalSign, które gwarantują ich autentyczność.

Można oczywiście używać szyfrowanego protokołu HTTPS bez posiadania certyfikatu (korzystamy z certyfikatu firmy hostingowej lub podpisujemy go sami), ale wtedy wchodząc na naszą stronę użytkownik zostanie poinformowany o niezaufanym certyfikacie.

Jaki certyfikat SSL wybrać?

Istnieje kilka rodzajów certyfikatów SSL. Do zabezpieczenia zwykłej strony internetowej wystarczy nam tak naprawdę najprostszy (i najtańszy) certyfikat Comodo PositiveSSL (lub analogiczny certyfikat innej firmy). Droższe opcje różnią się na przykład obsługą subdomen w ramach wybranej domeny, a najbardziej prestiżowe (EV – Extended Validation) wyświetlają tzw. „zielony pasek” w przeglądarce, w którym widnieje nazwa firmy będącej właścicielem domeny.

Jeśli chodzi o weryfikację danych właściciela domeny, to można wyróżnić trzy rodzaje certyfikatów SSL:

• DV (Domain Validation) – weryfikacja elektroniczna, potwierdzająca własność domeny (plik przesyłany na serwer); takie certyfikaty są wydawane w ciągu kilku minut
• OV (Organization Validation) – weryfikacja wymaga przesłania kopii dokumentów potwierdzających dane firmy, które są potem widoczne w informacjach o certyfikacie
• EV (Extended Validation) – weryfikacja wymaga przesłania bardziej szczegółowych danych dotyczących firmy, a także kopii wymaganych dokumentów w języku angielskim; czasem weryfikacja wymaga bezpośredniego kontaktu z firmą wystawiającą certyfikat

Ja na potrzeby bloga WPzen wybrałem najtańszą opcję, czyli certyfikat Comodo PositiveSSL (DV).

Gdzie kupić certyfikat SSL?

Większość stron, na których możemy kupić certyfikat SSL, są tak naprawdę tylko pośrednikami pomiędzy kupującymi a wystawcami. Osobiście polecam poszukać najkorzystniejszych finansowo ofert, a następnie spośród nich wybrać firmę cieszącą się najlepszą reputacją.

Jeśli język angielski jest dla nas problemem, powinniśmy (mimo nieco wyższych cen) rozejrzeć się za jakąś rodzimą firmą, bo w razie ewentualnych problemów (na przykład takich, jak moje) trzeba będzie się jakoś dogadać z anglojęzycznym wsparciem. Warto też zerknąć do cennika firmy hostingowej, z której usług korzystamy, bo często w pakiecie znajduje się bezpłatna instalacja certyfikatu na serwerze obsługiwanym przez tę samą firmę.

Ja wybrałem ofertę SSLs.com, marki należącej do grupy Namecheap. Certyfikat Comodo PositiveSSL kosztuje tam $8,95 za rok (około 35 złotych), ale w opcji trzyletniej zapłacimy tylko $4,99 za rok (czyli niecałe 20 złotych).

W polskich sklepach ceny certyfikatów SSL są nieco wyższe. Dwie duże polskie firmy hostingowe oferują też własne certyfikaty, które można kupić w całkiem rozsądnej cenie. Nie wiem jednak nic na ich temat, więc nie będę nawet próbował porównywać ich z certyfikatami wystawianymi przez renomowane firmy.

Jak aktywować certyfikat SSL?

Po zakupie (a u niektórych sprzedawców w trakcie zakupu) certyfikatu SSL musimy go aktywować, czyli przypisać do naszej domeny. Zakładam, że wybraliśmy certyfikat DV, czyli nie musimy przesyłać nigdzie żadnych dokumentów.

Aby dokonać aktywacji musimy przesłać firmie, od której kupiliśmy certyfikat, CSR (Certificate Signing Request), czyli żądanie podpisania certyfikatu. Wygenerowanie CSR wymaga podania kilku informacji, takich jak nazwa domeny, kontaktowy adres e-mail, imię i nazwisko lub nazwa firmy, kraj czy miejscowość. CSR można wygenerować samemu za pomocą pakietu OpenSSL, ale większość firm hostingowych udostępnia taką funkcję w panelu administracyjnym serwera.

Razem z CSR generowany jest również klucz prywatny, którego nie wolno nam zgubić – bez niego nie zainstalujemy certyfikatu na serwerze.

Po przesłaniu CSR zostaniemy poproszeni o umieszczenie na naszym serwerze specjalnego pliku weryfikacyjnego, tak aby firma wystawiająca certyfikat mogła sprawdzić, czy naprawdę jesteśmy w posiadaniu zgłaszanej domeny (a przynajmniej czy jesteśmy w stanie nią zarządzać). Po zakończeniu weryfikacji otrzymujemy w wiadomości e-mail pliki z certyfikatem.

Jeśli kupujemy certyfikat w naszej firmie hostingowej, aktywacja może sprowadzać się do podania naszych danych – reszta będzie wykonana automatycznie.

Jak zainstalować certyfikat SSL na serwerze?

Jeśli zdecydowaliśmy się na zakup certyfikatu w firmie hostingowej obsługującej nasz serwer, może się okazać, że do naszej dyspozycji jest funkcja umożliwiająca instalację certyfikatu jednym kliknięciem. Jeśli jednak taka funkcja nie jest dostępna, będziemy musieli zainstalować certyfikat „ręcznie”.

Wprowadzamy certyfikat i klucz prywatny (czasem w jednym polu, czasem w osobnych polach) oraz CA Root Certificate, czyli certyfikat identyfikujący organizację wystawiającą nasz certyfikat. Nasz certyfikat i certyfikaty CA dostaliśmy po aktywacji (wystarczy skopiować i wkleić w odpowiednie pola zawartość otrzymanych plików), a klucz prywatny wygenerowaliśmy podczas tworzenia CSR.

W przypadku cetyfikatów Comodo pliki z certyfikatami CA są trzy i nazywają się AddTrustExternalCARoot.crt, COMODORSAAddTrustCA.crt i COMODORSADomainValidationSecureServerCA.crt.

Jeśli mamy problem z instalacją certyfikatu na serwerze, zawsze możemy poprosić o pomoc firmę hostingową. Warto też zajrzeć do dokumentacji – najczęściej znajduje się w niej szczegółowa instrukcja instalacji certyfikatów SSL.

Po zainstalowaniu certyfikatu możemy sprawdzić czy wszystko zostało zrobione poprawnie – wystarczy wpisać w przeglądarce adres naszej strony z prefiksem https, na przykład https://nasza-domena.pl. Jeśli nie zobaczymy informacji o niezaufanym certyfikacie, to znaczy, że certyfikat został poprawnie zainstalowany na naszym serwerze (nie oznacza to jednak, że strona jest już dostępna przez połączenie szyfrowane).

Jak „przełączyć” naszą stronę na szyfrowane połączenie HTTPS?

Po tym nieco przydługim wstępie możemy w końcu zająć się konfiguracją naszej strony, tak aby wszyscy odwiedzający przeglądali ją korzystając z szyfrowanego połączenia. Nie jest to skomplikowane i nie powinno zająć nam więcej niż godzinę (chyba że wystąpią problemy, o których w dalszej części wpisu).

Jeśli nie chcemy robić wszystkiego samodzielnie, to możemy skorzystać z darmowej wtyczki Really Simple SSL, która większość modyfikacji wykona za nas.

Przed przystąpieniem do dalszych kroków należy wykonać kopię bezpieczeństwa.

Zmiana adresu strony w ustawieniach WordPressa

Pierwszym krokiem jest zmiana adresu naszej strony w konfiguracji WordPressa. Możemy to zrobić w panelu administracyjnym w sekcji Ustawienia → Ogólne. Nowy adres wprowadzamy w polach Adres WordPressa (URL) i Adres Witryny (URL). Po zapisaniu zmian zostaniemy wylogowani z panelu.

Jeśli zdecydowaliśmy się na użycie wtyczki Really Simple SSL, to zrobi to ona za nas.

Zmiana adresów URL w treści strony

Oczywiście we wpisach wciąż możemy mieć stare linki do naszej strony, a także (co ważniejsze) osadzone obrazki z adresami z prefiksem http, które będą powodować problemy z szyfrowaniem (wszystkie pliki na stronie muszą być pobierane również przez protokół HTTPS). W związku z tym musimy zamienić w bazie danych naszej strony wszystkie wystąpienia starej nazwy domeny na nową, z prefiksem https.

Ja zwykle robię to za pomocą tego skryptu, ale równie dobrze można skorzystać z wtyczki Better Search Replace. Wystarczy zamienić wszystkie wystąpienia ciągu http://nasza-domena.pl na https://nasza-domena.pl. Jeśli nasz serwis zawiera dużo treści, to operacja ta może chwilę potrwać.

Od tej chwili nasza strona powinna być dostępna bez problemów za pośrednictwem protokołu HTTPS – aby to sprawdzić wystarczy wpisać w przeglądarce jej adres poprzedzony https zamiast http (na przykład https://nasza-domena.pl/). Jeśli w pasku adresu przeglądarki zobaczymy informację, że strona nie jest szyfrowana, to najprawdopodobniej oznacza to, że jakieś pliki na naszej stronie są wciąż pobierane za pośrednictwem nieszyfrowanego protokołu HTTP (tzw. mixed content). Więcej na ten temat w części wpisu poświęconej najczęściej występującym problemom.

Przekierowanie użytkowników z http na https

Przez jakiś czas w wyszukiwarkach wciąż będą widniały linki do naszej strony z prefiksem http. Co więcej, na różnych stronach w Sieci na pewno znajdują się odnośniki do naszej witryny, z którymi nie jesteśmy w stanie nic zrobić. Warto więc przekierować wszystkich użytkowników wchodzących na naszą stronę na nowy adres z prefiksem https.

Aby to zrobić wystarczy do pliku .htaccess (najlepiej na samym jego początku) dodać następującą regułę:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Warto zauważyć, że jest to przekierowanie z kodem 301 (Moved Permanently), które mówi przeglądarce i robotom wyszukiwarek, że strona została na stałe przeniesiona pod wskazany adres.

Alternatywnie można skorzystać z wtyczki Really Simple SSL, która doda do naszej strony odpowiednie przekierowania.

Zmiana domyślnego adresu strony w Google Analytics

Jeśli korzystamy z Google Analytics, to nie musimy nic zmieniać w kodzie śledzącym. Warto natomiast w ustawieniach usługi (Administracja → Ustawienia usługi → Domyślny URL) zmienić domyślny adres naszej strony, a konkretnie jego prefiks.

Ponowne dodanie strony w Google Search Console

Niestety, narzędzie Google Search Console nie pozwala na zmianę adresu strony, tak więc musimy dodać naszą witrynę jeszcze raz, jako nową stronę. Trzeba pamiętać również o przesłaniu mapy strony, co powinno przyśpieszyć aktualizację adresów naszej witryny w indeksie Google.

Zmiana domeny w Disqus

Jeśli korzystamy z serwisu Disqus, to po zmianie adresu naszej strony wszystkie komentarze po prostu znikną. Dzieje się tak dlatego, że komentarze są przypisane do adresów URL wpisów, a te się zmieniły. Na szczęście Disqus udostępnia narzędzia, za pomocą których we w miarę wygodny sposób zmienimy adresy URL na nowe (z prefiksem https). Wystarczy wejść do panelu administracyjnego Disqus, przejść do zarządzania naszą stroną i na zakładce Community znaleźć opcję Migration Tools. Wbrew pozorom nie należy korzystać z Domain Migration Tool, ale z jednego z dwóch pozostałych narzędzi (URL Mapper lub Redirect Crawler).

I to właściwie wszystko, co musimy zrobić, aby nasza strona działała przez bezpieczne, szyfrowane połączenie HTTPS.

Możliwe problemy

W teorii wszystko to wygląda dość prosto, ale w praktyce różnie z tym bywa. Nie jestem oczywiście w stanie omówić wszystkich możliwych problemów, ale postaram się wspomnieć o tych najczęstszych oraz o tych, z którymi zetknąłem się podczas przełączania bloga WPzen na połączenie szyfrowane.

Mixed content

To chyba najczęściej występujący problem w witrynach udostępnianych przez połączenie szyfrowane. Występuje on gdy strona jest ładowana przez HTTPS, ale zawiera pliki (skrypty JavaScript, arkusze stylów CSS, obrazki itp.) ładowane przez HTTP. Problem ten objawia się różnie w zależności od używanej przeglądarki, ale w konsoli błędów zawsze znajdziemy infromację o zasobach, które są ładowane przez HTTP.

Problem z obrazkami znajdującymi się na naszym serwerze rozwiąże opisana wyżej zmiana adresów URL w treści wpisów. Jeśli chodzi o skrypty i arkusze stylów, to prawdopodobnie nasz motyw lub któraś z używanych przez nas wtyczek ładuje je w nieprawidłowy sposób. Najprostszym sposobem na rozwiązanie tego problemu jest skorzystanie z wtyczki Really Simple SSL, która automatycznie zamieni „w locie” http na https. Ten sposób nie zadziała jednak, gdy gdzieś w kodzie mamy „na sztywno” wprowadzone jakieś adresy URL – dotyczy to zarówno adresów prowadzących do naszej domeny, jak i do domen zewnętrznych.

Znikające polubienia (Like) z Facebooka

Facebook przypisuje polubienia do adresów URL, tak więc po zmianie adresu naszej strony znikną nam wszystkie „lajki”. Niestety, jedyne co jesteśmy w stanie z tym zrobić, to spróbować „oszukać” Facebooka zgodnie z oficjalną dokumentacją. Trick polega na przekazaniu w znaczniku og:url starego adresu URL. Jeśli do generowania znaczników OpenGraph korzystamy z wtyczki Yoast SEO, to wystarczy do pliku functions.php naszego motywu dodać taki kod:

function wpzen_og_url($url) {
	if(is_single()) {
		global $post;
		if($post->post_date < '2016-02-10') {
			$url = str_replace('https://', 'http://', $url);
		}
	}
	return $url;
}
add_filter('wpseo_opengraph_url', 'wpzen_og_url');

Widoczną w czwartej linii datę należy zmienić na datę wprowadzenia połączenia szyfrowanego (czyli zmiany adresu URL naszej strony), tak aby tylko starsze wpisy miały stary adres w znaczniku og:url, a nowe używały już adresu z prefiksem https.

Teraz korzystając z debuggera możemy sprawdzić jak Facebook widzi naszą stronę. Wszystko wygląda w porządku, poza ostrzeżeniem o przekierowaniu na nowy adres. Dlatego też wyłączymy przekierowania na nowy adres dla bota Facebooka (ale tylko dla niego!). Aby to zrobić wystarczy zmodyfikować regułę, którą wcześniej dodaliśmy do pliku .htaccess, aby wyglądała tak:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteCond %{HTTP_USER_AGENT} !facebookexternalhit/[0-9]
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

I to wszystko – nasze „lajki” powinny wrócić. Oczywiście nowe polubienia będą już przypisywane do nowych adresów URL (z prefiksem https) – po to dodaliśmy warunek na datę wprowadzenia zmian. Warto pamiętać, że polubienia nie wrócą od razu – Facebook musi odświeżyć sobie swój własnych cache, w czym możemy mu pomóc sprawdzając poszczególne wpisy w debuggerze.

Opisywany problem nie dotyczy polubień strony na Facebooku (fanpage) – tam wszystko pozostanie bez zmian.

Problemy z aktywacją certyfikatu

W moim przypadku pojawił się problem z aktywacją certyfikatu – nie było możliwe przesłanie danych z formularza, po czym mój certyfikat zmienił status na „Failed” i nie dało się już nic z nim zrobić. Konieczna była rozmowa z przemiłą panią ze wsparcia SSLs.com, która przeprosiła mnie za niedogodności i od razu zaproponowała przeprowadzenie ręcznej aktywacji i weryfikacji domeny. Po mniej więcej 10 minutach mój certyfikat był już aktywny.

Problemy z migracją adresów URL w Disqus

Jak już wspomniałem, po zmianie adresów URL wszystkie komentarze po prostu znikają i trzeba wykonać zmianę adresów URL w panelu Disqus. Ja skorzystałem (błędnie!) z narzędzia Domain Migration Tool, które zamiast zamienić http na https w adresach moich wpisów, dodało https do istniejących URLi, przez co wszystkie były nieprawidłowe. Co więcej, utworzone zostały puste wątki z poprawnymi adresami. Na szczęście łatwo dało się to „odkręcić” korzystając z narzędzia URL Mapper.

Zdjęcie: Michele M. F.

Wpis Jak (w miarę) bezboleśnie udostępnić stronę przez połączenie szyfrowane HTTPS pochodzi z bloga WPzen.

Pisząc o bezpieczeństwie serwisów opartych na WordPressie najczęściej skupiam się na zabezpieczaniu stron przed atakami z zewnątrz. Jednak równie ważne jest zadbanie o jak najlepsze zabezpieczenie samego procesu logowania, tak aby nikt niepowołany nie uzyskał dostępu do konta z uprawnieniami administratora.

Jedną ze skuteczniejszych i najpowszechniej stosowanych metod zabezpieczania procesu logowania jest uwierzytelnianie dwuskładnikowe (two-factor authentication), nazywane też dwuetapowym. Metoda ta polega na dodaniu do procesu logowania dodatkowego składnika w postaci zmieniającego się co pewien czas kodu. Kod ten może być dostarczany użytkownikowi za pomocą SMSa, poczty e-mail (podobnie jak w opisywanej przeze mnie wtyczce Paswordless) czy generowany przez dedykowaną aplikację. Dzięki temu nawet jeśli ktoś wejdzie w posiadanie naszego loginu i hasła, to i tak nie będzie w stanie zalogować się na nasze konto.

Dodanie uwierzytelniania dwuskładnikowego do WordPressa nie jest trudnym zadaniem – wykorzystamy do tego darmową wtyczkę Two Factor Authentication i aplikację Google Authenticator.

Google Authenticator to darmowa aplikacja dostępna na urządzenia mobilne z systemami iOS i Android. Służy ona do generowania kodu, który będziemy musieli wpisać przy każdym logowaniu. Co ważne, nie wymaga ona połączenia z internetem ani z siecią komórkową. Wybrałem akurat tę aplikację, ponieważ większość osób korzystających z internetu posiada konto Google i ma (a przynajmniej powinna mieć) włączoną weryfikację dwuetapową. Oczywiście można skorzystać z innej aplikacji do generowania kodów – wspomnę o nich w dalszej części wpisu.

Po instalacji i aktywacji wtyczki Two Factor Authentication w panelu administracyjnym pojawi się nowe menu Two Factor Auth, gdzie możemy skonfigurować uwierzytelnianie dwuetapowe dla naszej strony.

Przede wszystkim musimy włączyć tę funkcję, co robimy przez wybranie opcji Enabled w sekcji Activate two factor authentication. Po zapisaniu zmian przechodzimy do podłączania aplikacji Google Authenticator do naszej strony.

W sekcji Current codes znajdziemy kilka informacji, które są niezbędne do powiązania naszego konta w WordPressie z aplikacją Google Authenticator.

Aplikacja Google Authenticator pozwala na dodanie strony za pomocą kodu QR. Wystarczy wybrać opcję Zeskanuj kod paskowy i skierować aparat telefonu na wyświetlany na stronie kod. Po chwili nasza strona pojawi się na liście powiązanych kont w aplikacji.

Jeśli nie chcemy korzystać z kodu QR, możemy dodać stronę do aplikacji „ręcznie”, za pomocą klucza widocznego poniżej kodu QR. W aplikacji Google Authenticator wybieramy opcję Ręczne wpisanie, w polu Konto wprowadzamy naszą nazwę użytkownika, a w polu Klucz wprowadzamy pierwszy z widocznych na stronie kluczy (ten dłuższy).

Warto teraz sprawdzić, czy cały proces łączenia konta na stronie z aplikacją przebiegł poprawnie. Jeśli wszystko jest w porządku, jednorazowy kod widoczny na stronie (Current one-time password) powinien być taki sam, jak widoczny w aplikacji. Trzeba pamiętać, że kod ten zmienia się w czasie, tak więc jeśli kod widoczny w panelu naszej strony różni się od widocznego w aplikacji, to należy kliknąć link Update, aby go odświeżyć.

I to właściwie wszystko. Od tej pory po wprowadzeniu loginu i hasła zostaniemy dodatkowo poproszeni o wpisanie kodu wygenerowanego przez aplikację.

Warto dodać, że sekcja Two Factor Auth jest widoczna dla wszystkich roli wybranych w ustawieniach wtyczki (Ustawienia → Two Factor Authentication) – tym sposobem możemy zezwolić na konfigurację uwierzytelniania dwuskładnikowego wszystkim naszym użytkownikom.

Jeśli stracimy dostęp do urządzenia, na którym mieliśmy zainstalowaną aplikację Google Authenticator i nie mamy możliwości wygenerowania kodu, możemy wyłączyć uwierzytelnianie dwuskładnikowe dodając do pliku wp-config.php następującą linię:

define('TWO_FACTOR_DISABLE', true);

Alternatywne rozwiązania

Jeśli nie chcemy korzystać z aplikacji Google, do wyboru mamy sporą liczbę alternatywnych rozwiązań. Jednym z popularniejszych jest aplikacja Authy, która jest obsługiwana przez opisywaną tu wtyczkę. Generalnie z wtyczką powinny bez problemu współpracować wszystkie aplikacje korzystające z algorytmu TOTP (Time-based One-time Password) – sporą ich listę można znaleźć na przykład w Wikipedii.

Wpis Uwierzytelnianie dwuskładnikowe w WordPressie pochodzi z bloga WPzen.

Każdy, kto korzysta z WordPressa, na pewno nie raz używał shortcode. Są to specjalne znaczniki wstawiane do treści wpisów, które generują fragmenty kodu HTML. Sam WordPress posiada kilka wbudowanych shortcode (np. [gallery] do wstawiania galerii czy [video] do osadzania filmów), ale wtyczki i motywy mogą rejestrować własne.

Oczywiście po usunięciu wtyczki lub motywu wszystkie dodane przez nie shortcode przestają działać i w treści wpisów zamiast na przykład efektownego przycisku zobaczymy znacznik w stylu [super-przycisk]. Problem nie jest wielki jeśli nasza strona ma kilka lub kilkanaście wpisów, ale jeśli pozbywamy się jakiejś wtyczki lub zmieniamy motyw na blogu, którego prowadzimy od kilku lat, to wyszukanie i usunięcie takich „osieroconych” shortcode może stanowić nie lada wyzwanie. Na szczęście istnieje kilka narzędzi, które mogą nam w tym pomóc.

Wyszukiwanie nieistniejących shortcode

Warto zacząć od znalezienia wszystkich nieistniejących shortcode w treści naszych stron i wpisów. Użyjemy do tego darmowej wtyczki Shortcodes In Use.

Po instalacji i aktywacji rozszerzenia w menu Narzędzia panelu administracyjnego znajdziemy nową sekcję Shortcodes In Use, gdzie możemy wyszukiwać shortcode w treści naszej strony w oparciu o różne kryteria.

W polu Search Shortcode Tag możemy wpisać nazwę shortcode, którego chcemy znaleźć. Jeśli zostawimy to pole puste, wtyczka wyszuka wszystkie shortcode.

Opcja Filter by Provider/Tag pozwala na filtrowanie wyszukiwanych shortcode według ich „pochodzenia”. Możemy na przykład wybrać tylko shortcode wbudowane w WordPressa lub tylko shortcode zarejestrowane przez wybrane aktywne wtyczki lub aktywny motyw. Opcja ta jest szalenie przydatna gdy chcemy pozbyć się jakiejś wtyczki, ale najpierw chcemy zaktualizować lub usunąć wszystkie zarejestrowane przez nią shortcode, tak aby nawet przez chwilę na naszej stronie nie były wyświetlane ich znaczniki. Tę samą operację możemy chcieć wykonać przed zmianą używanego motywu na inny.
Wybranie opcji Unknown spowoduje wyszukanie nieistniejących shortcode, czyli takich, które nie są zarejestrowane przez żadną z aktywnych wtyczek ani przez używany motyw. Właśnie dzięki tej opcji możemy znaleźć „osierocone” shortcode, wyświetlane na naszej stronie w formie znaczników, których chcemy się pozbyć.

Opcja Filter by Location pozwala na przeszukiwanie tylko wybranych elementów stron i wpisów. Post Title przeszukuje tytuły stron i wpisów, Post Content przeszukuje ich treść, Post Excerpt przeszukuje wypisy, Post Meta przeszukuje dodatkowe dane powiązane z wpisami, a Widget pozwala na przeszukiwanie treści umieszczonych w widżetach. W większości przypadków wystarczy zaznaczenie opcji Post Content i Widget, ewentualnie dodatkowo Post Excerpt.
Jeśli nie wybierzemy żadnej opcji, wtyczka przeszuka wszystkie wszystkie elementy naszej strony.

Opcja Filter Posts by Type pozwala na przeszukiwanie tylko wybranych typów wpisów. Na pewno koniecznie musimy wybrać page (strony) i post (wpisy). Moim zdaniem nie warto przeszukiwać biblioteki mediów (attachment), bo tam raczej nie umieszczamy shortcode. Na zamieszczonym wyżej zrzucie ekranu widać jeszcze typ wpcf7_contact_form, czyli formularze wtyczki Contact Form 7 – gdybym wiedział, że w kodzie tych formularzy używałem jakichś shortcode, to zaznaczyłbym również ten typ wpisu. Jeśli na liście pojawi się typ wpisu, który nic nam nie mówi, to na wszelki wypadek powinniśmy go zaznaczyć.
Jeśli nie wybierzemy żadnej opcji, wtyczka przeszuka wszystkie typy wpisów.

Kliknięcie przycisku Find Shortcodes rozpocznie przeszukiwanie treści naszej strony zgodnie z wybranymi kryteriami. Po chwili (być może dłuższej) zobaczymy wynik wyszukiwania.

Na powyższym zrzucie ekranu widać cztery znalezione shortcode. Pierwszy z nich jest zarejestrowany przez wtyczkę Quiz And Survey Master, która jest aktywna, tak więc ten shortcode powinien działać i nie musimy nic z nim robić. Trzy kolejne są oznaczone jako Unknown Provider, co oznacza, że nie są zarejestrowane przez żadną z aktywnych wtyczek ani przez używany motyw – czyli po prostu nie istnieją i należy je usunąć lub zastąpić innymi.

Niestety, wtyczka nie pozwala na masowe usuwanie „osieroconych” shortcode. Możemy jedynie ręcznie edytować każdy ze znalezionych wpisów klikając na jego tytuł. Taka ręczna edycja nie będzie problemem gdy mamy do czynienia z kilkunastoma wpisami, ale jeśli wpisów jest już kilkadziesiąt, to taka operacja może nam zająć nawet kilka godzin. Poszukajmy więc jakiegoś bardziej efektywnego sposobu na pozbycie się nieistniejących shortcode z treści wpisów.

Ukrywanie nieistniejących shortcode

Najprostszym sposobem na rozwiązanie problemu nieistniejących shortcode jest ich ukrycie. Możemy do tego celu wykorzystać bezpłatną wtyczkę Remove Orphan Shortcodes – wystarczy ją zainstalować i aktywować. Trzeba jednak pamiętać, że wtyczka ta nie usuwa „osieroconych” shortcode z treści naszych wpisów, a jedynie ukrywa je, tak aby nie były widoczne na stronie.

Nieco bardziej zaawansowaną opcją ukrywania nieistniejących shortcode jest wtyczka Hide Unwanted Shortcodes, która pozwala na ukrycie tylko wybranych shortcode, w tym również istniejących, których po prostu nie chcemy wyświetlać na naszej stronie.

Usuwanie nieistniejących shortcode z treści wpisów i stron

Niestety, nie istnieje (a przynajmniej nic mi o tym nie wiadomo) wtyczka umożliwiająca automatyczne usunięcie „osieroconych” shortcode z bazy danych. Mimo że jest to technicznie wykonalne, to moim zdaniem jest dość ryzykowne i znacznie bezpieczniejszym sposobem jest ręczna modyfikacja treści w panelu administracyjnym. Bezpośrednie grzebanie w bazie danych zawsze jest obarczone ryzykiem, a jedynym sposobem na cofnięcie wykonanych w ten sposób zmian jest odtworzenie bazy z wykonanej uprzednio kopii.

Dodatkowym problemem jest mnogość sposobów, na jakie można zapisać shortcode:

[nasz_shortcode]
[nasz_shortcode /]
[nasz_shortcode parametr="wartosc"]
[nasz_shortcode parametr="wartosc" /]
[nasz_shortcode]Jakaś treść[/nasz_shortcode]
[nasz_shortcode parametr="wartosc"]Jakaś treść[/nasz_shortcode]

Jeśli mimo to jesteśmy zdecydowani na fizyczne usunięcie nieistniejących shortcode bezpośrednio z bazy danych, to możemy do tego celu wykorzystać wtyczkę Search Regex, dzięki której możemy wyszukiwać i zamieniać w bazie danych ciągi znaków używając wyrażeń regularnych.

Uwaga! Przed wykonaniem operacji opisanych w dalszej części wpisu należy bezwzględnie wykonać kopię bazy danych!

Pierwszym krokiem będzie znalezienie wyrażenia regularnego, które wyszuka wszystkie wystąpienia shortcode na naszej stronie. Jak widać na zamieszczonych wyżej przykładach, wariantów jest kilka, dlatego zwykłe wyszukiwanie nie zda tutaj egzaminu.

WordPress posiada funkcję get_shortcode_regex(), która zwraca wyrażenie regularne używane do parsowania danego shortcode. Wygląda ono tak:

/\[(\[?)(nasz_shortcode)(?![\w-])([^\]\/]*(?:\/(?!\])[^\]\/]*)*?)(?:(\/)\]|\](?:([^\[]*+(?:\[(?!\/\2\])[^\[]*+)*+)\[\/\2\])?)(\]?)/s

Oczywiście te wyrażenie może zmienić się w kolejnych wersjach WordPressa, tak więc najbezpieczniejszym sposobem jest skorzystanie ze wspomnianej funkcji. Można to zrobić używając wtyczki Shortcode Regex Finder, która jest dostępna na GitHubie. Po jej instalacji i aktywacji wystarczy w panelu administracyjnym przejść do sekcji Ustawienia → Shortcode Regex Finder, wpisać nazwę interesującego nas shortcode i kliknąć przycisk Create the shortcode regex.

Gdy mamy już wyrażenie regularne dla naszego shortcode, instalujemy i aktywujemy wtyczkę Search Regex, a następnie przechodzimy do sekcji Narzędzia → Search Regex.

Przede wszystkim musimy zaznaczyć opcję Regex, dzięki czemu wyszukiwanie będzie korzystało z wyrażeń regularnych. W polu Search pattern wklejamy znalezione wcześniej wyrażenie, a w polu Replace pattern wpisujemy \5, dzięki czemu nie stracimy tekstu znajdującego się wewnątrz shortcode (piąty i szósty przykład w zamieszczonej wyżej ramce z przykładami formatów shortcode). Jeśli chcemy usunąć również ten tekst, to pole Replace pattern powinniśmy zostawić puste.

Aby sprawdzić jaki efekt wywoła nasze wyrażenie klikamy przycisk Replace (nie Replace & Save!).

Jak widać na tym przykładzie, shortcode [nasz_shortcode]Jakaś treść[/nasz_shortcode] zostanie zastąpiony tekstem Jakaś treść (dzięki użyciu parametru \5 w polu Replace pattern). Gdybyśmy tego parametru nie użyli, cały shortcode zostałby po prostu usunięty.

Jeśli wszystko wygląda zgodnie z naszymi oczekiwaniami, możemy dokonać masowej zmiany klikając przycisk Replace & Save.

Na zakończenie mała uwaga. W internecie można znaleźć mnóstwo artykułów podających zapytania SQL, którymi (według autorów) można usunąć niepotrzebne shortcode z treści wpisów. Przestrzegam mniej zaawansowanych użytkowników przed korzystaniem z tego typu rozwiązań, bo o pomyłkę naprawdę nie jest trudno. Na dodatek zapytania te nie są w pełni skuteczne – zwykle usuwają tylko najprostsze znaczniki, bez żadnych parametrów.

Wpis Jak pozbyć się nieistniejących shortcode z treści wpisów pochodzi z bloga WPzen.

Edytor wizualny to jeden z najważniejszych elementów WordPressa – korzysta z niego praktycznie każdy użytkownik tego CMSa. To dzięki niemu możemy w łatwy i przyjazny sposób formatować nasze wpisy.

Edytor wizualny kryje wiele ciekawych funkcji, o których nie wszyscy użytkownicy wiedzą, a które mogą usprawnić naszą codzienną pracę z WordPressem. W tym wpisie przybliżę kilka z nich.

Skróty klawiszowe

Początkujący użytkownicy często nie wierzą w to, że skróty klawiszowe przyśpieszają i ułatwiają pracę – dotyczy to każdej aplikacji, a nie tylko WordPressa. Naprawdę gorąco polecam opanowanie przynajmniej tych najpotrzebniejszych skrótów, bo używanie ich jest znacznie szybsze niż klikanie myszką w przyciski na pasku edytora.

O skrótach klawiszowych w panelu administracyjnym WordPressa pisałem ponad 3 lata temu – mimo upływu czasu wpis ten jest wciąż aktualny i warto do niego zajrzeć.

Taką jak widoczna na zrzucie ekranu listę skrótów otworzymy klikając ikonkę ze znakiem zapytania, znajdującą się na pasku narzędziowym edytora wizualnego. Jeśli nie widzisz takiej ikonki, to zapraszam do kolejnego punktu.

Włączanie pełnego paska narzędzi edytora

Wbrew pozorom pytanie o brakujące przyciski w pasku narzędziowym edytora wizualnego pada dość często. Z nieznanego mi powodu domyślnie włączona jest uboższa jego wersja – aby zobaczyć pełen pasek narzędziowy należy kliknąć przycisk Przełącz widoczność paska narzędzi.

Problem jest o tyle istotny, że wtyczki, które dodają własne przycisku do paska narzędziowego, często dodają go właśnie do drugiej (domyślnie ukrytej) jego części.

Przesyłanie obrazków przez przeciągnięcie ich do okna edytora

Dodawanie zdjęć do wpisów to jedna z pierwszych czynności, jakich uczy się każdy użytkownik WordPressa. Ale czy wiesz, że można przesłać plik multimedialny po prostu przeciągając go do okna edytora?

Obrazek zostanie wstawiony w tym miejscu, w którym był ustawiony kursor

Znaczniki Markdown

Markdown to zestaw specjalnych znaczników, które w założeniu mają przyśpieszać i ułatwiać podstawowe formatowanie tekstu. Jeszcze nie tak dawno, aby móc korzystać z nich w WordPressie, trzeba było zainstalować specjalną wtyczkę. Jednak w wersji 4.3 pojawiły się podstawowe znaczniki Markdown, a z każdą kolejną wersją ich obsługa jest udoskonalana. Wprawdzie do wsparcia dla pełnego zestawu znaczników wciąż jeszcze daleko, ale już te, z których w tej chwili możemy korzystać w edytorze wizualnym, sporo ułatwiają (zakładając, że chce nam się nauczyć z nich korzystać).

W tej chwili WordPress obsługuje listy uporządkowane (1. lub 1)) i nieuporządkowane (* lub -), blok z cytatem (>) oraz nagłówki od 2 do 6 (##, ###, ####, ##### i ######). W wersji 4.5 do tego zestawu zostaną dodane znaczniki inline, czyli działające wewnątrz tekstu, a nie tylko w nowych liniach.

Nowy akapit a nowa linia

Gdy naciśniemy klawisz Enter, edytor automatycznie utworzy nowy akapit. Czasem jednak nie chcemy tworzyć nowego akapitu, a jedynie rozpocząć pisanie od nowej linii (na przykład po to, aby pomiędzy tymi liniami nie było tak dużego odstępu, jak pomiędzy akapitami). W takim przypadku zamiast klawisza Enter naciskamy kombinację Shift + Enter.

Tryb pisania bez rozpraszania

Po prawej stronie paska narzędzi edytora wizualnego znajduje się często niedostrzegana ikonka. Jej kliknięcie włącza tryb pisania bez rozpraszania (distraction-free writing mode), w którym z ekranu edycji wpisu znikają wszystkie elementy, które nie są niezbędne do pisania.

Osadzanie treści z zewnętrznych serwisów

Dzięki magicznej funkcji oEmbed w naszych wpisach możemy w łatwy sposób osadzać treści z zewnętrznych serwisów. Aby to zrobić wystarczy po prostu wkleić adres URL strony, z której treść chcemy umieścić w naszym wpisie (np. filmu w serwisie YouTube).

Oczywiście działa to tylko dla obsługiwanych przez WordPressa stron, których lista jest na szczęście bardzo długa.

Wstawianie znaków specjalnych

Niepozorna ikonka ze znakiem Ω otwiera okienko, za pomocą którego możemy do treści wpisu wstawić jeden z dostępnych znaków specjalnych.

Niby nic wielkiego, ale czasem się przydaje – ja na przykład regularnie korzystam z tej funkcji do wstawiania strzałki (→).

Wklejanie tekstu z formatowaniem i bez formatowania

Warto wiedzieć, że do edytora wizualnego możemy wklejać tekst sformatowany, skopiowany na przykład z jakiejś strony internetowej czy nawet z dokumentu stworzonego w edytorze Word. W większości przypadków funkcja ta działa zaskakująco dobrze – można nawet wklejać w ten sposób tabele.

Gdy jednak chcemy automatycznie usunąć formatowanie ze skopiowanego tekstu, z pomocą przychodzi funkcja Wklej jako tekst – wystarczy ją włączyć (ikonka z literą T), a wklejany tekst będzie pozbawiany formatowania. Trzeba pamiętać, że aby powrócić do domyślnego zachowania edytora należy tę funkcję wyłączyć.

Wstawianie shortcode do treści wpisu

Czasem zachodzi potrzeba wstawienia do treści wpisu shortcode, ale w taki sposób, aby był widoczny sam shortcode, a nie efekt jego działania (np. [gallery] – widać shortcode, a nie wygenerowaną przez niego galerię). Aby to zrobić należy objąć shortcode dodatkową parą nawiasów kwadratowych – na przykład tak: [[gallery]].

Jeśli znacie jakieś inne ciekawe i mało znane funkcje edytora wizualnego, to nie zapomnijcie podzielić się nimi w komentarzach.

Wpis 10 rzeczy, których być może nie wiesz o edytorze wizualnym w WordPressie pochodzi z bloga WPzen.

Wydany nieco ponad tydzień temu WordPress 4.5 wprowadził nieco zamieszania – wielu użytkowników donosi, że na ich stronach po aktualizacji przestały działać skrypty JavaScript. Objawia się to w różny sposób – od niedziałających elementów strony do znikających obrazków. Znaczna część tych problemów ma swoje źródło w nowej wersji popularnej biblioteki jQuery, która w najnowszym wydaniu WordPressa została zaktualizowana do wersji 1.12.x. Co ciekawe, nie jest to błąd w samej bibliotece (wręcz przeciwnie – o czym za chwilę), ale w kodzie motywów i wtyczek.

Na szczęście problem jest dość łatwy do zdiagnozowania i naprawienia.

Diagnoza problemu

Jeśli po aktualizacji do WordPressa 4.5 na naszej stronie zaczęły dziać się dziwne rzeczy, to przede wszystkim powinniśmy zajrzeć do konsoli przeglądarki. W Chrome znajdziemy ją w menu Więcej narzędzi → Narzędzia programistów (zakładka Console), a w Firefoksie w menu Narzędzia → Konsola przeglądarki. W konsoli znajdziemy między innymi wszystkie błędy w kodzie JavaScript, jakie wystąpiły na naszej stronie.

Komunikat, którego szukamy, wyglądać może na przykład tak:

Uncaught Error: Syntax error, unrecognized expression: a[href*=#]

albo tak:

Uncaught DOMException: Failed to execute 'querySelector' on 'Document': 'a[href*=#]' is not a valid selector.

W obu przypadkach problemem jest ten selektor: a[href*=#]. W różnych przypadkach może on różnie wyglądać, ale zawsze zawiera znak #, który jest przyczyną problemu.

Rozwiązanie problemu

W pierwszej kolejności sprawdźmy, czy używany przez nas motyw został uaktualniony przez autora – jeśli tak, to wykonajmy aktualizację. Jeśli jednak okaże się, że autor nie usunął błędu, to będziemy musieli poradzić sobie z nim sami.

Niestety, komunikat ten nie wskazuje na plik, w którym znajduje się błędny selektor, tak więc będziemy musieli poszukać go sami. Może on znajdować się w kodzie strony (wyświetlamy w przeglądarce źródło strony i szukamy widocznego w komunikacie o błędzie kodu) lub w plikach .js używanego motywu lub wtyczek. Jeśli mamy problem ze zlokalizowaniem miejsca występowania błędnego kodu, to najprościej będzie pobrać wszystkie pliki motywu na swój komputer i przeszukać je.

Gdy już znajdziemy problematyczny fragment kodu, znak # należy objąć apostrofami lub cudzysłowami (zależnie od kontekstu), tak aby wyglądał na przykład tak:

a[href*='#']

albo tak:

a[href*="#"]

Przyczyna problemu

Jak już napisałem na wstępie, wbrew pozorom nie jest to błąd jQuery. W nowej wersji biblioteki usprawniono wykrywanie nieprawidłowej składni selektorów, a pokazana wyżej składnia jest po prostu niepoprawna (a z jakiegoś powodu dość powszechnie używana).

Problem jest znany twórcom WordPressa, ale nie są oni w stanie nic z nim zrobić, bo nie leży on po ich stronie. Po prostu wiele motywów i wtyczek zawiera błędny kod JavaScript, który przez długi czas działał (mimo że nie powinien), a teraz przestał. Sytuacja ta jest jednak dość uciążliwa dla użytkowników (szczególnie tych mniej zaawansowanych), a większość z nich (nie bez powodu) dopatruje się przyczyny problemów w aktualizacji WordPressa do wersji 4.5.

Wpis WordPress 4.5 i błędy jQuery – rozwiązanie problemu pochodzi z bloga WPzen.

Robisz regularnie kopie bezpieczeństwa swojej strony? Jeśli nie, to niezwłocznie zacznij. Jeśli tak, to świetnie – ale czy na pewno robisz je prawidłowo? Czy w razie problemów zawsze będziesz w stanie w miarę szybko odtworzyć swoją stronę?

Postanowiłem zebrać kilka porad, z których warto korzystać przy tworzeniu kopii bezpieczeństwa naszych stron.

Nie ufaj firmie hostingowej

Każda szanująca się firma hostingowa robi kopie bezpieczeństwa stron swoich klientów. Różne firmy robią to z różną częstotliwością (niektóre nawet co kilka godzin) i przechowują różną liczbę ostatnich backupów. Zanim wybierzemy usługodawcę, koniecznie powinniśmy zorientować się jak często robi on kopie bezpieczeństwa oraz gdzie i jak długo są one przechowywane. Jeśli backup jest robiony „co jakiś czas” i przechowywany na tym samym serwerze, na którym działa nasza strona, to powinniśmy czym prędzej rozejrzeć się za inną firmą hostingową.

Niezależnie jednak od tego, jak świetnie wygląda pod tym kątem oferta wybranej przez nas firmy, absolutnie nie powinniśmy opierać się tylko i wyłącznie na tej jednej kopii bezpieczeństwa. Prawdopodobnie w razie problemów usługodawca będzie w stanie w ciągu kilkunastu minut odtworzyć naszą stronę z backupu. Co jednak jeśli w wyniku awarii kopia ulegnie uszkodzeniu lub całkowitemu zniszczeniu?

Dlatego dobrze jest mieć ograniczone zaufanie do oferowanego przez firmę hostingową mechanizmu tworzenia kopii bezpieczeństwa i zadbać o to we własnym zakresie.

Wybierz odpowiednie narzędzie

Wtyczek dla WordPressa do tworzenia kopii bezpieczeństwa jest sporo. Ja najczęściej korzystam z BackWPup, ale wybór każdego innego (w miarę popularnego) rozszerzenia będzie równie dobry.

Wybierając narzędzie warto zapoznać się z opiniami na jego temat – głównie tymi negatywnymi, tak aby wiedzieć, z jakimi problemami najczęściej zmagają się jego użytkownicy. Zwykle większość problemów jest związana tak naprawdę z konfiguracją serwera – proces tworzenia kopii bezpieczeństwa pochłania sporą ilość zasobów (szczególnie w przypadku dużych serwisów) i czasem trzeba poświęcić chwilę na odpowiednią konfigurację wtyczki lub poprosić firmę hostingową o pomoc w znalezieniu przyczyn problemów. Różne wtyczki różnie sobie radzą z ograniczeniami serwerów – jeśli jedna nie działa poprawnie na naszej stronie, to warto mimo wszystko wypróbować inne.

Niektóre wtyczki (na przykład BackupBuddy czy płatna wersja BackWPup) potrafią robić tak zwane kopie przyrostowe, czyli zawierające tylko nowe i zmodyfikowane pliki. Pozwala to zaoszczędzić mnóstwo miejsca (szczególnie przy dużych stronach) i w pewnych przypadkach wydane na wtyczkę pieniądze mogą się dość szybko zwrócić.

Możemy też skorzystać z narzędzi do tworzenia kopii działających na serwerze, takich jak na przykład duplicity. Jeśli nasza strona działa na VPSie lub serwerze dedykowanym, to będzie to naturalny wybór. Jeśli jednak korzystamy z serwera współdzielonego, to najprawdopodobniej nie będziemy nawet w stanie zainstalować takiego narzędzia.

Wybierz miejsce przechowywania kopii

Oczywiście trzymanie kopii bezpieczeństwa na tym samym serwerze, na którym działa nasza strona, nie ma większego sensu, chociaż czasem może się okazac wystarczające – na przykład jeśli chcemy odtworzyć zainfekowaną stronę. Złośliwe skrypty zwykle nie dotykają archiwów (plików .zip czy .gz), tak więc przechowywana w ten sposób kopia nie będzie nie powinna być (komentarz) zainfekowana.

Trzeba jednak zawsze zwrócić uwagę na to, czy pliki zawierające backup naszej strony są odpowiednio zabezpieczone przed dostępem z zewnątrz. Większość narzędzi do tworzenia kopii oferuje tego typu zabezpieczenia. Na przykład wspomniana już wtyczka BackWPup posiada opcję, która automatycznie tworzy plik .htaccess blokujący dostęp do zawartości katalogu z backupami (który i tak ma trudną do odgadnięcia nazwę). Jednak jeśli to możliwe, warto przenieść ten katalog poza katalog public_html, tak aby znajdował się na serwerze w miejscu całkowicie niedostępnym z zewnątrz.

Praktycznie wszystkie wtyczki do tworzenia kopii bezpieczeństwa umożliwiają automatyczne wysyłanie ich gdzieś poza nasz serwer i z tej możliwości zdecydowanie powinniśmy korzystać.

Wybór miejsca, w którym będą magazynowane nasze kopie, zależy głównie od naszych osobistych preferencji. Najpopularniejszymi usługami, które można wykorzystać do tego celu, są Dropbox, Google Drive, Microsoft OneDrive czy Amazon S3. W praktyce najkorzystniejszą cenę ma usługa Amazonu (szczególnie jeśli nasze kopie są duże), ale jest też najtrudniejsza w konfiguracji.

Ja do przechowywania kopii korzystam z Dropboksa (dla mniejszych projektów) i Amazon S3. Dodatkowo co jakiś czas pobieram kopie na dysk swojego komputera – tak na wszelki wypadek.

Dropbox oferuje darmowe 2 GB miejsca na nasze pliki oraz kosztującą 99 euro rocznie wersję Pro, w ramach której otrzymujemy 1 TB miejsca (to wystarczy nawet do bardziej zaawansowanych zastosowań).

Cennik usługi Amazon S3 jest dość skomplikowany i trudno jest wyliczyć dokładną kwotę, jaką przyjdzie nam zapłacić na koniec miesiąca. Zaletą jest natomiast to, że płacimy tylko za miejsce, które wykorzystujemy. Ja w tej chwili w usłudze S3 przechowuję nieco ponad 70 GB danych (cały czas ich przybywa), a za ubiegły miesiąc otrzymałem rachunek w wysokości $1.20 (czyli około 4,60 zł). To naprawdę dobra cena.

Ustal częstotliwość wykonywania i okres przechowywania kopii

Jeśli robimy backup codziennie, ale przechowujemy tylko kilka ostatnich kopii, to robimy to źle. Co jeśli nagle zajdzie potrzeba odzyskania zdjęcia, które usunęliśmy miesiąc temu? Co gdy dopiero po tygodniu zauważymy, że nasza strona została zainfekowana, a ostatnia „czysta” kopia już dawno została usunięta?

Częstotliwość wykonywania kopii bezpieczeństwa powinniśmy ustalać indywidualnie dla każdej strony. Jeśli mamy stronę firmową, która zmienia się stosunkowo rzadko (na przykład raz na miesiąc), to nie ma sensu robić jej kopii codziennie. Z kolei gdy prowadzimy sklep z dużą liczbą zamówień, to backup bazy danych wypadałoby robić co najmniej raz na dobę, a nawet częściej.

Najwięcej miejsca na dysku serwera zajmują zwykle pliki multimedialne (zdjęcia, pliki audio i wideo) oraz dokumenty. Z kolei kopia bazy danych, która ma postać zwykłego pliku tekstowego, jest zwykle niewielka. Dlatego też w przypadku większych serwisów możemy tworzyć kilka kopii bezpieczeństwa z różną zawartością, co przyśpieszy nieco cały proces i pozwoli zaoszczędzić trochę miejsca, ale jednocześnie wciąż będzie zabezpieczać nas przed skutkami awarii.

Przykładowo, raz dziennie możemy wykonywać kopię bazy danych, plików motywu i naszych własnych wtyczek (takich, których nie możemy pobrać z zewnętrznego źródła) oraz listy zainstalowanych wtyczek (tak aby w razie problemów łatwo można było je odtworzyć). Raz w tygodniu możemy wykonywać backup plików multimedialnych (katalog /wp-content/uploads/) oraz (opcjonalnie) kompletną kopię całej strony (aby w razie awarii można było szybko odtworzyć serwis na innym serwerze). Wszystko zależy od tego, co i jak często jest dodawane lub modyfikowane na naszej stronie.

Kopie najlepiej robić w nocy, gdy serwer jest najmniej obciążony i gdy nikomu nie będziemy tym procesem przeszkadzać.

Jeśli chodzi o czas przechowywania kopii bezpieczeństwa, to również jest to kwestia indywidualna. Dodatkowym czynnikiem jest przestrzeń dyskowa, jaką możemy przeznaczyć na magazynowanie backupów. W miarę bezpieczną opcją jest przechowywanie kopii z ostatnich 30 dni. Jeśli nasza strona jest naprawdę duża, to może wymagać to sporej ilości miejsca – nie warto jednak na tym oszczędzać, bo koszty braku backupu po awarii mogą być wielokrotnie wyższe.

Ja zwykle przechowuję 30 ostatnich kopii codziennych i 12-15 ostatnich kopii tygodniowych (całościowych). Uważam, że jest to dobra metoda ze sporym marginesem bezpieczeństwa – ale na szczęście jeszcze nigdy nie musiałem z tych backupów korzystać. Jak do tej pory zwykle spotykałem się z sytuacjami, w których kopii nie było w ogóle lub były robione źle (czegoś w nich brakowało, były robione zbyt rzadko lub nie były przechowywane odpowiednio długo).

Wybierz co znajdzie się w kopii

Teoretycznie do odtworzenia serwisu zbudowanego na WordPressie wystarczy baza danych, lista zainstalowanych wtyczek oraz zawartość katalogów /wp-content/uploads/ i /wp-content/themes/ (jeśli korzystamy z własnego motywu lub z motywu potomnego). Samego WordPressa (w dowolnej wersji) i wszystkie wtyczki można zawsze pobrać z repozytorium, tak więc nie ma sensu archiwizować tych plików. Z drugiej jednak strony, znacznie szybciej jest odtworzyć serwis z kompletnej kopii – wystarczy tylko rozpakować archiwum backupu, zaimportować bazę danych i wprowadzić nowe dane bazy danych do pliku wp-config.php. Taka kompletna kopia będzie na pewno lepsza w przypadku stron, których niedostępność przynosi wymierne straty, przez co czas potrzebny na ponowne ich uruchomienie powinien być jak najkrótszy.

Koniecznie należy też przyjrzeć się niestandardowym katalogom znajdującym się wewnątrz katalogu /wp-content/. Wiele wtyczek (na przykład do tworzenia galerii) zapisuje tam swoje dane, które również powinniśmy dołączyć do naszej kopii bezpieczeństwa. Jeśli dodatkowo korzystamy z własnego motywu i niestandardowych wtyczek, może się okazać, że najbezpieczniej i najwygodniej będzie po prostu dołączyć do backupu cały katalog /wp-content/ (wykluczając tylko – jeśli jest taka potrzeba – katalog cache i katalog, do którego trafiają archiwa z kopiami bezpieczeństwa).

Dyskusyjne jest dołączanie do archiwum pliku wp-config.php. Znajdują się w nim dane, które raczej powinniśmy chronić: nazwa użytkownika i hasło bazy danych oraz klucze zabezpieczające informacje przechowywane w ciasteczkach. Jednak w większości przypadków dane te są i tak mało użyteczne – do bazy zwykle nie da się dostać z zewnątrz (spoza serwera), a wykorzystanie kluczy do jakiegokolwiek ataku jest dość trudne (a po jakichkolwiek problemach z bezpieczeństwem strony i tak powinniśmy je zmienić).

Ponieważ odtworzenie zawartości pliku wp-config.php jest bardzo łatwe (wystarczy skopiować znajdujący się w paczce instalacyjnej WordPressa plik wp-config-sample.php i uzupełnić brakujące w nim informacje), osobiście nie polecam mimo wszystko dołączania go do kopii bezpieczeństwa. Jeśli konfiguracja naszej stronie jest nieco bardziej złożona, dodatkowe ustawienia możemy trzymać w zewnętrznym pliku, który dołączamy (na przykład za pomocą funkcji require()) do pliku wp-config.php.

Podsumowanie

Na koniec jeszcze raz apeluję, abyście nie lekceważyli wykonywania kopii bezpieczeństwa – konfiguracja backupu powinna być jedną z pierwszych czynności, jakie wykonujemy po uruchomieniu nowej strony. Nikt z nas przecież nie chce, aby efekt ciężkiej (często wieloletniej) pracy zniknął bezpowrotnie.

Życzę Wam jednocześnie, abyście ze swoich wykonywanych regularnie backupów nigdy nie musieli korzystać.

Wpis Jak prawidłowo robić kopie bezpieczeństwa strony pochodzi z bloga WPzen.

Znajdujący się w katalogu głównym WordPressa plik wp-config.php zawiera (jak sama nazwa wskazuje) podstawową konfigurację tego CMSa. Domyślnie znajdują się w nim dane niezbędne do nawiązania połączenia z bazą danych oraz klucze służące do szyfrowania danych przechowywanych w ciasteczkach. Jego podstawowa zawartość jest generowana automatycznie podczas instalacji i spora część użytkowników nie tylko nic w nim nie zmienia, ale często nawet do niego nie zagląda.

Jednak plik ten daje bardzo duże możliwości. Za jego pomocą możemy zmienić wiele parametrów WordPressa, a także rozwiązać kilka często spotykanych problemów.

Oczywiście sam plik wp-config.php nie robi nic niezwykłego. Wszystkie opisane w dalszej części wpisu ustawienia to tak naprawdę definicje stałych, które później są używane w kodzie WordPressa. wp-config.php jest po prostu dobrym miejscem na umieszczenie tych definicji – plik ten jest ładowany jako jeden z pierwszych, a poza tym nigdy nie jest nadpisywany ani usuwany w trakcie aktualizacji WordPressa.

Stałe, za pomocą których możemy modyfikować „ukryte” ustawienia WordPressa, definiuje się za pomocą funkcji define(). Może to wyglądać na przykład tak:

define('DB_NAME', 'nazwa_bazy_danych');

DB_NAME to nazwa stałej, a nazwa_bazy_danych to jej wartość. Proste.

Wszystkie dodatkowe opcje konfiguracyjne najbezpieczniej jest umieszczać zaraz przed tą linią:
/* That's all, stop editing! Happy blogging. */

Zobaczmy więc, jakie tajemnice kryje przed nami wp-config.php.

Dane bazy danych

To jedne z podstawowych i zawsze obecnych ustawień – bez nich WordPress nie będzie po prostu działał. Dane te są umieszczane w pliku wp-config.php podczas instalacji. Jeśli przenosimy stronę na inny serwer albo po prostu zmieniliśmy bazę danych, to musimy te ustawienia zmodyfikować.

• define('DB_NAME', 'nazwa_bazy_danych'); – nazwa naszej bazy danych
• define('DB_USER', 'nazwa_uzytkownika_bazy_danych'); – nazwa użytkownika (login) bazy danych
• define('DB_PASSWORD', 'haslo'); – hasło do bazy danych
• define('DB_HOST', 'localhost'); – nazwa hosta; najczęściej będzie to localhost, a jeśli nie, to trzeba zajrzeć do dokumentacji udostępnianej przez firmę hostingową lub do panelu naszego serwera

Jeśli musimy skorzystać z niestandardowego portu MySQL (innego niż 3306), to dodajemy go po dwukropku do hosta, na przykład tak: localhost:3307.

Dwie kolejne stałe są związane ze standardem kodowaniem znaków (DB_CHARSET – utf8 lub utf8mb4 od wersji 4.2) i z metodą porównywania znaków (DB_COLLATE). Tych parametrów po prostu nie ruszamy, chyba że naprawdę wiemy, co robimy.

Ostatnim parametrem związanym z bazą danych, zdefiniowanym nieco inaczej i w innym miejscu, jest prefiks nazw tabel w bazie danych. Znajduje się on w zmiennej $table_prefix i również jest tworzony podczas instalacji WordPressa. Można go oczywiście zmienić, ale do tego nie wystarczy po prostu modyfikacja zawartości tej zmiennej – trzeba jeszcze zmienić nazwy tabel w bazie danych i poszukać w niej miejsc, w których nazwy te zostały zapisane.

Klucze zabezpieczające dane przechowywane w ciasteczkach

Kluczy tych jest osiem i są one generowane w sposób pseudo-losowy podczas instalacji WordPressa. Za ich pomocą szyfrowane są dane przechowywane w ciasteczkach na komputerach naszych użytkowników. Jeśli mamy chociażby cień podejrzenia, że nasza strona mogła paść ofiarą ataku lub infekcji, należy te klucze zmienić.

define('AUTH_KEY',         'rU_~-C3FwMl6t*1J>-Rx*AIb9a7tj)[hMmGi@#CK.Jv,Vf6FE6a(S*WHU;(*AV@n');
define('SECURE_AUTH_KEY',  '}b7`l+u&Qj0F>+^[^Zu3JcHZ+CL/cY@h`aG;$G|R56e.D~sub!$A>-Y2Fhq9+uzo');
define('LOGGED_IN_KEY',    '-FBEqh:XOc,]ANjj4D-x@H5+XO!zL]-vM@>A-f,k&3{N>?[Q+o-6*9.NwK<3&q_v');
define('NONCE_KEY',        'RQSpz Ie?>z.Jv%pmXSougI$*nmo;@<d|],;Xa=s<A-x=,+L>/gl&R:[`n%44Nb/');
define('AUTH_SALT',        'ZPgo&+Ymf9>|Tyn8NQ-r_Lo2/IFf{PomhT3|j$@$0:sR6uLE Aw&S?i-6x?t^Fq5');
define('SECURE_AUTH_SALT', 'DK5+NXIg?>9a8]s&La;%#G5_-|4|+) X>qJCqAV>5EYoFqinyvR|>=AfzUR<x`g3');
define('LOGGED_IN_SALT',   ',&KAtvE-LgqDA;*SD+:n@-w?f=*_d-:N=>+VO(H+]Q<u.7!)mLTGH|`+ z]$LF@0');
define('NONCE_SALT',       'a3Ak`,*L-r9W%MP%*2>{-U|(GP+B(=x]+!|&M{7A+2Ed drW2/pVn%vv.}|,%sCH');

Do generowania kluczy służy specjalne narzędzie, ale oczywiście można te losowe ciągi znaków wymyślić sobie samodzielnie. Trzeba pamiętać, że zmiana któregokolwiek z kluczy spowoduje automatyczne wylogowanie wszystkich zalogowanych użytkowników.

Tak naprawdę tylko cztery pierwsze klucze są wymagane – jeśli nie podamy pozostałych czterech (których nazwy kończą się na _SALT) lub je usuniemy z pliku wp-config.php, to zostaną one wygenerowane automatycznie przez WordPressa.

Tryb debugowania

WordPress z włączonym trybem debugowania wyświetla na stronie wszystkie błędy, ostrzeżenia i informacje zwracane przez interpreter PHP. Pracując nad serwisem koniecznie należy włączyć ten tryb – dzięki temu jesteśmy w stanie wychwycić część błędów, w tym te najgłupsze, czyli literówki. Natomiast na dostępnej publicznie stronie tryb ten powinien być wyłączony (jest to zresztą ustawienie domyślne).

Gdy tryb debugowania jest wyłączony, wszystkie wspomniane komunikaty są ukryte. Jeśli na naszej stronie wystąpi jakiś krytyczny (czyli przerywający działanie skryptu) błąd, to zwykle zobaczymy po prostu białą stronę. W takiej sytuacji pierwszą czynnością, jaką powinniśmy wykonać, jest właśnie włączenie trybu debugowania.

Tryb debugowania włącza się przez nadanie stałej WP_DEBUG wartości true, a wyłącza nadając jej wartość false:

define('WP_DEBUG', true);  // włączamy tryb debugowania
define('WP_DEBUG', false); // wyłączamy tryb debugowania

Tryb debugowania ma kilka dodatkowych ustawień, które w pewnych sytuacjach mogą ułatwić znalezienie przyczyn problemów.

Na początek dwie opcje, które przydają się do debugowania skryptów JavaScript w panelu administracyjnym (nie na stronie). SCRIPT_DEBUG ładuje nieskompresowane wersje skryptów JavaScript, a CONCATENATE_SCRIPTS wyłącza scalanie skryptów JavaScript. Dzięki temu łatwiej możemy znaleźć w kodzie miejsce, w którym występuje problem.

Dość często zdarza się, że problem występuje tylko na wersji produkcyjnej naszej strony i po skopiowaniu jej na inny serwer (albo na nasz własny komputer) nie jesteśmy w stanie go odtworzyć. Nie jest zalecane włączanie trybu debugowania na dostępnej publicznie stronie, ale jakoś musimy przecież znaleźć przyczynę problemów. Posłużą nam do tego opcje WP_DEBUG_LOG i WP_DEBUG_DISPLAY, dzięki którym wszystkie komunikaty o błędach zamiast zostać wyświetlone na naszej stronie trafią do pliku logu na serwerze. Najprostszy sposób wykorzystania tych opcji wygląda tak:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);

Po dodaniu tych linii do pliku wp-config.php wszystkie komunikaty zostaną zapisane do pliku debug.log, znajdującego się w katalogu wp-content. Na wszelki wypadek możemy zablokować dostęp do tego pliku z zewnątrz dodając do pliku .htaccess następującą regułę:

<Files debug.log>
    Order allow,deny
    Deny from all
</Files>

Bardzo pomocną w analizowaniu problemów z wydajnością opcją jest SAVEQUERIES. Ustawienie jej na true spowoduje, że WordPress będzie zapisywał szczegółowe informacje o każdym zapytaniu do bazy danych. Informacje te można później analizować korzystając na przykład z wtyczki Debug Bar lub po prostu wyświetlić je na stronie dodając do pliku functions.php naszego motywu następujący kod:

function wpzen_display_queries() {
	if(current_user_can('manage_options')) { // wyświetlamy informacje tylko administratorom
		global $wpdb;
		echo "<pre>";
		print_r($wpdb->queries);
		echo "</pre>";
	}
}
add_action('wp_footer', 'wpzen_display_queries', 9999);

Aktualizacje WordPressa, motywów i wtyczek

W wersji 3.7 wprowadzono mechanizm automatycznych aktualizacji WordPressa, wtyczek i motywów. Domyślnie opcja ta jest włączona tylko dla samego WordPressa i działa tylko w ramach wersji głównej – czyli zaktualizuje na przykład wersję 4.2.1 do 4.2.2, ale 4.2.2 do 4.3 już nie.

Dostępnych jest kilka opcji, które dają nam kontrolę nad mechanizmem automatycznych aktualizacji. Możemy całkowicie je wyłączyć ustawiając wartość stałej AUTOMATIC_UPDATER_DISABLED na true. Z kolei opcja WP_AUTO_UPDATE_CORE określa, czy aktualizacje WordPressa mają być wyłączone (false), włączone dla wszystkich wersji (true) czy też włączone tylko w ramach wersji głównej (minor).

Na bardziej zaawansowaną konfigurację automatycznych aktualizacji pozwala darmowa wtyczka Update Control.

Mamy również możliwość wpływania na działanie samego mechanizmu aktualizacji, odpowiedzialnego za uaktualnianie WordPressa, motywów i wtyczek z poziomu panelu administracyjnego. W znacznej większości przypadków nie ma potrzeby korzystania z tych opcji, bo WordPress automatycznie powinien wybrać najlepsze ustawienia. Zdarzają się jednak sytuacje, gdy aktualizacje po prostu nie działają – wtedy zmiana tych ustawień może pomóc.

Najważniejszą opcją jest FS_METHOD, która określa sposób, w jaki WordPress będzie próbował umieścić pliki na naszym serwerze. Domyślnym ustawieniem jest direct i w większości przypadków to działa. Czasem jednak (najczęściej przez konfigurację serwera lub nieprawidłowe uprawnienia katalogów) metoda ta się nie sprawdza. Co ciekawe, spotkałem się już z przypadkiem, gdy pomimo poprawnej konfiguracji serwera aktualizacje nie działały, a rozwiązaniem było… nadanie stałej FS_METHOD wartości direct, czyli domyślnej.

Stała FS_METHOD może przyjmować następujące wartości:

• ssh2 – korzysta z SSH i wymaga zainstalowania na serwerze modułu SSH dla PHP,
• ftpext – korzysta z protokołu FTP i wymaga zainstalowania na serwerze modułu FTP dla PHP,
• ftpsockets – korzysta z protokołu PHP, ale nie wymaga dodatkowych modułów.

Nie będę tu dokładnie opisywał konfiguracji poszczególnych metod, bo instrukcje można znaleźć w dokumentacji.

Adres URL naszej strony

Stałe WP_SITEURL i WP_HOME pozwalają na „nadpisanie” adresów URL naszej strony, które normalnie wprowadzamy w ustawieniach WordpPressa (opcje Ustawienia → Ogólne → Adres WordPressa i Ustawienia → Ogólne → Adres witryny). O różnicach pomiędzy tymi dwoma adresami pisałem we wpisie o przenoszeniu plików WordPressa do podkatalogu.

define('WP_SITEURL', 'http://nasza-domena.pl/wp');
define('WP_HOME', 'http://nasza-domena.pl');

Trzeba jednak pamiętać, że zmiany te nie zostaną zapisane w bazie – po usunięciu deklaracji tych stałych z pliku wp-config.php wszystko wróci do stanu poprzedniego. Aby wprowadzone w pliku konfiguracyjnym adresy zostały zapisane w bazie należy nadać stałej RELOCATE wartość true.

Co ciekawe, można ustawiać te dwie stałe dynamicznie, w taki sposób, aby zawsze przyjmowały adres wpisany w przeglądarce. Ułatwia to na przykład korzystanie z tej samej konfiguracji na serwerze lokalnym i testowym.

define('WP_SITEURL', 'http://'.$_SERVER['SERVER_NAME'].'/wp');
define('WP_HOME', 'http://'.$_SERVER['SERVER_NAME']);

Przenoszenie i zmiana nazw katalogów WordPressa

Za pomocą odpowiednich stałych zdefiniowanych w pliku wp-config.php możemy zmienić nazwę i lokalizację niektórych katalogów WordPressa. Zmian tych możemy dokonać dla następujących katalogów:

• wp-content – w tym katalogu znajdują się wtyczki, motywy oraz wszystkie pliki użytkownika; stałe: WP_CONTENT_DIR (nazwa katalogu na serwerze) i WP_CONTENT_URL (adres URL katalogu),
• plugins – katalog, w którym znajdują się wtyczki; stałe: WP_PLUGIN_DIR, PLUGINDIR (dla zachowania wstecznej kompatybilności) i WP_PLUGIN_URL,
• mu-plugins – katalog, w którym znajdują się wtyczki „must-use”, czyli takie, których nie da się dezaktywować (są zawsze włączone); stałe: WPMU_PLUGIN_DIR, MUPLUGINDIR (dla zachowania wstecznej kompatybilności) i WPMU_PLUGIN_URL,
• uploads – katalog, do którego trafiają wszystkie pliki użytkownika (przesłane do biblioteki mediów lub zapisywane przez różne wtyczki); stała: UPLOADS.

Przykładowy kod zmieniający położenie tych katalogów może wyglądać tak:

define('WP_CONTENT_DIR', dirname(__FILE__).'/assets');
define('WP_CONTENT_URL', 'http://nasza-domena.pl/assets');
define('WP_PLUGIN_DIR', WP_CONTENT_DIR.'/extensions');
define('PLUGINDIR', WP_CONTENT_DIR.'/extensions');
define('WP_PLUGIN_URL', WP_CONTENT_URL.'/extensions');
define('UPLOADS', 'assets/media');

Warto zwrócić uwagę na katalog podany w stałej UPLOADS – znajduje się on zawsze wewnątrz katalogu WordPressa (stała ABSPATH).

Niestety, nie ma możliwości przeniesienia katalogu z motywami, ale za pomocą funkcji register_theme_directory() możemy dodać kolejny katalog, w którym WordPress będzie szukał motywów i w którym możemy umieścić na przykład stworzony przez nas motyw potomny.

Trzeba pamiętać, że samo ustawienie odpowiednich stałych nie spowoduje automatycznego przeniesienia odpowiednich katalogów ani zmiany ich nazw na serwerze – musimy to zrobić ręcznie.

Wersjonowanie wpisów

Mechanizm wersjonowania przechowuje kolejne wersje naszych wpisów i pozwala na odtworzenie dowolnej z nich oraz porównanie poszczególnych rewizji pod kątem wprowadzonych zmian. W pliku wp-config.php możemy wyłączyć całkowicie ten mechanizm nadając stałej WP_POST_REVISIONS wartość false lub ograniczyć liczbę przechowywanych wersji wpisując do tej stałej odpowiednią liczbę.

define('WP_POST_REVISIONS', false); // całkowicie wyłączamy wersjonowanie
define('WP_POST_REVISIONS', 5); // przechowujemy tylko 5 ostatnich wersji wpisu

Kosz w bibliotece mediów

Domyślnie biblioteka mediów nie ma kosza, do którego trafiają usunięte elementy, przez co kasowanie multimediów jest nieodwracalne. Można jednak włączyć tę funkcję nadając stałej MEDIA_TRASH wartość true. Więcej na ten temat znajdziecie w tym wpisie.

Częstotliwość automatycznego zapisywania wpisów

Edytor WordPressa co jakiś czas automatycznie zapisuje edytowany przez nas wpis, tak aby nagłe wyłączenie komputera czy zamknięcie okna przeglądarki nie spowodowało utraty efektów naszej pracy. Domyślnie taki zapis jest wykonywany co 60 sekund, ale czas ten można wydłużyć lub skrócić nadając odpowiednią wartość stałej AUTOSAVE_INTERVAL.

define('AUTOSAVE_INTERVAL', 300); // automatyczny zapis co 300 sekund (5 minut)

Automatyczne opróżnianie kosza

Usuwane wpisy i strony są przenoszone do kosza, z którego w każdej chwili możemy je przywrócić. Nie leżą one tam jednak wiecznie – kosz jest okresowo opróżniany. Domyślnie usuwane są wpisy, które znajdują się w koszu dłużej niż 30 dni. Okres ten możemy zmienić korzystając ze stałej EMPTY_TRASH_DAYS.

define('EMPTY_TRASH_DAYS', 60); // wpisy będą usuwane z kosza po 60 dniach

Wydawać by się mogło, że ustawienie wartości tej stałej na 0 (zero) lub false spowoduje, że wpisy nie będą w ogóle usuwane z kosza. Nic bardziej mylnego – efektem będzie całkowite wyłączenie funkcji kosza. Wpisy będą usuwane od razu, na dodatek bez żadnego ostrzeżenia – jedyną zauważalną zmianą będzie inna treść linku usuwającego wpis: Usuń na zawsze zamiast Do kosza.

Aby wyłączyć automatyczne opróżnianie kosza można ustawić wartość stałej EMPTY_TRASH_DAYS na jakąś bardzo dużą liczbę (na przykład 18250 – czyli 50 lat) lub dodać do pliku functions.php motywu lub do pliku wtyczki następujący kod:

function wpzen_remove_scheduled_delete() {
    remove_action('wp_scheduled_delete', 'wp_scheduled_delete');
}
add_action('init', 'wpzen_remove_scheduled_delete');

Zwiększenie limitu pamięci dla PHP

W dużym uproszczeniu, im bardziej rozbudowana jest nasza strona, tym więcej pamięci serwera potrzebuje. Z różnych przyczyn serwery mają ustawiony limit pamięci, którą może „zużyć” interpreter PHP. Domyślnie WordPress próbuje (bo nie każdy serwer na to pozwala) ustawić ten limit na 40 MB, co w dzisiejszych czasach nie jest dużą wartością. Jednak wystarczy zainstalować jakąś większą wtyczkę czy bardziej rozbudowany (a raczej wypchany zbędnymi funkcjami) motyw premium, aby limit ten okazał się zbyt niski i nasza strona przestała działać (więcej na ten temat znaleźć można w tym wpisie). W takim przypadku możemy spróbować zwiększyć limit pamięci korzystając ze stałej WP_MEMORY_LIMIT:

define('WP_MEMORY_LIMIT', '64M'); // ustawiamy limit pamięci na 64 MB

Co ciekawe, istnieje jeszcze stała WP_MAX_MEMORY_LIMIT, która ustawia osobny limit pamięci dla panelu administracyjnego (niektóre jego elementy mogą być nieco bardziej „zasobożerne”):

define('WP_MAX_MEMORY_LIMIT', '128M'); // ustawiamy limit pamięci dla panelu na 128 MB

Naprawianie uszkodzonych tabel w bazie danych

Okazjonalnie (a tak naprawdę bardzo rzadko) tabele w bazie danych ulegają uszkodzeniu, co objawia się komunikatem o nieudanym połączeniu z bazą danych lub o braku możliwości odczytu danych z którejś z tabel. Przyczyn tego zjawiska może być kilka, ale chyba najczęstszą jest brak miejsca na dysku serwera. Więcej na ten temat pisałem w tym wpisie.

WordPress posiada wbudowane narzędzie do sprawdzania i naprawy uszkodzonych tabel. Jest ono jednak domyślnie wyłączone – aby je włączyć należy ustawić wartość stałej WP_ALLOW_REPAIR na true.

define('WP_ALLOW_REPAIR', true);

Teraz możemy uruchomić wspomniane narzędzie wpisując w przeglądarce adres http://nasza-domena.pl/wp-admin/maint/repair.php. Wykona ono sprawdzenie tabel w bazie danych (CHECK), naprawę tych, które zostały rozpoznane jako uszkodzone (REPAIR) oraz analizę (ANALYZE) i optymalizację (OPTIMIZE) wszystkich tabel. Warto dodać, że dostęp do tego narzędzia nie wymaga autoryzacji, dzięki czemu działa ono nawet gdy uszkodzona zostanie tabela z danymi użytkowników i nie można zalogować się do panelu administracyjnego.

Wyłączenie WordPressowego crona

WordPress posiada wbudowany mechanizm automatycznego uruchamiania różnych procesów w określonych interwałach (np. co godzinę lub raz dziennie). W ten sposób są na przykład publikowane zaplanowane wpisy. Mechanizm ten jest bardzo przydatny, szczególnie że wtyczki mogą dodawać do niego własne procesy.

Działanie tego mechanizmu jest jednak uzależnione od ruchu na naszej stronie – proces zostanie uruchomiony tylko wtedy, gdy ktoś wejdzie na naszą witrynę. Dlatego też jeśli nasz serwis ma niewielką oglądalność lub chcemy uruchamiać zaplanowane procesy z najlepszą możliwą dokładnością, możemy sami zadbać o jego prawidłowe działanie.

W tym celu najpierw należy wyłączyć WordPressowego crona:

define('DISABLE_WP_CRON', true);

A następnie w panelu administracyjnym naszego serwera dodać do systemowego crona wywołanie co na przykład 15 minut takiego polecenia:

wget -q -O - http://nasza-domena.pl/wp-cron.php?doing_wp_cron >/dev/null 2>&1

Jeśli jednak korzystamy z domyślnego sposobu działania tego mechanizmu, to pomocna może okazać się stała WP_CRON_LOCK_TIMEOUT, za pomocą której ustalimy jak często mogą być uruchamiane procesy.

define('WP_CRON_LOCK_TIMEOUT', 60); // proces może być uruchamiany co najwyżej raz na minutę

Dzięki temu unikniemy sytuacji, w której jakaś wtyczka wymusi uruchamianie skryptu co 10 sekund, co może spowodować niepotrzebne obciążenie serwera (na przykład gdy co 10 sekund uruchamiany jest proces wykonujący się dłużej, niż 10 sekund).

Ustawienia ciasteczek (cookies)

WordPress pozwala na zmianę kilku parametrów ciasteczek, ale tak naprawdę przydatne jest tylko jedno ustawienie: COOKIE_DOMAIN.

define('COOKIE_DOMAIN', 'nasza-domena.pl');

Opcja ta pozwala na „wymuszenie” domeny, dla której ustawiane są ciasteczka. Dodawanie tej stałej do wp-config.php ma sens tylko wtedy, gdy korzystamy z subdomen do serwowania statycznych treści (na przykład obrazków czy innych multimediów) i nie chcemy, aby dla tych subdomen były ustawiane ciasteczka.

Wyłączenie edytora motywów i wtyczek w panelu administracyjnym

Zarówno z przyczyn związanych z bezpieczeństwem, jak i z możliwością łatwego zepsucia naszej strony, nie powinniśmy używać dostępnego w panelu administracyjnym WordPressa edytora wtyczek i motywów. Aby nikogo nie kusiła możliwość skorzystania z tego narzędzia, najlepiej jest po prostu je wyłączyć:

define('DISALLOW_FILE_EDIT', true);

Nieco bardziej restrykcyjną opcją jest DISALLOW_FILE_MOD, która wyłącza nie tylko edytor motywów i wtyczek, ale również możliwość ich instalacji i aktualizacji.

define('DISALLOW_FILE_MOD', true);

Wymuszenie logowania przez połączenie szyfrowane SSL

Jeśli cała nasza strona jest dostępna przez połączenie szyfrowane, to opcja ta nie ma dla nas większego znaczenia (co nie znaczy, że nie możemy jej – na wszelki wypadek – włączyć). Jeśli jednak nie posiadamy certyfikatu SSL, a mimo to chcielibyśmy wymusić logowanie i korzystanie z panelu administracyjnego przez połączenie szyfrowane (na przykład używając samodzielnie podpisanego certyfikatu), wystarczy ustawić stałą FORCE_SSL_ADMIN na true:

define('FORCE_SSL_ADMIN', true);

UWAGA: jeśli korzystamy z samodzielnie podpisanego certyfikatu SSL lub z certyfikatu SSL naszej firmy hostingowej, to przy pierwszym otwarciu strony w połączeniu szyfrowanym (https) przeglądarka wyświetli ostrzeżenie.

Blokowanie komunikacji z zewnętrznymi serwisami

Wiele wtyczek i motywów wysyła żądania HTTP do różnych zewnętrznych serwisów. Mogą one służyć do pobierania jakichś danych, sprawdzania uaktualnień czy wysyłania informacji o naszej stronie. Dotyczy to głównie produktów komercyjnych, bo wtyczki i motywy dostępne w oficjalnym repozytorium nie mogą tego robić (przynajmniej teoretycznie). Zwykle taka komunikacja nie stanowi żadnego zagrożenia, ale możemy zwyczajnie nie chcieć, aby coś takiego działo się na naszej stronie. Zdarza się też, że spowalnia to działanie naszej strony, na przykład gdy czas odpowiedzi zewnętrznego serwera jest zbyt długi lub gdy wysyłanych żądań jest zbyt dużo.

Za pomocą stałej WP_HTTP_BLOCK_EXTERNAL możemy całkowicie zablokować wysyłanie żądań HTTP do zewnętrznych serwisów. Możemy też odblokować wybrane domeny (np. api.wordpress.org) za pomocą stałej WP_ACCESSIBLE_HOSTS.

define('WP_HTTP_BLOCK_EXTERNAL', true);
define('WP_ACCESSIBLE_HOSTS', 'api.wordpress.org,*.github.com'); // zezwalamy na wysyłanie żądań do api.wordpress.org i całej domeny github.com

UWAGA: opcje te działają tylko dla żądań HTTP wykonywanych za pomocą HTTP API WordPressa. Nie mają one żadnego wpływu na inne metody komunikacji z serwerami zewnętrznymi (jak na przykład cURL), przez co w praktyce nie można na nich całkowicie polegać.

Usuwanie niepotrzebnych wersji obrazków

WordPressowy edytor obrazków po każdej edycji zapisuje na dysku serwera nowy zestaw (wszystkie rozmiary) plików i nie usuwa ich nawet gdy przywrócimy oryginalną wersję obrazka. Jeśli intensywnie korzystamy z tego narzędzia, to z czasem na serwerze możemy zgromadzić całkiem sporą kolekcję niepotrzebnych plików.

Stała IMAGE_EDIT_OVERWRITE zmienia działanie edytora. Po ustawieniu jej wartości na true na serwerze zapisywany jest tylko jeden komplet plików po edycji, który po przywróceniu oryginału jest automatycznie usuwany.

Wpis Sekrety pliku wp-config.php pochodzi z bloga WPzen.

Prawdopodobnie nikt z nas nie lubi oglądać reklam na stronach internetowych, podobnie jak nikt nie lubi oglądać filmów przerywanych co 20 minut 10-minutowym blokiem reklamowym. Dlatego powstał AdBlock – narzędzie (a raczej „narzędzia” – bo jest ich więcej) do blokowania reklam na stronach internetowych, które „czyści” je z wszelkiego rodzaju banerów i innych elementów reklamowych.

I mimo że wizja internetu bez reklam wydaje się świetna, to nieco mniej zadowoleni z popularyzacji AdBlocka są ci właściciele stron internetowych, którzy zarabiają właśnie na reklamach. Według Digital News Report 2016 aż 38% polskich użytkowników internetu korzysta z jakiegoś narzędzia do blokowania reklam (w czym notabene jesteśmy światowymi liderami). To ogromna liczba i ogromny problem zarówno dla dużych wydawców, jak i dla właścicieli mniejszych serwisów internetowych i blogów.

Użytkownicy WordPressa mają do dyspozycji kilka narzędzi pomocnych w walce z osobami blokującymi reklamy na stronach internetowych. Musimy mieć jednak świadomość, że jest to walka z wiatrakami.

W tym wpisie nie zachęcam do blokowania reklam ani do uprzykrzania życia osobom blokującym reklamy. Rozumiem zarówno osoby korzystające z AdBlocka, jak i ludzi próbujących zarabiać na wyświetlaniu reklam.

Jak działa AdBlock?

Narzędzia blokujące reklamy działają w oparciu o reguły (filtry), na podstawie których wykrywane są elementy reklamowe. W Sieci dostępne są gotowe listy takich filtrów – wystarczy dodać je do AdBlocka i cieszyć się internetem bez reklam.

Warto dodać, że narzędzia te mogą blokować dowolne elementy strony, nie tylko reklamy. Powstały na przykład listy filtrów pozwalające na blokowanie wszelkiego rodzaju skryptów zbierających dane na temat naszej aktywności w internecie.

Jak sprawdzić czy użytkownik korzysta z AdBlocka?

Najprostszą metodą na sprawdzenie czy osoba odwiedzająca naszą stronę używa oprogramowania blokującego reklamy jest… wyświetlenie mu reklamy. Na naszej stronie umieszczamy element, który powinien zostać zidentyfikowany przez AdBlocka jako reklama i ukryty (może to być oczywiście prawdziwa reklama). Następnie za pomocą prostego skryptu JavaScript sprawdzamy, czy element ten jest widoczny na stronie. Jeśli nie jest, to oznacza to, że użytkownik korzysta z AdBlocka.

Przykładowo, dodajemy sobie do naszej strony taki element:

<div class="adplacement" id="myadtest"></div>

A następnie sprawdzamy czy jest on widoczny (poniższy skrypt korzysta z jQuery):

<script type="text/javascript">
	jQuery(document).ready(function($) {
		if($('#myadtest').is(":visible")) {
			// Użytkownik nie ma AdBlocka
		}
		else {
			// Użytkownik korzysta z AdBlocka
		}
	});
</script>

Gdy wykryjemy, że osoba odwiedzająca naszą stronę używa AdBlocka, możemy wyświetlić jej jakiś komunikat albo wstawić w miejsce zablokowanej reklamy coś innego – ogranicza nas tylko nasza wyobraźnia.

Oczywiście robienie tego wszystkiego „ręcznie” byłoby dość czasochłonne (chociaż miałoby swoje zalety). Na szczęście mamy do dyspozycji kilka wtyczek, za pomocą których możemy skutecznie obrzydzić naszą stronę użytkownikom narzędzi blokujących reklamy.

Wtyczki pomagające w walce z użytkownikami blokującymi reklamy

Jak już wspomniałem, istnieje wiele wtyczek dla WordPressa, za pomocą których w ciągu kilku minut dodamy do naszej strony prośbę o wyłączenie AdBlocka, zastąpimy zablokowane reklamy alternatywną treścią lub (co szczerze odradzam) zablokujemy dostęp do naszej strony osobom blokującym reklamy.

AdBlock Notify

Wtyczka AdBlock Notify to przykład na to, że walka z oprogramowaniem blokującym reklamy jest walką z wiatrakami. Rozszerzenie to trafiło na „czarną listę”, z której korzystają te narzędzia, w związku z czym aby móc go używać należy… wyłączyć oprogramowanie blokujące reklamy. Nie ma to jednak większego wpływu na działanie wtyczki, bo problem dotyczy tylko panelu administracyjnego.

AdBlock Notify oferuje trzy metody informowania odwiedzających korzystających z AdBlocka, że nie podoba nam się blokowanie przez nich naszych reklam. Możemy wyświetlić im okienko z dowolnym tekstem (na przykład prośbą o rozważenie wyłączenia AdBlocka na naszej stronie) lub przekierować ich na dowolną stronę, na której opiszemy dlaczego nie mogą zobaczyć treści, po którą weszli na naszą stronę. Równolegle możemy też skorzystać z najmniej inwazyjnej metody walki z oprogramowaniem blokującym reklamy, czyli z wyświetlania w miejscu zablokowanej reklamy jakiejś zastępczej treści (na przykład prośby o wyłączenie AdBlocka lub jakiegoś obrazka).

Dodatkowo wtyczka zbiera dane na temat liczby odwiedzających blokujących reklamy i wyświetla statystyki w formie widżetu w Kokpicie. Wyłączając wszystkie opcje wtyczki możemy wykorzystać ją po prostu do zbierania tych danych, dzięki czemu będziemy w stanie określić, czy w przypadku naszej strony uprzykrzanie życia użytkownikom AdBlocka jest w ogóle warte zachodu.

Ustawienia wtyczki znajdziemy w menu AdBlock Notify. Możemy w nich wybrać sposób, w jaki będziemy traktować użytkowników blokujących reklamy (opcja Modal Box or Redirection – domyślnie wyłączona).

Jeśli wybierzemy opcję wyświetlania użytkownikom wyskakującego okienka (popup), w zakładce Modal Visual Options możemy ustalić treść, jaką będzie ono zawierać, oraz dostosować jego wygląd i kolorystykę. W zakładce Redirection Options możemy wybrać stronę, na jaką zostaną przekierowani użytkownicy korzystający z AdBlocka.

Ostatnia zakładka Alternative Message pozwala na zdefiniowanie treści, które pojawią się w miejscu zablokowanych reklam. Do dyspozycji mamy standardowy edytor wizualny WordPressa, tak więc możemy popuścić wodze wyobraźni (ale bez przesady). Warto zwrócić uwagę, że funkcja wyświetlania naszego tekstu w miejscu zablokowanych reklam jest domyślnie wyłączona.

Ad Blocking Detector

Wtyczka Ad Blocking Detector reprezentuje nieco inne podejście do tematu. Pozwala ona na definiowanie shortcode, które wyświetlają inną treść użytkownikom korzystającym z narzędzi blokujących reklamy, a inną użytkownikom, którzy ich nie używają. Można w ten sposób stworzyć również shortcode widocznego tylko dla jednej z wymienionych grup.

Ponieważ w treści shortcode można umieszczać kod HTML, jesteśmy w stanie wyświetlić w ten sposób praktycznie wszystko. Możemy przygotować komunikaty dla osób korzystających z AdBlocka, które w ogóle nie pojawią się pozostałym użytkownikom. Możemy umieścić na stronie reklamy, które po zablokowaniu zamienią się na jakiś tekst lub obrazek (a nawet inną reklamę). Shortcode można wstawiać zarówno do treści wpisów i stron, jak i do paneli bocznych, tak więc możliwości są naprawdę spore.

Ad Blocking Detector posiada moduł statystyk, dzięki któremu dowiemy się ile osób odwiedzających naszą stronę blokuje reklamy. Co ciekawe, możemy również sprawdzić, ilu odwiedzających, którzy przy pierwszym wejściu mieli włączonego AdBlocka, zdecydowało się na wyłączenie blokowania reklam, dzięki czemu jesteśmy w stanie mniej więcej oszacować skuteczność naszych działań.

Wtyczka dość dobrze radzi sobie z wykrywaniem narzędzi blokujących reklamy, ale nie zaszkodzi trochę jej w tym pomóc. Przede wszystkim warto zainstalować rozszerzenie Block List Countermeasure, które dodatkowo „maskuje” wtyczkę przed AdBlockami. Możemy to zrobić za pomocą przycisku Automatically Install Plugin na zakładce AdBlocking → Advanced Settings. W tym samym miejscu (opcja Global CSS Selectors) możemy dodatkowo podać listę selektorów (klasa lub ID elementu HTML), za pomocą których wtyczka ma identyfikować reklamy na naszej stronie.

Dla bardziej zaawansowanych technicznie właścicieli stron wtyczka oferuje dodatkowe możliwości. Można na przykład za pomocą CSS zmieniać wygląd strony lub jej poszczególnych elementów użytkownikom, którzy blokują reklamy. Jeszcze wieksze możliwości daje opcja uruchamiania własnych skryptów JavaScript. Więcej na ten temat znaleźć można w dokumentacji.

Czy takie wtyczki są skuteczne?

Nie ma oczywiście w stu procentach skutecznej metody na wykrywanie narzędzi blokujących reklamy, ale na pewno jesteśmy w ten sposób w stanie zidentyfikować znaczną większość ich użytkowników. Rzecz jasna gdy powstaje jakaś metoda na uprzykrzanie życia ludziom, to natychmiast powstają sposoby na jej ominięcie – takie jak na przykład Anti-Adblock Killer, czyli narzędzie, które służy do walki z wykrywaczami AdBlocków.

Zanim jednak włączymy się w wojnę z osobami blokującymi reklamy warto odpowiedzieć sobie na parę pytań. Czy aby na pewno zyski będą warte poświęconego czasu? Czy przy okazji nie zniechęcimy zbyt wielu osób do odwiedzania naszej strony? Czy w zamian za kilka lub kilkanaście centów z AdSense warto stracić czytelnika?

Wpis Jak sobie radzić z użytkownikami AdBlocka pochodzi z bloga WPzen.

Domyślnie w WordPressie wpisy są sortowane według daty publikacji – u góry strony znajduje się zawsze najnowszy tekst. W większości przypadków takie uporządkowanie treści jest odpowiednie, ale zdarzają się przypadki, w których chcielibyśmy posortować wpisy inaczej.

Specyficzną sytuacją jest sortowanie wpisów według daty ich modyfikacji. Takie uporządkowanie treści może sprawdzić się jeśli nie chcemy tworzyć nowych wpisów (na przykład dlatego, że istniejące mają już dobrą pozycję w wyszukiwarkach), ale jednocześnie chcemy, aby nasi czytelnicy zorientowali się, że dany wpis zawiera jakieś nowe informacje. Uaktualniony wpis zachowa się prawie tak samo, jak wpis nowy – czyli trafi na szczyt listy wpisów i do kanału RSS.

Zmiana sortowania wpisów

Warto wiedzieć, że WordPress sam z siebie zapisuje datę i czas modyfikacji wszystkich wpisów i stron, dzięki czemu zmiana sortowania wpisów nie jest trudna. Najprościej zrobić to za pomocą jednej z dostępnych w repozytorium wtyczek – ja wybrałem Posts Order. Po instalacji rozszerzenia wystarczy przejść do jego ustawień (Ustawienia → Posts order) i wybrać interesujące nas sortowanie wpisów.

Można ustawić kolejność pojawiania się wpisów osobno dla strony głównej (Homepage) i dla archiwów kategorii (Categories). Do wyboru jest sortowanie według identyfikatora wpisu, daty publikacji lub modyfikacji, tytułu, autora, adresu URL (slug) oraz atrybutu menu_order (o którym więcej można przeczytać w tym wpisie).

Oczywiście dokładnie taki sam efekt możemy osiągnąć bez korzystania z wtyczki. Aby nasze wpisy były wyświetlane według daty modyfikacji wystarczy do pliku functions.php lub do pliku wtyczki dodać taki kod:

function wpzen_reorder_posts($query) {
    if($query->is_main_query() && ($query->is_home() || $query->is_search() || $query->is_archive())) {
        $query->set('orderby', 'modified');
        $query->set('order', 'desc');
    }
}
add_action('pre_get_posts', 'wpzen_reorder_posts');

Warto zauważyć, że kod ten zmieni sortowanie tylko na stronie głównej (is_home()), na stronie wyników wyszukiwania (is_search()) i na stronach archiwów (is_archive()). Jeśli chcemy zostawić domyślne sortowanie wpisów na którejś z tych stron, wystarczy usunąć sprawdzanie wybranego warunku z kodu.

Wyświetlanie daty modyfikacji wpisu

Gdy już posortowaliśmy nasze wpisy według daty modyfikacji, to wypadałoby jeszcze tę datę gdzieś wyświetlić. Posłuży nam do tego funkcja the_modified_time(). Możemy ją wstawić w dowolnym miejscu w kodzie naszego motywu, pod warunkiem, że zrobimy to wewnątrz pętli wyświetlającej wpisy (The Loop). Można też poszukać w plikach motywu miejsca, w którym znajduje się wywołanie jednej z funkcji zwracających datę i/lub czas publikacji wpisu (the_date(), the_time(), get_the_date() lub get_the_time()). Niestety, tutaj wiele zależy od konkretnego motywu, tak więc nie jestem w stanie wskazać pliku, w którym należy szukać.

Jeśli nie czujemy się na siłach, aby samodzielnie znaleźć odpowiednie miejsce w kodzie motywu, możemy prawie automatycznie wyświetlić datę i czas modyfikacji wpisu nad lub pod jego treścią. Aby to zrobić wystarczy do pliku functions.php wstawić następujący kod:

// Wyświetlanie daty i czasu modyfikacji nad treścią wpisu
function wpzen_add_modified_time_before($content) {
    if(is_single()) {
        $content = get_the_modified_date().' '.get_the_modified_time().$content;
    }
    return $content;
}
add_filter('the_content', 'wpzen_add_modified_time_before');

// Wyświetlanie daty i czasu modyfikacji pod treścią wpisu
function wpzen_add_modified_time_after($content) {
    if(is_single()) {
        $content .= get_the_modified_date().' '.get_the_modified_time();
    }
    return $content;
}
add_filter('the_content', 'wpzen_add_modified_time_after');

Bonus: data modyfikacji w panelu administracyjnym

Skoro już sortujemy wpisy na stronie według daty modyfikacji, to dobrze byłoby jeszcze móc tę datę zobaczyć w panelu administracyjnym. Posłużyć się tutaj można wtyczką Last Modified Timestamp, która dodaje do listy wpisów nową kolumnę zawierającą czas ostatniej modyfikacji wpisu. Oczywiście listę wpisów możemy sortować według tej kolumny.

Wpis Sortowanie wpisów według daty modyfikacji pochodzi z bloga WPzen.

WordPress 4.7 wprowadził pełne REST API, poprzez które zewnętrzne aplikacje czy usługi mogą odczytywać wszystkie treści dostępne publicznie na naszej stronie, a po autoryzacji również je modyfikować i dodawać nowe. Idea tego interfejsu jest świetna i osobiście jestem jej wielkim zwolennikiem, ponieważ daje ona ogromne możliwości, dzięki którym WordPress może być wykorzystywany nie tylko do tworzenia stron, ale również jako CMS dla aplikacji mobilnych czy magazyn treści dla zewnętrznych serwisów i usług.

Interfejs ten ma jednak jedną wadę: każdy może z niego skorzystać, a domyślnie jest on włączony. Tak więc jeśli go nie używamy, to najlepiej po prostu go wyłączyć.

Wszystkie nasze treści dostępne dla każdego

Jak już wiemy, nie sposób zabezpieczyć naszych treści przed złodziejami – jeśli ktoś chce, to wyciągnie z naszej strony wszystko. W Internecie działa mnóstwo stron, które agregują treści bez wiedzy i zgody ich autorów. Pomijając sensowność tego procederu (Google jest coraz lepszy w rozpoznawaniu takich stron), nie jest to coś, co osoby poświęcające wiele godzin na tworzenie treści chciałyby widzieć.

Skrypty wyciągające teksty ze stron korzystają najczęściej z kanałów RSS. Oczywiście łatwo jest w ustawieniach WordPressa skonfigurować je tak, aby zawierały tylko fragmenty wpisów. W takim przypadku większość automatów daje sobie spokój, bo parsowanie strony w celu wyciągnięcia z niej treści wpisu jest już większym problemem.

Jednak niezależnie od ustawień kanałów RSS, REST API zawsze udostępnia całą treść wpisów. Aby to zobaczyć wystarczy w przeglądarce wpisać adres odpowiedniej metody API: http://nasza-domena.pl/wp-json/wp/v2/posts/ (działający przykład). To daje automatom do wyciągania treści ze stron możliwość szybkiego i taniego (zużywającego mało zasobów serwera) pobierania naszych wpisów.

Wszystko to dotyczy nie tylko wpisów, ale również stron, multimediów i komentarzy.

Pobieranie listy użytkowników

REST API udostępnia też metodę zwracającą listę wszystkich aktywnych użytkowników naszej strony. Mimo że lista ta nie zawiera oczywiście haseł ani adresów e-mail, to sam fakt jej dostępności jest już lekkim ułatwieniem dla złośliwych skryptów próbujących łamać hasła metodą brute force.

Jak wyłączyć REST API?

Przede wszystkim warto zaznaczyć, że nie ma tu żadnych powodów do paniki. Wszystkie dane udostępniane przez REST API są i tak w takiej czy innej formie dostępne na naszej stronie. Jednak jeśli nie korzystamy z REST API, to osobiście polecałbym jego wyłączenie.

Najprostszym sposobem na wyłączenie REST API jest dodanie takiego kodu do pliku functions.php motywu lub do pliku wtyczki:

add_filter('rest_authentication_errors', 'wpzen_disable_rest_api', 99);
function wpzen_disable_rest_api() {
	return new WP_Error('wpzen_rest_api_disabled', 'REST API disables', array('status' => 403));
}

Można też skorzystać z darmowej wtyczki REST API Toolbox, która pozwala nie tylko na wyłączenie całego REST API, ale również pojedynczych metod, dzięki czemu możemy na przykład wyłączyć możliwość pobierania wpisów, ale zostawić dostęp do komentarzy czy stron.

Po instalacji i aktywacji wtyczki wystarczy w panelu administracyjnym przejść do sekcji Ustawienia → REST API Toolbox i na zakładce General wyłączyć REST API i wsparcie dla JSONP. Jeśli chcemy wyłączyć tylko wybrane metody API, możemy to zrobić na zakładce Core.

Wpis Nie używasz REST API? To go wyłącz! pochodzi z bloga WPzen.

WordPress 4.7 przyniósł jedną małą zmianę, z której część użytkowników tego CMSa nie jest zadowolona: z edytora wizualnego usunięto przyciski pozwalające na justowanie oraz podkreślanie tekstu. Mimo że od wydania nowej wersji minęło już sporo czasu, wciąż pojawiają się pytania o możliwość przywrócenia usuniętych funkcji. Zobaczmy więc, dlaczego twórcy WordPressa zdecydowali się na tę kontrowersyjną zmianę oraz jak z powrotem dodać do edytora usunięte przez nich przyciski.

Dlaczego usunięto przyciski justowania i podkreślania tekstu?

Twórcy WordPressa wyjaśnili przyczyny podjęcia decyzji o usunięciu przycisków w tym wpisie. Podkreślanie tekstu może być mylące dla czytelników, ponieważ przyjęło się, że podkreśleniem wyróżniane są linki. Justowanie natomiast działa różnie w różnych przeglądarkach, a na dodatek nie jest dobre dla czytelności tekstu.

Mimo że argumenty te są sensowne, to moim zdaniem decyzje o używaniu lub nie danej funkcji edytora powinno się pozostawić użytkownikom.

Warto dodać, że mimo usunięcia przycisków z paska narzędzi edytora wizualnego, funkcje justowania i podkreślania tekstu wciąż działają i można z nich korzystać za pomocą skrótów klawiszowych.

Jak przywrócić przyciski justowania i podkreślania tekstu?

Sposób 1: wtyczka Re-add text underline and justify

Jak to zwykle przy takich zmianach w WordPressie bywa, bardzo szybko powstało kilka wtyczek, które pozwalają na łatwe przywrócenie usuniętych przycisków. Jedną z nich jest Re-add text underline and justify.

Po instalacji i aktywacji wtyczki wystarczy przejść do ustawień pisania (Ustawienia → Pisanie) i wybrać odpowiednią opcję w sekcji Editor style.

Pierwsza opcja to pozostawienie przycisków bez zmian (czyli wciąż ich nie będzie). Opcja druga dodaje usunięte przyciski, ale nie w tych miejscach, w których powinny się one znajdować. Opcja trzecia ustawia przywrócone przyciski w odpowiednich miejscach, a opcja czwarta przywraca tylko przycisk justowania i ustawia go w prawidłowym miejscu.

Sposób 2: wtyczka TinyMCE Advanced

O TinyMCE Advanced po raz pierwszy pisałem cztery lata temu. To bardzo dobra wtyczka pozwalająca na rozszerzenie edytora wizualnego WordPressa o mnóstwo dodatkowych funkcji. Posiada ona oczywiście również opcję dodania przycisków justowania i podkreślania tekstu. Zarządzanie dodatkowymi funkcjami edytora odbywa się w ustawieniach wtyczki (Ustawienia → TinyMCE Advanced).

Oczywiście jeśli nie korzystamy z tego rozszerzenia i nie jest nam do niczego potrzebne, to nie ma sensu instalować go tylko po to, aby przywrócić dwa przyciski – w takim przypadku lepiej skorzystać ze znacznie mniejszej wtyczki Re-add text underline and justify.

Wpis Jak przywrócić przyciski justowania i podkreślania tekstu pochodzi z bloga WPzen.

Przez wiele lat korzystając z WordPressa używałem praktycznie tylko edytora tekstowego, głównie dlatego, że lubiłem mieć całkowitą kontrolę nad formatowaniem tekstu. Jednak z czasem edytor wizualny TinyMCE stawał się coraz lepszy, a ja stawałem się coraz bardziej leniwy – i w końcu porzuciłem ręczne wstukiwanie znaczników HTML i postawiłem na komfort pracy.

Bardzo szybko zauważyłem, że z nieznanego mi powodu w moich tekstach pojawiają się same z siebie znaki twardej (niełamliwej) spacji, widoczne w kodzie strony jako  , powodujące niepotrzebne przenoszenie słów do kolejnych wierszy. Znaki te pojawiają się w różnych miejscach i trudno w ich ułożeniu dostrzec jakiś schemat. Na szczęście problem jest łatwy do rozwiązania, aczkolwiek jego przyczyna jest co najmniej dziwna.

Co i dlaczego wstawia twarde spacje do treści wpisów?

Problem z wstawianymi w losowych miejscach twardymi spacjami nie jest nowy – po raz pierwszy został zgłoszony ponad 3 lata temu i od tamtej pory nie został rozwiązany. Nie jest to ani błąd samego WordPressa, ani (wbrew pozorom) edytora wizualnego TinyMCE. Tak naprawdę to nie jest w ogóle błąd – to funkcja przeglądarki. Jak wyjaśniono w tym komentarzu, ponieważ w HTMLu wiele spacji jest zawsze wyświetlanych jako jedna spacja, przeglądarki próbują zachować widoczność wielu spacji zamieniając je na twarde (niełamliwe) spacje. Wygląda jednak na to, że niektóre przeglądarki (w szczególności Chrome) wstawiają te znaki w wielu miejscach, często wyglądających na losowe.

Problem ten jest dość trudno wychwycić, ponieważ znak niełamliwej spacji nie jest widoczny ani w edytorze wizualnym, ani w tekstowym – jest bowiem wstawiany jako biały znak o kodzie U+00A0, a dopiero w bazie danych i na stronie pojawia się jako  . Gdy jednak już go zauważymy, to da się go usunąć w edytorze tekstowym – po prostu wystarczy skasować znak wyglądający na spację i zastąpić go spacją. Brzmi to nieco dziwacznie, więc nie będziemy tak robić i zamiast tego poszukamy prawdziwego rozwiązania problemu.

Rozwiązanie problemu

Znalazłem kilka prób rozwiązań tego problemu, przy czym większość z nich albo już nie działa, albo nie działała nigdy. Skupię się więc tylko na tych, które na pewno się sprawdzą.

Pierwsza metoda to usuwanie zbędnych twardych spacji z treści wpisów przed ich wysłaniem do przeglądarki. Jest to sposób skuteczny i prosty – wystarczy do pliku functions.php motywu lub do pliku wtyczki dodać następujący kod:

function wpzen_remove_nbsps($string) {
	return str_replace("\xc2\xa0", " ", $string);
}
add_filter('the_excerpt', 'wpzen_remove_nbsps', 99);
add_filter('the_content', 'wpzen_remove_nbsps', 99);

Wadą tego rozwiązania jest to, że usuwa ono wszystkie twarde spacje, co nie zawsze jest pożądanym przez nas działaniem. Poza tym tak naprawdę usuwane są tylko objawy, a nie ich przyczyna – tekst w bazie danych wciąż będzie zawierał niepotrzebne twarde spacje.

Drugą (moim zdaniem lepszą) metodą jest usuwanie zbędnych twardych spacji w momencie zapisywania treści wpisu do bazy danych. Dzięki temu niezależnie od tego, ile zbędnych znaków zostanie dodanych na etapie edycji, do bazy danych (a co za tym idzie również na stronę) trafi wyczyszczony z nich tekst. Aby to zrobić należy do pliku functions.php motywu lub do pliku wtyczki dodać następujący kod:

function wpzen_remove_nbsps($content) {
	$content = str_replace(array("\xc2\xa0", " "), " ", $content);
	return $content;
}
add_filter('content_save_pre', 'wpzen_remove_nbsps');

Wadą tego rozwiązania jest to, że aby pozbyć się zbędnych znaków z danego wpisu musimy zapisać go w panelu administracyjnym (nie trzeba dokonywać w nim żadnych zmian – wystarczy kliknąć przycisk Zaktualizuj).

Wpis Jak rozwiązać problem wstawianych przez edytor wizualny twardych spacji pochodzi z bloga WPzen.

Wiele osób szukających najprostszego sposobu na założenie swojego pierwszego bloga wybiera usługę WordPress.com. Niestety, wybór ten w większości przypadków nie jest świadomy – taki wniosek wyciągam z liczby pytań o możliwość instalacji wtyczek i motywów, czego na WordPress.com po prostu nie da się zrobić. Jednak nawet jeśli ktoś wybiera tę usługę mając świadomość jej ograniczeń, to z czasem ograniczenia te stają się zbyt uciążliwe, a często wręcz uniemożliwiają dalszy rozwój prowadzonego serwisu.

Oczywiście najlepszą alternatywą jest zainstalowanie WordPressa na własnym serwerze. Daje nam to pełną swobodę w prowadzeniu naszego bloga: możemy instalować dowolne wtyczki i motywy, a w razie potrzeby swobodnie je modyfikować. Sporo osób boi się jednak, że nie poradzi sobie z przeniesieniem istniejącej strony z usługi WordPress.com na własną instalację WordPressa. Na szczęście nie jest to aż takie skomplikowane, co pokażę w dalszej części tego wpisu.

Operację przenosin bloga z usługi WordPress.com na własny serwer podzieliłem na kilka kroków. Nie idź na skróty! Tylko poprawne wykonanie wszystkich czynności gwarantuje bezproblemowe przeniesienie strony.

1. Wybieramy hosting (serwer)

Hosting to usługa, w ramach której otrzymujemy kawałek serwera, na którym możemy zainstalować WordPressa i prowadzić swoją stronę internetową. Wybór odpowiedniego hostingu to chyba najtrudniejszy etap przenosin. Firm oferujących tego typu usługi jest mnóstwo, a niestety nie da się jednoznacznie wskazać najlepszej. Można posiłkować się rankingiem serwisu WebHostingTalk albo opiniami publikowanymi w internecie (na przykład na forum serwisu WebHelp.pl), ale nie ma gwarancji, że dokonany w ten sposób wybór będzie dobry.

O tym, na co powinniśmy zwrócić uwagę wybierając hosting dla naszej strony, można przeczytać w tym wpisie.

2. Kupujemy domenę

Domena to adres internetowy naszej strony (np. wpzen.pl). Większość firmy hostingowych ma je w swojej ofercie, tak więc możemy po prostu kupić domenę tam, gdzie kupiliśmy serwer dla naszej strony. Często firmy do serwera dodają pierwszy rok utrzymania domeny za symboliczną złotówkę – warto skorzystać z takiej promocji, ale trzeba też upewnić się, że zwykły koszt domeny w wybranej przez nas firmie nie jest zawyżony (po pierwszym roku będziemy musieli zapłacić normalną cenę).

Jeśli już mamy domenę podpiętą do naszego bloga w usłudze WordPress.com, to oczywiście nie musimy kupować nowej – wystarczy że podepniemy tę domenę do nowego serwera.

3. Instalujemy WordPressa

Proces instalacji WordPressa jest bardzo prosty i zajmuje dosłownie kilka minut. Jego opis znaleźć można w rozdziale Instalacja mojego Podręcznika dla początkujących.

Wiele firm hostingowych oferuje automatyczną instalację WordPressa na serwerze. Nie polecam korzystać z tego typu instalatorów. Nie są one wielkim ułatwieniem (zwykła instalacja WordPressa naprawdę nie jest ani trudna, ani czasochłonna), a zdarza się, że występują problemy przy przenoszeniu takich stron na inny serwer.

Zakładam, że kupiona domena jest już podpięta do naszego konta hostingowego, czyli wskazuje na naszą świeżą instalację WordPressa.

4. Kopiujemy treści z istniejącej strony

To najważniejszy etap przenosin – od niego zależy bowiem, w jakim stopniu treści przeniesionego bloga będą odpowiadały oryginałowi prowadzonemu w usłudze WordPress.com.

Najpierw musimy wykonać eksport treści z usługi WordPress.com. Robi się to w panelu zarządzania witryną na ekranie Ustawienia → Eksportuj (można też po prostu udać się pod ten adres). Wystarczy kliknąć przycisk Export All, a po chwili pojawi się link pozwalający na pobranie pliku ZIP z wyeksportowanymi wpisami (link ten zostanie wysłany też na nasz adres e-mail).

Domyślnie eksportowane są wszystkie wpisy i strony znajdujące się na blogu. Można jednak wyeksportować tylko wybrane treści. Aby to zrobić należy kliknąć ikonkę strzałki znajdującą się po prawej stronie przycisku Eksport All. Spowoduje to pojawienie się listy filtrów, dzięki którym możemy wyeksportować na przykład tylko wpisy z wybranej kategorii lub z konkretnego okresu.

W pobranym pliku ZIP znajduje się jeden plik XML, zawierający wszystkie treści z naszego bloga. Teraz musimy zaimportować go do naszej nowej instalacji WordPressa. W tym celu wchodzimy do panelu administracyjnego i przechodzimy do sekcji Narzędzia → Import, gdzie na liście importerów wyszukujemy WordPressa i instalujemy go klikając link Zainstaluj teraz (o ile nie mamy go jeszcze zainstalowanego).

Po instalacji w tym samym miejscu pojawi się link Uruchom Importer, który oczywiście klikamy aby uruchomić proces importu.

Na kolejnym ekranie klikamy przycisk Wybierz plik i wybieramy pobrany z WordPress.com plik XML (nie ZIP!), a następnie klikamy przycisk Wyślij plik na serwer i zaimportuj go. Jeśli na naszym blogu znajduje się dużo wpisów, przejście do kolejnego kroku może potrwać dłuższą chwilę.

Na kolejnym ekranie zobaczymy listę autorów, których wpisy znajdują się w naszym pliku XML. Wpisy każdego z autorów możemy przypisać do wybranego istniejącego na nowym blogu użytkownika (assign posts to an existing user) lub do nowego autora (create new user with login name).

Na koniec zaznaczamy opcję Download and import file attachments, dzięki której WordPress automatycznie pobierze z naszego „starego” bloga wszystkie obrazki umieszczone we wpisach i doda je do biblioteki mediów na naszym nowym blogu, a następnie uaktualni odpowiednie adresy URL. Moim zdaniem opcja ta powinna być domyślnie włączona, bo zdarza się, że użytkownicy zapominają o niej i importują wpisy bez multimediów (nie da się później zaimportować samych obrazków – trzeba całą operację zaczynać od nowa).

Import wpisów uruchamiamy klikając przycisk Submit. Proces ten może zająć trochę czasu. Po jego pomyślnym zakończeniu zobaczymy komunikat All done. Have fun!.

5. Instalujemy motyw

Jeśli na WordPress.com korzystaliśmy z któregoś z darmowych motywów, to możemy go również zainstalować w WordPressie zainstalowanym na własnym serwerze. Większość tych motywów znaleźć można w oficjalnym repozytorium, a pozostałe można bez problemu pobrać z WordPress.com.

Motywy instalujemy w panelu administracyjnym w sekcji Wygląd → Motywy → Dodaj nowy, gdzie możemy po prostu wyszukać interesujący nas motyw i zainstalować go klikając przycisk Zainstaluj. Jeśli chcemy zainstalować motyw pobrany z WordPress.com (lub z innego źródła), klikamy przycisk Wyślij motyw na serwer, a następnie wybieramy pobrany plik ZIP i klikamy przycisk Zainstaluj teraz.

Oczywiście nic nie stoi na przeszkodzie, aby wybrać inny motyw niż dotychczas używany. W tym wpisie zakładam jednak, że naszym celem jest wykonanie jak najwierniejszej kopii istniejącego bloga.

6. Konfigurujemy nowego bloga

Niestety, nie ma możliwości eksportu i importu konfiguracji naszego bloga, tak więc musimy zrobić to ręcznie. Zaczynamy od przeniesienia wszystkich ustawień znajdujących się w sekcji Ustawienia panelu administracyjnego. Jeśli korzystaliśmy z Personalizatora (Wygląd → Dostosuj), to powinniśmy przejrzeć wprowadzone na WordPress.com modyfikacje i wykonać je również na nowym blogu.

Ponieważ teraz to my jesteśmy odpowiedzialni za działanie naszego bloga, musimy przede wszystkim zadbać o regularnie i dobrze wykonywaną kopię bezpieczeństwa. Warto również zapoznać się z podstawowymi zasadami dotyczącymi zabezpieczania WordPressa.

7. Instalujemy wtyczkę Jetpack (opcjonalnie)

W panelu administracyjnym strony w usłudze WordPress.com znajduje się sekcja Wtyczki, w której znajdziemy ustawienia wtyczki Jetpack. Jest to bezpłatne rozszerzenie, które możemy zainstalować na własnej stronie, a które wzbogaca WordPressa zainstalowanego na własnym serwerze o niektóre funkcje dostępne w usłudze WordPress.com. Jeśli korzystamy (i wciąż chcemy korzystać) z którejś z tych funkcji, to musimy zainstalować tę wtyczkę.

Jeśli nie wiesz, czy wszystkie te funkcje są Ci do czegoś potrzebne, to prawdopodobnie możesz się bez nich obejść i nie musisz instalować Jetpacka.

8. Zmieniamy adres bloga

Ten krok wykonujemy tylko jeśli nasz blog miał adres w domenie wordpress.com.

Jeśli wszystkie poprzednie kroki zostały poprawnie wykonane, to pod nowym adresem znajduje się kopia naszego bloga. Problem w tym, że strona jest wciąż dostępna pod starym adresem (w domenie wordpress.com). Oczywiście możemy ją po prostu usunąć, ale wtedy osoby wchodzące na któryś ze starych adresów (na przykład z Google albo z umieszczonych gdzieś w Internecie linków) zobaczą tylko komunikat o nieistniejącej stronie.

Najlepszą metodą na wskazanie naszym odwiedzającym nowego adresu naszej strony jest ustawienie przekierowania ze starego adresu (w domenie wordpress.com) na nowy adres (czyli kupioną przez nas domenę). Niestety, jest to opcja płatna i nie istnieją żadne alternatywne metody. Na szczęście koszt nie jest duży i wynosi 13 dolarów rocznie.

Aby ustawić przekierowanie należy w panelu administracyjnym WordPress.com przejść do sekcji Redirect a Site, która znajduje się pod tym adresem. Z listy wybieramy bloga, dla którego chcemy ustawić przekierowanie, a następnie wpisujemy jego nowy adres i klikamy przycisk Go. Zostaniemy przekierowani do formularza płatności, po wykonaniu której nasze przekierowanie zostanie ustawione. Od tej pory wszyscy użytkownicy wchodzący na stary adres naszego bloga będą automatycznie przenoszeni pod nowy adres.

Dobrze byłoby też wskazać wyszukiwarce Google nowy adres naszego bloga. Oczywiście ustawione przekierowanie załatwi sprawę i w końcu w indeksie wyszukiwarki nasza strona pojawi się pod nowym adresem, ale nie zaszkodzi trochę pomóc Google i przyśpieszyć cały proces.

Aby to zrobić należy dodać „starego” i „nowego” bloga do narzędzia Search Console (instrukcję można znaleźć tutaj), a następnie skorzystać z funkcji zmiany adresu strony. Wszystkie czynności są dość dokładnie opisane w oficjalnej dokumentacji, tak więc nie ma sensu abym je tutaj dodatkowo omawiał.

I to w zasadzie wszystko. Teraz możemy wprowadzić na naszym blogu wszystkie te funkcje, których z uwagi na ograniczenia usługi WordPress.com wprowadzić nie mogliśmy. Pamiętajmy jednak, że co za dużo, to nie zdrowo i we wszystkim należy zachować umiar.

Wpis Przenoszenie strony z WordPress.com na własny serwer pochodzi z bloga WPzen.

Instalujemy i aktywujemy wtyczkę, po czym okazuje się, że przez znajdujący się w niej błąd lub przez naszą nie do końca poprawną modyfikację wtyczka ta przestaje działać, odcinając nas jednocześnie od panelu administracyjnego. Każdy, kto próbował eksperymentować z WordPressem, na pewno znalazł się kiedyś w takiej sytuacji. Jedyna rada to oczywiście wyłączenie wtyczki, ale… nie mamy przecież dostępu do panelu administracyjnego. Na szczęście istnieje prosty sposób na dezaktywację wtyczki w takiej awaryjnej sytuacji.

Aby wyłączyć wtyczkę bez dostępu do panelu administracyjnego musimy mieć dostęp do naszego serwera przez SFTP (lub FTP – czego nie polecam). Dostęp taki powinniśmy mieć zawsze – jeśli nie wiemy jak połączyć się w ten sposób z naszym serwerem, warto zajrzeć do dokumentacji lub poprosić firmę hostingową o pomoc.

Aby połaczyć się z serwerem przez SFTP musimy skorzystać z jakiegoś klienta SFTP. Dobrym wyborem jest bezpłatna FileZilla, dostępna dla systemów operacyjnych Windows, OS X / Mac OS i Linux. Wiele firm hostingowych również poleca ten program i często umieszcza w dokumentacji szczegółowe informacje na temat jego konfiguracji.

Po połączeniu z serwerem musimy przejść do katalogu, w którym znajdują się pliki naszej strony. Najczęściej będzie to katalog public_html, ale może się nazywać inaczej – jeśli nie wiemy jak, warto zajrzeć do dokumentacji udostępnianej przez naszą firmę hostingową. Następnie przechodzimy do katalogu /wp-content/plugins/, w którym znajdują się wszystkie zainstalowane wtyczki.

Teraz wystarczy zmienić nazwę katalogu wtyczki, którą chcemy wyłączyć. Aby to zrobić klikamy prawym przyciskiem myszy na wybrany katalog i wybieramy opcję Zmień nazwę. Ja zwykle dodaję znak _ na początku nazwy katalogu, dzięki czemu ląduje on u góry listy katalogów. Po zmianie nazwy katalogu otwieramy w przeglądarce panel administracyjny naszej strony, który teraz powinien już działać.

Po wejściu w panelu na stronę Wtyczki zobaczymy komunikat, że nasza wtyczka została wyłączona, ponieważ nie znaleziono jej plików. Mimo to wtyczka będzie wciąż widoczna na liście zainstalowanych rozszerzeń (nie będzie jednak aktywna). Dzieje się tak dlatego, że wtyczka ta nadal znajduje się na naszym serwerze, tyle że w innym katalogu (pod zmienioną przez nas nazwą). Jeśli chcemy ponownie aktywować wtyczkę, należy zmienić nazwę jej katalogu na oryginalną. Nie jest to konieczne do jej aktywacji, ale jest wymagane przez mechanizm aktualizacji rozszerzeń WordPressa (rozpoznaje on wtyczki po nazwie katalogu).

Wpis Jak wyłączyć wtyczkę bez dostępu do panelu administracyjnego pochodzi z bloga WPzen.