Przeglądając przykładowe implementacje Drupala na polskim forum poświęconym temu CMS'owi zauważyłam, że nader często developerzy popełniają sporo błędów w przypadku instalacji modułów. Uczestniczenie w dyskusjach na oficjalnej stronie systemu tylko utwierdziło mnie w tym przekonaniu. Z tego względu postanowiłam zebrać najczęstsze błędy w przypadku zarządzania modułami.
Gdzie umieszczać moduły?
Początkujący developerzy Drupala mają bardzo często problemy z prawidłowym umieszczeniem modułu w strukturze plików.
Poniższy zrzut ekranu przedstawia domyślne ułożenie folderów w głównym katalogu systemu w wersji 7 oraz 6.
Główna struktura katalogów Drupala.
Jak można zauważyć widnieją w nim dwa specyficzne foldery – themes i modules. Wydawałoby się więc, że nie ma lepszego miejsca na umieszczenie modułów czy skórek. Nic bardziej mylnego. Modułów własnych i ściągniętych z drupal.org nie należy umieszczać w katalogu modules w głównym folderze Drupala.
Te dwa katalogi służą tylko i wyłącznie do przechowywania elementów dostarczonych z systemem, wszystko co sami ściągniemy aby rozszerzyć funkcjonalność powinno być rozpakowane do innego folderu.
Jakkolwiek moduły umieszczone w takiej lokalizacji będą działać jest to wbrew zaleceniom twórców Drupala.
Prawidłowe katalogi, w których mogą się znajdować moduły to m.in.:
- W
sites/all/modules umieszczamy moduły, które powinny być dostępne dla każdej strony w danej instalacji; jeśli planujemy uruchomić tylko jedną stronę na danej instalacji Drupala to właśnie to miejsce, gdzie powinny się znaleźć wszystkie dodatkowe moduły tworzone przez społeczność
- W
sites/mysite.com/modules umieszczamy moduły dla specyficznej strony w naszej instalacji Drupala; dotyczy to jedynie tzw. multi-site installation, moduły będą dostępne tylko dla strony, w której katalogu je umieścimy.
Przykładowo jeśli na jednej instalacji Drupala chcemy umieścić stronę informacyjną (drupal.informacja.pl), na drugiej zaś portal społecznościowy (spolecznosc.drupal.pl) w katalogu sites/all/modules powinny znajdować się moduły wspólne dla obu witryn, w folderze sites/drupal.informacja.pl/modules moduły używane tylko dla strony informacyjnej (np. FiveStar), zaś w sites/spolecznosc.drupal.pl tylko dla strony społecznościowej (np. Private Message czy User Points).
W przypadku multi-site installation warto zadbać o to, aby moduły specyficzne dla danej witryny znalazły się nie w ogólnym katalogu, a w odpowiednim folderze witryny. Pomijając jakiekolwiek inne względy o wiele wygodniejsze jest przeglądanie 50 modułów zamiast 100.
W przypadku skórek są to odpowiednio katalogi: sites/all/themes oraz sites/mysite.com/themes.
W obrębie tych folderów można umieszczać inne foldery, np. gdy chcemy pogrupować moduły na ich funkcjonalności (przykładowo osobny folder na zarządzanie użytkownikami, osobny na cck i jeszcze inny na moduły developerskie jak devel czy coder). Drupal poradzi sobie bardzo dobrze nawet z najbardziej zaawansowaną strukturą katalogów i znajdzie nasze moduły.
Drupal 7 i użytkownicy rozpoczynający pracę z Drupalem
Na stronie admin/modules/install znajduje się narzędzie (po włączeniu odpowiedniego modułu dostępnego w core systemu – Update) do automatycznej instalacji modułów. Warto z niego skorzystać, ponieważ sam Drupal umieści wtedy moduły tam, gdzie powinny się znaleźć.
Deinstalacja
Drugi najczęściej popełniany błąd, skutkujący niekiedy trudnymi do naprawienia błędami to brak deinstalacji modułu.
Wyłącznie modułu na stronie admin/build/modules (d6) lub admin/modules (d7) niekoniecznie znaczy, że moduł jest jednocześnie odinstalowany z systemu!
W momencie, gdy moduł dodaje jakiekolwiek informacje do bazy danych proste wyłączenie modułu powoduje jedynie, że funkcje wewnątrz są niedostępne dla innych modułów. Stworzone tabele czy zmienne jednak zostają.
Po usunięciu folderu z systemu plików bez wcześniejszej deinstalacji może powodować „błędy z opóźnionym zapłonem”. Z tego powodu gdy chcemy faktycznie odinstalować moduł zawsze należy odwiedzić po wyłączeniu modułu zakładkę „Odinstaluj” („Uninstall”) i sprawdzić, czy wyłączonego modułu tam nie ma.
Można sprawdzić czy moduł wymaga deinstalacji również z poziomu plików. Jeśli w niechcianym module występuje plik .install najprawdopodobniej trzeba go będzie odinstalować przed usunięciem z poziomu Drupala.
A może by tak zmienić coś w module...?
Nigdy, przenigdy nie zmieniajcie niczego w kodzie modułu (a tym bardziej w modułach z core'a). Drupal oferuje system hook'ów (funkcji do „nadpisywania”), aby nie było potrzeby mieszać bezpośrednio w kodzie modułu.
Niekiedy może się to wydawać prostszym rozwiązaniem i kusić. Ale jest „złe” i niezgodne z wszelkimi zasadami systemu. Ponadto, gdy moduł będzie update'owany wszelkie zmiany znikną i trzeba je będzie wprowadzać jeszcze raz!
Najlepiej więc stworzyć własny moduł, który poprawia funkcjonalność, z której nie jesteśmy zadowoleni. Mamy przy tym do wyboru całe Drupal API oraz hooki pozostałych zainstalowanych modułów. Istnieje relatywnie niewiele zmian, które nie mogą być zaaplikowane przez napisanie własnego modułu.
W ostateczności należy stworzyć patcha poprawiającego funkcjonalność. Po updacie modułu wszystko co należy zrobić to jeszcze raz zaaplikować patcha.
Bezpośrednie zmiany niosą ze sobą wiele niebezpieczeństw, z czego niewątpliwie najważniejszą jest stworzenie w module luk bezpieczeństwa – Waszego modułu nie widzi społeczność, użytkownicy Drupala nie będą więc w stanie zareagować i zwrócić uwagi na błędy mogące spowodować np. ataki XSS na waszą witrynę.
