Blog

Źle się dzieje w państwie duńskim, czyli "rynek" CMS-ów dla Pythona

Subiektywny przegląd CMS-ów zbudowanych w oparciu o Pythona.

Źle się dzieje w państwie duńskim, czyli "rynek" CMS-ów dla Pythona

W jednym z moich poprzednich wpisów wspominałem, że jakiś czas temu (a ściślej był to rok 2018) odbiłem się od Django. Z perspektywy czasu przyznać muszę, że w pierwszej kolejności był to efekt niewłaściwie ukierunkowanych oczekiwań czy raczej błędnego rozpoznania charakteru tego frameworka. Mówiąc wprost widziałem w nim narzędzie będące czymś na modłę wyszukanego CMS-a niźli zestaw narzędzi do tworzenie internerowych aplikacji. W mojej opinii taki charakter Django uprawdopodobniała geneza jego powstania, co z resztą po latach potwierdził jego współtwórca Simon Willison (“We never really intended to build a web framework—for the longest time, the code that became Django was referred to as “the CMS”).

Tak czy siak moją przygodę z tamtego okresu trudno uznać za szczególnie udaną, a przy tym na tyle zniechęcającą, że na dłuższy czas dałem sobie spokój z tematyką web devu, choć potem były jeszcze jakieś – już nieco bardziej owocne – eksperymenty z WordPressem czy Drupalem. Jednak gdyby nie nagła potrzeba zaistnienia w blogosferze, pewnie dalej bym żył w przekonaniu, że to jednak domena nijak nie przystająca do moich zainteresowań czy bardziej trafniej rzecz ujmując: rzeczywistość, taka jaka mi się wówczas objawiła pozostawała w totalnej kontrze do moich wyobrażeń i oczekiwań.

Dzisiaj moja ocena jest oczywiście zgoła inna, o czym dobitnie może świadczyć chociażby to, że  pierwotnie chciałem pisać na nieco inne tematy, a póki co moja aktywność w tym zakresie krąży wokół tematu tworzenia rozwiązań webowych. Tym niemniej moja słabość do Pythona mocno doprawiona niechęcią od JavaScript wzięła górę i tym sposobem zacząłem się rozglądać za rozwiązaniem na Pythonie bazującym. Rzecz jasna tym razem moje oczekiwania były dużo lepiej określone i tym sposobem zdecydowałam się przyjrzeć projektom, których twórcy jednoznacznie definiują je jako rozwiązania CMS właśnie. 

Niestety od razu muszę napisać, że oczywiście nie spodziewałem się aż takiego bogactwa jak w przypadku ekosystemu PHP, to aż takiej nędzy chyba jeszcze bardziej. Tak naprawdę w przypadku Pythona można mówić o trzech rozwiązaniach, które jakoś tam lepiej lub gorzej funkcjonują i są rozwijane przez swoich twórców. Z resztą nie jestem nawet przekonany, czy nie powinienem mówić de facto tylko o dwóch, ale o tym za chwilę. Co gorsza każdy z nich zbudowany jest na bazie Django, który to framework – jak już wielokrotnie pisałem – nie jest moim faworytem, choć akurat w tej kwestii nie spodziewałem się, że będzie inaczej. Rzecz jasna jest tych CMS-ów troszkę więcej, ale są to projekty mniej lub bardziej niszowe póki co (FeinCMS), a przy tym nierzadko już nierozwijane (Django Fiber) bądź całkiem porzucone, a w najlepszym razie będące nadbudową, na którymś z trzech CMS-ów, o których troszkę dalej będzie można przeczytać. Nie da się ukryć, że nie wygląda to ekstatycznie, ale w końcu nie ilość się liczy, a przynajmniej nie zawsze.

Jeśli chodzi o wspomniane trzy rozwiązania to rzecza jasna mam na myśli:

Mezzanine

I tutaj możemy przejść do kwestii faktycznej liczebności stanu posiadania, bo w przypadku Mezzanine nie mam jakoś przekonania, że ten projekt jest jeszcze rozwijany, a na pewno wygląda na to, że znalazł się w fazie bardzo głębokiej stagnacji. Wprawdzie na Githubie widać jakieś nieśmiałe ruchy, ale ostatnie stabilne wydanie datowane jest na sierpień 2018 roku. Rzecz jasna o niczym to jeszcze świadczyć nie musi, ale jeśli weźmiemy pod uwagę fakt, że w 2019 roku miało miejsce wydanie 3 wersji Django, gdzie wprowadzona została między innymi oczekiwana przez wielu asynchroniczność, to taki zastój rodzi pewne wątpliwości i ja raczej temu projektowi nie zamierzam poświęcać przesadnie wiele czasu, zwłaszcza, że mi go nie zbywa. Wspominam o nim z kronikarskiego obowiązku, ponieważ zazwyczaj pojawia się w takich jak moje wyliczeniach CMS dla Pythona.

Wagtail

Drugie z wymienionych rozwiązań (Wagtail) ma stosunkowo najkrótszy staż, bo światło dzienne ujrzało dopiero w 2014 roku, tym niemniej zdążyło już wyprzedzić swojego leciwego konkurenta (za chwilę o nim będzie) w walce o rząd dusz miłośników Pythona. Świadczyć o tym może liczba gwiazdek na Githubie oraz różnorodnych tutoriali, na które można się natknąć w Internetach. Nie będę się mądrzył w kwestii samego rozwiązania, bo ledwie przejrzałem początkową dokumentację na stronie projektu, a też nie chcę powielać tego, co piszą o tym bardziej biegli w temacie. Z całą pewnością Wagtaila wyróżnia bardzo schludny i ponoć całkiem ustawny panel administratora oraz kawał solidnej dokumentacji. Niestety za dużo w nim naleciałości z Django, a ściślej zafiksowania się na schemacie model-widok-szablon, przy czym ten pierwszy wydaje się ten pierwszy element być szczególnie wyeksponowany. W sieci można się nawet spotkać na określeniu Wagtail jako frameworka CMS a nie CMS jako takiego i tutaj faktycznie może być coś na rzeczy, bo to rozwiązania chyba głównie budowana z myślą o deweloperach/programistach, a znacznie mniej na twórcach kontentu czy chociaż tych, który jakoś bardziej skupieni są na front-endzie. W związku z tym na ten moment odpuszczam sobie to narzędzie.

Django CMS

Na koniec pozostaje wspomnieć o Django CMS, po którym chyba najmniej dobrego się spodziewałem, ale to był w pierwszej kolejności efekt całkowitej niewiedzy. Z powodu tych braków prawdopodobnie dokonałem podświadomego skojarzenia jego nazwy z samym frameworkiem (zakładałem też – nie wiedzieć czemu – że za oba narzędzia odpowiadają te same osoby). Dodatkowo data zawiązania się tego projektu (okolice 2007 roku) powodowała narastanie w mojej głowie przekonania, że w przypadku tego narzędzia dostajemy tylko lekko podrasowany framework Django. W pewnym sensie tak jest, ponieważ wykorzystywane są tu wszystkie mechanizmy, który mgliście pamiętam z moich zmagań z Django, choć rzecz jasna trudno by było inaczej. Na szczęście w dużej części zostały one przykryte autorskim rozwiązaniem, więc zgłębianie tajników “czystego” Django nie jest w tym przypadku konieczne. Jeśli mam być szczery to Django CMS zrobił na mnie dużo lepsze pierwsze wrażenie niż Wagtail, głównie za sprawą wyraźnej separacji działań związanych z tworzeniem kontentu od zadań ściśle programistycznych. Wbrew temu co można przeczytać na stronie projektu nie jest to rozwiązanie tak “przyjazne” jak WordPress, tym niemniej na bazie tego, co na ten moment udało mi się zobaczyć, jestem w stanie wyobrazić sobie, że na pewnym podstawowym poziomie poradzi sobie z jego obsługą osoba zupełnie nie zaznajomiona z Pythonem czy jakimkolwiek językiem programowania, choć w tym drugim przypadku raczej ciężko będzie o spektakularne rezultaty. No i co ważniejsze ktoś najpierw musi odpowiednio skonfigurować projekt, nad którym chcemy następnie takiego klikacza posadzić. 

Podsumowując

Jaki koń jest ponoć każdy widzi. W przypadku CMS-ów w ramach ekosystemu Pythona napisać więc należałoby, że mamy do czynienia raczej z jakąś lichą chabetą. Nie chcę przez to powiedzieć, że omówione wyżej rozwiązania stoją na niskim poziomie. Aż takiej śmiałości nie mam. Natomiast moją ocenę próbuję formułować z perspektywy pewnych standardów rynkowych wyznaczonych z jednej strony przez WordPressa, zaś z drugiej przez rozwiązania w rodzaju Strapi. Wydaje mi się, że nawet w przypadku CMS-ów, które określa się mianem “headless” próg wejścia jest niższy niż dla tego, co ma do zaoferowania Python. Oczywiście piszę to bez najmniejszej satysfakcji, ale mam wrażenie, że nie wróży to dobrze na przyszłość przynajmniej jeśli chodzi o rozwiązania sensu stricto związane z tworzeniem i zarządzaniem treścią (zwłaszcza w przypadku projektów raczej niewielkiej skali). Po cichu liczę, że Django CMS, który wydaje się nabierać rozpędu w ostatnich miesiącach może zmieni trochę tens stan rzeczy, ale o tym już w innym wpisie.