Strony internetowe

Strony www na WordPress – czy to naprawdę „CMS nr 1 na świecie”?

Strony internetowe na WordPress powstają nieprzerwanie od 2003 roku. Przez ten czas zyskał on status najbardziej uniwersalnego, elastycznego, wręcz zbliżonego do ideału rozwiązania w zakresie projektowania stron www. Przez wielu programistów nazywany jest on CMSem nr 1 na świecie. Czy słusznie?

W poniższym wpisie przedstawię własne obserwacje na temat realizacji projektów właśnie z wykorzystaniem tego rozwiązania. Są to wnioski wynikające z zaangażowania w wiele projektów, które tworzone były wewnętrznie ale także takich, które przejmowaliśmy jako wsparcie techniczne.

  • Czym tak naprawdę jest WordPress i dlaczego jest on tak popularny?
  • Wdrożenie strony na WordPressie może przeprowadzić każdy ale nie każdy potrafi zrobić to dobrze
  • WordPress posiada bardzo wiele zalet. Potrafi jednak przysporzyć także wielu niespodziewanych problemów.

Na czym polega WordPress?

WordPress to bez wątpienia najpopularniejszy system zarządzania treścią (CMS) na świecie. Jest to darmowe oprogramowanie, zbudowane w oparciu o PHP i MySQL. W założeniu twórców system ten powstał jako narzędzie blogowe. W miarę upływu czasu, dzięki dużej społeczności skupionej wokół projektu, ewoluował on jednak do miana CMSa do wszystkich zastosowań. Znany jest ze swojej uniwersalności – do tego stopnia, że do dziś powstają z jego wykorzystaniem:

  • Blogi
  • Strony internetowe
  • Sklepy internetowe
  • Landing page’e
  • Serwisy informacyjne
  • Inne, nieskomplikowane aplikacje

Jestem przekonany, że niejednokrotnie czytałaś/-eś treści zawarte na stronie opartej właśnie o to narzędzie. Wynika to choćby z czystej statystyki, według której, zgodnie z opracowaniem W3Techs, aż 64,3% udziału w rynku CMSów posiada właśnie WordPress (stan na 23 września 2022 roku).

WordPress posiada bardzo intuicyjny interfejs. Użytkownik może w nim zarządzać wpisami (newsami), stronami statycznymi, mediami czy użytkownikami. Dodatkowo umożliwia tworzenie on tzw. taksonomii w ramach wspomnianych wcześniej elementów. Do niedawna wyposażony był w edytor zbliżony swoimi funkcjami do klasycznego Worda; dziś natomiast jego głównym narzędziem w zakresie obróbki treści jest edytor Gutenberg.

Gutenberg zawiera szereg predefiniowanych bloków, które sprawiają, że edycja treści polega na klikaniu na odpowiednie bloki, np. akapit, nagłówek, obrazek, itp. A następnie uzupełnianie treści w ramach wybranych bloków. Bloki te są automatycznie konwertowane na wersję HTML i wyświetlane następnie na stronie. W praktyce jest to bardzo przyjemne rozwiązanie. Co jednak, gdy potrzebujemy bloków innych, niż standardowe?

Wtyczki, motywy, filtry i akcje

Gdy funkcje oferowane przez WordPressa przestają wystarczać, wówczas do akcji wkraczają… Wtyczki! A jest ich całe zatrzęsienie.

To właśnie wtyczki są głównym powodem tak wielkiej popularności WordPressa. Wtyczki do formularzy, do grafiki, do SEO, a nawet do usuwania tzw. „sierotek” w tekście. Dosłownie do wszystkiego! A każda z nich wpływa na to, jak wydajny staje się WordPress. Każda wtyczka to wpinanie oddzielnej logiki do tzw. akcji i filtrów w ramach motywu. Oznacza to dokładnie tyle, że każda wtyczka wykonuje dodatkowe co najmniej (oby tylko!) jedną operację.

Spójrzmy na przykład na sytuację, w której mamy świeżo zainstalowany projekt. Czy wiesz, że przy każdym odświeżeniu strony, uruchamianych jest 61 akcji i 238 filtrów modyfikujących kod? A to tylko „czysta” wersja, bez żadnej wtyczki!

Czy WordPress jest trudny?

Stosując WordPressa do wdrożenia prostych stron www, możemy uznać, że nie jest on specjalnie trudny do nauki. Wspierając się edytorem Gutenberg każdy, bez przesadnej znajomości zasad programowania może stworzyć swojego własnego bloga czy autorską stronę. W miarę zwiększania stopnia skomplikowania wymagań projektowych, trudność wdrożenia WordPressa znacząco jednak wzrasta.

Znajomość języka PHP jest absolutnym minimum, jeśli chodzi o przygotowywanie stron w oparciu o tego CMSa. I choć sam rdzeń WordPressa jest bardzo dobrze zabezpieczony (tu jednak domyślnie moim zdaniem powinien być wyłączony dostęp publiczny do API (patrz: „Czarna dziura. Czyli rest api a WordPress”), to prawdziwy problem może pojawić się podczas stosowania niesprawdzonych wtyczek lub własnych implementacji. O tym jednak nieco później.

Jakie są zalety WordPressa?

Bezwzględną wartością CMSa jest to, że jest on oparty o licencję open source. Efektem tego jest bardzo duża społeczność skupiona wokół projektu. W efekcie:

  • Powstaje wiele wtyczek, obniżając koszt rozwoju oprogramowania (wiele gotowych rozwiązań)
  • Każdy ma dostęp do kodu i może wnosić do niego swoje usprawnienia,
  • Na rynku jest wielu specjalistów (ale także osoby uważające się za nich).

Bezsprzecznie więc, popularność i intuicyjność tego oprogramowania to główne jego zalety. Czy aby na pewno nie przesłaniają one jednak wad, które rzutują na końcową wydajność strony?

Jakie są wady WordPressa?

WordPress, pomimo swojej popularności, ma także dość istotne wady. I choć wady te można łatwo wyeliminować, będąc ich świadomym, to często spotykam się z sytuacjami, gdy wdrożony serwis jest niezoptymalizowany, nieodpowiednio zabezpieczony i/lub niegotowy na współpracę z integrowanymi rozwiązaniami. Moim zdaniem najbardziej istotnymi problemami są:

  • Nieoptymalna struktura tabel w bazie danych WordPress
  • Brak domyślnego zabezpieczania formularzy
  • Niepoprawne kody odpowiedzi z API
  • Stosowanie edytorów wizualnych

Struktura tabel w WordPress

Domyślnie, struktura bazy danych WordPressa opiera się na 12 tabelach. I dopóki serwis nie jest zbyt rozbudowany, nie stanowi to żadnego problemu.

Struktura bazy danych WP

Problem pojawia się w chwili, gdy zaistnieje co najmniej jeden z dwóch podstawowych scenariuszy:

  1. Mapa strony zostanie potężnie rozbudowana
  2. Zostanie zainstalowana nadmiarowa liczba wtyczek

Dlaczego są to problemy? Otóż pomimo posiadania domyślnych 12 tabel WordPress większość danych umieszcza w dwóch: wp_posts oraz wp_postmeta. Dzieje się tak dla większości treści na stronie, dla mediów oraz dla dodatkowych pól tworzonych na etapie rozbudowy serwisu (np. przez wtyczki). Wpisy odróżniane są poprzez kolumnę post_type a ich atrybuty umieszczane są w tabeli wp_postmeta.

Jaki jest tego efekt? Z każdym nowym wpisem tworzonych jest kilka rekordów w wp_posts (treści, media, custom post type’y), a do każdego z nich, w wp_postmeta, dodawanych jest kolejna określona liczba atrybutów.

Skutkiem takiego stanu rzeczy są coraz wolniejsze zapytania do bazy. Często zdarza się więc także, że nieświadomy problemu programista może stworzyć wtyczkę, która wywołując się przy każdym odświeżeniu strony odpytuje taką bazę. Gdy więc na przykład zainstalowana została wtyczka woocommerce (sklep), dodanych zostało tysiące (dziesiątki tysięcy?) produktów oraz sklep ma duży ruch, a na dodatek powstało nieefektywne zapytanie do bazy, wyświetlające jakieś parametry, powstaje mieszanka wybuchowa, uniemożliwiająca normalne korzystanie ze strony (sklepu internetowego).

Brak zabezpieczenia domyślnych endpointów API.

Standardowa instalacja WordPressa posiada ogólnodostępne endpointy, z których można wyciągać podstawowe dane. Problem polega jednak na tym, że oprócz danych ogólnodostępnych jak strony czy wpisy blogowe, możliwe jest pobranie także listy użytkowników panelu. Wystarczy, że wejdziemy na endpoint:

/wp-json/wp/v2/users

i dostaniemy ich listę. Wtedy już możemy albo spróbować ataku brute force - albo na etapie logowania przez przeglądarkę albo poprzez inny endpoint, np. komendą:

curl -X GET --user username:password -i http://yoursite.com/wp-json/wp/v2/posts?status=draft

Jeśli przy którejś próbie otrzymamy wyniki, wiemy, że trafiliśmy z danymi logowania i możemy dokonywać dowolnych operacji na pozostałych, zabezpieczonych endpointach.

Brak domyślnego zabezpieczenia formularzy

Nierzadko zdarzało nam się pracować z projektami otrzymanymi „w spadku”, które posiadały różnego rodzaju zapytania AJAX (asynchroniczne) do backendu w WP. Jest to normalna praktyka, którą stosuje się, aby uzyskać efekt dynamicznego przetwarzania danych, bez konieczności przeładowywania strony.

I właśnie, w zależności od tego, jak bardzo świadomy zagrożenia był programista, mógł on uwzględnić zabezpieczenie przesyłanych danych przed jednym z najczęstszych zagrożeń w aplikacjach webowych – SQL Injection.

Domyślnie bowiem funkcje WP nie są w żadnym stopniu zabezpieczane. Nieświadomy programista może więc przyjąć dane takie, jakimi są i je dalej przetworzyć (np. dane kontaktowe). Gdy użytkownik zamiast danych kontaktowych zdecyduje się przesłać kod, może dojść do sytuacji, w której przykładowo uzyska dostęp do danych w bazie danych. Stąd już, jak się zapewne domyślasz, krótka droga do katastrofy.

Niepoprawne kody odpowiedzi z API

Ten problem pojawia się często w podobnych sytuacjach, jak te z formularzami.

Zadaniem backendu jest odpowiedź na zapytanie wraz z odpowiednim statusem (dla uproszczenia 2xx – poprawne, 4xx-5xx – niepoprawne, gdzie x to cyfra 0-9). Jaki jest tego efekt? Pracując z takimi funkcjami, często zdarza się sytuacja, w której przetwarzamy formularz, wysyłamy go na backend, a pomimo błędu (np. walidacji) otrzymujemy kod 200. W efekcie możemy otrzymać odpowiedź, że formularz został wysłany oraz wiadomość towarzyszącą, np. „niepoprawny email”. Bazując na statusach, użytkownikowi zostanie wyświetlony komunikat, że wszystko było w porządku. Wiadomość jednak nigdy do adresata nie dotrze…

{
	status: 200,
	message: „Invalid email”
 }

Edytory wizualne

W czasach, gdy wyjątkowo popularne stało się stosowanie szablonów graficznych opartych o edytory wizualne, ich niepoprawne implementacje sprawiły, że strony, oprócz problemów wymienionych wcześniej, stały się jeszcze mniej wydajne.

Edytory wizualne, poprzez swoją strukturę, dodały bowiem olbrzymią ilość nadmiarowego, wynikowego kodu HTML, który sprawia, że próby pozycjonowania takiego serwisu okazują się bezskuteczne. Okazuje się wówczas, że nawet największy budżet przeznaczony na działania optymalizowania wyników w wyszukiwarkach może nie przynieść oczekiwanych rezultatów – Google zwyczajnie nie lubi wolnych stron.

Zaufało nam już ponad 200 firm.
Wyceń bezpłatnie swój projekt.

Jaka alternatywa dla WordPressa?

Stwierdzenie, że WordPress jest „CMSem nr 1 na świecie” jest, według mnie, dużym nadużyciem. Oczywiście, jeśli chodzi o popularność, nie ma on sobie równych. Nie popularność jednak decyduje o tym, czy jest to najlepsze rozwiązanie dla firm. Nieumiejętne wykorzystanie zalet WordPressa często może skutkować błędami pozycjonowania lub wręcz sprawiać, że serwis nigdy nie pojawi się w wynikach wyszukiwania na pożądane przez nas frazy.

Na przestrzeni lat w Mits korzystaliśmy z naprawdę szerokiego zestawu CMSów i możemy stwierdzić, że wreszcie znaleźliśmy taki CMS, który spełnia wszystkie nasze wymagania. Nie jest on niestety aż tak popularny, przez co wielu naszych Klientów (w tym także być może i Ty 😉) nie chce decydować się na jego zmianę. Wiemy jednak, że posiada on wszystkie te funkcje, które charakteryzują WordPressa (a nawet więcej!) a przy tym jest dużo bardziej wydajny.

Postanowiłem więc, że podzielę się z Tobą swoimi opiniami na temat WordPressa, a już w kolejnym wpisie przedstawię naszą propozycję. Propozycję, która zmieniła nasze podejście do tworzenia stron.

Aktualizacja:

Ps. Szewc bez butów chodzi. Ale nie my. W Mits korzystamy właśnie z tego, naszym zdaniem najlepszego obecnie, CMSa. Poznajcie Sulu! 😉

Udostępnij

Zarezerwuj spotkanie icon Zarezerwuj spotkanie