Drupal w poszukiwaniu najlepszego doświadczenia edytorskiego

Doświadczenie edytorskie staje się coraz istotniejsze dla każdego CMSa. Użytkownicy chcą większej kontroli, ale prostszych interfejsów. W przypadku Drupala, jednego z największych i najpopularniejszych CMSów Open Source na rynku, poszukiwanie najlepszego doświadczenia trwa do dziś. Społeczność testuje różne podejścia – wraz z każdą edycją niektóre nowe podejścia są badane dokładniej, a inne – porzucane. Obserwowanie rozwoju tego procesu jest interesujące z punktu widzenia agencji drupalowej.

Zobaczmy, jak drupalowe doświadczenie edytorskie znalazło się w obecnym punkcie i dokąd zmierza.

Początki Drupala

Początkowo, strony drupalowe były budowane na node'ach (węzłach). Myśl o takim węźle jak o artykule lub stronie w typowym CMSie. Węzeł składał się z elementów Title (tytuł) i Body (treść) Nadawało się węzłowi tytuł i wstawiało całą treść do jednego dużego pola tekstowego. Zazwyczaj ludzie wpisywali w polu Body treść strony – był to głównie tekst, ale dało się tam wstawić dowolne elementy (HTML, obrazy itp.). Dość szybko ludzie wprowadzili do pola Body edytory WYSIWYG (CKEditor, TinyMCE i inne zostały zintegrowane jako moduły utworzone przez społeczność). Dzięki temu można było stworzyć dość złożoną stronę bez znajomości HTML.

Edytory WYSIWYG były tak popularne, że w Drupalu 7 CKEditor został dodany do rdzenia Drupala.

Po stronie bazy danych wszystko wciąż było stosunkowo proste. Tabela węzłów z tytułem i dodatkowa tabela dla treści. Wordpress nie zmienił się pod tym względem do dzisiaj. W przypadku Drupala natomiast, nadal dokonywała się ewolucja. 

Drupal 6 - dominacja CCK i szablonowanie

W czasach Drupala 5 stworzono początkowo mały moduł, który w Drupalu 6 całkowicie zmienił zasady gry (moduł Content Construction Kit, czyli CCK).

CCK był dodatkowym modułem, który umożliwił dodawanie kolejnych pól do węzłów. Nie brzmi to może zbyt ekscytująco, ale stanowiło przełom. Absolutnie genialny moduł CCK pozwolił użytkownikom dodawać różne pola (number, text, bool, select itp.) i tworzył osobną tabelę bazy danych dla każdego pola. Pole tabeli pasowało do tego, co chciano w nim przechowywać (decimal, float, varchar, text itp.). Ponadto, dodawał pole do domyślnego formularza treści. 

To było wspaniałe, ponieważ pozwalało utworzyć formularz z wieloma polami, a następnie wyświetlić dane w szablonie wstępnie zbudowanym przez programistę (obraz po prawej stronie, statystyki po lewej, długie testy u dołu – tego typu rzeczy). Tak budowano strony w Drupalu. Edytor nie musiał już „projektować” układu w WYSIWYG. Można było po prostu wypełnić formularz polami, a szablon zajmował się resztą. 

Co więcej, można było teraz tworzyć zapytania SQL dla poszczególnych węzłów według zawartości pola. Na przykład jeśli utworzyłeś węzeł typu Miasto i dodałeś do niego pole dla poziomu ludności, mogłeś wyszukać wszystkie miasta o populacji większej lub mniejszej niż ten ustalony poziom. 

Bardzo szybko po CCK powstał kolejny moduł – Views. Moduł Views umożliwił użytkownikom tworzenie zapytań w interfejsie administratora. Dzięki temu można było utworzyć listę miast uporządkowanych według ludności z tytułem i teaserem oraz innymi danymi, bez potrzeby kodowania czegokolwiek. Był to ogromny przełom, który pozwolił programistom tworzyć bardzo atrakcyjne strony internetowe bez konieczności napisania choćby jednego wiersza kodu. 

CCK był tak popularny, że został włączony do Drupala w wersji 7, a następnie w Drupalu 8 pojawił się moduł Views.

Przez dłuższy czas w taki właśnie sposób budowano drupalowe witryny internetowe. Również dzisiaj wiele z nich jest nadal tak budowanych.

Drupal 7 – Pierwsze próby dotyczące układu strony 

Od chwili wydania Drupala 7, pola uznawano za standard. Jednakże szablonowanie nie było wystarczające dla społeczności i klientów. Programiści Drupala zaczęli szukać rozwiązań, które umożliwiałyby większą kontrolę nad wyświetlaniem treści za pomocą samego interfejsu użytkownika.

Główną przyczyną tych poszukiwań był sposób, w jaki zaczęto budować serwisy internetowe. Coraz bardziej powszechna stała się wiedza, że każde dodatkowe kliknięcie zmniejsza szansę na dotarcie klienta do treści. Podejście polegające na umieszczeniu paska bocznego i podzieleniu informacji na strony nie budziło już zainteresowania. Pojawiły się długie przewijane strony.

Początki długich stron docelowych z zawartością podzieloną na sekcje sięgają około roku 2010. Jednak to telefony komórkowe skutecznie zlikwidowały paski boczne. Po prostu w przypadku telefonów komórkowych nie dało się zmieścić podmenu na pasku bocznym. Teraz wszystko musiało być umieszczone na jednej przewijanej stronie z wieloma sekcjami (przewijanie jest na telefonie komórkowym znacznie łatwiejsze niż klikanie w linki). A każda z tych sekcji musiała być interesująca, przykuwająca uwagę oraz różnić się od innych.

Programiści Drupala zaczęli szukać rozwiązań, które pozwoliłyby edytorom łatwiej tworzyć sekcje na stronach.

Początkowe rozwiązania stanowiły:

• Panelizer – moduł oparty na innym (Panels), który skutecznie przejmował wyświetlanie węzła. Zamiast samych pól, można było teraz zaprojektować swoją stronę tak, aby zawierała bloki, pola, statyczne obrazy, widoki i różne inne elementy renderowane przez Drupala. Edytorzy mogli obejść „domyślny” predefiniowany układ węzeł za węzłem. To rozwiązanie było świetne i zyskało wielu zwolenników w świecie Drupala.
• Paragraphs – pojawił się już w końcowym stadium Drupala 7, ale jednak zachwycił. Bardzo szybko zaczął zdobywać popularność. Głównym tego powodem było połączenie dwóch światów: doświadczenia związanego z budowaniem form drupalowych i swobody dodawania bloków przy jednoczesnym zachowaniu łatwości użycia dla edytorów, czego brakowało opisanym wyżej rozwiązaniom. 
• Context – Context  jest bardziej ogólnym modułem, który zaoferował użytkownikom mechanizm lepszego działania w ramach kontekstów (np. strony, na której się znajdują, ich roli lub rodzaju użytkownika itp.). Korzystając z tych warunków, można dodawać reakcje (np. pokazać dany blok, ustawić daną opcję). Context był swego czasu bardzo często stosowany do układania bloków na stronach. Jeśli jestem na danej stronie, chcę widzieć odpowiednie bloki. Minusem było fakt, że zarządzało się układami z centralnej lokalizacji, trzeba było posiadać uprawnienia administratora, aby móc zarządzać układami, a interfejs użytkownika nie należał do łatwych w obsłudze. Nie nadawał się dla dużych witryn internetowych.
• Blockreference – prosty, ale potężny moduł, który pozwala na odniesienie do bloków z węzła i skutecznie układa je jeden na drugim. To rozwiązanie nie było zbyt powszechne.

Obecny stan rzeczy w Drupalu 8 i nowszych

Drupal 8, będący bardzo poważną przeróbką Drupala, wyrównał nieco sytuację, ponownie pozwalając społeczności decydować, co według niej powinno stanowić prawidłowe podejście do tworzenia stron. 

Dla Blockreference nie utworzono wersji D8, głównie dlatego, że moduł entityreference był już w rdzeniu Drupala 8, a bloki stały się odniesieniami. Można teoretycznie budować w ten sposób strony za pomocą surowego Drupala, ale pomysł raczej nie chwycił.

Context okazał się nie posiadać zbyt wielu zastosowań w D8 i do dziś nie ma stabilnego wydania.

Paragraphs – na prowadzeniu

Moduł Paragraph okazał się wyraźnym zwycięzcą. Był stabilny bardzo szybko i w ciągu roku stał się de facto standardem w Drupalu 8. Z ponad 140 tys. instalacji obsługuje teraz jedną trzecią wszystkich stron drupalowych. Warto również wspomnieć, że popularne dystrybucje drupalowe utworzone w Drupalu 8 wybrały Paragraphs jako podstawowe rozwiązanie dla edytowania treści. W szczególności warto tu wskazać Thundera – dystrybucję dla wydawnictw i Drooplera – służącego do budowania korporacyjnych stron internetowych. 

Oto rzut okiem na działanie modułu Paragraphs w Drupalu 8. Dużo pracy wkłada się również w dalsze ulepszanie doświadczenia edytorskiego w widżecie Experimental.

Penalizer wprowadzono do rdzenia (stał się Layout Builderem)

Penalizer poszedł inną ścieżką. Pozostawał nieco w tyle za Paragraphs pod względem liczby instalacji, ale ze względu na jego popularność w D7, trwały prace nad przeniesieniem go do rdzenia Drupala (podobnie jak CCK w D7). Jednak to dopiero w Drupalu 8.5 udostępniono Layout Builder (jako moduł eksperymentalny). Uzyskał stabilność w Drupalu 7.8. 

Layout Builder oferuje dużą elastyczność i prezentuje się obiecująco, ale interfejs użytkownika, nawet w chwili pisania tych słów, wciąż nie jest łatwy w obsłudze (wymaga pewnego przeszkolenia, ponieważ wiele rzeczy nie jest oczywistych). Ponadto, nie ma obecnie jasnej „najlepszej praktyki” dotyczącej zarządzania treścią i komponowania stron. Występują również opóźnienia w integracjach, szczególnie z modułami wyszukiwania. 

Obecnie nie ma wyraźnego zwycięzcy, a najlepsze praktyki nie zostały jeszcze ustalone. Dostępny jest moduł Paragraphs ze 100 tys. instalacji, wieloma integracjami i przejrzystym interfejsem użytkownika. Z drugiej strony – dostępny jest też Layout Builder, który stanowi element rdzenia Drupala, co stanowi sporą przewagę. 

Mimo to, istnieje wiele modułów, które nie przetrwały próby czasu i zostały usunięte z rdzenia.

Gutenberg (edytor WordPressa)

Na koniec warto jeszcze wspomnieć o projekcie Gutenberg. Jest to najnowszy z ciekawszych edytorów w Drupalu. Został przeniesiony z Wordpressa, gdzie stanowi główny edytor.

Gutenberg to edytor oparty na React, który przejmuje całe doświadczenie edycyjne, oferując użytkownikowi WYSIWYG jako doświadczenie. Różni się podejściem od Paragraphs i Layout Buildera, bo nie przechowuje układu ani encji w bazie danych, ale wygenerowany kod HTML. Tworzysz treść za pomocą edytora WYSIWYG, a wynikowy HTML jest zapisywany. Oferuje prawdziwą czytelność WYSIWYG treści dla maszyn (automatyczne aktualizacje lub migracje takich treści mogą być kłopotliwe). Niemniej jednak, jest coraz lepiej integrowany z Drupalem. Przy około 900 instalacjach nie jest w żaden sposób porównywalny z dwoma powyższymi, ale szybkość wzrostu jego popularności jest imponująca. Rzuć okiem na krótki przegląd Gutenberga w Drupalu.

Jak widać, nie ma wyraźnego zwycięzcy. Społeczność drupalowa wciąż testuje różne podejścia do tworzenia witryn internetowych i wzmocnienia pozycji edytorów. Z jednej strony – to fantastycznie, ponieważ konkurencja pozwala na zwycięstwo najlepszego rozwiązania. Z drugiej strony – wysiłki programistów są rozłożone na wiele różnych podejść, co spowalnia postęp. Która droga jest najlepsza? Nie mam pojęcia.