Dlaczego moim pierwszym systemem zarządzania treścią była Joomla!, skoro teraz wolę zajmować się WordPressem. Czy to była porażka projektowa?
Nie, Joomla! była moją pierwszą deweloperską świadomą decyzją: nie tylko szukałam popularnego systemu zarządania treścią, który oferował mój hosting (nazwa.pl), ale też – takiego systemu, który dostosuje się do moich wymogów.
Nie chciałam robić kolejnego forum, bardziej inspirowałam się serwisem poema.art (który oferował przestrzeń dla autorów do dodawania swoich kawałków twórczości). Potrzebowałam uporządkować i wprowadzić: wielu użytkowników, wiele treści, wiele wątków.
Joomla nie był dla mnie „ułatwieniem”, tylko wejściem w zupełnie nowy poziom odpowiedzialności: za treść, strukturę, stabilność i cudze dane.
Co chcę jednak podkreślić – wstępny projekt strony Grupy Poetyckiej IWA był ułatwiony, ponieważ znaczna część treści była już napisana.
Pamiętam moment przejścia ze statycznej strony HTML – do której dodawano ręcznie kolejne teksty, trzeba było się upewniać czy skrypt wysyłający treści dobrze działa. Również, poprzedni administrator ręcznie naprawiał konflikty w wyświetlaniu znaków (standard UTF-8). Nagle zdałam sobie sprawę, że dodawanie treści jest takie łatwe… a jednocześnie – musiałam dbać, żeby odpowiednie teksty były przypisane do odpowiednich autorów. Nie mogłam również pominąć zasług poprzednich administratorów i poprzednich lub aktualnych redaktorów.
Warstwa wizualna też zmieniła się bardzo, musiałam przygotować się na krytyczne głosy i pracę zespołową. Nie wszystko wyszło tak jak w pomysłach na projekt, bo nie miałam doświadczenia w szukaniu grafik ani kontaktu z profesjonalistą – wszystko powstawało od zera i z mojej inicjatywy, na moich zasadach.
Podczas rozwoju tego projektu musiałam się wiele uczyć, czytać dokumentacji, sprawdzać zewnętrzne serwisy (stackoverflow), oglądać poradniki na youtube, czytać blogi. Musialam się zorientować i wyćwiczyć:
- co jest treścią strony
- jak ma wyglądać jej architektura
- gdzie zaczyna się szablon
- co jest konfiguracją
- czym różni się wtyczka (plugin), dodatek i szablon
System Joomla! pozwolił mi na pewną elastyczność: dzięki wbudowanej obsłudze wielu autorów (użytkowników) oraz ich ról – mogłam przydzielać uprawnienia do konkretnych czynności. Logika wyglądała następująco: część autorów miała dostęp tylko do okrojonego edytora pozwalającego na dodawanie własnych wierszy do własnej części strony (jeśli autor się zarejestrował i zalogował), część – redaktorów miała uprawnienia do dodawania artykułów także w innych miejscach, część użytkowników miała uprawnienia administracyjne – do zaplecza.
Projekt strony IWY był pracą zespołową, udokumentowaną w repozytorium Bitbucket. Doświadczenia z systemem kontroli wersji i repozytorium lokalnym nauczyły mnie spokojnej, świadomej pracy. Nie musiałam się bać wprowadzać nowych rzeczy, bo zawsze mogłam je przetestować i ewentualnie cofnąć, zmienić, zaakceptować. To było podejście, które przyzwyczaiło mnie do dobrych praktyk projektowych: pisanie, wdrożenie, sprawdzanie i testowanie, komentowanie (commit i issue), ewentualna dyskusja nad rozwiązaniem, zatwierdzenie.
Zauważyłam, że pewnych zależności nie widać na pierwszy rzut oka, a po niektóre trzeba sięgnąć… do samego systemu. Już wtedy sprawiało mi radość grzebanie i czytanie plików PHP – nawet jeśli nie rozumiałam warstwy funkcjonalnej, to przez hierarchię, nazwy – mogłam wnioskować niektóre rzeczy. To pomogło mi na przykład wpaść na pomysł formularza kontaktowego obsługującego wysyłkę wiadomości do trzech różnych konsultantów.
Opracowywanie warstwy wizualnej zajęło nam sporo czasu, chcieliśmy się czymś wyróżniać i nie stosować prostych – dostępnych wtedy rozwiązań. Znajdowanie grafik dopasowanych do naszych potrzeb i na odpowiedniej licencji (free for commercial use) zajmowało zbyt dużo czasu, wybór był na tyle ograniczony, że postanowiliśmy osadzić własne pomysły i projekty. Z perspektywy czasu, strona wydaje się bardzo „artystyczna”, a grafiki trochę zbyt krzykliwe – jest ich dużo w różnych miejscach, paradoksalnie jednak pasuje to do klimatu strony. W końcu to serwis dla ludzi z dobrze rozwiniętymi zmysłami artystycznymi. Przynajmniej tło było spokojne, widać też znaczną różnicę pomiędzy wersją przed (poprzedniego administratora), a wersją po.
Strona był pisana w innych realiach niż obecnie, w środowisku panowały inne nastroje i metody na rozmieszczanie obiektów na stronie – stosowanie dyrektywy !absolute było podejściem restrykcyjnym (i niemile widzianym), a pojęcie kontenera (specjalnego znacznika <div>) do przechowywania treści dopiero raczkowało i przebijało się do świadomości deweloperów. Stosowano też specjalne rozwiązania (wydzielony kod CSS) dostosowane do kolejnych przeglądarek – inaczej kalkulował padding – to tylko jeden z przykładów, do czego przydało mi się śledzenie tematów na stackoverflow.
Odpowiedzialność za stronę i jej treść przyszła później. Tak mniej więcej w dniu, kiedy dowiedziałam się o ataku hakerskim, o tym jednak napiszę w kolejnym wpisie.