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.

Jeśli zamierzamy kupić sprzęt, który dopiero co trafił na półki w sklepach, to prawdopodobnie zaraz po podłączeniu go do naszego komputera okaże się, że to urządzenie nie jest nawet wykrywane przez system operacyjny. W przypadku gdy jego producent zapewnia w miarę przyzwoity support, to być może problemy, których doświadczamy, zostaną rozwiązane wraz z instalacją najnowszego kernela. Co jednak w przypadku gdy nawet po aktualizacji kernela nie jesteśmy w stanie odpalić, np. nowo zakupionej karty WiFi? Jako, że te wszystkie sprzęty działają w oparciu określone moduły, wystarczy taki moduł pozyskać, skompilować i załadować w systemie. Problem w tym, że z każdą nową wersją jądra operacyjnego, która trafi do repo debiana, będziemy musieli ręcznie budować moduł na nowo i właśnie w tym artykule opiszę jak nauczyć system, by sam przeprowadzał tę mozolną czynność bez naszego udziału.

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.

Wszystkie główne dystrybucje, a może raczej ich środowiska graficzne, wykorzystują do odtwarzania dźwięku serwer PulseAudio. Niektóre wręcz są tak z nim zżyte, że nie idzie ich oddzielić od siebie. Ja generalnie uważam, że ten kawałek oprogramowania jest jak najbardziej przydatny człowiekowi i potrafi realizować kilka kwestii, które bez niego, albo by nie były możliwe do osiągnięcia, albo trzeba by się natrudzić przy ich implementacji, np. przesyłanie dźwięku przez sieć. U siebie na debianie nigdy nie miałem większych problemów z PulseAudio, z kolei zaś te, które się przytrafiały na drodze jego użytkowania, szło w miarę prosty sposób wyeliminować. Jest jednak jeden problem, z którym prawdopodobnie spotkaliśmy się wszyscy, przynajmniej jeśli wykorzystujemy mikrofon w stopniu większym niż przeciętny użytkownik komputera. Chodzi o to, że po odpaleniu pewnych aplikacji (lub też i w trakcie ich działania), takich jak np. Skype, Mumble, czy TeamSpeak3, dźwięk we wszystkich pozostałych programach potrafi zwyczajnie zdechnąć.

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.

System rewizji postów to nic innego jak wersjowanie kolejnych zmian tworzonych artykułów za pomocą WordPress'owego edytora. Domyślnie ten ficzer jest włączony i powoduje nadmierne rozrastanie się bazy danych, a to z tego powodu, że każda drobna poprawka, to kolejna wersja artykułu, która wędruje do bazy. Nie ma przy tym żadnego ograniczenia co do ilości przechowywanych rewizji. Tego typu mechanizm jest w wielu przypadkach bardzo użyteczny, no bo przecie mamy podgląd wszelkich zmian wprowadzanych do postów i dodatkowo możemy te zmiany śledzić na przestrzeni tygodni, miesięcy czy nawet i lat.

Na stronie Apache jest kawałek ciekawego artykułu na temat zagrożeń jakie niesie ze sobą stosowanie pliku .htaccess w katalogach stron trzymanych na serwerze wwww. Oczywiście, w pewnych sytuacjach, takich jak np. hostingi, nie będziemy mieć innego wyboru jak zdać się na ten plik ale jeśli mamy bezpośredni dostęp do konfiguracji Apache, możemy przenieść wszystkie te wpisy z pliku .htaccess i poprawić tym bezpieczeństwo witryny jak i po części wydajność samego serwera www.