Jeśli piszemy dużo na swoim blogu i mamy sporo treści, którą trzeba uaktualnić, to prawdopodobnie często wprowadzamy poprawki polegające na usuwaniu starych wpisów i tworzeniu szkiców nowych artykułów. Tego typu rotacja sprawia, że sporo wiadomości ląduje w koszu, z tym, że jeśli chodzi o bazę danych, to jej jest bez różnicy czy przenieśliśmy dany post do kosza, przynajmniej do momentu gdy faktycznie on wyleci z bazy danych. Także pod względem objętości bazy nic się nie zmienia. Poza tym, WordPress potrafi opróżniać kosz co pewien czas i dla jednych ten interwał może być za krótki, a dla innych za długi. Postaramy się więc go dostosować.

Ostatnio opisywałem skrypt wp-cli , który posiada ciekawe możliwości pod względem zarządzania instalacją i konfiguracją WordPressa. W tym artykule postaram się przebrnąć przez ten proces wykorzystując jedynie powyższe narzędzie. Nie mam zamiaru korzystać z przeglądarki i nie będę przy tym nawet potrzebował odwiedzać strony WordPressa w celu pobrania jakichkolwiek plików. Wszystkie poniższe kroki zostaną przeprowadzone w terminalu na serwerze i mam nadzieję, że uda mi się pobrać, zainstalować i przygotować WordPressa do pracy.

Narzędzie wp-cli to wiersz poleceń upchnięty w pliku .phar (PHP Archive), przy pomocy którego możemy zarządzać instalacją WordPress'a bez potrzeby zaprzęgania do tego przeglądarki. Przy pomocy tego skryptu będziemy w stanie instalować i aktualizować rdzenne pliki WordPress'a, jego wtyczki i motywy, a także dokonywać szeregu operacji na bazie danych. Projekt jest na licencji MIT, zaś jego źródła są dostępne na githubie.

By dokonywać jakichkolwiek zmian w WordPressie (i mowa tu nie tylko o dodawaniu treści ale także zmianie jego plików źródłowych), to musimy uzyskać dostęp do panelu administracyjnego, a tu z kolei możemy się dostać tylko za pośrednictwem formularza logowania. Panel admina możemy wywołać przez dopisanie do adresu strony wp-admin/ , z tym, że jeśli nie jesteśmy zalogowani, to automatycznie zostaniemy przekierowani na wp-login.php . Nie oznacza to bynajmniej, że nie możemy wykonać zapytania do plików znajdujących się w katalogu wp-admin/ . Obie te powyższe lokalizacje muszą być traktowane ze szczególną ostrożnością, a dostęp do nich limitowany i bardzo restrykcyjny.

Standardowo WordPress dorzuca nieco informacji na swój temat bezpośrednio do kodu wygenerowanej witryny. Jednym z bardziej niebezpiecznych takich dodatkowych wpisów jest wskazówka na temat zainstalowanej wersji skryptu. Oczywiście, że powinniśmy aktualizować WordPressa na bieżąco i możliwie od razu jak tylko zostanie wypuszczona jego nowa wersja ale nie zawsze możemy nadążyć za tymi wszystkimi zmianami i wyrobić się w terminach. Ja jestem też zdania, że kluczowe oprogramowanie (zwłaszcza w internecie) powinno posiadać wersję nie do ustalenia, albo chociaż jakiś mylący ciąg znaków, tak by automatyczne ataki opierające się o wersję danej aplikacji, nie tyle zostawiły nas w spokoju, co zaczęły popełniać błędy, które będą widoczne w logach. Przynajmniej takie jest optymistyczne założenie.

WordPress, jako jeden z popularniejszych CMSów, został przetłumaczony na wiele języków, w tym też i na polski. Czasem jednak przez zwykłe roztargnienie (lub też i z innych przyczyn) możemy nie przestawić opcji odpowiedzialnej za język, wobec czego zainstaluje nam się angielska wersja WordPressa. W tym krótkim wpisie zostanie zawartych kilka informacji na temat tego jak zmienić język, na wypadek gdybyśmy odziedziczyli angielską wersję skryptu oraz też jak przebiega sam proces lokalizacji tekstu w WordPressie i co się tak naprawdę dzieje po wybraniu innego języka.

Być może kiedyś zdarzy się nam taka sytuacja, gdzie zwyczajnie zapomnimy hasła do konta admina na naszym blogu opartym o skrypt Wordpressa. Standardowo ten CMS nie wymaga od nas byśmy podawali hasło przy przeprowadzaniu szeregu operacji w panelu administracyjnym, w przeciwieństwie do usług świadczonych choćby przez google. Jeśli zdarzy nam się zgubić albo zapomnieć takie hasło, to mamy cały wachlarz rozwiązań, z którego możemy skorzystać, by hasło odzyskać.

Typografia ma na celu wprowadzenie pewnego rodzaju urozmaiceń do pisanego tekstu, takich jak np. bardziej zawinięte ogonki w cudzysłowach, albo zmianę ich pozycji (lewy dolny róg, zamiast górnego), czy też mniejszy odstęp między trzema kropkami lub ewentualnie łączenie kilku myślników w jeden dłuższy. W WordPressie ten mechanizm automatycznie będzie przepisywał nam te powyższe znaki (i wiele innych), co w przypadku systemów linuxowych nie zawsze jest rzeczą pożądaną, a to z tego względu, że np. skrypty shellowe, czy polecenia systemowe, korzystają jedynie z prostych apostrofów ' oraz prostych cudzysłowów " i wszelkie inne odpowiedniki, to inny numerek w tablicy kodowej, a więc i inny znak. Wobec czego, tak skopiowany tekst (czy skrypt) będzie zawierał błędy składni.

Gdy wprowadzamy sporo zmian na swoim blogu i nie mam tutaj na myśli dodawania/edytowania/usuwania postów, a jedynie przeróbki dotyczące zmiany wyglądu motywu czy też instalowanie i konfigurowanie nowych wtyczek, to istnieje spore prawdopodobieństwo, że gdzieś wystąpi jakiś błąd, który może zagrażać bezpieczeństwu całej witryny. Dlatego też warto wiedzieć, że WordPress posiada obsługę trybu debug, który może nam te wszystkie problemy z działaniem serwisu uwidocznić. Nie jest on jednak standardowo włączony, z oczywistych względów ale jeśli zajdzie taka potrzeba, to możemy sobie ten tryb debugowania aktywować i sprawdzić czy są jakieś błędy, ostrzeżenia czy też inne dodatkowe informacje, które mogą nam w jakiś sposób pomóc.

WordPress dysponuje bardzo rozbudowanym edytorem, przy pomocy którego można tworzyć dość zaawansowane posty. Ten edytor potrafi nawet automatycznie zapisywać stan artykułu przesyłając w ten sposób zmiany do bazy danych, co zapobiega utracie treści. Oczywiście, że potrzebna będzie dodatkowa przestrzeń w samej bazie by kolejną kopię postu przechować ale wydaje się to niebyt wygórowaną ceną za minimalizowanie ryzyka utraty części albo i całego wpisu.