15 błędów popełnianych na początku pracy z systemem WordPress

Artykuł kierowany jest głównie do osób stawiających pierwsze kroki przy budowaniu stron w opraciu o WordPressa, osoby mniej techniczne posiadających swoje strony na WP oraz poczatkujących WP Developerów.

Spis treści


Instalacja autoinstalatorem lub poprzez usługę hostingu

Dzisiaj już praktycznie każdy hosting umożliwia zainstalowanie dowolnego systemu z poziomu panelu hostingu poprzez tzw. autoinstalatory. To oczywiście bardzo kuszące, bo w łatwy sposób możemy samodzielnie zainstalować WordPressa. Jednak dlaczego nie powinno się tego robić?

Powodów jest kilka. Pierwszym z nich jest fakt, że paczka instalacyjna jest przygotowywana przez firmę hostującą. Nie chcemy tutaj nikogo oczerniać, ale w takim przypadku nigdy nie mamy pewności, czy pliki nie zostały zmodyfikowane lub uszkodzone.

Drugim powodem jest to, że najczęściej automatycznie tworzona jest baza danych z domyślnym prefiksem, który warto zmienić dla bezpieczeństwa. W tym przypadku również nie mamy pewności, co zostaje nam dodane do bazy dodatkowo.

Jak prawidłowo zainstalować WordPressa?

Jeżeli decydujemy się zainstalować WordPressa – instalujemy go ręcznie przez serwer FTP, pobierając go bezpośrednio z oficjalnej strony WordPressa, a bazy danych twórzmy ręcznie.

Jeśli mamy dostęp do shella, możemy użyć WP-CLI.


Brak bieżącej aktualizacji wtyczek i core

Kolejny błąd nie tylko dotyczy początkujących, ale dotyczy bardzo często również osób, które posiadają strony zrealizowane przez agencje bądź freelancerów – są to strony żyjące swoim życiem, czyli takie, które pozostawione są bez opieki.

Mowa tutaj o bieżącej aktualizacji wszelkiego rodzaju wtyczek, motywów oraz samego core WordPressa. Bardzo często spotykamy się z przypadkami, kiedy klient powierzający nam opiekę nad stroną lub zlecający nam pojedyncze prace, ma na niej dużą liczbę nieaktualizowanych wtyczek. Całkiem niedawno zdarzył nam się również przypadek strony, która wykorzystywała jeszcze WordPressa w wersji 4.9 (czyli wersji z końcówki 2017 roku).

Dlaczego bieżące aktualizacje są tak ważne?

Jest ku temu bardzo prosty powód. Stare, niewspierane wersje core / wtyczek / motywów bardzo szybko trafiają pod lupę hakerów. Hakerzy korzystając z dostępnych dla danej wersji luk, realizują działania szkodliwe dla naszej strony i bardzo często w takim przypadku dochodzi np. do infekcji strony lub włamań.

Rozwiązanie? Starajmy się przynajmniej raz w miesiącu robić wszystkie aktualizacje. WordPress od wersji 5.5 posiada możliwość automatycznej aktualizacji wtyczek, co teraz znacznie ułatwia nam sprawę.


Używanie starej wersji PHP

Przypadek, z którym można spotkać się bardzo często – WordPress 5.5 zainstalowany na serwerze z ustawioną wersją PHP 5.6. Bardzo mało osób przed instalacją WordPressa nie sprawdza wymagań dotyczących tego CMS-a. I jest to poważny błąd, bowiem automatycznie w tym momencie zwalniamy działanie naszej strony i zmniejszamy poziom jej bezpieczeństwa.

Przed instalacją WordPressa warto sprawdzić czy nasz serwer posiada PHP w wersji 7.4, gdyż najnowsza wersja WordPressa zaleca pracę na tej wersji, a jak już wcześniej wspomnieliśmy – bieżące aktualizacje systemu są bardzo ważne.


Operacje na żywym organizmie

Bardzo duża część początkujących WordPressowiczów nie zdaje sobie zupełnie sprawy, jak powinno wyglądać odpowiednie środowisko do pracy z WP. Wynika to głównie z tego, że większość witryn budowana jest na gotowych motywach, niewymagających integracji w kod.

Ale co w przypadku, gdy jednak w tym kodzie trzeba będzie coś zrobić, bo np. nie wiemy jak używać połączenia FTP albo lokalnego serwera? Robimy zmiany w kodzie na żywym organizmie.

Błąd polega na tym, że w sytuacji gdy wysypie nam się strona – bo np. coś źle napisaliśmy w kodzie, to bez dostępu do serwera FTP nie będziemy w stanie uratować strony poprzez np. usunięcie błędnego kodu albo nadpisanie pliku na poprawny.

Jak edytować pliki motywu WordPressa?

Przed każdą zmianą w kodzie szablonu warto zrobić sobie jego kopię zapasową. Aby edytować kod naszego motywu powinniśmy używać tylko edytora kodu, takiego jak Visual Studio Code, Brackets czy Sublime Text – odradzamy używanie notatnika.

Edytory kodu potrafią nam pokazać błędy w kodzie podczas edycji. Zalecamy wszystkie zmiany testować w środowisku testowym lub lokalnie, a także korzystać z systemu kontroli wersji.

Pamiętajmy również o tym, że zmiany w kodzie najlepiej robić na motywie potomnym, o czym piszemy niżej.


Brak pracy na motywie potomnym (child theme)

Wyobraźmy sobie taką sytuację – wprowadziliśmy zmiany klientowi np. w pliku header.php i index.php. Klient po 2 tygodniach pisze do nas, że zrobił aktualizacje i nasze zmiany przestały działać.

Co się stało? Nasze zmiany zostały nadpisane przez pliki wypuszczone w ramach aktualizacji motywu. Właśnie po to powstała możliwość tworzenia child theme. Ideą motywów potomnych jest możliwość zmian bez konsekwencji w przypadku np. właśnie aktualizacji głównego motywu.

Zdarzyć się może, że kupiony gotowy motyw będzie wymagał jakiejś poważniejszej i większej zmiany w jego kodzie. Nie robimy tego wówczas na głównym motywie, tylko tworzymy swoją wersję kupionego motywu i pracujemy na niej.


Używanie wtyczek do wszystkiego

Kolejnym błędem przez początkujących WordPressowiczów jest szukanie i instalowanie wtyczek do absolutnie wszystkiego. Często bowiem spotykamy się z wtyczkami, które mają zastąpić coś, co ręcznie można zrobić w kilka minut.

Za doskonały przykład niech posłuży Google Analytics. Istnieje bardzo dużo wtyczek, które w łatwy sposób, poprzez podanie identyfikatora usługi, podpinają nam to narzędzie pod stronę. Pytanie tylko – po co tak „brudzić” WordPressa? Tym bardziej, że nigdy nie mamy pewności, co we wtyczce siedzi.

Przy zakładaniu GA dostajemy gotowy kod do wklejenia na stronę, gdzie tak naprawdę wystarczy minimum wiedzy (połączenie FTP oraz edycja pliku), aby takie narzędzie podpiąć pod stronę. A w przypadku ewentualnej obawy przed zrobieniem tego ręcznie, wystarczy poprosić kogoś, kto siedzi w tym temacie.

To tylko jeden z przykładów. Dobrymi przykładami są np. wtyczki migracyjne do optymalizacji, wtyczka do zainstalowania Messengera na stronie czy nawet certyfikatu SSL.

Wtyczki nie powinny być pierwszą sprawą, o której myślimy w przypadku chęci dodania jakiejś funkcjonalności na stronie. Często zastępują one działania, które obeznana w temacie osoba zrobi w parę minut i niekoniecznie musi kosztować to miliony.


Trzymanie zbędnych wtyczek i motywów

Zasadniczo po instalacji WordPressa i instalacji własnego motywu, zostaje w nim zawsze kilka motywów oraz wtyczek, których nie używamy. A że ich nie używamy, to również ich nie aktualizujemy, czego potencjalne efekty opisaliśmy wyżej.

Jeżeli nie używamy danych motywów oraz wtyczek to po prostu warto je usunąć z serwera. Zabezpieczamy się przed potencjalnymi lukami nieaktualizowanych wtyczek / motywów oraz zwalniamy miejsce na serwerze.


Wtyczki optymalizacyjne

Powiedzmy to od razu – wtyczki optymalizacyjne nie są najlepszym sposobem na przyśpieszenie działania naszej strony, bo finalnie niewiele robią.

W jakimś stopniu takie wtyczki “coś” nam pomogą, ale czasami efekty są zupełnie odwrotne do tego, czego oczekujemy. Używając tych wtyczek bez zagłębiania się w ich możliwości, możemy pogorszyć funkcjonowanie strony.

Nie warto używać wtyczek, które rzekomo zrobią coś za nas automatycznie.

Jak zoptymalizować stronę WordPress?

Temat optymalizacji strony jest bardzo indywidualny. Poza standardowymi operacjami typu kompresja grafiki, to nie ma jednego sprawdzonego sposobu na optymalizację strony, ponieważ na prędkość motywu składa się wiele czynników m.in kod motywu, dołączone biblioteki, wielkość zdjęć. Wszystkie te rzeczy wymagają dokładnej analizy.

Najlepszy wynik optymalizacji uzyskamy podchodząc do tematu indywidualnie bez użycia zbędnych wtyczek.


Wtyczki zabezpieczające

Uzupełniając temat wtyczek, ostatnią kwestią, której powinniśmy unikać to wtyczki „zabezpieczające”. Tworzą tylko złudne poczucie bezpieczeństwa np. poprzez ładny interfejs, dobrą stronę sprzedażową i dobre opinie dodane przez osoby niezdające sobie sprawy jak działają takie wtyczki. Ale nie zapominajmy – właśnie dodaliśmy do naszego WordPressa kolejną wtyczkę, która również może zawierać luki umożliwiające infekcję czy włamanie się na stronę – tym bardziej, że tego typu wtyczki są dość popularne wśród użytkowników i ingerują bezpośrednio w core WordPressa.

Takich wtyczek powinno się użyć np. w celu szybkiego przeskanowania strony gdy np. nie mamy możliwości połączenia FTP, a faktycznie mamy podejrzenie infekcji, jednak trzeba brać pod uwagę scenariusz, w którym wtyczki tego typu mogą manipulować wyniki skanowania w celu sprzedaży ich wersji PRO. Po przeskanowaniu najlepiej jest je od razu usunąć, a najlepiej nie używać i skanować lokalnie lub przez połączenie SSH, albo zlecić skan obsłudze hostingu.


Używanie SSL w celu zabezpieczenia strony

Trzeba powiedzieć to na głos – SSL nie ma na celu zabezpieczenia strony i błędem jest myślenie, że do tego służy. Certyfikat SSL służy do szyfrowania informacji zachodzących między przeglądarką a serwerem, czyli np. w momencie przesłania danych klienta na sklepie internetowym, te informacje w drodze do serwera są szyfrowane.

Oczywiście w dzisiejszych czasach posiadanie certyfikatu SSL na stronie internetowej coraz częściej jest standardem, bowiem daje to poczucie bezpieczeństwa oraz wiarygodności, jednak kompletnie nie ma nic wspólnego z zabezpieczeniem strony internetowej od strony jej plików i funkcjonowania.


Tworzenie backupów po stronie WordPressa

Bardzo częsty błąd i niestety notorycznie spotykany. Bardzo często amatorzy WordPressa tworzą sobie backupy strony przy wykorzystaniu wtyczek np. All in One WP Migration czy BackWPup. Wtyczki te w łatwy sposób pozwalają na stworzenie kopii strony oraz jej przywracanie z poziomu CMS-a, bez potrzeby posiadania dodatkowej wiedzy.

Co jednak w sytuacji, kiedy nasza strona uległa awarii, nie możemy dostać się do WP Admina i przywrócić zrobionego backupu nasza magiczną wtyczką? Pamiętajmy, że jesteśmy osobą, która nie potrafi połączyć się z serwerem FTP i phpmyadmina. Jesteśmy w sytuacji, w której sami sobie możemy nie poradzić.

Pierwszą rzeczą, której powinni nauczyć się początkujący użytkownicy, czy twórcy stron na WordPressie, jest umiejętność stworzenia ręcznego backupu strony i ręcznego jej przywrócenia.


Zabezpieczenia treści wpuszczanych przez użytkowników / boty

Domyślny system komentarzy WP oraz brak jego zabezpieczenia może niestety skutkować masą spamu przychodzącego na naszą stronę. Taki komentarz, to też jakieś zapytanie do bazy danych i przestrzeń którą zajmuje, więc jeżeli tych komentarzy pojawi się nagle duża liczba – może okazać się, że nasz serwer zostanie przeładowany.

Jaki system komentarzy do WordPressa?

Bardzo polecamy integrowanie systemu komentarzy z Disqusem. Zdecydowanie unikniemy dużej ilość spamu poprzez możliwość ustawienia uwierzytelnienia użytkownika np. przez Facebooka. Oczywiście Disqus to nie wymóg, bowiem bardziej zaawansowana technicznie osoba może wdrożyć nam np. zabezpieczenie Recapcha.

Drugim problemem może okazać się np. formularz kontaktowy z którego boty spamujące korzystają równie chętnie, jak z systemu komentarzy. Przy formularzach kontaktowych możemy również spotkać się z problemem w postaci możliwości załączenia wszelkiego rodzaju załączników – nawet takich złośliwych, bo nie zostały ograniczone wprowadzenia co do wielkości oraz formatu przesyłanego załącznika. Pomijając wyżej opisane kroki, warto doprecyzować jakie pliki mogą zostać przesłane na nasz serwer i ile mogą ważyć.


Posiadanie wielu stron na jednym hostingu

Posiadanie wielu stron na jednym koncie hostingowym jest bardzo oszczędnym rozwiązaniem od strony finansowej. Dlaczego jednak lepiej na jedną stronę przeznaczyć tylko jedno konto hostingowe?

Załóżmy sytuację, w której na jednym serwerze mamy 15 stron, a jedna ze stron padła ofiarą infekcji. Jest duże prawdopodobieństwo, że nasza infekcja przeniesie się bezpośrednio na pozostałe strony umieszczone na tym serwerze i wtedy mamy 14 razy problemów więcej.

Jeżeli chcemy posiadać kilka stron – kupujmy osobne serwery dla każdej strony lub ustawiamy separację domen.


Display: none;

Drobny błąd polegający na ukrywaniu pewnych elementów strony za pomocą własności display: none. Spotkaliśmy się kiedyś z przypadkiem strony, na której tą metodą był ukryty system komentarzy, a mimo to – komentarze spływały. Jak zatem do możliwe?

Bot spamujący nie wpisuje wszystkiego ręcznie, tylko z góry wie jakie konkretne akcje ma wywołać, aby komentarz znalazł się w naszej bazie danych.

Display:none tylko ukrywa element, ale nadal pozostawia go w kodzie strony.

Jeżeli planujemy już ukrywać elementy na stronie – w pierwszej kolejności sprawdzamy, czy nasz motyw nie posiada do tego odpowiedniej opcji. W drugiej kolejności możemy edytować kod child theme, aby usunąć całkowicie ten element ze strony.


Wybór WordPressa

Ostatnim błędem, który omówimy jest wybranie samego WordPressa jako bazę zarządzania treścią naszej strony. WordPress bardzo często wybierany jest dlatego, że daje nam możliwość łatwego stworzenia swojej strony internetowej w przypadku braku wiedzy technicznej oraz chęci oszczędzenia na kosztach związanych z pisaniem autorskich systemów CMS.

Nie zapominajmy jednak, że WordPress jest najpopularniejszym systemem zarządzania treścią. Według statystyk na rok 2020 – ponad 35% stron internetowych zbudowanych jest na systemie WordPress.

Za tą popularnością idzie również zainteresowanie hakerów, którzy wśród stron internetowych szukają sobie bardzo często czarnych owieczek, które pozwolą na stronę wpuścić różnego rodzaju wirusy, które prawdopodobnie przyczynią się do zarobku albo podbudowania ego hakera.

Pomyślmy czy warto w ogóle robić to na WordPressie?

Zastanówmy się przed tym wszystkim, jak dużo i z jaką częstotliwością będziemy zmieniać teksty lub zdjęcia na stronie? Bo jeżeli przewidujemy rozbudowywać ofertę raz na rok, galerię uzupełniać raz na pół roku, a zdarza się i tak, że po 2 latach strona ma nadal te same treści, co w momencie publikacji, to w takim przypadku kompletnie nie ma sensu robić strony na WordPressie. Najlepszą wtedy opcją (i też bardziej opłacalną finansowo) będzie posiadanie strony na zwykłych plikach html, bez podpiętego CMS-u. Szukamy tylko osoby / firmy, która za symboliczną opłatę lub abonament będzie umieszczać nam te informacje, a my możemy być spokojni, że wyeliminowaliśmy system zarządzania treścią, który poza dodatkowym kosztem – oszczędzi nam dużo potencjalnych problemów związanych z jego popularnością.