Drupal 8 to wymagający system, dlatego zanim przyjmiesz gotowy projekt od wykonawcy, koniecznie sprawdź, czy dobrze wykonał swoją pracę. Niestety, wiele firm/freelancerów nie zna Drupala, ale przyjmuje zlecenia na wykonanie stron w oparciu o ten CMS. Najczęściej testowanie strony przez klienta polega tylko na sprawdzeniu frontu oraz funkcjonalności– jeśli wszystko działa i w miarę dobrze wygląda, to projekt musi być zrobiony poprawnie...
W ten sposób nie sprawdzimy jednak, jak wykonany jest backend oraz jakiej jakości jest kod przygotowany przez programistów. W tym tekście przedstawiamy sposoby na sprawdzenie kodu strony stworzonej w Drupal 8, które pozwolą wyeliminować problemy z nim związane w przyszłości.
Drupal 8 – nowa wersja popularnego CMS
Na sam początek jednak kilka ważnych informacji dotyczących Drupala 8. Jest to przełomowa wersja dla całego ekosystemu CMS-a, gdyż zmieniła podejście do tworzenia rozwiązań w oparciu o Drupala. W Drupalu 8 wykorzystano m.in. komponenty Symfony czy silnik motywów Twig. Różnica między Drupal 7 a 8 jest kolosalna, dlatego jeżeli posiadasz doświadczenie w „siódemce”, nastaw się na duży przeskok i wyczul się na pracę agencji. Przed realizacją warto też zweryfikować, jakie doświadczenie w Drupal 8 zdobył software house.
GIT- system kontroli wersji
Z jego pomocą masz pełną kontrolę nad całym kodem projektu. Wszelkie zmiany, jakie są dokonywane w kodzie, będą rejestrowane i możliwe do wglądu. Cały proces dostarczania kodu powinien być oparty właśnie o Gita. Wysyłka plików ze środowiska lokalnego na serwer produkcyjny powinna odbywać się poprzez komendy Gita w wierszu poleceń.
Aby sprawdzić, czy projekt jest wrzucony do Gita, w głównym katalogu projektu powinien znajdować się folder .git a w nim plik config. W configu znajdziemy adres url do 'remote origin', gdzie jest dostępny aktualny kod projektu.
Composer- pomoc w zarządzaniu pakietami
Composer to system zarządzania pakietami dla języka PHP. Z jego pomocą możemy zainstalować Drupala 8 oraz inne wersje, wszystkie moduły i zależności. Dzięki temu aktualizacja całego kodu jest banalnie prosta i sprowadza się do polecenia composer update w wierszu poleceń.
Jeśli projekt został wykonany przy użyciu Composera, struktura katalogów w głównym folderze projektu powinna dzielić się na vendor i web/docroot.
W vendor trzymane są wszystkie zależności a w web/docroot instalacja Drupala. Kolejnym krokiem jest sprawdzenie pliku composer.json. W sekcji 'require' powinny być wszystkie moduły z katalogu web/modules/contrib. Jeśli w katalogu web/libraries są zamieszczone jakieś biblioteki, to powinny znajdować się w sekcji 'repositories'.
Moduły - klucz do sukcesu Drupal 8
Moduły są bardzo ważną funkcjonalnością Drupala. Wszystkie z nich wraz z rozszerzeniami obecnych znajdują się w katalogu web/modules. Katalog powinien być podzielony na:
- katalog contrib- zawierający wszystkie moduły napisane przez społeczność dostępne na drupal.org,
- katalog custom- w którym, znajdują się moduły dedykowane napisane przez programistów odpowiedzialnych za projekt.
Katalog contrib
Najpierw zajmijmy się katalogiem contrib. Jeśli liczba modułów w nim zawartych mieści się w dziesiątkach, a projekt wcale nie był rozbudowany, to może znaczyć, że deweloperzy poszli na skróty, tworząc stronę w Drupal 8 i chcieli zrobić wszystko najmniejszym kosztem, instalując co popadnie. Należy również sprawdzić jakość instalowanych modułów, gdyż wiele z tych dostępnych na drupal.org jest w wersjach dev czy beta i nie nadają się do wrzucania w tej formie na produkcję. Najlepiej, jeśli moduł na stronie drupal.org jest w kolorze zielonym – wtedy mamy pewność, że wszystko z nim w porządku i można go uwzględnić w projekcie.
Katalog custom
Jeśli chodzi o moduły w folderze custom, tu trzeba być szczególnie uważnym. Tutaj znajduje się cały kod napisany przez programistów. Moduły powinny być podzielone na funkcjonalności, tzn. że jeden moduł powinien odpowiadać za jedną konkretna funkcjonalność, np. do newslettera powinien być osobny moduł, a do integracji z innym systemem powinien być osobny moduł. Złą praktyką jest tworzenie jednego modułu o nic nie wnoszącej nazwie np. 'common' i wrzucanie tam wszystkiego.
Każdy moduł powinien mieć nazwę adekwatną do tego, czym się zajmuje. Na przykład moduł do wysyłki newslettera nazywa się 'newsletter', a moduł do integracji z Elasticsearch nazywa się 'elastic', 'elastic_integration' itp.
Po wejściu w moduł powinieneś zobaczyć najpierw plik .module. Jeśli ma on setki czy tysiące linii, to może być to błędem. Oczywiście nadal można tak pisać kod, ale jest on strukturalny i w przyszłości podczas kolejnych aktualizacji (szczególnie Drupala 8 do Drupala 9) może przestać działać. Większość funkcjonalności powinno się znajdować w katalogu src modułu.
W większych modułach, szczególnie tych odpowiadających za kluczowe funkcjonalności strony, powinien również znajdować się katalog tests. Aby złożony kod dobrze działał, musi być przetestowany.
Ważne jest również dokumentowanie kodu. Po wejściu w jakikolwiek plik z końcówką php nad funkcjami powinny widnieć adnotacje zamieszczone w /** */. To właśnie tam zamieszczone są informacje, do czego dana funkcja/metoda służy, jakie argumenty przyjmuje i co zwraca.
Skórka- dobra realizacja graficzna
W katalogu web/themes znajdziemy tak jak w przypadku modułów 2 katalogi- custom i contrib. W contrib są skórki gotowe, pobrane z drupal.org, a w custom te stworzone przez developerów.
Gotowe skórki nie powinny przysparzać problemów, jeśli są dobrze zaimplementowane, jednak customowe to już inny temat.
W customowej skórce w pliku .info.yml powinny znaleźć się informacje na temat tego, czy skórka jest stworzona od podstaw przez dewelopera, czy dziedziczy z jakiejś gotowej (np. bootstrap). W tym pliku znajdziemy również spis wszystkich regionów strony. Jeśli jest ich dużo, a ich nazwy są typu 'header1', 'header2', 'footer_bottom', 'footer_bottom_after' tzn., że programista nie miał najlepszego pomysłu na wdrożenie projektu graficznego. Nazwy regionów powinny być jasne i precyzyjne, a ich ilość powinna się mieścić w większości przypadkach w max 10.
Kolejnym plikiem, którym warto się zainteresować jest .theme. To właśnie tam programiści często dodają mnóstwo kodu, który nadpisuje przeróżne rzeczy na stronie. Jeśli jest go dużo, a dodatkowo jest słabo udokumentowany, może oznaczać, że deweloper nadpisał sporą część Drupala/gotowych modułów zamiast zaprojektować coś samemu. Takie nadpisywane funkcjonalności ciężko się rozwija i aktualizuje.
Skórka powinna mieć katalogi css i js. Katalogi powinny składać się z wielu plików, które odpowiadają za różne elementy strony stworzonej w Drupal 8. Jeśli jest tylko jeden plik style.css i jeden plik script.js i oba mają po kilka tysięcy linii, to nie świadczy to za dobrze o programiście.
Drupal 8 - podsumowanie
Dzięki takim testom jesteśmy w stanie sprawdzić, czy deweloperzy starali się dostarczyć projekt dobrej jakości, czy chcieli go zrobić 'byle jakoś działało'. Warto również przedstawić wymagania przed startem projektu, aby Drupal 8 był zainstalowany Composerem, moduły wykorzystywane na stronie nie były w wersjach dev lub beta, a kod był dobrze udokumentowany i wrzucony do Gita. Programiści często chcąc zaoszczędzić trochę czasu na naukę Drupala, robią to, co znajdą w pierwszym lepszym tutorialu.
W razie problemów z takimi testami zawsze można zlecić audyt tego, co zostało wykonane doświadczonym programistom, którzy dokładnie sprawdzą i ocenią kod. Dzięki temu aplikacja może działać dobrze przez wiele lat, a jej rozwój będzie szybki i bezproblemowy.
