10 lat później i dziesięć największych problemów WordPressa

Więc na początek przyznam się do małej nieprawdy – pracuję przy WP trochę więcej niż 10 lat(ponad 11) plus problemów też mam więcej ale to fajniej brzmi w tytule komponując z topką problemów :)

Wracając jednak do tematu – po kilkunastu latach używania i kodowania na WordPressie myślę, że czas najwyższy zaznaczyć jakie są z nim największe problemy. Niektóre są nieco bardzie świeże, inne wiszą od początków cms-a, a jeszcze inne wynikają z… mentalności twórczej zespołu odpowiedzialnego za filar rozwoju platformy.

Żeby nie przedłużać:

Lista dziesięciu największych grzechów WordPressa.

1. Brak „porządnego”, natywnego narzędzia do importu/exportu danych.

Owszem, WP posiada dość prymitywne narzędzie, które możemy doinstalować z miejsca ale jest ono mega ograniczone i praktycznie bezużyteczne przy większych zadaniach. Chcesz wyeksportować konkretne wpisy? Masz pecha. Potrzebujesz tych mediów, żeby zaimportowały się prawidłowo? Rzuć koścmi, może się uda. Potrzebujesz wiedzieć jaki jest status importu dużych zadań? Straszne… Może tak eksport według wybranych tagów? Nie u nas.

To wszystko składa się na mega frustrację i potrzebę korzystania z zewnętrzych narzędzi, czy zabawę z WP CLI(do którego nie zawsze mamy dostęp).

Jesteśmy już na dalekim etapie rozbudowy całej platformy ale wewnętrzne narzędzia, które oferuje niestety jakością wołają nie raz o pomstę do nieba.

2. Sanityzacja nazw plików.

Tego na serio nie ogarniam do dzisiaj – dlaczego wszystkie inne, nie raz archaiczne cms-y to potrafią ale WordPress usilnie trzyma się w zachowywaniu niestandardowych znaków w nazwach plików? Jest to niesamowicie problematyczna kwestia przy jakichkolwiek operacjach na migracji danych, w skranych wypadkach pliki potrafią kończyć nawet jako uszkodzone.

Oczywiście jak na wszystko i od tego jest wtyczka ale to jest rzecz, która powinna być natywnie dostępna w WordPressie od BARDZO dawna.

3. Biblioteka mediów.

Kwestia, na którą notorycznie narzekają klienci – organizacja plików wgranych do cms-a jest po prostu okropna; przy więcej, niż kilkunastu plikach zawsze się robi problem.

W pełni rozumiem, że jest to m.in. związane ze sposobem zapisywania danych w bazie ale to mogło być przeorganizowane wieki temu, na obecnym etapie zastanawiam się, czy w ogóle zmiana jest możliwa.

Ponownie – są wtyczki(i najczęściej niestety płatne, jeśli całość ma działać sensownie) ale jest to funkcja, przy której niestety nie możemy sobie pozwolić na korzystanie z zewnętrznych modułów, plus te nierzadko są załadowane zbędnym „syfem”.

4. Wtyczki freemium.

Problem, który przewija się od lat. Repozytorium jest zalane wtyczkami, które nierzadko działają tylko i wyłącznie jako reklama dla wersji PRO(czyt. są okrojone maksymalnie do granic możliwości), zdarza się także że działają na zasadzie zewnętrznych abonamentów, subskrypcji, czy dużych jednorazowych opłat.

Całość potęguje fakt, że w bazie znajdują się nie raz klony tej samej wtyczki, oferujące identyczne możliwości ale również wisi na nich ten sam paywall.

Rozumiem, że po części całość wynika z faktu, że WordPress działa na otwartym kodzie i ma licencję jaką ma ale doszliśmy do miejsca, gdzie wtyczki w pełni darmowe, czy oferujące satysfakcjonującą liczbę funkcjonalności są znikomą częścią bazy.

Opierasz na tym cały swój biznes? Spoko, tylko nie rób z 3/4 okna roboczego reklamy wersji Pro, czy kilku-kilkunastu pustych, „zablokowanych” podstron. Oferujesz darmową wersję? Odpowiednio ją wspieraj, jeśli pootencjalny klient widzi, że nie obchodzi cię podstawowa wersja modułu, to dlaczego miałby się zainteresować rozbudowaną?

Przy okazji warto tutaj podpiąć się z innym problemem – „odkupowanych” wtyczek. Twórcy odsprzedają je nie raz za grosze komu innemu z różnych powodów, jednak najgorsze jest to, że w nie raz prostych wtyczkach po takim „oddaniu” dochodzi masa niepotrzebnego kodu, funkcjonalności, reklam, bibliotek i innego badziewia. Naprawdę fajnie by było, gdyby w zakres wymogów repo wszedł punkt o wymogu zaznaczenia grubym fontem na samym początku opisu timestampa, kiedy zmieni się właściciel(a jeszcze fajniej by było, gdyby na liście aktualizacji – ale to już sfera czystych marzeń). Najczęściej dowiadujemy się o tym niestety za późno i bardzo rzadko kiedy od samych właścicieli.

5. Gutenberg.

Słodki Jezu jak ja nienawidzę Gutenberga.

Pomysł pojawił się jakiś czas po „królowaniu” idei page builderów i łatwego „tworzenia ładnych stron za pomocą bloków” – kto siedzi w wordpressie od dłuższego czasu, ten wie że całość spadła na community i branżę jak lawina; nie wiem, czy oba są ze sobą bezpośrednio związane ale jeśli Gutek nie jest natywną odpowiedzią na płatne PB-y, to nie mam pojęcia czym jest.

W każdym razie gdzie leży mój problem z Gutenbergiem – pomijając to, że samo ładowanie arkuszów CSS dla niego to prawie 0.5MB(innych bibliotek nie sprawdzałem ale zakładam, że sam js wymagany do jego obsługi też do najlżejszych nie należy), natywnie wyparł wszystkie klasyczne edytory, jest niespecjalnie przejrzysty interfejsem i powoduje masę innych problemów zarówno na froncie jak i backu – po prostu spowolnił rozwój wordpressa.

Od czasu wdrożenia Gutenberga do jądra WordPressa stał się on głównym celem wszystkich aktualizacji i jest grubo naświetlany za każdym razem, gdy dostajemy nową łatkę. Ostatecznym gwoździem do trumny była dla mnie wersja 6.0 – która mogła jakoś… zrewoluzcjonizować postęp platformy, a dostaliśmy jeszcze więcej bajerów do Gutka. Owszem, mapa na 2022 zawiera drugi etap gutkowania ale dla mnie zmiany pierwszej liczby wersji zawsze były „znaczące”, a przynajmniej takie próbowały być.

Pomniejsze, „wielkie” rzeczy takie jak choćby wprowadzenie natywnego wsparcia dla webp(dopiero latem zeszłego roku!) pokazują się gdzieś na dole notek i w zasadzie można je bardzo łatwo przeoczyć.

Wordpress nadal ma swoje problemy, a uwaga teamu developerów (moim skromnym zdaniem) jest skupiana zupełnie nie tam, gdzie powinna.

wordpress.org/about/roadmap/ – jak widać też mapa na 2022 też wygląda(a właściwie wyglądała, bo lada chwila kończy sie nam rok) po prostu bzdurnie, natomiast lista aktywnie rozwijanych funkcjonalności: make.wordpress.org/core/features/ – też nie prezentuje się zbyt „przyszłościowo”.

6. Sortowania repozytoriów.

Wordpress do dzisiaj nie oferuje ŻADNEJ opcji sortowania wyników wyszukiwań dla wtyczek – czy to po wspierających najnowszą wersję, czy to po ilości instalacji, czy pozytywnych recenzjach – nic. Wpisujemy hasło i mamy nadzieję, że wielki brat pozwoli nam dzisiaj znaleźć to, czego szukamy.

Tutaj też obligatoryjnie należy wspomnieć o „popularne” przy bazie motywów:

– dziwnym trafem w top10 znajdują się motywy, które są dołączane do paczki WordPressa :) To trochę sytuacja jakby tego…

Same motywy mają jakieś pobieżne opcje sortowania, w tym również „najnowsze” co jest całkiem ok ale też nie nazwałbym tego pełnym pakietem, a już w ogóle w przypadku oficjalnej bazy.

7. Brak natywnego wsparcia panelu administracyjnego dla dark mode.

Interfejs administracyjny wordpressa zaczyna się powoli robić leciwy – i choć pojedyncze elementy interfejsu wyglądają jeszcze względnie „czysto”, tak inne wymagałyby redesignu.

Jednak ja nie o tym. WordPress docelowo był zawsze platformową blogową – i tak, od dawna zmienił się jej charakter na znacznie bardziej rozmaity i blogi na dzień dzisiejszy są może nawet w mniejszości… jednak nie zmienia to innej kwestii, natywnie nie wspiera ciemnego motywu dla interfejsu administracyjnego. Przy dłuższej pracy z tekstem oczy niesamowicie potrafią się męczyć klepiąc tekst klasycznie „czarno na białym”.

Wordpress jako przodująca platforma CMS powinna dawać dobry przykład innym, a nie wprowadzać rozwiązania długo później po kilkuset-krotnym naświetleniu problemu.

Ponownie musimy korzystać ze wtyczek albo pisać własny arkusz css.

8. Brak natywnego wsparcia dla stron multi-języcznych.

Kto miał potrzebę integrowania kilku języków na stronę ten wie, że na dzień dzisiejszy nie ma zbyt wielu „solidnych” opcji – ogranicza się to zazwyczaj do wyboru pomiędzy Polylang, a WPML – w zależności od tego jakie mamy potrzeby i jaki mamy dostępny budżet.

Polylang potrafi płatać figle, a czasami nawet powodować poważne problemy na dalekim etapie tłumaczeń – coś się spartaczy w bazie i możemy kombinować godzinami, czy nawet dniami żeby coś ugrać – to nierzadko kończy się na kompromisach, czy rozwiązaniach technicznie „niekonwencjonalnych”; osobom nieznaznajomionych w technikaliach możemy co najwżyżej życzyć powodzenia. Wisienka na torcie – wsparcie Woocommerce dla Polylang kosztuje 99€.

WPML jest cholernie nieintuicyjny – sam nierzadko gubię się w jego obsłudze, a teraz jeszcze wyjaśnić klientowi co, gdzie i jak… najbardziej brakuje mi w nim prostoty tłumaczeń bezpośrednich jak w polylang, tutaj cały proces jest o wiele bardziej skomplikowany. Doceniam natomiast support wpml-a, nie raz googlując widzę problemy zupełnie niezwiązane ze samą wtyczką, a zespół stara się pomóc nawet w takich przypadkach i robi to sukcesywnie. Realnie musimy zapłacić za licencję 99$ – podstawowa opcja nie posiada nawet możliwości tłumaczenia wyrażeń z motywu, czy wsparcia Ecommerce tak więc leci z automatu opcja „środkowa”. No i licencje ograniczają nie tylko support do jednego roku ale i też aktualizacje, tak więc niezależnie co kupimy za rok musimy odnowić.

Przejrzałem sobie również repozytorium WordPressa w poszukiwaniu alternatyw i owszem, są takie nowości jak „WP Globus”, czy „Falang” ale problem jest zawsze ten sam, rozszerzanie funkcjonalności w PRO albo brak wsparcia ecommerce w wersji darmowej.

Chcę natywnego wsparcia z zestawem filtrów, akcji i prostego tłumaczenia wpisów kolokwialnie mówiąc w wersji „idioto-odpornej”.

9. Zabezpieczenia… a właściwie ich brak.

Nie pamiętam kiedy ostatnio WordPress wprowadzał cokolwiek „radykalnego” pod względem zabezpieczeń – mieliśmy kilka lat temu wymuszenie minimalnej wersji php, czy półtorej roku temu skok wersji jquery ale w kwestii zabezpieczania samego panelu admistracyjnego od strony użytkownika nie dostaliśmy praktycznie nic.

Owszem, zabezpieczane/aktualizowane na bieżąco są cały czas wewnętrzne moduły, biblioteki itd. ale w kwestiach „praktycznych” zmiany są znikome, jeśli nie zerowe.

Kilka z przykładów:
* Motywy i wtyczki nadal mogą być edytowane bezpośrednio z panelu, do czasu aż tego sami nie wyłączymy.
* Panel ma statyczne adresy logowania od ZAWSZE.
* Do nazw użytkownika jak i haseł nadal możemy dawać „admin” lub nazwę strony.
* Folder wp-content może zawierać pliki wykonywalne php.
* Logowanie dwuetapowe jako opcja istnieje tylko w zewnętrznych wtyczkach.
* Prefiks bazy danych w kreatorze instalacji jest zawsze taki sam.
* Wersja wordpressa jest pokazywana publicznie w źródle.

Bonus: Do dzisiaj w zasadzie przerasta mnie wyobraźnia twórców oficjalnego artykułu, gdzie zaleca się instalowanie kombajnów… tak więc kolego, zainstaluj kombajna na swojej stronie-wizytówce, zapomnij o jego aktualizacji na następne kilka lat, a potem przypomnij sobie że „przecież instalowałem zabezpieczenia” i zrób minę pikaczu, bo Twoja strona linkuje do zagranicznych przedłużaczy konara :>

10. Brak natywnego lightboxa i leciwa obsługa galerii.

Nie do końca w zasadzie rozumiem dlaczego do dzisiaj nie wprowadzono unikalnego dla wordpressa skryptu typu Lightbox – nie jest to w zasadzie coś, co musiałoby się aktualizować co chwila, a dałoby użytkownikom podstawową możliwość względnie wygodnego przeglądania dużych galerii obrazkowych. Plus opcja włącz/wyłącz w opcjach wordpressa i voila.

No i właśnie jest jeszcze kwestia tych nieszczęsnych galerii – jest to cholernie archaiczne i jednocześnie nieintuicyjne. Gutenberg właściwie tylko naświetlił natywną opcję plus dodał kilka zbędnych bajerów ale ponowna próba ich edycji bywa nierzadko problematyczna.

Tak więc w ten sposób wygląda moja WordPressowa ściana płaczu, a was co w nim irytuje?