Poradniki - Codovado – Agencja Interaktywna z Katowic

WordPress – zabezpieczenie przed włamaniem. Praktyczne i skuteczne porady.

Jak zabezpieczyć WordPressa?

WordPress to najpopularniejszy system CMS na świecie. Popularność oraz ilość gotowych rozwiązań, które oferuje, wiąże się także z dużą ilości zagrożeń – tym bardziej, że wgląd do kodu tych rzeczy może mieć każdy.

Jak temu zapobiec? Przedstawimy kompletny poradnik dotyczący profilaktyki bezpieczeństwa systemu WordPress.

Artykuł powstał przy współpracy z wisedigital.pl

Wstęp

WordPress to jeden z najczęściej wybieranych systemów zarządzania treścią w internecie. Według oficjalnych statystyk, aż 455 milionów stron internetowych na świecie korzysta z tego systemu, a każdego dnia powstaje średnio 650 nowych stron.

Wykorzystywany jest on do robienia prostych stron na gotowych motywach, jak również rozbudowanych witryn opartych o dedykowane rozwiązania. WooCommerce, które jest rozszerzeniem e-commerce do tego systemu, stanowi również bardzo duży procent platform e-commerce na świecie. 

Popularność ta jednak niesie ze sobą wiele zagrożeń ze strony cyberprzestępców – tym bardziej, że WordPress jest projektem GPL na licencji OpenSource i wgląd do jego kodu ma każdy. Podobna sytuacja ma się również do wtyczek czy motywów. 

Należy pamiętać, że nawet najlepsze zabezpieczenia i dbanie o WordPressa, nigdy całkowicie nie wyklucza zagrożenia i nie zapewni Ci stuprocentowego bezpieczeństwa.

Dzisiejszy poradnik to zbiór porad zdobytych na przestrzeni lat pracy z tym systemem oraz od społeczności WordPressa. Nasz poradnik nie zawiera zestawienia wtyczek, którym magicznie zabezpieczymy naszą stronę, a idzie w zupełnie odwrotnym kierunku.

Po co atakuje się WordPressa?

Powodów jest wiele i nie ma tutaj znaczenia, czy nasza strona jest dużym portalem internetowym, czy stroną lokalnego warsztatu samochodowego.

Najczęstsze przyczyny atakowania WordPressa to:

  • Spamerskie linki, dzięki którym osoba atakująca zyskuje profity.
  • Przekierowania na inne strony internetowe, również w celach zyskiwania profitów.
  • Wysyłka spamu w komentarzach lub na mail właściciela.
  • Ataki DDoS powodujące przeciążenia i próby włamania na serwer.
  • Zarażanie innych stron znajdujących się na serwerze.
  • Wykorzystywanie zasobów serwera do kopania kryptowalut.
  • Backdoor w celu wykradania poufnych danych.
  • Złośliwość konkurencji.

Jakie może to mieć konsekwencje w praktyce?

Brak stosowania odpowiednich praktyk zabezpieczających może grozić naprawdę nieprzyjemnymi konsekwencjami. Jak w praktyce objawia się atak na naszą stronę?

  • Google będzie zrzucać stronę z pozycji wyników wyszukiwania, a w najgorszym wypadku może ona zostać z nich całkowicie wykluczona. Twoja strona może atakować inne strony, co może skutkować wpisaniem jej na czarną listę domen, a proces przywracania jest długi i czasem kosztowny.
  • Kampanie reklamowe Google Ads będą odrzucane, co zresztą samo Google argumentuje, że próbujemy kierować na zainfekowaną stronę.
  • Pod twoją domeną będą indeksowane spamerskie linki np. witryn pornograficznych, reklamowych lub próbujących zawirusować komputer użytkownika. 
  • Dodatkowo mogą zostać ustawione przekierowania na ww. strony w momencie wejścia na naszą stronę, co może negatywnie wpływać na wizerunek firmy.

Brzmi groźnie? Bo takie właśnie jest!

Bezpieczeństwo zaczyna się już na etapie wyboru serwera

Istnieje wiele czynników, które powinieneś brać pod uwagę przy wyborze hostingu, aby zapewnić sobie jak najlepsze warunki spełniania standardu bezpieczeństwa:

  • Zweryfikuj opinie użytkowników korzystających z hostingu. Pozwoli to wykluczyć stosowanie przez dany hosting nieczystych praktyk typu modyfikacje plików stron, a także weryfikować opinie na temat supportu serwera i jego dostępności.
  • Sprawdź, czy serwer wspiera najnowszą wersję PHP, która jest fundamentem poprawnego wsparcia i działania najnowszych wersji WordPressa.
  • Upewnij się, że hosting ma system kopii zapasowych.
  • Dowiedz się, czy w przypadku posiadania kilku stron na jednym serwerze jest zapewniona separacja domen.
  • Sprawdź, czy hosting posiada mechanizm anty-DDoS i umożliwia połączenie SFTP / SSH.

Po tym krótkim wstępie nadeszła pora przejść do meritum, czyli profilaktyki bezpieczeństwa systemu – co robić oraz czego nie robić?

W większości niniejsze porady nie wymagają wiedzy technicznej, ale nie w każdym przypadku. Dlaczego? W wielu przypadkach trudno jest zabezpieczyć WordPressa bez ingerencji w warstwę serwerową, gdzie powinny zaczynać się wszelkie asekuracje.

Nie instaluj wtyczek zabezpieczających

Wtyczki bezpieczeństwa są prawdopodobnie ostatnią rzeczą, jaką powinniśmy zainstalować na stronie internetowej opartej na WordPressie.

Tego typu rozwiązania złudnie budują poczucie bezpieczeństwa i usypiają naszą czujność, a to właśnie te wtyczki stanowią 90% podatności na wszelkiego rodzaju ataki.

Dodatkowo bardzo często manipulują wynikami skanowania, aby zachęcać użytkownika do zakupu wersji PRO takiej wtyczki, która usunie to zagrożenie. W rzeczywistości takie zagrożenie może w ogóle nie istnieć.

Do najpopularniejszych wtyczek bezpieczeństwa zaliczamy: Wordfence, Securi, iThemes Security Pro, All in One WP Security.

Oczywiście tych wtyczek jest znacznie więcej, ale mimo wszystko nie instalujemy takich rozwiązań. 

Wtyczki bezpieczeństwa ze względu na swoją popularność są bardzo chętnie atakowane. Dodatkowo warto brać pod uwagę fakt, że same posiadają luki bezpieczeństwa:

Jeżeli wtyczka mająca zapewnić nam bezpieczeństwo, sama posiada luki w bezpieczeństwie, to chyba coś tu jest nie tak.

#ProTIP: wszelkiego rodzaju zabezpieczenia rób tylko i wyłącznie z poziomu serwera, a nie z poziomu panelu administracyjnego WordPressa.

Nie instaluj wtyczek optymalizujących

W przypadku wtyczek optymalizacyjnych sytuacja jest bardzo podobna do tej z wtyczkami zabezpieczającymi. Wtyczki te również są bardzo popularne i chętnie instalowane, ale również podobnie chętnie atakowane, co wtyczki zabezpieczające. 

Do takich najpopularniejszych wtyczek zaliczamy: WP Fastest Cache, W3 Total Cache, Autoptimize, WP-Optimize, WP Super Cache, WP Fastest Cache.

Dodatkowo te wtyczki są mocno niewskazane dla WooCommerce, ze względu na błędy, z którymi będą spotykać się użytkownicy sklepu i tutaj również optymalizacja powinna zostać wykonana tylko z poziomu serwera – oczywiście jeżeli wymaga tego dana strona, ale optymalizacja to temat na osobny artykuł.

Nie instaluj wtyczek ingerujących w główną warstwę serwera

Wtyczki ingerujące w warstwę serwera są bardzo łatwym sposobem na atak poprzez bezpośredni dostęp do serwera, pomijając przy tym wszelkiego rodzaju zabezpieczenia serwerowe.

Bardzo często z tego typu wtyczek używa się z racji braku danych dostępowych lub umiejętności do korzystania z połączenia FTP.

Do najpopularniejszych wtyczek zaliczamy wszelkiego rodzaju wtyczki typu File Manager (wtyczki dające dostęp do warstwy serwera z plikami strony z poziomu CMSa, zastępując przy tym programy FTP) czy wtyczki do zarządzania bazą danych np. WP phpMyAdmin.

Warto ponownie tutaj zaznaczyć wszystkie wtyczki optymalizujące oraz zabezpieczające, ponieważ ich fundamentem są również ingerencje do warstwy serwerowej.

Nie instaluj wtyczek nieznanego pochodzenia

Jest to chyba bardzo oczywiste, ale mimo wszystko wciąż można zauważyć tendencje do zakupu wtyczek z nieoficjalnych źródeł, np. paczki wtyczek do WP na Allegro po cenach niższych, niż w przypadku zakupu każdej wtyczki osobno. 

Wiążą się z tym dwa zagrożenia: pierwsze jest takie, że nigdy nie mamy pewności czy do takiej wtyczki nie zostało dodane coś „ekstra”. Po drugie – kupując wtyczkę od producenta masz pewność aktualizacji i suportu, czego nie otrzymujesz kupując wtyczki z innego źródła.

A co z wtyczkami lub motywami, które normalnie kosztują kilkanaście dolarów, a są dostępne za darmo np. na forach? Od razu mówimy – instalacja takiej wtyczki to świadomy strzał w kolano dla naszej strony internetowej. 

Jeżeli chcemy instalować wtyczki – instalujemy tylko te, które dostępne są w repozytorium WordPressa. Przed instalacją jednak nawet te wtyczki warto zweryfikować pod kątem bezpieczeństwa i czy posiadają aktualne wsparcie np. weryfikując datę ostatniej aktualizacji.

#ProTIP: skąd czerpać wiedzę na temat instalowanych wtyczek? Warto na pewno zacząć od przejrzenia historii podatności na stronie wpscan.com.

Innym dobrym sposobem, choć nie zawsze skutecznym jest wpisanie w Google: „nazwa wtyczki wordpress malware” albo „nazwa wtyczki virus” i weryfikacją, co internet mówi o danej wtyczce.

Aktualizacje – fundament bezpieczeństwa

Bieżące aktualizacje core WordPressa, wtyczek i motywu są kluczową czynnością, która wzmacnia bezpieczeństwo naszego WordPressa, więc powinniśmy dbać o to na bieżąco.

Pomijając oczywisty cel aktualizacji, od strony bezpieczeństwa stare wersje są otwartymi drzwiami dla hakerów, bo jakiś fragment kodu może zostać wykorzystany do wpuszczenia złośliwego kodu lub innego niepożądanego działania.

#ProTIP: Jeżeli pojawiła się aktualizacja – instalujemy i nie czekamy. Jeżeli mamy obawy przed aktualizacją – sprawdzamy aktualizacje na wersji testowej.

Jeżeli w naszym systemie posiadamy wtyczki, których ostatnia aktualizacja została odnotowana więcej niż 6 miesięcy temu, powinniśmy poważnie zastanowić się nad usunięciem jej i poszukiwaniu alternatywy. Zdarza się, żę autorzy wtyczek porzucają ich dalszy rozwój i hakerzy bardzo chętnie wykorzystują luki w takich porzuconych wtyczkach.

Warto też nadmienić, że wiele wtyczek wymaga wykupienia wsparcia (licencji), w ramach której otrzymujemy aktualizacje.

#ProTIP: sprawdzenia dostępności aktualizacji jak i samej aktualizacji możemy dokonać z poziomu kokpitu, wybierając opcję “Aktualizacje”.

Zadbaj o zalecaną wersję PHP

PHP, czyli język programowy, na którym zbudowany jest WordPress oraz wszystkie motywy i wtyczki. W celu polepszenia działania i lepszego bezpieczeństwa zaleca się, aby na serwerze była ustawiona wersja PHP zgodna z tą, której wymaga obecna wersja WordPressa. Poza kwestiami bezpieczeństwa, nowej wersji PHP mogą również wymagać motywy lub wtyczki do zapewniania poprawnego działania.

Wymagania bieżącej wersji WordPressa można sprawdzić tutaj: https://pl.wordpress.org/about/requirements/

Jeżeli nasz WordPress wyświetla komunikat o zalecanej aktualizacji PHP to staramy się taką aktualizację zapewnić.

#ProTIP: jeżeli nie jesteś osobą techniczną, to aktualizację wersji PHP zalecamy zrobić ze specjalistą, aby można było szybko zweryfikować poprawność działania poprzez staging strony.

Regularnie zmieniaj hasła

Potwierdzoną informacją jest to, że hakerzy często udostępniają wykradzione hasła w sieci. Dlatego taką prostą czynnością, jak zmiana hasła możemy zmniejszyć potencjalną próbę włamania lub ataku.

Starajmy się raz na miesiąc (albo przynajmniej kwartał lub pół roku) zmieniać hasła dostępowe kont administracyjnych, serwera FTP oraz bazy danych. Natomiast jeżeli dowiedzieliśmy się, że jeżeli WordPress lub któraś z wtyczek lub motywów miała podatność i została ona usunięta wraz z aktualizacją, to zmianę hasła powinniśmy wykonać każdorazowo po takiej sytuacji.

Przy ustawianiu haseł dbajmy o to, aby były to hasła trudne. Nie używajmy haseł typu: admin123, Jarek123, Audi, abc123. Są to hasła bardzo proste do rozszyfrowania, a narzędzia do ataków Brute-Force w pierwszej kolejności weryfikują takie kombinacje.

#ProTIP: dobre hasło to takie składające się z ciągu losowych dużych i małych znaków wraz z cyframi. Do generowania takich haseł polecamy: https://passwordsgenerator.net/

Podwójna autentykacja

Czyli innymi słowy weryfikacja, która odbywa się jeszcze przed próbą zalogowania do panelu administracyjnego, np. token w aplikacji, token SMS. Z takimi metodami najczęściej spotykamy się korzystając z bankowości internetowej lub stronami urzędowymi, które to na telefon przesyłają nam kody do logowania.

Do popularnych rozwiązań używanych z WordPressem należą Rublon, Google Authenticator czy miniOrange’s Google Authenticator.

Jeżeli nie jesteśmy w stanie wdrożyć powyższych rozwiązań, powinniśmy zastanowić się choćby nad prostszymi sposobami autentykacji, takimi jak ustawienie Google reCAPTCHA lub ustawienie hasła za pomocą plików .htaccess i .htpasswd.

W pliku .htaccess w głównym ustawiamy regułę kierującą do naszego pliku .htpasswd:

<Files wp-login.php>
	AuthType Basic
	AuthGroupFile /dev/null
	AuthName "Komunikat"
	AuthUserFile /sciezkadoroota/.htpasswd
	require valid-user
</Files>

Nazwę użytkownika oraz hasło możemy sobie wygenerować dowolnym generatorem.

Możemy również przejść na poziom wyżej i zastosować…

Ograniczenie dostępu do panelu administracyjnego po IP

Jeżeli do wp-admina loguje się konkretna liczba użytkowników ze stałym adresami IP, bardzo dobrym zabiegiem będzie ograniczenie dostępu do panelu administracyjnego tylko dla konkretnej puli IP.

Taki dostęp możemy ustawić w pliku .htaccess wklejając:

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_URI} ^(.*)?wp-login\.php(.*)$ [OR]
RewriteCond %{REQUEST_URI} ^(.*)?wp-admin(\/)$ [OR]
RewriteCond %{REQUEST_URI} ^(.*)?wp-admin/$
RewriteCond %{REMOTE_ADDR} !^200\.200\.200\.200$
RewriteRule ^(.*)$ – [R=403,L]
</IfModule>

Dzięki temu mamy pewność, że nikt z zewnątrz nie jest w stanie zalogować się do naszego panelu administracyjnego

Wyłącz debugowanie

Błędy w kodzie pozwalają zobaczyć komunikaty błędów, które ułatwiają wykrycie potencjalnych luk w składni kodu. W pliku wp-config.php warto zamienić WP_DEBUG na:

define('WP_DEBUG', false);

if ( ! WP_DEBUG ) {
	ini_set('display_errors', 0);
}

Zablokuj dostęp edycji kodu z poziomu WordPressa

Z poziomu WordPressa mamy dostęp do dwóch miejsc, w których mamy możliwość bezpośredniej edycji kodu przy pomocy edytora motywu oraz edytor wtyczki.

To właśnie z tych edytorów bardzo chętnie korzystają hakerzy lub wtyczki / narzędzia wpuszczające do naszej strony złośliwy kod, dlatego bardzo ważnym elementem jest całkowite wyłączenie tych edytorów.

Aby wyłączyć edytor motywu, należy w pliku wp-config.php umieścić:

define( 'DISALLOW_FILE_EDIT', true );

Aby wyłączyć edytor wtyczki w tym samym pliku należy umieścić:

define( 'DISALLOW_FILE_MODS', true );

Uwaga! Wyłączenie edytora wtyczki jest równoznaczne z wyłączeniem opcji aktualizacji wtyczek. Jest to spowodowane właśnie tym, że w trakcie takiej aktualizacji kod walidowany jest z poziomu WordPressa. Dobrą praktyką jest ręczna aktualizacja wtyczek uprzednio testując poprawność działania na stagingu  lub wyłączenie tej opcji na czas przeprowadzenia aktualizacji wtyczek.

Zablokuj dostęp do listy użytkowników z REST API

W ramach zabezpieczania często ukrywa się nazwy użytkowników, jednak REST API bez problemu pozwala na sprawdzenie listy tych użytkowników. Wystarczy w przeglądarce wejść pod adres:

https://twojastrona.pl/wp-json/wp/v2/users

Możemy ograniczyć dostęp do zawartości tego pliku poprzez funkcję:

add_filter('rest_endpoints', function( $endpoints ) {
    if ( isset( $endpoints['/wp/v2/users'] ) ) {
        unset( $endpoints['/wp/v2/users'] );
    }
    if ( isset( $endpoints['/wp/v2/users/(?P<id>[\d]+)'] ) ) {
        unset( $endpoints['/wp/v2/users/(?P<id>[\d]+)'] );
    }
    return $endpoints;
});

Obserwacja działań i zmian

Bieżąca analityka to dobra metoda na wczesne wykrycie potencjalnego zagrożenia. Mowa tutaj o analityce zarówno wejść na naszą stronę, jak również zmian zachodzących w plikach strony.

Jeżeli widzimy, że na naszej stronie mamy odwiedziny z krajów, z których raczej nie spodziewamy się wejść np. Afganistan to powinniśmy wtedy być bardziej czujni. Być może to jakiś zwykły bot, ale równie dobrze może to być haker korzystający z VPN (narzędzia do maskowania adresu IP).

Obserwacja plików strony jest również bardzo ważna, ale niestety wymaga ona dość dobrej znajomości całej struktury plików i folderów WordPressa, bo to właśnie dzięki wyłapaniu pliku, którego nie powinno być, jesteśmy w stanie skutecznie opóźnić lub całkowicie zneutralizować atak.

#ProTIP: obserwację plików możemy prowadzić również przy pomocy logów serwera dostępnych w panelu zarządzania naszym serwerem.

Separacja domen

Jeżeli posiadamy na naszym hostingu kilka stron internetowych to zdecydowanie powinniśmy zweryfikować separację domen, aby pliki stron internetowych nie były ze sobą wymieszane.

Prawidłową strukturą katalogów na serwerze przy separacji jest m.in:

  • twojserwer.pl/domains/domenaA.pl/public_html/wordpress/index.php
  • twojserwer.pl/domains/domenaB.pl/public_html/wordpress2/index.php

Jeżeli spotkamy się z czymś takim:

  • twojserwer.pl/domains/domenaA.pl/public_html/wordpress/index.php
  • twojserwer.pl/domains/domenaA.pl/public_html/wordpress/domenaB.pl/index.php

to możemy być pewni, że przy ataku na domenę A, domena B również zostanie zainfekowana. Jeżeli stron na serwerze mamy więcej bez separacji, to przywrócenie tego do działania może być dla nas bardzo kosztowne i szkodliwe dla biznesu.

Nie rób z serwera przechowywalni plików

Nie używajmy naszego serwera jako przechowywali plików osobistych czy co gorsza – plików skryptowych, rozruchowych, tekstowych czyli takich, które pozwalają na swobodne dodawanie tekstu do takiego pliku. 

Dodatkowo – jeżeli na serwerze mamy pliki motywu czy wtyczek których nie używamy, to bez zastanowienia usuwamy. Wtyczka, która jest nieaktywna nadal jest na serwerze i stanowi potencjalne drzwi do włamania.

#ProTIP: do przechowywania dokumentów czy też plików osobistych zachęcamy do korzystania z usług wirtualnych dysków typu Google Drive, Dropbox itp.

Rób kopie zapasowe strony internetowej

Kopie zapasowe są często kluczowym elementem pozwalającym na szybkie przywrócenie do działania naszej strony internetowej – w przypadku ataku czy choćby awarii spowodowanej aktualizacją, błędną modyfikacją kodu lub instalacją uszkodzonego motywu / wtyczki.

Bardzo ważne jest jednak to, aby w przypadku zainfekowania strony internetowej przywrócenie kopii nie było pierwszą rzeczą, którą robimy. Nie mamy pewności kiedy pojawiła się podatność, dlatego przywracanie kopii zapasowej na starcie nie ma sensu, bo w 99% przypadkach infekcja powróci oraz utrudniamy zlokalizowanie źródła infekcji. Bardzo często źródło infekcji znajduje się już w plikach kopii zapasowej.

Dlatego kopię możemy przywrócić, uprzednio robiąc kopię strony zainfekowanej, która będzie służyć za repozytorium do usunięcia infekcji i musimy pamiętać, że jest to rozwiązanie tymczasowe.

Pamiętajmy, aby kopii zapasowej nie robić wtyczkami. W przypadku całkowitej awarii naszej strony, gdzie nie będzie możliwy dostęp do panelu administratora, nie będziemy w stanie przywrócić naszej strony do działania. Dodatkowo nigdy nie mamy pewności czy do takiej kopii nie została dodana szkodliwa niespodzianka.

Częstotliwość tworzenia kopii zapasowej staramy się dostosować do częstotliwości aktualizacji treści na naszej stronie internetowej. Jeżeli posiadamy mały serwis, w którym dodajemy informacje raz na pół roku, to wystarczy jak kupię będziemy robić raz w miesiącu.

Duży portal internetowy, w którym codziennie dodawanych jest kilka newsów – archiwizujemy codziennie.

Klucze szyfrujące

Jedną z podstaw bezpieczeństwa są klucze szyfrujące – warto po instalacji zmienić je na własne. Klucze znajdują się w pliku wp-config.php, który znajduje się w głównym katalogu serwera.

Klucze możemy wygenerować tutaj: https://api.wordpress.org/secret-key/1.1/salt/

Wygenerowane klucze wklejamy i podmieniamy z istniejącymi.

Sanityzacja danych

Przez formularze komentarzy czy jakiekolwiek inne formularze, użytkownik może przesłać coś na naszą stronę, np. skrypt będący złośliwym kodem, który będzie wykonywać się w momencie publikacji na stronie.

Użytkownik (nawet nieświadomie) może wysłać także jakiś ciąg znaków, który uniemożliwi dalsze wykonywanie kodu strony.

WordPress posiada natywnie wbudowane funkcje do sanityzacji: https://developer.wordpress.org/?s=sanitize_

Opcja co prawda dla bardziej zaawansowanych, ale również bardzo ważna, a bardzo często zaniedbywana i nie testowana.

Odseparuj dostęp do bazy danych

Z racji tego, że większość ataków w pierwszej kolejności kierowanych jest do wyżej wspomnianego pliku wp-config, aby uzyskać dostęp do bazy danych (a ta daje nam w dostęp do środka panelu), warto nieco utrudnić ten proces, zmieniając lokalizację danych bazy danych.

W naszym pliku wp-config.php znajdziemy dane bazy danych:

define('DB_NAME', '');
define('DB_USER', '');
define('DB_PASSWORD', '');
define('DB_HOST', '');
define('DB_CHARSET', '');
define('DB_COLLATE', '');

Tworzymy w tym samym katalogu plik o innej nazwie np. wp-danedobazydanych.php i do niego wklejamy powyższe dane.

W oryginalnym pliku wp-config.php wywołujemy stworzony wcześniej plik:

require_once "wp-danedobazydanych.php"

Zablokuj dostęp do plików konfiguracyjnych

Dodaj do pliku .htaccess w głównym katalogu:

<FilesMatch "wp-config.*\.php|\.htaccess|readme\.html">
    Order allow,deny
    Deny from all
</FilesMatch>

Ukryj wersję WordPress wyświetlaną w kodzie strony

Ukrycie wersji WordPressa pozwoli na utrudnienie szybkiego wykorzystywania podatności specyficznych dla danej wersji.

W pliku functions.php należy dodać::

remove_action('wp_head', 'wp_generator');

robimy to samo również dla skryptów:

function remove_version_wp( $src ) {
global $wp_version;
$version_str = '?ver='.$wp_version;
$offset = strlen( $src ) - strlen( $version_str );
if ( $offset >= 0 && strpos($src, $version_str, $offset) !== FALSE )
return substr( $src, 0, $offset );
return $src;
}

add_filter( 'script_loader_src', 'remove_version_wp' );
add_filter( 'style_loader_src', 'remove_version_wp' );

Zablokuj wp-includes

Warto zabezpieczyć pliki, które nie są użyteczne dla użytkowników odwiedzających stronę, ale są wymagane do prawidłowego działania WordPrssa.

W pliku .htaccess w głównym katalogu WP dodajemy:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^wp-admin/includes/ – [F,L]
RewriteRule !^wp-includes/ – [S=3]
RewriteRule ^wp-includes/[^/]+\.php$ – [F,L]
RewriteRule ^wp-includes/js/tinymce/langs/.+\.php – [F,L]
RewriteRule ^wp-includes/theme-compat/ – [F,L]
</IfModule>

Zablokuj wykonywanie plików PHP

Poniższy kod zablokuje wykonywanie plików o rozszerzeniu .php, które mogą być przesyłane przez np. formularze kontaktowe.

Kod dodajemy do wp-content/uploads/.htaccess:

<Files *.php>
deny from all
</Files>

a w .htaccess w katalogu głównym dodajemy:

Options +FollowSymLinks
RewriteEngine On
RewriteCond %{QUERY_STRING} (<|%3C).*script.*(>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} GLOBALS(=|[|%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} _REQUEST(=|[|%[0-9A-Z]{0,2})
RewriteRule ^(.*)$ index.php [F,L]

Usuwanie wirusów WordPress

Czyli co zrobić jak już złapiesz infekcję? Działaj szybko! Im dłużej zwlekasz z usunięciem infekcji, tym więcej efektów ubocznych odczujesz, nie mówiąc również o czasie potrzebnym na posprzątanie po infekcji.

W przypadku infekcji zachęcamy do skorzystania z naszej oferty na kompleksową obsługę związaną z usunięciem infekcji lub bezpośrednio na nasz e-mail. Jeżeli nie jesteś osobą techniczną, nie należy działać na własną rękę, ponieważ w większości przypadków kończy się to powrotem infekcji lub uszkodzeniem strony.

Powtórzymy – nie należy przywracać backupu, ponieważ znacząco utrudnia to znalezienie źródła infekcji. Nie nadpisuj także plików strony internetowej czy plików CMSa – jest to równoznaczne z przywróceniem backupu.

Polepsz odbiór Twojej strony! codoUX #1

Czym jest UX?

Na początek określmy krótko, czym jest zagadnienie UX. User Experience, czyli Doświadczenie Użytkownika, to dziedzina polegająca na projektowaniu w taki sposób, aby odbiorcy w trakcie korzystania z produktów czy usług mogli w pełni polegać na swoich przyzwyczajeniach, umiejętnościach itp. Dzięki temu odbiór przekazu jest jak najbardziej użyteczny, przekonujący oraz intuicyjny. 

Dziedzina ta dotyczy większości przedmiotów, które nas otaczają. Za przykład niech posłużą drzwi. Jeden przedmiot, 3 rodzaje możliwości interakcji – na tym właśnie polega UX. W tym artykule jednak swoją uwagę skupiamy przede wszystkim na polepszeniu odbioru stron internetowych.

#tip1: Zbuduj hierarchię przycisków.

Przyciski na stronie odgrywają bardzo ważną rolę, jednak często zdarza się, że struktura i cel takich przycisków nie jest do końca przemyślana. Warto zastanowić się nad tym, w jaki sposób chcemy prowadzić użytkownika po naszej stronie przy pomocy przycisków.

Button spełniający rolę wezwania do działania powinien być wypełniony wyróżniającym się kolorem, aby zwrócić uwagę użytkownika i zachęcić do kliknięcia. Alternatywnie, jeżeli w obrębie danego miejsca stosujemy kilka takich przycisków, to taki najważniejszy element możemy ozdobić np. cieniem, aby wyróżnić go na tle innych elementów strony.

Natomiast zwykły przycisk wypełniony powinien spełniać standardową rolę poruszania się po ważnych elementach strony. Istnieją również buttony obramowane, tzn. przyciski duchy, które spełniają rolę przycisków neutralnych i są zazwyczaj stosowane jako uzupełnienie.

Kolejność hierarchiczna w praktyce: wyróżniony przycisk wezwania do działania, przycisk wezwania do działania, przycisk wypełniony i przycisk duch.

#tip2: Nie utrudniaj, tylko ułatwiaj.

Jeżeli na Twojej stronie istnieje jakiś proces lub akcja, postaraj się je maksymalnie skrócić i ułatwić interakcję z nimi. Nie marnuj czasu użytkownika wdrażaniem popupa ze zdjęciem, przez które nie będzie widać przycisku zamknięcia. Istnieje duża szansa, że użytkownik, który będzie miał problem ze znalezieniem sposobu na zamknięcie takiego popupa po prostu wyjdzie ze strony.

W przypadku e-commerce istnieje wiele elementów, które można skrócić np. dodanie produktu do koszyka z poziomu katalogu produktów dla klientów, którzy chcą szybko coś kupić, dynamiczny cross selling, formularz zamówienia bez ładowania kolejnych podstron itp.

#tip3: Nie justuj tekstu.

W Internecie tekstu nie justujemy. Tekst justowany jest automatycznie dopasowywany do obszaru w którym definiujemy umieszczenie treści. W przypadku obszaru opływowego przy skalowaniu strony nie ma gwarancji, w jaki sposób dany tekst będzie wyświetlany na ekranie np. przez użytkownika korzystającego z narzędzi wspomagających (powiększenie) czy też urządzenia mobilne.

Sposób wyświetlania tego tekstu może być różny w zależności od urządzenia, rozdzielczości oraz przeglądarki.

Ponadto, justowanie tekstu bardzo często tworzy puste przestrzenie między słowami oraz błędy w przypadku umieszczenia spójników i przyimków na końcu linii, które traktowane są jako uchybienie typograficzne. Próba przerzucenia takiego spójnika miękkim enterem spowoduje powstanie jeszcze większej pustej przestrzeni, a te wpływają na finalny odbiór tekstu sprawiając, że czytany tekst nie jest ani czytelny, ani estetyczny.

#tip4: Nie używaj niebieskiego koloru dla tekstu.

Są dwie cechy, dzięki którym użytkownicy mogą rozpoznać link – niebieski kolor oraz podkreślenie. Jeżeli nasza treść nie jest linkiem, nie ustawiajmy jej niebieskiego koloru, bo taki zabieg wprowadza użytkownika w błąd. Niebieski kolor zostawmy tylko dla hiperłączy.

Jeżeli z jakiegoś powodu musimy zmienić kolor hiperłącza, to zadbajmy o widoczność drugiej cechy – podkreślenia. Jest to również przydatne dlatego, że w przypadku gdy na naszą stronę trafi osoba ze ślepotą barw, np. tritanopią, to dzięki podkreśleniu będzie wiedziała, że w danym miejscu znajduje się link.

#tip5: Używaj sprawdzonych wzorców.

W dobrze przemyślanych aplikacjach i stronach można zauważyć powielające się elementy. Na przestrzeni lat użytkownicy przyzwyczaili się do określonych znaków i tego, co się za nimi kryje. Za najprostszy przykład mogą posłużyć ikonki ustawień.

Użytkownik widzący ikonki po lewej stronie od razu wie, że kryją się pod nimi ustawienia. Przykładową ikona po prawej stronie pobraliśmy z innej strony, a kliknięcie w nią kieruje do procesu rejestracji.

#tip6: Zaplanuj priorytety ładowania treści.

Jednym z czynników nadchodzącego CWV jest CLS czyli Cumulative Layout Shift. W wielkim skrócie: chodzi o to, aby zapewnić użytkownikowi stabilność elementów na stronie internetowej w momencie ładowania oraz po jej pełnym załadowaniu.

Za przykład może posłużyć zwykły tekst okraszony obrazkiem. W momencie ładowania strony zadbajmy o to, aby w pierwszej kolejności załadował się tekst, aby użytkownik mógł go już czytać, a dopiero potem obrazek. Pilnujmy również tego, aby w momencie załadowania obrazka nie spowodować przesunięcia się treści, które wpływa bezpośrednio na czynnik CLS.

#tip7: Zadbaj o użyteczność mobilną.

90% ruchu odbywa się za pomocą telefonów komórkowych. Jest wiele czynników użytkowych, nad którymi warto się zastanowić i dopracować.

Sprawdź, czy wszelkiego rodzaju linki tekstowe lub buttony nie są za małe i wymagają od użytkownika precyzyjnego trafienia w punkt. Zdarzają się użytkownicy, którzy obsługują stronę małym palcem ponieważ odstępy między elementami są dla nich za małe i wywołują niepożądane akcje. Zapewnij każdemu elementowi klikalny obszar o minimalnym rozmiarze 1x1cm.

Osoby korzystające z tabletów najczęściej posługują się tylko kciukami przy przeglądaniu strony. Zadbaj o to, aby elementy nawigacyjne lub linki nie wymagały zaangażowania pozostałych palców lub obracania urządzenia. Testując stronę sprawdź, jak wygląda ich użyteczność przy korzystaniu z jednej lub dwóch rąk.

#tip8: Zapewnij wiele ścieżek nawigacji i skracaj je najbardziej, jak to możliwe.

Jeżeli twoja strona posiada złożoną hierarchię stworzoną do tego, aby dostać się do celu np. Nawigacja -> Oferta -> Budowa domów -> Budowa domów jednorodzinnych -> Podstrona oferty budowy jednorodzinnych, to najwyższy czas na zmianę projektu twojej strony. Pomóż użytkownikowi dostać do podstrony ofertowej już z poziomu strony głównej albo z poziomu oferty.

Zastanów się również nad samymi elementami nawigacyjnymi strony. Przy długiej stronie, gdzie użytkownik pokonuje długi  dystans scrollując stronę, warto przykleić nawigację do góry strony, aby bez konieczności powracania tą samą droga mógł przejść do innej podstrony.

Dodatkowo, na dole strony warto umieścić przycisk powrotu do góry, ponieważ w dalszym ciągu duży % użytkowników wraca do góry strony w celu wejścia w nawigację, nawet jeżeli taka nawigacja jest przyklejona.

W przypadku nawigacji mobilnej rozważ wyszczególnienie najważniejszych elementów, np. numer telefonu w formie przycisku na belce nawigacji lub button z linkiem do formularza kontaktowego.

#tip9: Slider – zrób to dobrze, a najlepiej… wcale.

Nie ma się co okłamywać – slidery już dawno wyszły z mody i nie mają wiele wspólnego z użytecznością. Według analityki tylko 1% użytkowników klika w slajdy, dlatego nie powinieneś przywiązywać szczególnej uwagi do tego rozwiązania.

Jeżeli jednak decydujemy się na slider, to pamiętajmy o kilku sprawach. Jeżeli Twój slider automatycznie się przewija, to zapewnij użytkownikowi manualne sterowanie w momencie, gdy wchodzi w nim w interakcje. Unikaj szybkiej zmiany slajdów, aby użytkownik mógł wystarczająco się skupić i zapoznać ze slajdem. 

Zapewnij użytkownikom również odpowiednią nawigację w wersji mobilnej. Kropki nawigacyjne postawione blisko siebie, bez możliwości ręcznego przewijania slajdów nie wydają się być dobrą opcją.

#tip10: Zadbaj o typografię.

ypografia na stronie jest bardzo ważnym czynnikiem, ponieważ jest głównym elementem odbioru tego, co chcemy przekazać na stronie internetowej.

Zadbaj o odpowiednie proporcje nagłówków, aby użytkownik mógł rozróżnić nagłówek główny od nagłówka nadrzędnego. 

Postaraj się także ujednolicić typografię na Twojej stronie – użyj 1 kroju i maksymalnie 2 grubości, zamiast 5 różnych fontów. Opracuj interlinię oraz zadbaj o to, aby użytkownicy z dysleksją nie mieli problemu z odczytaniem tekstu np. poprzez unikanie używania kursywy.

I najważniejsze – tekst czytany dla ekranów w telefonach nie powinien być mniejszy, niż ten widoczny na ekranie komputera czy laptopa. Dobrą praktyką w tym przypadku jest nawet powiększenie takiego tekstu o 1-2 punkty.

Podsumowanie

Wydawać by się mogło, że wszystkie powyższe rzeczy są dość oczywiste. Niestety realnie wygląda to tak, że wielu twórców stron internetowych nie zwraca uwagi na aspekty użyteczności przed oraz w trakcie realizacji i nawet w żaden sposób nie analizuje zachowania użytkowników na ich stronie już po jej uruchomieniu.

I niestety za niedługo bardzo wiele stron odczuje brak przywiązania uwagi do użyteczności, dlatego warto popracować nad tym już teraz. Dla wielu będzie oznaczało to całkowitą budowę strony internetowej na nowo pod kątem użyteczności, a tą uda się uzyskać tylko przy współpracy ze specjalistami UX oraz projektantami.

Dostępna strona internetowa dla osób narażonych na wykluczenie cyfrowe, czyli jak ugryźć temat WCAG 2.1 w przypadku WordPressa.

Tekst ten nie odnosi się tylko do stron wykorzystujących system WordPress jako CMS. Będzie tutaj kilka informacji ogólnych, które stosuje się do wszelkiego rodzaju stron z dostępnością dla osób narażonych na wykluczenie cyfrowe. Z racji, że sami korzystamy z systemu WordPress w roli bazy do zarządzania treścią na stronach, większość przykładów będzie opierać się właśnie o ten system.

Co to jest WCAG 2.1?

Na początek przytoczmy szybko, czym jest WCAG 2.1. Web Content Accessibility Guidelines poza tym, że jest to bardziej dopracowana wersja wcześniejszego WCAG 2.0, jest głównie zbiorem dokumentów opierających się o ustawę Parlamentu Europejskiego o dostępność stron internetowych oraz aplikacji mobilnych. Dostępność jest obowiązkowa dla podmiotów publicznych czyli np. sektor finansów publicznych, państwowe jednostki organizacyjne, czy też osoby prawne, ale także niektóre organizacje pozarządowe oraz jednostki dysponujące finansami publicznymi.

W praktyce oznacza to także zbiór kryteriów, jakie powinna spełniać strona / aplikacja w obszarach Postrzegalność, Funkcjonalność,  Zrozumiałość i Solidność, aby można było ją nazwać dostępną dla osób narażonych na wykluczenie cyfrowe.

Na starcie warto podkreślić, że WCAG nie obejmuje tylko osoby niepełnosprawne, a obejmuje osobny narażone na wykluczenie cyfrowe.

Do osób narażonych na wykluczenie cyfrowe zalicza się:

  • niewidomych, niedowidzących lub osoby posiadające dysfunkcje wzroku np. daltonizm;
  • głusi oraz głuchoniewidomi;
  • osoby z niepełnosprawnością kończyn;
  • osoby z niepełnosprawnością intelektualną;
  • dyslektycy;
  • osoby starsze;
  • osoby korzystające ze starych komputerów;
  • osoby korzystające z urządzeń mobilnych;
  • osoby z biednych regionów;
  • obcokrajowcy;
  • osoby korzystający ze stron w głośnych lub cichych miejscach.

Jak widać praktycznie każdy z nas może być narażony na wykluczenie cyfrowe i nie są to tylko osoby niepełnosprawne. Prostym przykładem który może nas spotkać jest sytuacja kiedy to złamiemy prawą rękę będąc osobą praworęczną. Nasza lewa ręka niestety trudno będzie radzić sobie z myszką, ale już klawiaturę jesteśmy w stanie obsłużyć bezproblemowo, bo praktycznie każdy pracuje obiema rękami na klawiaturze i ma wyćwiczony dynamiczny zakres ruchu lewą ręką na klawiszach.

Czy potrzebuję WCAG 2.1 na stronie?

Jak zostało napisane to wyżej – na chwile obecną obowiązkiem posiadania tego standardu objęte są instytucje państwowe, jednostki samorządu terytorialnego oraz wszystkie podmioty podlegające pod nie. Wymóg ten muszą również spełniać jednostki dysponujące finansami publicznymi. Za takie podmioty uznaje się:

  • Przedszkola, żłobki, szkoły publiczne oraz wyższe;
  • Urzędy miast, powiatu, gmin, wojewódzkie i marszałkowskie;
  • Agencje rządowe;
  • Domy kultury, publiczne muzea i galerie sztuki;
  • Sąd i prokuratura na wyższych szczeblach;
  • Policja, straż miejska, straż graniczna;
  • Zakłady karne;
  • Związki metropolitalne.

Na ten moment, jeżeli nie kwalifikujemy się pod żadną z powyższych grup to wdrożenie standardu WCAG nie jest od nas wymagane, a jedynie jest naszą dobrowolną inicjatywą skierowaną w kierunku osób narażonych na wykluczenie cyfrowe, aby ułatwić im poruszanie się na naszej stronie.

Od strony biznesowej otwieramy możliwości dla grupy potencjalnych Klientów, bowiem osoby narażone stanowią prawie 1/7 ludności na świecie i również korzystają z internetu.

Jakie są obszary i poziomy WCAG 2.1?

Standard WCAG 2.1 dzieli się na 3 typy poziomów:

Poziom A – oznacza minimalne wymogi, które musza zostać spełnione. Jeśli się tak nie stanie, treść opublikowana na stronie nie będzie dostępna dla części użytkowników.

Poziom AA – to zalecane do wdrożenia aspekty, które znacząco ułatwiają odbiór treści przez użytkowników.

Poziom AAA – oznacza wytyczne, które w pełni umożliwiają korzystanie z serwisu osobom z najróżniejszymi przypadłościami i przypadkami.

Poziomy uzupełniają się tz. chcąc zapewnić standard na poziomie AAA, musimy spełnić również wszystkie wymagania z poziomów A/AA.

Dodatkowo omówmy teraz obszary, na jakie dzieli się standard WCAG:

Postrzegalność – wszystkie informacje oraz interfejs musi być w pełni dostępny dla zmysłów użytkowników.

Funkcjonalność – interfejs musi w pełni umożliwiać swobodną nawigację po stronie.

Zrozumiałość – interfejs i obsługa interfejsu muszą być zrozumiałe dla odbiorcy.

Solidność – redagowanie treści w sposób taki, aby była prawidłowo interpretowana przez różnego rodzaju oprogramowania oraz technologie wspomagające np. czytniki dla osób niewidomych.

Wydawać by się mogło, że powyższe obszary są dość oczywiste i wdrażane są przy każdej stronie internetowej. Niestety tak nie jest. Weźmy przykładową zasadę z obszaru Funkcjonalność z pierwszego stopnia:

2.1.1 Klawiatura (Poziom A)

Wszystkie funkcjonalności w treści są obsługiwane za pomocą interfejsu klawiatury, bez wymogu określonego czasu użycia poszczególnych klawiszy, z wyjątkiem sytuacji, kiedy dana funkcja wymaga wprowadzenia informacji przez użytkownika w oparciu o ścieżkę ruchów, a nie w oparciu o punkty końcowe wejścia.

Zrób mały test dla samego siebie – odstaw mysz i sprawdź teraz czy jesteś w stanie na swojej stronie bez problemu poruszać się przy pomocy samej klawiatury. Zacznij od wyżej wspomnianej nawigacji, a potem przejrzyj każdą podstronę.

Spróbuj także samej obsługi komputera i różnych stron internetowych z których korzystasz na co dzień.

Kolejnym ciekawym eksperymentem jest to samo doświadczenie opisane wyżej, ale z osobą która w nie widziała nigdy na oczy naszej strony internetowej i dodatkowo – ma zakryte oczy.

Jak wiele utrudnień napotkałeś albo napotkała taka osoba? No właśnie… Dostępność polega na tym, aby takich problemów nie miał nikt.

Wtyczka do WCAG, czyli jak nie robić dostępności

Wiele osób, które dążą do zorganizowania dostępności swojej strony podchodzi do tego bez większego zagłębiania się w temat – no bo po co? Zdarza się, że takie osoby myślą: “nie jestem informatykiem i taka wiedza jest mi niepotrzebna, a przecież mogę sobie to zrobić wtyczką do WordPressa”. Pokażemy teraz na bardzo prostym przykładzie, dlaczego taka wtyczka niczego nam nie załatwia. Załóżmy, że naszą stronę odwiedza osoba kompletnie niewidoma.

Przyjrzyjmy się jednej z najpopularniejszej wtyczek w tym temacie, która zapewnia nam dostępność jednym kliknięciem. Dodaje ona nam menu kontekstowe z ułatwieniami (i tylko tyle). Co oferuje od strony użytkowej?

  • Powiększenie i pomniejszenie tekstu;
  • Skalę szarości;
  • Wysoki lub negatywny kontrast;
  • Podkreślenie linków;
  • Zmianę fontu na bardziej czytelny.

I oto wszystko, co dana wtyczka oferuje w ramach dostępności. “Już, gotowe. Mamy WCAG na stronie. Osoba niewidoma na pewno nie będzie miała problemu korzystania ze strony, bo może sobie teraz powiększyć tekst, aby był dla niej czytelny nawet jak nie widzi”.

Powyższe podsumowanie jest oczywiście sarkastycznym wyrazem tego, w jaki sposób działa ten proces rozwiązywania tego za pomocą wtyczek.

Niestety prawda jest taka, że wtyczki sugerujące dostępność paroma kliknięciami niczego nam nie załatwiają, a co najwyżej dodadzą parę narzędzi do strony, które potencjalnie mogą ułatwić coś wybranej grupie osób, a patrząc po tym co oferują – ułatwiają korzystanie tylko osobom niedowidzącym lub ślepotą braw. No bo naprawdę – po co osobie niewidomej możliwość powiększania sobie tekstu? Na świecie jest 45 milionów osób niewidomych, a w samej Polsce jest ich ponad 150 000. Instalacją takiej wtyczki w żaden sposób nie umożliwiliśmy możliwość korzystania ze strony.

Tak osoba niewidoma widzi możliwości naszej wtyczki zapewniającą dostępność:

Przyjrzyjmy się teraz innemu przykładowi, który faktycznie takiej osobie znacząco pomoże poruszać się po stronie i zrozumieć jej zawarte treści.

Jednym z fundamentów dostępności strony dla osoby niewidomej jest zbudowanie kodu strony w taki sposób, aby był on w pełni semantyczny oraz wykorzystywał technologię WAI-ARIA dla lepszego działania i logiki czytników ekranu.

Czym się różnią powyższe screeny kodu strony? Prawy zrzut przedstawia kod strony zbudowanej na Elementorze, a drugi ten sam kod strony, ale z zainstalowaną wspomnianą wcześniej wtyczką. Co się zmieniło? Nic.

Pisanie semantycznego kodu jest jednym ze standardów programowania stron internetowych, ale jest również podstawowym elementem niezbędnym do prawidłowego odbioru strony przez czytniki ekranowe. Niestety gotowe motywy stron internetowych są raczej pisane szybko w celach sprzedażowych i rzadko stosowana jest tam semantyka (już nie mówiąc o WAI-ARIA, bo nie jest to na ten moment żaden standard). Narzędzia typu Elementor czy WP Bakery Page Builder nie generują żadnej semantyki, bowiem najczęściej generują one kod oparty na divach, które nie są elementem semantycznym.

I tutaj wkracza technologia WAI-ARIA, czyli zbiór reguł które ułatwiają odbiór osobom narażonym na wykluczenie cyfrowe. Nie ma możliwości zrobienia tego wtyczką, bo nie powstały jeszcze tak inteligentne wtyczki które zgadują, że ten element to slider i trzeba mu dać aria-role=”slider” i aria-live=”assertive” aby treść nie była odczytywana za każdym razem jak zmienia się slajd i najlepiej aby wtyczka dodała jeszcze aria-label=”Karuzela logosów” żeby osoba niewidoma wiedziała, że to slider z logosami. Problem z określaniem tych elementów mają czasem nawet doświadczeni programiści, więc nie ma tutaj co polegać na wtyczkach, bo one nie załatwiają niczego w temacie dostępności.

Technologia ARIA i mikrodane pozwalają w logiczny sposób czytnikowi odczytać treść strony, a co za tym idzie – jest to bardziej zrozumiałe i pomocne dla odbiorcy. W poniższym przykładzie mamy zajawkę wpisu blogowego zbudowanego o semantyczny kod, a także z wykorzystaniem w/w technologii:

Na pierwszy rzut oka widać znaczącą różnice w logice kodu. Niestety, brak semantyki dyskwalifikuje naszą stronę z bycia dostępną, a sama w sobie semantyka jest standardem przy pisaniu stron internetowych oraz jedną z wielu wytycznych, które należy spełniać przy dostępności.

Oczywiście na semantycznym kodzie temat się nie kończy, a tak naprawdę dopiero zaczyna. Pomijając prace programistyczne związane z dostępnością – na późniejszym etapie redagowanie takiej strony również powinno być prowadzone zgodnie ze standardem poprzez np. mikrodane w treściach, uzupełnianie altów grafik, pliki PDF przygotowane z myślą o dostępności czy nawet np. transkrypcje video.

Dlatego jeżeli na stronie ktoś zrobił dostępność instalując wtyczkę (lub sami tak zrobiliście) to tak na prawdę w kierunku dostępnej strony internetowej nie zostało zrobione nic i przy walidacji strony „przez górę” możemy spodziewać się ostrzeżenia + wymogu poprawy.

Warto również brać pod uwagę to, że dostępność to również późniejsze redagowanie strony pod tym kątem czy przygotowywanie dokumentów jako dostępne pliki PDF / Word / Excel.

Deklaracja dostępności

Do przystosowanej pod dostępność strony internetowej powinna być wykonana deklaracja dostępności opisująca m.in.

  • Kto przeprowadzał audyt i na jakiej podstawie została sporządzona ocena dostępności;
  • Jaki standard (poziom) spełnia strona internetowa;
  • Jakie ułatwienia wprowadzają one dla użytkowników;
  • Co nie zostało przystosowane wraz z wyjaśnieniem;
  • Możliwość zgłoszenia problemu z dostępnością;
  • Datę złożenia deklaracji oraz ostatniej aktualizacji strony.

Jest tego oczywiście znacznie więcej.

Temat deklaracji szerzej omówimy w kolejnym artykule, bo jej obecność jest bardzo ważna. Niestety gotowe wtyczki nie sporządzą za nas deklaracji dostępności, a nikt świadomy wszystkich aspektów technicznych związanych z dostępnością nie podpisze się pod stroną, której dostępność została zrobiona wtyczką.

Co za tym idzie? W przypadku braku takiej deklaracji, którą realizuje się na bazie wdrożonej dostępności strony internetowej, możemy ponieść konsekwencje.

Czy za brak lub brak dostępności można dostać karę?

Tak. Oczywiście warunek ten muszą spełniać podmioty gospodarcze, które zostały wymienione na początku artykułu. Zgodnie z Ustawą o dostępności cyfrowej, niespełnienie wymogów dotyczących dostępności może pociągać za sobą nałożenie na instytucję kary finansowej. Konkretne cyfry przedstawiają się w ten sposób:

  • Brak zapewnienia dostępności – do 10 000 zł;
  • Brak deklaracji dostępności – do 5000 zł;
  • Brak dostępności dla Biuletynu Informacji Publicznej oraz elementów stron opisanych w Art. 8 ust. 2 pkt 2 – do 5000 zł.

Poza karami finansowymi, podmioty mogą utracić możliwość dofinansowania.

Kontrolę naszego serwisu i nałożenie kary może przeprowadzić Ministerstwo Cyfryzacji. Przypominamy, że pod koniec tego roku będzie miało miejsce pierwsze sprawozdanie do Komisji Europejskiej, a na rok 2022 przewiduje się pierwsze kary za brak deklaracji dostępności strony internetowej.

Jak sprawdzić czy moja strona spełnia WCAG?

Przede wszystkim nie należy sugerować się wtyczkami zapewniającymi dostępność strony w kilku prostych krokach i stwierdzać, że po ich instalacji mamy temat gotowy. Jeżeli nie jesteśmy osobami technicznymi lub posiadającymi wiedzę o dostępności, to nie należy także ufać naszej intuicji, bo jako osoby sprawne nie zauważamy wielu aspektów, które odczuć może osoba narażona na wykluczenie cyfrowe.

Najbardziej stosownym sposobem weryfikacji będzie przeprowadzenie audytu dostępności, na bazie którego następuje później wdrożenie standardu oraz sporządzenie deklaracji dostępności. Taki audyt najlepiej wykonać w firmach specjalizujących się w dziedzinie dostępności cyfrowej. Można również skorzystać z automatycznych usług audytujących stronę internetową, ale niestety nie będzie to takie dokładne, jak audyt i testy wykonane przez wykwalifikowanych specjalistów.

Możemy również użyć narzędzi do szybkiego testu pod kątem dostępności naszej strony, ale nie należy opierać na nich całego przystosowania strony pod kryteria sukcesu.

Podsumowanie

Temat dostępności stron internetowych jest bardzo obszerną kwestią wymagającą dużej wiedzy i doświadczenia związanego z programowaniem stron internetowych. Co więcej, opiera się ona o doświadczenia użytkownika, umiejętności przewidywania zachowania i sytuacji użytkowników narażaonych na wykluczenie cyfrowe oraz ogólnych dobrych praktyk robienia stron internetowych.

Nie pozwólmy sobie wmówić, że wszystkie wyżej wymienione rzeczy jesteśmy w stanie załatwić instalacją jednej wtyczki do WordPresa czy innego CMSa. WordPress ma dużo możliwości zrobienia czegoś samemu, ale niestety dostępność nie zalicza się do grona takich rzeczy, które można zrobić bez znajomości technologii wykorzystywanych przy rozwiązaniach webowych i wymaga dokładnego podejścia do tematu, bo pamiętajmy – mówimy o czymś, co poparte jest ustawą i może mieć swoje konsekwencje.

Z tego miejsca zapraszamy również do skorzystania z naszej oferty. Oferujemy kompleksowe rozwiązania związane z dostępnością stron internetowych:

Jak zainstalować WordPressa? Poradnik dla każdego.

WordPress jako system zarządzania treścią (nie mylić z wordpress.com) jest darmowym oraz najpopularniejszym systemem zarządzania treścią. Jego instalacja jest możliwa do wykonania samodzielnie – należy jednak pamiętać o kilku konkretnych kwestiach niezbędnych do prawidłowego przebiegu konfiguracji.

Większość hostingów posiada w panelu klienta możliwość automatycznej instalacji WordPressa pod wybraną domenę, jednak nasz poradnik skupia się na zrobieniu tego we własnym zakresie.

Dlaczego lepiej zainstalować WordPressa samemu?

Warto zrobić to z jednej prostej przyczyny – instalując WP samemu, mamy pełną kontrolę nad tym, co instalujemy. Instalując WordPressa z autoinstalatora dostępnego w panelu hostingu, nigdy nie mamy pewności, co tak naprawdę się dzieje i czy nie są instalowane jakieś dodatkowe pliki.

Na co zwracać uwagę przy zakupie konta hostingowego?

Zanim przystąpimy do zainstalowania naszego WordPressa, potrzebujemy konta hostingowego. Nie będziemy tutaj omawiać zakupu domeny i podpinania jej, bo u każdego dostawcy wygląda to zawsze trochę inaczej, a z reguły każdy z nich na swojej stronie posiada odpowiednie poradniki jak to zrobić.

Skupimy się tutaj bardziej na wymogach, jakie musi spełniać hosting przy założeniu, że chcemy mieć najnowszą wersję WordPressa.

Do najważniejszych spraw, na które warto zwrócić uwagę należą:

  • Obsługa PHP w wersji 7.3 w górę,
  • MySQL w wersji 5.6 w górę lub MariaDB w wersji 10.1 w górę,
  • Wsparcie SSL,
  • Zalecany serwer w oparciu o Apache lub NGINX,
  • Zalecamy również hosting na dyskach SSD lub dedykowany pod WordPressa.

Na chwilę obecną te standardy spełniają takie serwisy hostingowe, jak:

  • Cyber_Folks
  • OVH
  • az.pl
  • Zenbox.pl

Zapewnia je większość najpopularniejszych firm hostingowych, ale również wiele innych mniejszych. Finalny wybór hostingu pozostaje po stronie Klienta, a w razie pytań możemy pomóc, doradzić albo zaproponować hosting u nas.

Przy pisaniu tego poradnika korzystamy z naszego testowego konta na cyber_folks.

Podsumowując – przed rozpoczęciem instalacji WordPressa będziemy potrzebować konto hostingowe spełniające odpowiednie wymagania z podpiętą domeną.

Pobieranie paczki z WordPressem na komputer.

Na tym etapie pobierzemy paczkę z plikami WordPressa, które będziemy musieli rozpakować i przerzucić na nasz serwer FTP.

Najnowszą wersję WordPressa w paczce można pobrać z tego miejsca.

Stworzenie konta FTP, czyli tworzymy konto które pozwoli nam zainstalować pobrane pliki WP na serwerze.

Każdy z hostingów posiada Panel admina (DirectAdmin, cPanel itp). To właśnie w tym miejscu w bezpieczny sposób zarządzamy naszym serwerem.

W tym miejscu znajduje się również możliwość zarządzania oraz tworzenia kont FTP. Odnajdujemy taką opcję u siebie i tworzymy konto.

Nazwę użytkownika oraz hasło zapisujemy w programie do przechowywania haseł (Lastpass, 1 password, KeePass) albo w inny bezpieczny sposób.

Może zdarzyć się sytuacja, że nie zostanie podany nam adres serwera FTP. Wówczas odnajdziemy go w DirectAdminie lub Danych dostępowych, ponadto w FAQ dostawcy znajduje się informacja na temat adresu erwera FTP.

Kolejny krok – baza danych, czyli najważniejsza rzecz.

Baza danych to prawdopodobnie najważniejszy element strony internetowej opartej o WordPressa (ale także każdej innej), ponieważ w bazie danych będą znajdować się wszystkie treści, produkty, użytkownicy itd. Wszystko, co dodamy przez panel administratora umieszczane jest w bazie danych.

Tak samo jak w przypadku konta FTP, utworzyć bazę danych możemy z poziomu Panelu Admina/DirectAdmina. Powinnyśmy mieć tam opcję „Utwórz nową bazę MySQL”, którą wybieramy.

Wpisujemy nazwę bazy danych, nazwę użytkownika oraz hasło.

Po utworzeniu takiego konta powinniśmy otrzymać informację o adresie bazy danych. Zazwyczaj jest to localhost, ale może być również adres, który sprawdzimy w danych dostępowych.

Krótkie podsumowanie na tym etapie.

Na tym etapie na wykupionym przez  nas hostingu z podpiętą domeną utworzyliśmy konto FTP, które pozwoli nam przesłać pobrane wcześniej pliki WordPressa. Stworzyliśmy także bazę danych niezbędną do instalacji WordPressa.

Co dalej?

Łączymy się z serwerem i wgrywamy WordPressa.

Przechodzimy w tym momencie już do konkretów! Jednak zanim wgramy pliki WordPressa na naszym serwerze, musimy się z nim połączyć.

Musimy w tym momencie zainstalować dowolnego klienta FTP:

  • WinSCP
  • FileZilla
  • Total Commander
  • Cyberduck

W naszym przypadku korzystamy z WinSCP i bardzo go polecamy. Pobieramy dany program i instalujemy go na naszym komputerze, stosując się do instrukcji przy instalacji. Gdy zainstalujemy – włączamy program.

Naszym oczom ukaże się interfejs programu, który jest względnie prosty bo od razu powinniśmy zauważyć miejsce do wpisania wcześniej utworzonego konta FTP:

Teraz dość ważna kwestia, ponieważ po połączeniu z serwerem w zależności od hostingu – możemy mieć różną strukturę folderów, a my szukamy miejsca, gdzie musimy wgrać nasze pliki na stronę. Poniżej przedstawiamy kilka przykładowych ścieżek, które mogą się pojawić:

  • /domains/mojadomena.pl/public_html
  • /public_html/
  • /www/
  • /mojadomena.pl/

Gdy nie mamy pewności czy wybraliśmy prawidłowy katalog, wgrywamy nie pusty plik testowy na przykład: test.txt o treści dla przykładu: „TEST OK” do potencjalnie dobrego katalogu. Próbujemy uzyskać do niego dostęp przez przeglądarkę przechodząc do adresu mojadomena.pl/test.txt. Jeżeli wybraliśmy prawidłowy katalog, powinna nam się ukazać treść pliku, w przeciwnym przypadku wybraliśmy złą ścieżkę.

Gdy już jesteśmy w odpowiednim katalogu na serwerze, przerzucamy nasze pliki do serwera.

Jak sprawdzić czy pliki WordPressa zostały przesłane prawidłowo?

Najprostszą metodą, by to sprawdzić jest po prostu wpisanie w przeglądarce adresu naszej strony. Jeżeli wszystko zrobiliśmy dobrze, to naszym oczom powinna ukazać się taka oto plansza zapraszająca do dalszej instalacji WordPressa.

Pojawił się taki widok? Świetnie, przechodzimy dalej klikając „Zaczynajmy!”.

Ostatni etap – konfiguracja!

Kolejnym krokiem, o jaki poprosi nas WordPress jest podanie mu informacji o bazie danych, którą utworzyliśmy wcześniej:

Dodatkowo pojawi się również pole do wpisania prefiks tabel. Domyślnie jest on ustawiony na wp_ jednak ze względu bezpieczeństwa zalecamy zmienić prefiks na jakiś inny.

Klikamy „Wyślij” i jeżeli wszystko zrobiliśmy dobrze to naszym oczom ukaże się komunikat:

A co w przypadku komunikatu „Błąd łączenia się z bazą danych”?

Komunikat ten w większości przypadków pojawia nam się wtedy, gdy prawdopodobnie podaliśmy błędne dane do połączenia z bazą danych, dlatego weryfikujemy wszystkie te informacje.

Teraz pozostał nam ostatni etap, w którym musimy nadać nazwę naszej strony internetowej oraz utworzyć konto administratora.

Ze względów bezpieczeństwa zalecamy używać generatora haseł oraz unikać prostych haseł typu audi123 czy jan123. Preferujemy także używać innej nazwy użytkownika niż domyślny admin.

Na dole mamy również informację „Poproś wyszukiwarki o nieindeksowanie tej witryny”. Na etapie, w którym dopiero robimy nasza stronę, warto zaznaczyć opcję, aby Google nie indeksował naszej strony w wersji roboczej.

Klikamy „Zainstaluj WordPressa”, po czym pojawi się komunikat:

Gratulujemy! Właśnie udało Ci się zainstalować WordPressa.

Podsumowanie

Pamiętajmy, aby po instalacji i skonfigurowaniu naszej strony, zadbać o jej odpowiednie zabezpieczenie strony internetowej i ograniczyć się do minimum wtyczek (nie używać wtyczek niewiadomego pochodzenia oraz modyfikowanych paczek WordPressa – mogą zawierać złośliwy kod).

Mamy nadzieję, że nasz poradnik będzie pomocny przy instalacji WordPressa we własnym zakresie.

W razie problemów służymy pomocą! Nie chcesz robić tego samodzielnie? Zleć nam realizację strony internetowej z wykorzystaniem systemu WordPress lub samą instalację systemu.

Złe nawyki w biznesowej komunikacji internetowej.

Witam!

Używanie słowa „Witam” przez wiele osób w komunikacji biznesowej odbierane jest jako obraźliwe. Według definicji słownikowej słowo „Witam” jest formą pozdrowień przy spotkaniu czy reakcją na widok czegoś. Witać może nas gospodarz, gdy zaprasza nas do swojego domu lub Klient kiedy zaprasza nas do biura.

Słowo to warto pożegnać i zamienić na klasyczne „Dzień dobry” czy nawet, jeżeli mamy jakiś bliższą więź z Klientem, „Cześć”.

Używanie maila jako komunikatora

Bardzo często zdarza się, że dostajemy od jednego nadawcy ciąg wiadomości mailowych, która każda kolejna jest uzupełnieniem poprzedniej.

Przełóżmy tutaj pewien dobry nawyk z życia codziennego i przemyślmy to, co chcemy powiedzieć, zanim rzeczywiście to powiemy. Pamiętajmy, że nikt nie każde nam odpisywać od razu i warto uzbierać konkretną wypowiedź i dopiero wtedy wysłać to jako jedną wiadomość.

Szybkie odpowiedzi

Od czasów szkolnych uczono nas, aby wypowiadać się pełnym zdaniem. Jeśli więc nie chcemy pisać dłuższych wiadomości, to warto pamiętać o tej zasadzie i na zapytanie „Czy mogę na dzisiaj spodziewa się raportu?” odpisać „Tak, może Pan dzisiaj spodziewać się raportu”.

W takim przypadku, gdyby Klient otrzymał od nas po prostu „Tak”, mógłby to odebrać jako zlekceważenie go, ponieważ nie poświęciliśmy wystarczająco dużo czasu na to, aby złożyć jedno zdanie.

Wiadomość w temacie wiadomości

Punkt ten w pewnym stopniu nawiązuje do dwóch ostatnich punktów.

W dobrej komunikacji biznesowej zazwyczaj w pierwszym akapicie powinno określić się cel czy też podać konkretną informację. Do tego służy Temat wiadomości, aby jego odbiorcy określić nasz cel.

Nie warto podążać tutaj myśleniem „napiszę o co chodzi w temacie, to będzie widział od razu o co chodzi i przeczyta”. Jest to oczywiście błędne myślenie, bo jeżeli ktoś ma odczytać naszą wiadomość – to i tak ją przeczyta. Nie musimy tak ostentacyjnie zachęcać do czytania naszej wiadomości.

Składanie ofert przez komunikatory

Jest to niestety bardzo częsty błąd. Ogólnie można nawet powiedzieć, że załatwianie interesów czy celów służbowych przez wszelkiego rodzaju komunikatory np. Messengera jest mało profesjonalne.

Tego typu komunikatory służą najczęściej do szybkiego kontaktu. Owszem – śmiało można dopytać o pewne szczegóły projektowe czy informacje o produkcje, jednak samo złożenie oferty powinno być zrealizowane profesjonalnie – w PDFie na papierze firmowym. Unikajmy nawet składania ofert w formie mailowej jako zwykły niesformatowany tekst.

Ogromnym błędem jest również składanie ofert przez komunikatory w formie kopiuj wklej. Jest to sygnał dla odbiorcy, że Klient ma się odezwać do nas. Nie okłamujmy się – w 90% przypadkach konkretny Klient się do nas nie odezwie.

Za dużo słów / za dużo informacji

Dobrym nawykiem w komunikacji jest przedstawienie problemu / rozwiązania / zagadnienia w pierwszych zdaniach wiadomości, a dopiero w jego dalszej części ewentualnego rozwinięcie wątku.

Zdarza się tak, że to, co interesuje Klienta, piszemy na samym końcu wiadomości i jest szansa, że do tego miejsca Klient nie dotrze, bo po prostu zabraknie mu czasu lub cierpliwości

Klient, któremu przedstawimy nasz przekaz od razu, zainteresowany na pewno przejdzie do rozwinięcia naszej myśli. Starajmy się dalsze wypowiedzi formułować w miarę zwięźle i na temat.

Używanie socjolektu

Socjolekt to forma wypowiedzi składająca się ze słów związanych z konkretną branża i wiedzą.

Wyobraźmy sobie sytuację np. z branży stron internetowych, że dopytujemy Klienta o szczegóły realizacji. Klient wie o stronach internetowych tyle, co my o podróżach w czasie.

„Możemy zrealizować dla Pana stronę typu one-page ze standardami WCAG z wykorzystaniem CMS WordPress z SSLem.”

Jedno zdanie, 5 słów socjolektu. Klient który nie ma bladego pojęcia o stronach internetowych będzie miał problem ze zrozumieniem słów „one-page”, „WCAG”, „CMS”, „WordPress” „SSL”.

W takich przypadkach warto przełożyć to „na chłopski rozum”, co oznaczają konkretne słowa / skróty. W takim przypadku, powyższa wiadomość powinna wyglądać tak:

„Możemy zrealizować dla Pana stronę one-page – jest to forma strony internetowej gdzie wszystkie treści można obejrzeć bez klikania na stronie. Strona będzie posiadała standard WCAG, czyli będzie spełniała normy odbioru przez osoby niepełnosprawne. Strona zbudowana będzie w oparciu o system zarządzania treścią WordPress, aby bez znajomości programowania mógł Pan dodać sobie treści na stronę. Strona będzie posiadała także certyfikat SSL czyli kłódkę przy adresie strony.

Wypowiedź trochę dłuższa, ale konkretniejsza dla osoby bez wiedzy technicznej. Często też używanie socjolektu względem takiego Klienta, odbierane jest jako forma wywyższenia się – ja wiem, a Pan nie.

Brak odpowiedzi

Brak odpowiedzi w komunikacji biznesowej jest niegrzeczne, choć bardziej pasuje tutaj nawet używać słowo wulgarne.

Wyobraźmy sobie sytuację, że jesteśmy na spotkaniu. Rozmawiamy o ofercie, przechodzimy do konkretów i w tym momencie nasz Klient bierze ofertę do ręki i wychodzi bez słowa. Jak poczulibyśmy się w takiej sytuacji? Sądzę, że nie było by to za bardzo miłe.

Tak samo jest w komunikacji mailowej. Jeżeli ktoś wysyła nam ofertę – podziękujmy oraz napiszmy, że zapoznamy się z ofertą i odezwiemy się w przeciągu kilku dni.

Będąc na miejscu odbiorcy oferty – w przypadku nie wybrania oferty wykonawcy, warto napisać, że dziękujemy za ofertę, ale wybraliśmy innego wykonawcę.

Często robiąc oferty, uwzględniamy w nich czas pracy oszacowany na podstawie aktualnych mocy przerobowych. Jeżeli odpowiedź napisze się po miesiącu – można spotkać się z informacją, że aktualnie czas realizacji z oferty wydłuża się ze względu na inne prace.

Nieprecyzyjne określanie zadań

Realizując jakiś projekt lub produkt, warto jest rozłożyć go na czynniki pierwsze. Warto określić cele, nasze wymagania, przygotować sobie wszystkie informacje, które będą potrzebne wykonawcy.

Bardzo złymi formami zapytań są np. „Dzień dobry, ile kosztuje budowa domu?” czy „Dzień dobry, w jakiej cenie robią Państwo strony?”.

W wielu branżach koszt zrealizowania czegoś jest uzależniony od czasu pracy, od potrzebnych materiałów, od wielkości itp. i nie ma stałych cen za takie usługi.

Jeżeli faktycznie chcemy wybudować dom – napiszmy metraż, liczbę pokoi, informacje o materiałach, o lokalizacji i wszystkie inne wskazówki, które i tak wykonawcy będą potrzebne do zrealizowania celu.

Taka forma pytań jest bardzo ogólna i stawia nas w oczach odbiorcy jako osobę nieprzygotowaną do zrealizowania swojego celu.

NIE KRZYCZ

Korzystanie z wielkich liter w komunikacji internetowej jest odbierana jako forma krzyku, jednak w wielu przypadkach jest ona stosowana w celu podkreślenia jakiejś części wypowiedzi w zdaniu.

Naukowo udowodnione jest, że zdanie sformułowane tylko z wielkich liter będzie odbierane jako zdanie pretensjonalne albo forma ataku. Jeżeli faktycznie chcemy już coś zaakcentować w zdaniu – używajmy pogrubienia.

Literówki

Prawdziwy klasyk, którego niestety nie pilnujemy i zdarza się praktycznie każdemu. Mało tego – bardzo często nie zwracamy na to uwagi, że podczas pisania tekstu edytor sugeruje nam źle napisane zdanie.

W tym temacie krótko – piszmy poprawnie po polsku i nie róbmy literówek. A jak już, to poprawiajmy.

Zła forma komunikacji

Prawda jest taka, że takich nawyków można by doszukać się znacznie więcej. Kilka przypadków wymienionych wyżej przytoczyliśmy z autopsji.

Warto nad tym popracować, aby polepszyć naszą formę porozumiewania się przez Internet, zwłaszcza jeśli kontaktujemy się w sprawie naszego biznesu.

Finalnie jednak warto zastanowić się nad tym, czy każdy Klient ma ochotę porozumiewać się drogą internetową? W wielu przypadkach zawsze lepiej jest się spotkać lub złapać za telefon, a otrzymaną wiadomość e-mail wykorzystać tylko jako temat do rozwinięcia rozmowy lub formalnej finalizacji zlecenia.