Główny cel istnienia CMS-ów to przyspieszenie prac nad aplikacjami internetowymi. Większość stron zawiera zestaw typowych elementów, przeważnie opakowanych jedynie w nieco inną szatę graficzną, dlatego możemy zaprogramować szkielet, każdy taki element osobno, a później składać stronę z gotowych cegiełek, skupiając się na tym, gdzie co ma się pokazywać i jakie interakcje mają zachodzić między nimi. Oszczędzamy przez to czas pracy programistów oraz zwiększamy niezawodność - wystarczy raz napisać i dokładnie przetestować jeden komponent, a może on nam służyć w wielu projektach. Ścieżką tą próbują też podążać popularne CMS-y PHP, których istnieje cała masa. Patrząc na ich oficjalne strony, znajdziemy pokaźne katalogi dodatków, które wystarczy ściągnąć i zastosować u siebie, aby w kilka dni zbudować dużą witrynę. W tym miejscu zatrzymujemy się nad pierwszą wadą...
Mnóstwo komponentów... i co dalej?
Jedną z podstawowych wad CMS-ów jest brak jakiejś przewodniej myśli czy idei, która byłaby widoczna w całym projekcie. Projektanci takiego systemu przeważnie zatrzymują się na pomyśle, że musi być możliwość użycia wielu cegiełek - komponentów. Super, możemy pościągać 100 MB dodatków, zainstalować je, ale co dalej? Milczeniem pomijany jest fakt, że na większości stron różne elementy potrafią ze sobą współpracować. Taka funkcjonalność jest zapewniana jedynie, gdy pomyśli o niej autor komponentu, ze strony CMS-a najprawdopodobniej nie doczeka się żadnego wsparcia. Współpraca może i nie jest potrzebna przy budowie stron typu mydło i powidło, ale bardziej poważne rzeczy już jej wymagają. Tutaj obecność dużej liczby komponentów niewiele daje, gdyż i tak będziemy musieli je przerabiać, a to już wymaga umiejętności programistycznych.
Odbiorca docelowy
Oprogramowanie pisane jest z myślą o pewnej grupie docelowej użytkowników. Korporacyjne CMS-y powstają zgodnie z wytycznymi firmy i są dostosowane do potrzeb, procedur lub profilu działalności, dzięki czemu praca z nimi faktycznie jest wydajna. Projektanci otwartych systemów popełniają jeden, zasadniczy błąd, mianowicie kierują swe produkty do użytkowników niemających pojęcia o tworzeniu stron internetowych. Nie mówię tu oczywiście o samym zadaniu wypełniania strony treścią, gdyż tym zadaniem zazwyczaj zajmują się właśnie tacy ludzie, ale o samym stawianiu i konfigurowaniu systemu do pracy. Efekt to ogromna liczba kreatorów, konfiguratorów i paneli, które muszą uwzględniać tak dużą liczbę opcji by być wystarczająco ogólne, że ich używanie na dłuższą metę wcale nie jest takie proste. W dodatku sama ogólność też jest iluzoryczna, o czym się boleśnie przekonałem.
Największą ogólność układu strony zawsze da możliwość edycji kodu źródłowego. Da się tak zaprojektować API, by było to zadanie proste, ale trzeba o tym zawczasu pomyśleć i je zrobić. Spełnianie marzeń zwykłych ludzi o tworzeniu stron okrężną drogą i zapominanie, że jednak mnóstwo witryn tworzą normalni programiści to kolejna wada przynosząca efekt odwrotny od zamierzonego. Zamiast czytelnego i elastycznego systemu jest skomplikowany i ograniczony.
Jakość kodu
Orientacja CMS-ów na zwykłych, prostych ludzi to miecz obosieczny również z innego powodu. Wiele CMS-ów ma dość stary rodowód, a ich twórcy wtedy również sami nie mieli zbyt dużych umiejętności programistycznych. Efekt to ogromna ilość archaicznego, źle napisanego kodu, który nie bardzo da się tak łatwo wymienić, by nie stracić ogromnej popularności wśród ludzi, którzy średnio się znają na aktualizowaniu oprogramowania i PHP. Kod Joomli nawet w wersji 1.5 to gigantyczny śmietnik bez większego ładu, który nawet nie bardzo jest jak poprawiać, gdyż autorzy kurczowo trzymają się muzealnego PHP4, a który przez to niebawem przestanie całkowicie działać na nowych wersjach. Już teraz przy próbie uruchamiania Joomli na PHP 5.3 jesteśmy atakowani mnóstwem komunikatów o nieprawidłowym użyciu jakiegoś elementu, które nie bardzo da się wyłączyć. A co będzie, gdy wejdzie PHP 6?
Druga problematyczna rzecz to API takich frameworków, które jest strasznie nieuporządkowane. Jeśli używane jest programowanie obiektowe, wiele elementów zaprojektowanych jest niezgodnie z jego regułami, a normą jest istnienie "klas do wszystkiego i do niczego". Mam wrażenie, że wiele rzeczy w Joomli powstawało na zasadzie "kurna, potrzebuję tutaj XXX... (klep klep klep) OK, jest! Zaraz to zcommituję i będzie to częścią nowej wersji". Weźmy dla przykładu klasę JPagination do generowania stronicowania. Aby dodać stronicowanie do jakiejś listy trzeba wykonać tyle rzeczy (na dodatek część z nich zaszyta jest w zupełnie innych klasach, które ze stronicowaniem nie powinny mieć nic wspólnego), że przy większej ilości kodu bardziej się opłaca siąść i napisać własną bibliotekę.W sumie jedyny plus, jaki dostrzegłem to poprawna implementacja wzorca MVC, czego nie można powiedzieć o większości świetnie napisanych frameworków... :)
Bezpieczeństwo
Dziury w zabezpieczeniach są bezpośrednim następstwem źle napisanego, nieprzemyślanego kodu, a próba ich łatania to syzyfowa praca. Załatamy sto dziur, dodamy nowy kod według tych samych śmietnikowych standardów, robi nam się 50 kolejnych. Wiele z zabezpieczeń powstało na zasadzie, że ktoś tam coś usłyszał o tym, po czym znalazło się to w kodzie bez specjalnego zrozumienia, czemu to w ogóle ma służyć. W efekcie kod korzysta z mnóstwa rzeczy niezgodne z ich przeznaczeniem, a to prowadzi do luk, które można wykorzystać do ataku.
Problemy rodzi również sama konfigurowalność i założenia projektowe. W Joomli mechanizm wybierania, jakie moduły w bocznych panelach mają towarzyszyć głównej treści opiera się na argumencie Itemid przekazywanym razem z adresem URL, który identyfikuje pozycję menu. Wpiszemy inny ID, mogą nam się wyświetlić zupełnie inne moduły. Co gorsza, powiązany z nim jest też system bezpieczeństwa. Jeśli coś przeoczymy, wejście do "niedostępnej dla gości" strony będzie sprowadzało się jedynie do usunięcia Itemid z adresu... moim zdaniem dobrze zaprojektowany system powinien uniemożliwiać takie zagrywki.
Niebezpieczne dodatki
Gwoździem do trumny są ostatecznie same dodatki. Wiele z nich zostało napisanych przez osoby, które po prostu nie potrafią jeszcze na tyle dobrze tworzyć oprogramowanie, by zapewnić mu odpowiednią jakość. Tragiczny kod to jedna z wielu konsekwencji. Przykładem takiego zupełnie nietrafionego rozwiązania jest popularny Community Builder, którego kod to jedna wielka rzeźnia reimplementująca połowę funkcjonalności Joomli, w tym m.in. rezygnująca z szablonów na rzecz zaszytego w kodzie HTML-a. Co z tego, że można sobie wyklikać pola społecznościowe, kiedy na dłuższą metę dodatek jest praktycznie nie do użycia i spersonalizowania? Ponadto uniemożliwia to współpracę dodatków, o której pisałem na początku.
Skoro już jesteśmy przy temacie dodatków, ze smutkiem należy przyznać, że w przypadku Joomli ich twórcy w wielu przypadkach łamią licencję GPL. O ile sprzedaż dodatków za pieniądze jest w porządku, o tyle dostarczanie zakodowanych źródeł czy blokowanie prób udostępniania tychże w innych miejscach już jest jak najbardziej karalne. Przypomnę, że Joomla rozprowadzana jest na licencji GNU General Public License, co oznacza, że oprogramowanie łączące się z nią i wymagające jej do współpracy w przypadku próby rozpowszechniania musi samo być udostępnione także na takiej licencji. Jeśli nawet kupię płatne rozszerzenie, mam prawo je udostępnić na swojej stronie za darmo innym bez względu na to, co w "licencji" napisał jego autor, ponieważ jego licencja jest w tym wypadku naruszeniem prawa.
Jak sobie poradziłem?
W przypadku mojego zadania poradziłem sobie w najbrutalniejszy sposób: napisałem coś w rodzaju mini-frameworka, który zintegrowałem z OPT (a co, jak już się bawić, to czemu mam sobie utrudniać życie pisaniem szablonów w PHP?) i wyposażyłem w podstawowe biblioteki do obsługi formularzy, których w Joomli brakuje, stronicowania oraz własną implementację MVC. To ostatnie było konieczne, gdyż Joomlowa bazowała na PHP4 i po prostu przy bardziej zaawansowanych operacjach zachowywała się niedeterministycznie, co czyniło korzystanie z niej wysoce ryzykownym. W efekcie powstał gigantyczny komponent, do którego trzeba było na dodatek dodać kilka modyfikacji właściwego kodu źródłowego CMS-a, aby załatać braki i idiotyzmy domyślnych mechanizmów.
Dobry CMS?
Stworzenie elastycznego i skalowalnego CMS-a to zadanie moim zdaniem trudniejsze od napisania frameworka. To nie jest jedynie napisanie kilkunastu bibliotek i ew. dodanie jakiegoś kreatora, a napisanie kilkudziesięciu bibliotek, paneli i jeszcze zbudowanie na tym odpowiednio zaprojektowanego systemu. Za zadanie to biorą się jednak przeważnie ludzie, którzy albo nie do końca wiedzą, co właściwie chcą stworzyć (czyt: posługują się wyłącznie stereotypami), albo nie mają wystarczających umiejętności, by na chwilę obecną coś takiego nie tylko napisać, ale i zaprojektować. Wystarczy spojrzeć na proporcje. Ile potrafisz wymienić porządnych frameworków? Prawdopodobnie co najmniej kilka. Ile potrafisz wymienić porządnych CMS-ów? Mi żaden nie przychodzi do głowy. Słyszałem jedynie o planach stworzenia nowego Extreme Fusion, którego twórcy chcą właśnie skierować się bardziej na programistę, a nie na zielonych użytkowników i porządnie go zaprojektować (według autorów, w projekcie ma być wykorzystany framework Kohana oraz Open Power Template 2). Niestety, na efekty przyjdzie nam prawdopodobnie jeszcze długo poczekać, gdyż dotąd całość nie wyszła jeszcze poza etap planów. Perspektywy są marne. Jeśli ktoś ma pomysł, jak stworzyć taki elastyczny CMS, będzie raczej wolał zachować go dla siebie i wykorzystywać do celów komercyjnych, niż ot tak go wypuścić.
Podsumowanie
Werdykt jest dość jednoznaczny. CMS-y takie, jak Joomla i Mambo nie nadają się do poważniejszych zastosowań z uwagi na ogromną liczbę niewłaściwych założeń, niską jakość kodu oraz błędy projektowe będące tam na porządku dziennym. Jeśli nie zamierzamy tworzyć strony z gatunku mydło i powidło, lepszym wyborem będzie napisanie jej z użyciem porządnego frameworka. Wprawdzie będziemy musieli napisać takie rzeczy, jak zarządzanie artykułami czy użytkownikami, ale na pewno zajmie to mniej czasu, niż naprawianie tego, co jest skopane w CMS-ie i reimplementowanie połowy jego funkcjonalności, by w ogóle móc dotrzeć do celu.
Napisał karol w wtorek, 27 października 2009 o 18:13
a co byś powiedział na komercyjnego cms'a z odpowiednią licencją dla programistów, dobrym api, pełną dokumentacją, bezpłatnymi automatycznymi aktualizacjami i wsparciem technicznym z tym wyjątkiem że ścisły kod cms'a byłby zamknięty (co nie wykluczałoby jednak pisania doń własnych modułów, czy też rozszerzeń do już istniejących modułów)? I co jeśli mógłbyś to dostać za jakąś rozsądną cenę? Myślisz że taki model miałby szanse zaistnieć i się przyjąć na szerszą skalę?