Mgr Paweł Traczyński 3266 - Praca dypl
-
Upload
pawe-traczyski -
Category
Documents
-
view
773 -
download
0
Transcript of Mgr Paweł Traczyński 3266 - Praca dypl
Wydział Informatyki
Katedra Inżynierii Oprogramowania
Programowanie Aplikacji Biznesowych
Paweł Traczyński Nr albumu 3266
Systemy CMS w aplikacjach internetowych
Praca magisterska napisanapod kierunkiem
dr Krzysztofa Barteczko
Warszawa, wrzesień 2010
1
Spis treści
Wprowadzenie ..................................................................................................... 4 Co zostało omówione w poszczególnych rozdziałach ........................................................................ 4
1. Rola systemów zarządzania treścią w aplikacjach internetowych .............. 5 1.1. Potrzeba posiadania systemu CMS .............................................................................................. 5
1.1.1. Czym jest System Zarządzania Treścią? ............................................................................... 5
1.1.2. Korzyści wynikające z posiadania systemu CMS ................................................................. 5
1.1.3. Kto korzysta z systemu CMS? .............................................................................................. 5
1.1.4. Narzędzia typu Dreamweaver i Front Page ........................................................................... 6
1.1.5. „Site buildery” i kreatory stron www dostępne u firm hostingowych ................................... 6
1.2. Serwisy www z systemem CMS a tradycyjne strony XHTML .................................................... 6
1.2.1. Wady statycznych stron www ............................................................................................... 6
1.2.2. Zalety statycznych stron www .............................................................................................. 7
1.3 Cechy charakterystyczne, zalety i wady systemów CMS ............................................................. 8
1.3.1. Zalety systemów CMS .......................................................................................................... 8
1.3.2. Wady systemów CMS ........................................................................................................... 9
1.4. Podsumowanie ........................................................................................................................... 10
2. Porównanie wybranych systemów CMS typu open source ....................... 11 2.1. Wybór systemów do porównania ............................................................................................... 11
2.1.1. Komercyjne systemy CMS ................................................................................................. 11
2.1.2. Systemy CMS typu open source ......................................................................................... 11
2.1.3. Wybór systemów do porównania ........................................................................................ 12
2.2. Krótko o wybranych systemach CMS ........................................................................................ 12
2.2.1. WordPress ........................................................................................................................... 12
2.2.2. Joomla! ............................................................................................................................... 14
2.2.3. Drupal ................................................................................................................................. 14
2.3. Porównanie możliwości i ograniczeń wybranych systemów CMS ............................................ 14
2.3.1. CECHY PODSTAWOWE .................................................................................................. 15
2.3.2. ZAAWANSOWANE CECHY I FUNKCJE ........................................................................ 31
2.3.3. CECHY POZOSTAŁE ........................................................................................................ 51
2.3.4. PODSUMOWANIE PORÓWNANIA ................................................................................ 55
2.4. Testy porównawcze .................................................................................................................... 59
2.5. Wybór najlepszego systemu ....................................................................................................... 62
2.5.1. Wnioski ............................................................................................................................... 64
2
2.6. Podsumowanie ........................................................................................................................... 64
3. Projekt i realizacja aplikacji testowej .......................................................... 65 3.1. Opis aplikacji ............................................................................................................................. 65
3.1.1. Opis działalności firmy ....................................................................................................... 65
3.1.2. Cel aplikacji ........................................................................................................................ 65
3.2. Założenia projektowe - opis głównych zadań które będzie musiała realizować aplikacja .......... 66
3.2.1. Planowane typy podstron i wiążące się z nimi funkcje ....................................................... 67
3.2.2. Inne funkcje ........................................................................................................................ 69
3.3. Projekt graficznego interfejsu użytkownika ............................................................................... 70
3.4. Opis etapów implementacji ........................................................................................................ 71
3.5. Realizacja projektu .................................................................................................................... 71
3.5.1. Utworzenie szablonu ........................................................................................................... 72
3.5.2. Konfiguracja systemu CMS ................................................................................................ 73
3.5.3. Określenie wymaganych dodatkowych modułów oraz ich instalacja .................................. 74
3.5.4. Wypełnienie strony treścią .................................................................................................. 77
3.5.5. Dopracowywanie strony ..................................................................................................... 77
3.6. Testy wydajnościowe ................................................................................................................. 78
3.7. Podsumowanie ........................................................................................................................... 78
4 ........................................................................................................................... 79
4. Metody poprawiania wydajności aplikacji wykonanej w wybranym systemie CMS ..................................................................................................... 79
4.1. Wbudowane opcje poprawiania wydajności .............................................................................. 79
4.1.1. Buforowanie podstron ......................................................................................................... 80
4.1.2. Kompresja podstron ............................................................................................................ 80
4.1.4. Optymalizacja plików CSS i JavaScript .............................................................................. 81
4.2. Kompresja plików CSS .............................................................................................................. 81
4.3. Kompresja plików JavaScript .................................................................................................... 82
4.4. APC (Alternative PHP Caching) ................................................................................................ 82
4.5. Moduł „Boost” ........................................................................................................................... 82
4.8. Podsumowanie ........................................................................................................................... 84
5 ........................................................................................................................... 85
5. Podsumowanie ............................................................................................... 85 5.1. Najcenniejsze doświadczenie wyniesione z pisania pracy ......................................................... 85
5.2. Czy cele zostały osiągnięte? ...................................................................................................... 85
6. Bibliografia ..................................................................................................... 86
3
4
Wprowadzenie
Niezaprzeczalnym jest fakt, że najczęściej wykonywaną w Internecie czynnością jest
przeglądanie jego zawartości. Miliony użytkowników odkryły potencjał Internetu
umożliwiający wykorzystanie go do podzielenia się różnego rodzaju informacjami np. o sobie
i swoim życiu. Inni chcą zaprezentować swoją twórczość, np. prace artystyczne lub muzykę.
Dla jeszcze innych Internet stanowi bardzo ważne medium przekazywania informacji np. o
prowadzonej działalności lub o produktach dostępnych w aktualnej ofercie. Niezależnie od
potrzeb użytkowników Internet musi umożliwiać realizację ich pomysłów w sposób
przystępny i wydajny.
Potrzebne jest tutaj coś co ułatwi ludziom osiągnąć swój cel bez konieczności
wielomiesięcznego studiowania różnych technologii, na których opiera się Internet. Z pomocą
przychodzą tu systemy zarządzania treścią (CMS).
Dobry system CMS jest tym czego potrzebują użytkownicy aby zbudować stronę www
począwszy od strony o charakterze prostej wizytówki bądź bloga a na skomplikowanych
interaktywnych wielojęzycznych stronach skończywszy.
Celem pracy jest dokonanie dogłębnego porównania wybranych systemów zarządzania treścią
oraz wybranie zwycięskiego systemu. Następnie wykonana zostanie implementacja aplikacji
www w oparciu o wyłoniony system CMS, przeprowadzone zostaną testy wydajnościowe tej
aplikacji oraz zaprezentowane zostaną liczne sposoby poprawiania wydajności zbudowanej
aplikacji.
Co zostało omówione w poszczególnych rozdziałachRozdział 1 omawia czym są systemy zarządzania treścią (CMS) oraz dlaczego są one
potrzebne i jakie mają możliwości. Zamieszczone jest tu porównanie tradycyjnych
statycznych stron www ze stronami opartymi na systemach CMS. Omówiłem tu także wady i
zalety skorzystania z systemu CMS.
Rozdział 2 zawiera porównanie wybranych systemów CMS oraz omówienie ich możliwości i
ograniczeń. Przyjrzymy się także innym systemom CMS istniejącym na rynku. Wykonam tu
testy porównawcze wybranych systemów i wyłonię zwycięski system.
5
Rozdział 3 prezentuje specyfikację aplikacji testowej, którą będę starał się utworzyć w oparciu
o zwycięski system CMS. Znajduje się tu lista funkcji, które ma udostępniać aplikacja oraz
projekt interfejsu graficznego, w oparciu o który tworzona będzie nasza strona. Rozdział ten
dotyczy również implementacji aplikacji testowej w oparciu o zwycięski system CMS. Przed
przystąpieniem do tworzenia aplikacji opisałem etapy implementacji, przez które trzeba było
przejść. Na końcu znajdują się wyniki wykonanych testów wydajnościowych gotowej
aplikacji.
Rozdział 4 to omówienie sposobów poprawiania wydajności zwycięskiego systemu CMS oraz
omówienie ich implementacji. Wszelkie działania wykonuję nadal w ramach tej samej
aplikacji testowej. Poprawianiu wydajności towarzyszą kolejne testy sprawdzające szybkość
działania aplikacji oraz porównanie ich z testami wykonanymi przed poprawianiem
wydajności.
6
1. Rola systemów zarządzania treścią w aplikacjach internetowych
Do niedawna jedną z ważniejszych rzeczy, której mógł się podjąć nowy użytkownik sieci
World Wide Web przygotowujący się do zbudowania własnej funkcjonalnej strony www, było
zakupienie książki szkoleniowej dotyczącej jednego z języków nastawionych na potrzeby
Internetu, takich jak np. PHP lub Perl1. Nie da się ukryć, że nauczenie się wybranego języka
w zakresie umożliwiającym stworzenie poważnej aplikacji internetowej wymagało
poświęcenia wielu godzin pracy w skupieniu. Mimo to nawet po świetnym opanowaniu
wybranego języka wykorzystanie go w celu utworzenia porządnej aplikacji internetowej było
nie lada wyzwaniem, któremu zapewne wielu zapaleńców nie podołało.
Próby utworzenia własnej aplikacji mogły w związku z powyższym być dla mniej
wytrwałych osób frustrujące. Opisana sytuacja dla większości użytkowników jest
niedopuszczalna. To tak jakby np. zmuszano pracowników biurowych do studiowania metod
wytwarzania stołów, regałów i innych mebli tylko dlatego, że będą z nich korzystać. Powinno
wydawać się oczywiste, że należy przynajmniej częściowo oddzielić zadanie wytworzenia
oprogramowania dla strony www od budowania samej strony, dzięki czemu użytkownicy
budujący stronę będą mogli skupić się na tym w czym są dobrzy, na przykład na
konfigurowaniu strony i zapełnianiu jej treścią. Dzięki temu zużyją na wszystko mniej
swojego czasu i energii, którą musieliby w przeciwnym razie poświęcić na opanowywanie
technik i języków programistycznych.
Biorąc pod uwagę wyżej wymienione fakty nie jest zaskakującym, że powstały tak zwane
systemy zarządzania treścią.
1.1. Potrzeba posiadania systemu CMSNiezależnie od tego kim jest czytelnik – osobą prywatną, przedstawicielem firmy czy
członkiem jakiejś organizacji – być może posiada starzejącą się statyczną stronę www. Być
może stara się ulepszać i wzbogacać swoją stronę ale nie robi tego za często bo nie chce za
dużo płacić drogim programistom. Powyższy problem jest często spotykany i nieraz
1 Perl– język programowania przeznaczony głównie do pracy z danymi tekstowymi. Wykorzystywany także na potrzeby stron internetowych. http://www.perl.org/
7
przyczynia się do zupełnego zaprzestania dokonywania jakichkolwiek jakże potrzebnych
aktualizacji ponieważ łączny ich koszt byłby ogromny.
Niestety standardy sieciowe, i wspierające je technologie zmieniają się bardzo szybko.
Zmiany te dotyczą także przeglądarek internetowych, wyszukiwarek, mobilnego Internetu
oraz trendów panujących w sieci. Z tych względów pozostają dwa wyjścia: albo odświeżenie
strony www i zapewnienie jej zgodności z najnowszymi standardami albo pozwolenie jej po
prostu się zestarzeć.
W tej sytuacji najlepszym wyborem, uwzględniając relację kosztów i korzyści oraz biorąc pod
uwagę łatwość integracji i dopasowania do swoich potrzeb, jest przeznaczony na potrzeby
stron www, System Zarządzania Treścią.
Dalsza część rozdziału wyjaśnia wszystko co potrzeba wiedzieć na temat systemów
zarządzania treścią oraz odpowiada na pytanie dlaczego warto korzystać z takiego systemu.
1.1.1. Czym jest System Zarządzania Treścią?System Zarządzania Treścią, z angielskiego Content Management System (CMS), w
odniesieniu do stron www jest narzędziem stanowiącym pewnego rodzaju zaplecze witryny
internetowej, umożliwiającym łatwe utworzenie serwisu www oraz jego późniejszą
aktualizację bądź rozbudowę. System taki umożliwia łatwe dodawanie nowych treści na
stronie oraz edytowanie już istniejących bez konieczności pisania kodu HTML. CMS
udostępnia użytkownikom posiadającym odpowiednie uprawnienia pewnego rodzaju
interfejs, który pozwala zarządzać stroną www bądź jej wydzielonymi częściami. Zwartość
podstron jest przechowywana w bazie danych i jest z niej wydobywana w celu prezentacji
podczas odwiedzania strony przez odwiedzających. Zarządzanie stroną poprzez system
zarządzania treścią, który jest stale dostępny przez Internet niezależnie od miejsca i czasu,
odbywa się poprzez przeglądarkę internetową.
W przypadku tradycyjnych statycznych stron HTML-owych, właściciel strony pisał teksty i
artykuły a następnie przekazywał je programistom, którzy umieszczali przekazane materiały
na stronie. Zazwyczaj gdy jakaś podstrona wymagała aktualizacji bądź zamiany była ona
ściągana z serwera, edytowana i wgrywana z powrotem na serwer. W systemie zarządzania
treścią jest inaczej – strona www, a zwłaszcza treść w niej zawarta, znajduje się pod kontrolą
użytkownika. Od momentu gdy system CMS został zainstalowany i skonfigurowany tak aby
8
spełniał potrzeby właściciela strony, zmienianie i dodawanie treści może odbywać się bez
udziału programistów.
Istnieje wiele różnych platform CMS, z których niektóre są łatwe w obsłudze, inne zaś
bardziej rozbudowane i w związku z tym trudniejsze. Przykład przejrzystego i łatwego w
obsłudze formularza dodawania nowej podstrony przedstawiam poniżej:
Rysunek . Przykładowy formularz dodawania nowej podstrony w systemie WordPress cechuje łatwość obsługi i przejrzystość.
Wygląd powyższego formularza może wydawać się znajomy – faktycznie zawiera on pasek z
narzędziami znanymi z aplikacji Microsoft Word lub innych programów do przetwarzania
tekstu. Każdy kto umie posługiwać się którymś z takich narzędzi może bezproblemowo
rozpocząć aktualizowanie istniejącej lub dodawanie nowej podstrony.
1.1.2. Korzyści wynikające z posiadania systemu CMSZ posiadania systemu CMS wynika wiele korzyści. Dokładne omówienie wszystkich zalet i
wad takich systemów znajduje się w dalszej części tego rozdziału. W tej sekcji wymienione
zostaną tylko główne powody dla których warto korzystać z systemu zarządzania treścią.
Łatwość aktualizowania – Jeśli strona www nie jest aktualizowana i można powiedzieć, że
pełni bardziej rolę wizytówki lub bilbordu, oznacza to, że niespecjalnie wykorzystywany jest
9
fakt bycia jej w Internecie. Wiele firm i organizacji tworzy strony www przypominające
reklamy w książkach telefonicznych – proste statyczne informacje. Faktycznie w książkach
telefonicznych sprawdza się to świetnie ale w Internecie już nie za bardzo. W Internecie
odwiedzający oceniają firmę po wyglądzie strony oraz po tym jak świeże są informacje na
niej zawarte. CMS pozwoli utrzymać stronę zaktualizowaną przy jednoczesnych bardzo
niskich kosztach.
Opłacalność finansowa – Wiele stron różnego typu przeniosło się na systemy CMS dawno
temu z prostej przyczyny – koszty płacenia programistom za kodowanie nowych podstron w
celu umieszczania nowych artykułów oraz koszty aktualizowania już istniejących podstron
były zbyt wysokie. Podczas gdy większość stron to małe przedsięwzięcia, opłaty związane z
aktualizowaniem mogą okazać się nie do zaakceptowania. System CMS minimalizuje koszty
związane z aktualizowaniem ponieważ nie trzeba kodować kolejnych niezliczonych podstron.
Ponadto utworzenie witryny od początku posiadającej wiele podstron również może
przyczynić się do zmniejszenia kosztów gdyż nie trzeba kodować każdej z nich osobno. Jak
przedstawiłem na przykładzie powyżej, utworzenie nowej podstrony, artykułu, wprowadzanie
korekty czy dokonywanie aktualizacji jest tak proste jak otwarcie dokumentu Worda,
dokonanie zmian i zapisanie ich. Wszystko poprzez przeglądarkę www.
Optymalizacja pod kątem indeksowania w wyszukiwarkach (SEO2) – Jeżeli statyczna
strona została zbudowana dobrych kilka lat temu, prawdopodobnie nie jest zoptymalizowana
pod kątem indeksowania w najpopularniejszych wyszukiwarkach takich jak np. Google.
Niektóre systemy CMS po dokonaniu przeróżnych poprawek i ulepszeń mogą stać się
świetnymi sprzymierzeńcami w poprawianiu swojej pozycji w wyszukiwarkach. Ulepszenia
wystarczy wykonać tylko raz i będą one działać w zakresie wszystkich stron. Główny
problem polega na tym, większość systemów CMS nie zapewnia dobrego indeksowania
podstron bez wykonywania ulepszeń.
Blogowanie i social media3 – Blogi i social media to systemy ułatwiające szybkie
publikowanie treści w Internecie w sposób, który ułatwia budowanie więzi z klientami,
2 SEO – Search Engine Optymalization – optymalizacją pod kątem wyszykiwarek. Proces mający na celu poprawienie widoczności witryny w wyszukiwarkach www. Wiele ciekawych informacji nt. Tej dziedziny monża znaleźć pod adresem http://www.seobook.com/
3 Social Media – forma publikowania treści w internecie pozwalająca użytkownikom na angażowanie się w współtworzeniu zawartości strony. Więcej informacji pod adresem http://en.wikipedia.org/wiki/Social_media
10
osobami odwiedzającymi witrynę bądź ze znajomymi. Są to narzędzia umożliwiające szybkie
umieszczanie informacji odnośnie np. wydarzeń zaplanowanych na najbliższe dni,
specjalnych ofert sprzedaży bądź firmowych aktualności. Ponieważ odwiedzający mogą
komentować posty więc można mówić tu o dwukierunkowej relacji, konwersacji obsługi
strony z czytelnikami. W dzisiejszych czasach większość dużych firm poważnie inwestuje w
strategie związane z social media ponieważ strategie te są kluczowe w tworzeniu więzi z
klientem. Poza tym przyciągają one uwagę Google i innych wyszukiwarek. Wszelkie
funkcjonalności związane ze zwiększaniem więzi z czytelnikami czy klientami są bardzo
pożądane. Większość systemów CMS wspiera różne tego typu rozwiązania.
Dodatkowe funkcje – zapewnienie statycznym stronom www dodatkowych funkcji
zazwyczaj wiąże się z poniesieniem dodatkowych kosztów, nieraz dość sporych, w zależności
od tego ile dodatkowej pracy będą musieli wykonać programiści aby napisać dodatkowy kod.
Większość systemów CMS jest wspierana przez pokaźną grupę programistów tworzących
tysiące darmowych dodatków do systemów zarządzania treścią, tzw. plugin-ów lub modułów.
Dla przykładu moduł dodający formularz kontaktowy może zostać dodany do strony szybko i
bezpłatnie. Nieco bardziej złożone zadanie takie jak np. utworzenie formularza zbierającego
dane klientów i przechowującego te informacje w bazie danych może zostać
zaimplementowane niskim kosztem.
Zmiana wyglądu – Wiele aspektów strony opartej na systemie CMS może być łatwo
zmienianych. Wliczyć w to można nie tylko treść strony ale także jej wygląd. Oprócz
możliwości zmiany całego design-u, wiele systemów CMS udostępnia np. możliwość zmiany
samego logo firmy w przypadku gdy zostanie ono np. przeprojektowane na nowe.
Większa kontrola – Dodanie do strony nowej funkcjonalności może wymagać pomocy
programisty, aczkolwiek wiele innych prostych zadań może być realizowanych przez osoby
zajmujące się redagowaniem strony. CMS umożliwia utworzenie wielu kont użytkowników
posiadających różnego rodzaju uprawnienia. Dział marketingu może mieć konto
umożliwiające mu publikowanie firmowych aktualności podczas gdy dział obsługi klienta
poprzez swoje konto może np. tylko odpowiadać na pytania użytkowników. Żadna
specjalistyczna wiedza nie jest to konieczna. Jeśli podwładni umieją korzystać z Worda i np.
Gmaila, to mogą także bez problemu zalogować się do panelu zarządzania aby dodawać nowe
podstrony. Jeśli wpisywana przez nich treść musi być zatwierdzona przez np. kierownika
działu, można ograniczyć ich uprawnienia do samego wpisywania treści pozostawiając
11
możliwość publikowania menadżerowi. W takiej sytuacji posty będą oczekiwać aż menadżer
je zatwierdzi i opublikuje.
1.1.3. Kto korzysta z systemu CMS?Z systemów zarządzania treścią korzystają wszystkie średnie i duże firmy oraz wszystkie
multimedialne i społecznościowe strony Web 2.04 takie jak Youtube, Picasa czy Flickr. Z
CMS-ów korzystają także takie firmy takie jak Microsoft, Symantec, Universal, Amnesty
International czy Amazon i wiele innych. Nie byłoby sposobu obsłużenia ich niesamowitej
ilości podstron oraz niezliczonej ilości aktualizacji bez dynamicznych stron zarządzanych
przez liczne CMS-y.
Facebook jest bardzo dobrym przykładem. Osoby należące do społeczności Facebook-a mają
ten sam szablon strony, który personalizują sobie umieszczając w nim różne dodatki. Nie ma
przy tym potrzeby kodowania czegokolwiek – wystarczy wypełnić odpowiednie pola,
pozaznaczać pola wyboru i wpisać swoją treść aby zaktualizować swoje dane lub dodać nowy
post. Na stronie MySpace można nawet zmieniać wygląd całego szablonu.
1.1.4. Narzędzia typu Dreamweaver i Front PageNarzędzia umożliwiające projektowanie stron w trybie WYSIWYG, takie jak Dreamweaver5
lub Front Page6, były głównymi aplikacjami deweloperskimi w późnych latach 1990 i w
pierwszych kilku latach 21 wieku. Zmieniły one sposób tworzenia stron www z pisania kodu
w prostym edytorze tekstowym na wizualne środowisko, w którym można było oglądać
budowaną stronę przed jej ukończeniem.
4 Web 2.0 – Termin ten odnosi się do stron www, które umożliwiają swoim użytkownikom nie tylko na przeglądanie informacji ale także pozwalają im na większą interakcję. http://en.wikipedia.org/wiki/Web_2.0
5 Więcej na informacji na temat programu Dreamweaver: http://www.adobe.com/products/dreamweaver/
6 Więcej na informacji na temat programu Front Page: http:// www.microsoft.com/poland/frontpage/
12
Wiele osób nie zdaje sobie sprawy z tego, że Microsoft Word sam w sobie też jest edytorem
WYSIWYG7. Poza tym program Word potrafi zapisać dany dokument jako stronę
internetową.
Narzędzia WYSIWYG wspaniale służyły w swoich czasach ale korzystanie z nich nadal
wymagało znajomości języka HTML, umiejętności kopiowania plików na serwer oraz innych
zadań związanych z obsługą serwera. Programy te nadal świetnie działają pod warunkiem, że
korzystający z nich użytkownicy znają się na kodowaniu stron www – w takiej sytuacji mogą
korzystać z programów WYSIWYG aby przyspieszyć swoją pracę.
Dzisiaj programy WYSIWYG są dużo bardziej złożone ponieważ strony internetowe stały się
dużo bardziej skomplikowane. Oprócz języka HTML mamy jeszcze style CSS (które
umożliwiają definiowanie m.in. kolorów i czcionek używanych na stronie) oraz wiele, wiele
innych technologii takich jak JavaScript czy PHP. Korzystanie z tak rozbudowanych narzędzi
wymaga także wielu godzin poświęconych na nauczenie się ich obsługi.
Poważną wadą narzędzi WYSIWYG może być też kiepskiej jakości, nieczytelny kod co
pogarsza jakość strony i tym samym źle wpływa na indeksowanie strony przez wyszukiwarki.
Poniżej przedstawiono niskiej jakości fragment kodu dokumentu HTML wygenerowanego
przez edytor Word.
<v:shape id="Obraz_x0020_0" o:spid="_x0000_i1025" type="#_x0000_t75" alt="2.2. Logo Drupal.png" style='width:453.75pt;height:138.75pt;visibility:visible; mso-wrap-style:square'> <v:imagedata src="Testowa%20treść_pliki/image001.png" o:title="2.2. Logo Drupal"/></v:shape><![endif]--><![if !vml]><img width=605 height=185src="Testowa%20treść_pliki/image002.gif" alt="2.2. Logo Drupal.png"v:shapes="Obraz_x0020_0"><![endif]></span></p><p class=MsoNormal>Testowa treść, testowa treść, testowatreść.</p><table class=MsoTableGrid border=1 cellspacing=0 cellpadding=0 style='border-collapse:collapse;border:none;mso-border-alt:solid black .5pt; mso-border-themecolor:text1;mso-yfti-tbllook:1184;mso-padding-alt:0cm 5.4pt 0cm 5.4pt'>
7 Edytor WYSIWYG - What You See Is What You Get – To Co Widzisz Jest Tym Co Otrzymasz. Edytor tego typu prezentuje podczas edycji treść w postaci jak najbardziej zbliżonej do jej wyglądu po obublikowaniu.Więcej na ten temat: http://en.wikipedia.org/wiki/WYSIWYG
13
<tr style='mso-yfti-irow:0;mso-yfti-firstrow:yes'> <td width=307 valign=top style='width:230.3pt;border:solid black 1.0pt; mso-border-themecolor:text1;mso-border-alt:solid black .5pt;mso-border-themecolor: text1;padding:0cm 5.4pt 0cm 5.4pt'> <p class=MsoNormal style='margin-bottom:0cm;margin-bottom:.0001pt;line-height: normal'>Komórka nr 1</p>
1.1.5. „Site buildery” i kreatory stron www dostępne u firm hostingowychWiele dobrych firm hostingowych udostępnia usługi ułatwiające utworzenie strony www,
wliczając w to instalatory wymagające kilku kliknięć i kreatory www posiadające pewną
grupę gotowych szablonów. Jedna z popularniejszych firm hostingowych w Polsce, Home.pl,
oferuje kreator stron www już od kilku lat dla wszystkich klientów, którzy wykupili u nich
konto na serwerze www. Kreator taki jest narzędziem z rodziny systemów CMS i posiada
podobne cechy jak kreatory wymienione wcześniej. Poniżej przedstawiono jako przykład
wygląd kreatora dostępnego na Home.pl.
Rysunek . Wygląd strony głównej kreatora www dostępnego na home.pl
Korzystanie z takiego kreatora może być dobrym rozwiązaniem jedynie na początek. Niestety
narzędzia te są mocno ograniczone, np. Home.pl umożliwia utworzenie jedynie 6 podstron
poziomu podstawowego i udostępnia ograniczoną ilość szablonów z pośród których można
wybierać. Rozwiązanie takie umożliwia szybkie i łatwe utworzenie prostej strony ale nie
14
nadaje się dla większych rozbudowanych stron, dla stron wymagających oryginalnego
wyglądu ani dla tych które wymagają wyszukanych funkcji dodatkowych.
1.2. Serwisy www z systemem CMS a tradycyjne strony XHTMLPrzed chwilą wyjaśniłem dokładnie czym jest system CMS i jakie są najważniejsze korzyści
wynikające z posiadania takiego systemu. Wspomniałem także nieco o statycznych stronach
www. Teraz nadeszła pora aby omówić je dokładniej. W tym podrozdziale przedstawię
najważniejsze różnice pomiędzy stronami opartymi na CMS-ach a tradycyjnymi statycznymi
stronami HTML.
Zasadnicza różnica pomiędzy statyczną witryną a aplikacją opartą na systemie CMS polega
na sposobie przechowywania treści podstron. W przypadku strony opartej na systemie CMS
treść jest przechowywana w bazie danych. Dla tradycyjnych stron www cała treść jest
przechowywana bezpośrednio w plikach HTML. Oznacza to, że utworzenie statycznej strony
wymaga jedynie zakodowania treści w plikach HTML oraz dołączenia przygotowanych styli
CSS, które zapewnią jej odpowiedni wygląd. Opcjonalnie można jeszcze dodać różnego
rodzaju skrypty JavaScript, które wzbogacą witrynę o funkcje takie jak wyświetlanie na
stronie daty i godziny lub np. animowanie elementów strony. Zbudowanie tak samo
wyglądającej strony w oparciu o system CMS wymaga zdecydowanie większego nakładu
pracy ponieważ trzeba skonfigurować system i przygotować odpowiednie szablony, których
CMS będzie używał podczas wyświetlania stron.
Jak wspomniałem we wcześniejszym podrozdziale aktualizacja bądź przebudowa statycznej
strony www jest problematyczna – np. dla statycznej witryny posiadającej 50 podstron,
zmiana jednego elementu nawigacji może wiązać się z koniecznością zmieniania tego
elementu na każdej stronie z osobna, co daję nam aż 50 dokumentów, które trzeba
zaktualizować. Z tego powodu statyczne strony www nadają się głównie do tworzenia
małych, nieskomplikowanych stron, których autor nie planuje ich nigdy aktualizować.
Problem ten nie występuje w przypadku stron opartych na systemach CMS.
Zaletą statycznych stron jest fakt, że aby nauczyć się je tworzyć wystarczy opanować HTML,
CSS i podstawy tworzenia grafiki komputerowej. Strony takie nie będą posiadały wyszukanej
funkcjonalności ale mogą zostać z powodzeniem utworzone przez entuzjastów, którzy chcą
mieć stronę www, za której utworzenie nie chcą płacić programistom. Wbrew pozorom to
bardzo częsty przypadek. Umiejętne zbudowanie oryginalnie wyglądającej strony opartej na
15
systemie CMS wymaga bardzo dużego nakładu pracy, ale utworzenie strony statycznej –
zdecydowanie mniej.
1.2.1. Wady statycznych stron wwwStatyczne strony www posiadają wiele poważnych ograniczeń, które powodują, że dla
większości witryn i portali, nie zdają one egzaminu. Główne ograniczenia to:
Mniej wygodne i droższe aktualizacje – Statyczne strony www nie posiadają panelu
zarządzania treścią. Aktualizowanie podstron wymaga pobrania plików HTML z serwera,
edytowanie ich i ponowne przesłanie ich na serwer. Jeżeli właściciel strony nie umie zrobić
tego samemu, bo np. nie zna HTML-a lub nie wie jak przesyła się pliki przez FTP, zmuszony
jest płacić programistom za każdą wykonaną aktualizację, co znacząco przyczynia się do
zwiększenia ponoszonych kosztów. Aktualizacja design-u wymaga dokonywania zmian we
wszystkich dokumentach zawierających zmieniany element. Zadanie to można sobie ułatwić
umieszczając podstawowe elementy strony, takie jak np. nawigacja, w oddzielnych plikach, i
dołączanie ich za pomocą tzw. server side includes. Innym rozwiązaniem ułatwiającym tego
typu aktualizacje może być korzystanie z tzw. template-ów programu Adobe Dreamweaver.
Bardzo czasochłonna zmiana wyglądu całej strony – Trudności związane z
aktualizowaniem dają się jeszcze bardziej odczuć podczas zupełnego odświeżania wyglądu
strony. Nadanie stronie zupełnie nowego wyglądu wiąże się właściwie ze zbudowaniem tej
strony całkowicie od początku. Jedyne co pozostaje po starej stronie to wycięta z plików
HTML treść.
Gorsze możliwości rozbudowy – Rozbudowa statycznej strony również nie jest zbyt
wygodna. Dodawanie nowych elementów wiąże się z dołączaniem ich do wszystkich
podstron na których mają się pojawić. Przeciwnie sytuacja wygląda w przypadku systemów
CMS, które posiadają liczne moduły dodatkowe zapewniające dodatkowe funkcje. Instalacja
dodatkowych modułów to zazwyczaj kwestia kilku minut.
Brak istotnych funkcji - Statyczne strony www nie posiadają wielu istotnych funkcji takich
aplikacje do blogowania, sondy, automatyczne tworzenie list najnowszych postów i tym
podobnych.
Mniejsze możliwości kontroli strony – Osoby, które nie utworzyły swojej statycznej strony
www same tylko zamówiły ją w firmie deweloperskiej mają mniejsze możliwości panowania
16
nad tą stroną gdyż nie mogą nią zarządzać poprzez panel administracyjny. Świetnym
przykładem takiego przypadku może być mój znajomy, który posiada statyczną stronę www,
na której niczego nie może zmienić nie tylko z powodu braku panelu zarządzania ale także
dlatego, że firma która utworzyła dla niego tę stronę weszła z nim w konflikt i nie chce robić
mu aktualizacji.
1.2.2. Zalety statycznych stron wwwOprócz wymienionych powyżej wad statyczne strony www posiadają także pewne zalety, w
których mają przewagę nad systemami zarządzania treścią. Oto ich lista:
Prędkość działania – Nie da się ukryć, że ze wszystkich możliwych rodzajów stron www
statyczne strony ładują się najszybciej. Jest tak ponieważ jedyne akcje serwera podczas
odbioru zapytania o stronę www polegają na przesłaniu do przeglądarki klienta pliku HTML i
towarzyszących mu plików CSS, zdjęć i ewentualnych skryptów JavaScript. W przypadku
systemów CMS proces ten jest dużo bardziej złożony i składa się z następujących kroków:
• Po odebraniu zapytania serwer uruchamia aplikację CMS
• Aplikacja CMS odpytuje bazę danych w celu dynamicznego utworzenia strony www,
która zostać wyświetlona odwiedzającemu. Zapytań do bazy jest tu zazwyczaj wiele,
począwszy od wczytania różnych ustawień CMS-a, a na wyciągnięciu z bazy danych
treści strony skończywszy
• W trakcie odpytywania bazy danych CMS stopniowo buduje stronę
• Serwer przesyła do przeglądarki gotową stronę www
• Przeglądarka interpretuje przesłany kod HTML i doczytuje odpowiednie pliki CSS,
obrazki i skrypty.
Po przeanalizowani kroków, które następują podczas odwiedzin na stronie zarządzanej przez
system CMS nie jest zaskakujące, że statyczne strony HTML ładują się dużo szybciej.
Problem prędkości wczytywania się stron opartych na systemie zarządzania treścią można w
dużym stopniu obejść. Przykłady jak tego dokonać przedstawiam w rozdziale 6.
Bezpieczeństwo – Ponieważ statyczne strony www nie umożliwiają logowania się i
zarządzania treścią przechowywaną w bazie danych, ani nie korzystają ze skryptów
17
uruchamianych po stronie serwera, takich jak np. PHP, w związku z tym są bardzo
bezpieczne. Nie wymagają też aktualizowania oprogramowania tak jak jest to z systemami
CMS. Dzięki temu raz zbudowaną stronę www można umieścić na serwerze i więcej się nią
nie przejmować – możemy mieć pewność, że wszystko będzie działać jak należy.
Brak konieczności wykonywania kopii zapasowych – Ze względu na to, że statyczne strony
nie korzystają z bazy danych, i nie są na okrągło aktualizowane tak jak to jest ze stronami
bazującymi na CMS, nie trzeba zawracać sobie głowy tworzeniem kopii zapasowych. Wynika
to także z tego, że statyczne strony www nie są podatne na uszkodzenia tak jak to jest ze
stronami dynamicznymi.
Łatwość zmiany firmy hostingowej – Ponieważ statyczne strony www nie korzystają z bazy
danych, więc przeniesienie takiej strony na nowy serwer to właściwie tylko kwestia
skopiowania plików. Oprócz tego, ponieważ statyczne strony internetowe nie wymagają bazy
danych ani interpretera kodu uruchamianego po stronie serwera (takiego jak np. PHP), mogą
być z powodzeniem nagrywane np. na płyty CD lub DVD i uruchamiane bezpośrednio z
nośnika. Dzięki temu można np. dołączyć na płycie małą stronę www do sprzedawanej
książki.
Możliwość podglądu gotowej strony przed jej opublikowaniem – Finalną zaletą
statycznych stron www jest możliwość podglądu gotowej strony prosto z dysku twardego
komputera na, którym się ją tworzy. Dzięki temu można bardzo dokładnie skontrolować
wygląd dowolnego elementu danej podstrony przed opublikowaniem jej w Internecie. Strony
oparte na systemach CMS nie umożliwiają wykonywania tego typu podglądu ale zazwyczaj
dają możliwość podejrzenia wyglądu np. samego artykułu przed jego opublikowaniem.
Z powyższej listy zalet można łatwo wywnioskować, że statyczne strony www nie są
bezużyteczne. Zdecydowanie mają one swoje mocne strony, które sprawiają, że jeszcze na
długo pozostaną w użyciu. Najbardziej istotną ich cechą wydaje się być ich szybkość
działania. Są one nieporównanie szybsze od aplikacji CMS. Różnica w czasie ładowania jest
drastyczna. Niektóre dynamiczne witryny wykorzystują nawet odpowiednio skonfigurowany
system CMS, który dla każdej dynamicznej podstrony tworzy jej statyczną kopię. System taki
podczas odwiedzin użytkownika nie musi już wykonywać wielu zapytań do bazy – jedyne co
robi polega głównie na przesłaniu do przeglądarki użytkownika wygenerowanej wcześniej
statycznej kopii podstrony. Znacząco przyśpiesza to proces ładowania.
18
19
1.3 Cechy charakterystyczne, zalety i wady systemów CMSOmówiliśmy już podstawy systemów CMS i przedyskutowaliśmy najważniejsze korzyści
wynikające z korzystania z takich systemów. Porównałem tradycyjne statyczne strony www
ze stronami opartymi na systemach zarządzania treścią i wymieniłem główne ograniczenia
wynikające z korzystania z tego typu stron. Omówię teraz wszystkie najważniejsze zalety
systemów CMS. Oczywiście, jak to zazwyczaj bywa z oprogramowaniem, systemy takie
także posiadają swoje minusy, które też omówię za chwilę.
Być może zdziwiłeś się na wieść o tym, że systemy CMS mogą posiadać wady. Faktycznie po
przeczytaniu wcześniejszych podrozdziałów można pomyśleć, że systemy te nie mają swoich
słabych stron. Ilość istotnych korzyści, wynikających z używania CMS-a jest jednak tak
znacząca, że w dużej mierze przesłania ich minusy.
1.3.1. Zalety systemów CMSPodstawowe zalety systemów CMS to:
• Łatwość dodawania i edytowania treści – Publikacja nowego gotowego artykułu nie
wymaga prawie żadnego wysiłku. Osoby dodające nowe artykuły nie muszą znać
kodu HTML czy PHP ani zajmować się design-em dzięki czemu mogą bardziej skupić
się na pisaniu samej treści – są praktycznie zupełnie odciążone ze wszystkich innych
zadań. Nawet kompletnie niedoświadczone osoby mogą zostać bardzo łatwo
wyszkolone w posługiwaniu się systemem CMS. Wyświetlanie na odpowiednich
podstronach informacji o nowych artykułach odbywa się automatycznie. Dzięki
powyższym cechom systemy CMS bardzo ułatwiają wykonywanie częstych
aktualizacji.
• Niski koszt – Istnieje wiele solidnych systemów CMS. Spora część z nich jest
oprogramowaniem typu open source8 co oznacza, że są one całkowicie bezpłatne.
Systemy nie należące do tej grupy to głównie rozwiązania komercyjne. Ceny płatnych
systemów są zróżnicowane, nie brakuje jednak w śród nich świetnych rozwiązań o
przystępnej cenie. Płatne systemy zazwyczaj posiadają także wliczoną w cenę
możliwość pobierania darmowych aktualizacji oraz pełne wsparcie techniczne,
najczęściej ograniczone do 1 roku
8 Open Source – wiele przydatnych informacji na temat wolnego oprogramowania znajduje się pod adresem http://www.opensource.org/
20
• Mnogość przydatnych funkcji – Dobry system CMS, oprócz swojego podstawowego
zadania jakim jest umożliwienie łatwego zarządzania treścią strony, dostarcza także
wielu świetnych funkcji takich jak np. sprawdzanie poprawności ścieżek odnośników
(chociażby tych wpisywanych dla elementów nawigacji) lub funkcji związanych z
poprawianiem usability strony takich jak np. kategoryzacja treści polegająca na
przypisywaniu artykułów do uprzednio zdefiniowanych kategorii. Kategoryzacja
artykułów umożliwia odwiedzającym przejrzenie na oddzielnej podstronie wszystkich
artykułów przypisanych do danej kategorii. W skład systemów CMS wchodzą często
funkcje takie jak kalendarz, fora internetowe, galerie zdjęciowe czy np. newsletter.
Funkcjami tymi można zarządzać z poziomu panelu administracyjnego. CMS bogato
wyposażony znacząco zmniejsza konieczność inwestowania w dodatkowe funkcje.
Ponadto zarządzanie dodatkowymi funkcjami wspierającymi działanie strony jest
prostsze gdy ma się do nich wszystkich dostęp z poziomu jednego interfejsu
administracyjnego.
• Większa interaktywność strony z użytkownikami – CMS ułatwia zbudowanie
strony posiadającej dużą interaktywność z jej użytkownikami, np. poprzez możliwość
komentowania artykułów. Funkcjonalność tego typu bardzo ożywia stronę.
Użytkownicy mogą prowadzić dyskusje odnośnie np. artykułu. Dla niektórych
autorów stron jest to bardzo ważne ponieważ umożliwia im to stworzenie pewnego
rodzaju społeczności użytkowników strony, którzy będą regularnie ją odwiedzać w
poszukiwaniu nowości. Fakt ten pozwala także nieco bardziej uniezależnić się od
wyszukiwarek – strona będzie i tak odwiedzana przez stałych gości oraz przez osoby
którym została polecona (ustnie lub poprzez odnośniki z innych stron). Ponadto strony
z możliwością komentowania stale się zmieniają – pojawiają się nowe komentarze.
Jest to bardzo korzystne z punktu widzenia SEO – wyszukiwarki „lubią” strony,
których treść często ulega aktualizacji.
• Zwiększenie użyteczności – CMS-y zwiększają użyteczność strony bez zwiększania
nakładu pracy jaki muszą wykonać redaktorzy. Wszelkie funkcje ułatwiające np.
poruszanie się po stronie oraz poprawiające użyteczność interfejsu użytkownika
działają niezależnie od działań redaktorów.
• Łatwe sprawdzanie czy są nowości na stronie, współdzielenie informacji z innymi
stronami – System CMS często dostarcza centralnego punktu gdzie użytkownicy
21
mogą sprawdzać co nowego pojawiło się na stronie. Świetnym tego przykładem może
być podstrona z listą ostatnio dodanych wpisów (np. artykułów i/lub aktualności).
Bardzo popularny stał się także system kanałów RSS9, umożliwiający odczytywanie
najświeższych informacji ze stron www bez faktycznego wchodzenia na nie, co
znacząco skraca czas potrzebny na zapoznanie się z nowościami publikowanymi na
ulubionych stronach. Treść kanałów RSS przesyłana jest w formacie XML10, a do jej
odczytu konieczny jest jeden z programów określanych mianem czytnik RSS.
Alternatywnie skorzystać można z czytników dostępnych online, takich jak np.
Google Reader dostępny pod adresem http://www.google.com/reader. Systemy takie
jak np. RSS umożliwiają również współdzielenie informacji pomiędzy serwisami.
Innym rozwiązaniem pojawiającym się w systemach CMS, które umożliwia
współdzielenie informacji są usługi internetowe (ang. Web services11)
Następujące zalety związane są z wyglądem strony:
• Spójność wyglądu podstron – System CMS zarządza wyglądem strony, który opiera
się na tak zwanych szablonach (zwanych także template-ami lub w przypadku
niektórych systemów – theme-ami). Dzięki wykorzystaniu szablonów zapewniona jest
spójność wyglądu wszystkich podstron i elementów interfejsu. Jest to praktyczne
zwłaszcza w przypadku gdy strona ma kilku redaktorów – nie trzeba martwić się o to,
że któryś z nich zmieni wyglądu jakiegoś elementu, którego miał nie zmieniać.
Redaktorzy mogący np. dodawać artykuły ograniczeni są w działaniu do edytowania
treści samego artykułu – nie mają oni natomiast możliwości dokonywania zmian w
innych elementach strony.
• Łatwość zmiany wyglądu całej witryny – Systemy CMS to aplikacje typu MVC (z
ang. Model View Controller – Model Widok Kontroler). W aplikacjach tych
wyróżniamy 3 warstwy:
9 Pełna specyfikacja standardu RSS dostępna jest na stronie http://validator.w3.org/feed/docs/rss2.html
10 Wiele przydatnych informacji na temat języka XML znajduje się pod adresem http://www.w3.org/XML/
11 Web services – Bardzo dobrym źródłem informacji nt. usług sieciowych jest książka Ethana Cerami - Web Services Essentials, wydawnictwo O'Reily. http://oreilly.com/catalog/9780596002244/
22
o Model – pewne dane, które będziemy przetwarzać. Dla systemów CMS są to
np. przechowywane w bazie danych treści artykułów.
o Widok – czyli warstwa prezentacji, jest odpowiedzialna za wyświetlanie
danych.
o Kontroler – warstwa odpowiedzialna za odczyt danych z bazy i przekazanie
ich do warstwy prezentacji.
Aplikacje MVC cechuje łatwość zmiany wyglądu całej strony. W przypadku systemów CMS
zazwyczaj ogranicza się to głównie do zmiany template-a na nowy. Operacja ta nie ma
wpływu na treść (model) ponieważ zmieniana jest jedynie warstwa prezentacji (widok)
Zmiany w wyglądzie są odwzorowywane natychmiastowo dla wszystkich podstron.
• Atrakcyjne szablony – Niektóre systemy CMS zapewniają wiele atrakcyjnych,
bezpłatnych szablonów i dodatkowych modułów związanych z prezentacją zdjęć.
Darmowe szablony mogą znacząco obniżyć koszt strony ale nie zapewnią jej
oryginalnego wyglądu.
Poniższe zalety dotyczą współpracy redakcyjnej kilku osób:
• Ułatwienie pracy wielu współtwórców jednocześnie – CMS umożliwia prace wielu
współtwórców bądź redaktorów strony jednocześnie. Mogą oni bez problemu
pracować nad tą samą witryną w tym samym czasie a ich działania nie będą ze sobą
konfliktować. W przypadku statycznych stron www mogą pojawić się konflikty.
Przykładem może być sytuacja w której jeden redaktor edytuje element nawigacji na
stronie x a inny redaktor aktualizuje treść artykułu na tej samej podstronie. Po
zakończeniu prac może okazać się, że redaktor, który opublikował poprawioną wersję
jako drugi nadpisał zmiany wprowadzone chwilę wcześniej przez pierwszego
redaktora.
• Śledzenie działań użytkowników a odpowiedzialność – Systemy CMS zazwyczaj
zapisują, który użytkownik i kiedy dokonał jakich zmian. Dotyczy to zarówno rzeczy
prostych jak np. dodawanie komentarzy oraz operacji dostępnych tylko dla redaktorów
takich jak np. edytowanie artykułów. Dzięki zapisywaniu wykonanych przez
użytkowników działań, w przypadku np. usunięcia istotnych treści lub wykonania
23
dowolnych innych niewskazanych operacji, wiadomo kogo pociągnąć do
odpowiedzialności.
• Workflow – CMS może udostępniać system workflow. System taki polega na
automatyzacji pewnych procesów, podczas której dokumenty, informacje lub zadania
są przekazywane od jednego uczestnika do następnego, zgodnie z pewnymi
procedurami. W odniesieniu do systemów CMS system taki może umożliwiać np.
przechodzenie artykułów przez pewne fazy zanim zostaną one opublikowane w sieci.
Przykładowe kroki, które mogą być wymagane przed opublikowaniem artykuł, to np.:
artykuł do przejrzenia → artykuł do poprawienia → artykuł do zatwierdzenia, przy
czym każdy etap przetwarzania artykułu może być realizowany tylko przez
uprawnioną do tego osobę. Na przykład: reporter dodaje artykuł, który otrzymuje
status „do przejrzenia”. Następnie kierownik działu reportaży sprawdza artykuł i jeśli
jest w porządku oznacza go jako artykuł „do zatwierdzenia”. Oznaczone w ten sposób
artykuły wymagają już tylko akceptacji naczelnego redaktora aby mogły zostać
opublikowane w sieci.
• Zablokowanie fragmentów designu – System CMS umożliwia zablokowanie
różnych elementów designu (kolorów, czcionek, nawigacji itp.) i pozwala ograniczyć
możliwości redaktorów dotyczące zarządzania zdjęciami i treścią. Dzięki temu mamy
większą kontrolę nad stroną niezależnie od tego ile osób współpracuje przy jej
tworzeniu.
Inne istotne zalety to:
• Centralnie przechowywana treś
• - Cała treść strony jest przechowywana centralnie w bazie danych dzięki czemu jest
łatwo dostępna i może być w dowolny sposób przetwarzana przez system CMS lub
dowolny inny system współpracujący.
• Indeksowanie i przeszukiwanie treści – Ponieważ treść jest przechowywana w bazie
danych, w związku z tym może być dowolnie przeszukiwana. Większość CMS-ów
posiada wewnętrzny system indeksowania i przeszukiwania treści, co może ułatwić
użytkownikom odnalezienie interesujących ich artykułów bez przechodzenia do
niebędącej częścią strony wyszukiwarki, np. do Google
24
• Automatyczne publikowanie – Część CMS-ów posiada możliwość ustawienia
automatycznego, zaplanowanego publikowania artykułów z puli gotowych do
publikacji (np. codziennie jeden). Dzięki temu możemy w wolnej chwili dodać kilka
artykułów, ale ich nie publikować – system CMS automatycznie opublikuje
codziennie jeden z nich. Jest to dobre z punktu widzenia SEO, ponieważ lepiej jest
dodawać jeden artykuł dziennie niż np. 5 artykułów na raz co 5 dni. Jest tak ponieważ
5 artykułów dodawanych co 5 dni oznacza rzadsze aktualizacje strony niż jeden
artykuł dziennie.
• Obsługa różnych formatów – Systemy CMS często umożliwiają dostarczanie
informacji, takich jak np. treści artykułów, w różnych formatach, wliczając w to m.in.
HTML, zapisywanie artykułów jako PDF lub jako dokumenty Worda. Inne formy to
treści przygotowane dla urządzeń mobilnych czy chociażby wspomniany wcześniej
standard RSS.
• Stopniowe poznawanie języka HTML – Ostatnią zaletą, którą zamierzam wymieć
jest fakt, że CMS umożliwia łatwe i stopniowe poznawanie języka HTML.
Użytkownicy często, po przyzwyczajeniu się i nauczeniu się obsługi CMS-a,
zaczynają powoli wykorzystywać podstawowe elementy HTML-a. Naukę tego języka
może ułatwić także korzystanie z edytora WYSIWYG używanego nieraz podczas
wpisywania artykułów.
1.3.2. Wady systemów CMSSystemy zarządzania treścią posiadają następujące wady:
• Zmniejszone bezpieczeństwo witryny – Systemy CMS to złożone struktury
składające się zazwyczaj z wielu modułów i skryptów pełniących różnorakie funkcje.
Elementy te to częściowo skrypty uruchamiane po stronie serwera (np. PHP), a
częściowo skrypty uruchamiane po stronie klienta (JavaScript). Wykorzystywanie
skryptów, oprócz wielu niezliczonych korzyści, wiąże się także z pewnym
potencjalnym ryzykiem. Nawet najlepiej napisane skrypty i programy zawsze będą
narażone na pojawienie się dziur w zabezpieczeniach. Ponieważ cała strona www i jej
system CMS są dostępne publicznie, każdy kto odkryje dziurę w oprogramowaniu
CMS-a zanim zostanie ona załatana, może próbować uszkodzić witrynę oraz
przechowywane przez nią dane (np. artykuły). Ryzyka ataku zwiększa się w
25
przypadku stron, których system CMS długo nie był aktualizowany. Dlatego bardzo
ważne jest aby dokonywać stałych aktualizacji gdy tylko pojawiają się kolejne wersje
używanego CMS-a
• Rzadkie aktualizacje zabezpieczeń – W przypadku niektórych systemów CMS
aktualizacje zabezpieczeń nie pojawiają się odpowiednio szybko co również zmniejsza
bezpieczeństwo witryn bazujących na tych systemach. Nawet jeśli aktualizacje
pojawiają się odpowiednio szybko, wielu użytkowników ignoruje je i pozostawiają
swoje systemy CMS niezaktualizowane co naraża ich strony.
• Niedostępność strony podczas aktualizacji systemu CMS – Podczas aktualizacji
systemu w przypadku większości CMS-ów strona będzie niedostępna. Jeśli
aktualizacja wymaga nie tylko wgrania nowych plików systemu CMS ale także
dokonania zmian w bazie danych, konieczne będzie uruchomienie skryptu
aktualizacyjnego zanim cała strona zacznie poprawnie działać. Ponieważ wiele osób
ma niską prędkość wysyłania danych przez swoje łącza, więc aktualizacja może zająć
sporo czasu co jest bardzo niekorzystne dla stron posiadających dużą liczbę
odwiedzających.
• Konieczność wykonywania kopii zapasowych – Dla wszystkich stron opartych na
systemach CMS konieczne jest wykonywanie regularnych kopii zapasowych. Kopii
tych nie można (w przeciwieństwie do statycznych stron HTML) przejrzeć bez
ponownego wgrywania ich na jakiś serwer obsługujący odpowiednie skrypty i bazę
danych. Wgrywając kopię witryny na inny serwer należy pamiętać, aby nazwa
użytkownika i hasło bazy danych zapisane w konfiguracji CMS-a zgadzały się z tymi
ustawionymi na serwerze.
Następujące wady dotyczą wyglądu strony i warstwy prezentacji:
• Niezgodność z najnowszymi trendami i standardami www – Systemy CMS często
nie są „na czasie” jeśli chodzi o najnowsze trendy i standardy www. Przyczynić się to
może do:
o Pogorszenia jakości, poprawności i czytelności generowanego kodu HTML, co
z kolei utrudnia i osłabia indeksowanie strony przez wyszukiwarki oraz
26
powoduje, że strona jest postrzegana, przez osoby zajmujące się tworzeniem
witryn internetowych, jako nieprofesjonalna.
o Niepoprawny kod może pogarszać działanie strony, np. ją spowalniać lub
powodować pojawianie się różnego typu artefaktów graficznych. Pogarsza to
jakość doznań osób odwiedzających witrynę i może bardzo negatywnie odbić
się na ilości odwiedzin.
• Przestarzały i nieoryginalny wygląd – W przypadku korzystania z jednego z
domyślnych szablonów dostarczanych razem z systemem CMS, strona może mieć
przestarzały wygląd. Szablony te są zazwyczaj ubogie i nawet jeśli są zgodne ze
standardami www, nieraz wyglądają nieciekawie. Domyślne template-y CMS-ów nie
zapewniają oryginalnego wyglądu - zapewnić go mogą jedynie własne szablony
tworzone specjalnie na potrzeby konkretnej strony. Ponadto wiele szablonów jest do
siebie mocno podobna i posiada zbliżony układ, kojarzący się z CMS-em.
Wady związane z kodem wynikowym strony:
• Ograniczenia dotyczące kodu wynikowego strony – Niektóre CMS-y ograniczają
możliwości definiowania i zmieniania designu, ponieważ kod HTML generowany
przez system, niepochodzący z samego szablonu, zazwyczaj nie może być zmieniany.
Kod taki przechowywany jest w plikach systemowych CMS-a i jest wstawiany w
odpowiednie miejsca szablonu podczas procesu generowania podstrony. Jakość szaty
graficznej strony jest czasem zależna od jakości tego typu kodu HTML (pomocne jest
jeśli elementy HTML posiadają liczne klasy, dzięki którym można się odwoływać do
tych elementów w stylach CSS). Poza ograniczeniami związanymi z designem,
niektóre systemy CMS mogą generować kiepskiej jakości kod HTML.
Uwaga: Osoby budujące stronę w oparciu o system CMS nie powinny zmieniać kodu HTML
osadzonego w plikach systemowych, ponieważ podczas aktualizacji CMS-a pliki te zostaną
zastąpione nowszymi wersjami, a wprowadzone zmiany przepadną.
• Ograniczenia nałożone na wpisywaną treść – Systemy CMS często ograniczają
możliwości wykorzystywania języka HTML w różnych formularzach. Rozsądne
wydawało by się jednak umożliwienie głównemu administratorowi strony wpisywania
27
dowolnego kodu HMTL do dowolnych pól umożliwiających edycję treści, czy to
artykułu czy informacji wyświetlanych w stopce strony.
Wada związana z pozycjonowaniem strony:
• SEO – Wiele systemów posiada ograniczoną funkcjonalność związaną z SEO. Na
szczęście niektóre wiodące systemy CMS, po zainstalowaniu specjalnych modułów i
dokonaniu pewnych ulepszeń stają się wręcz idealnymi sprzymierzeńcami w
pozycjonowaniu stron.
Wady związane z dokonywaniem gruntownych zmian:
• Trudność przeniesienia strony na inny serwer – Zmiana firmy hostingowej jest
mało wygodna ponieważ wymaga nie tylko przeniesienia plików strony ale także
wymaga wyeksportowania zawartości bazy danych, utworzenia bazy danych tego
samego typu na serwerze, na który przenoszona jest strona i na końcu zaimportowania
danych do nowej bazy. Należy też pamiętać o zgodności faktycznej nazwy bazy
danych, jej użytkownika i hasła z tymi ustawionymi w systemie CMS. Dla wielu osób
operacja tą jest zbyt skomplikowana i wymaga pomocy informatyka. Przenoszenie
statycznej strony www jest zdecydowanie prostsze.
• Przebudowywanie strony opartej na systemie CMS może pochłonąć dużo czasu –
Przebudowa taka pochłonie bardzo dużo czasu zwłaszcza jeśli część wcześniejszych
rozwiązań wykonana była bez dokładnego przemyślenia. Jeśli w oparciu o
wcześniejsze kiepskie rozwiązanie utworzonych zostało wiele podstron (lub np.
wgranych zostało wiele zdjęć) przerobienie dawnego rozwiązania na nowe może być
bardzo czasochłonne (a co za tym idzie – kosztowne, jeśli nie robimy tego samemu).
Równie skomplikowana i kosztowna jest zmiana jednego CMS-a na inny, przy
założeniu, że strona której zmiana dotyczy posiada już pokaźną liczbę podstron (np.
200 lub 1000).
• Konieczność wyszkolenia personelu – Jeżeli system CMS jest wykorzystywany
przez firmę tworzącą strony www, to wyszkolenie nowych programistów tak aby
28
umieli sprawnie i szybko posługiwać się CMS-em oraz korzystać z jego API12 w celu
pisania dodatkowych modułów, może okazać się czasochłonne i kosztowne. Dlatego
każdy solidny system zarządzania treścią musi posiadać bogatą dokumentację.
• Konieczność wyszkolenia redaktorów – strony robione na zamówienie i oparte na
systemach CMS wymagają również wyszkolenia klientów zamawiających stronę w
obsłudze systemu zarządzania treścią.
• Konieczność moderowania treści wpisywanej przez użytkowników – Strony oparte
na systemach CMS, umożliwiające użytkownikom np. komentowanie artykułów
wymagają moderowania treści w celu usuwania tych wpisów, które są bezwartościowe
i irytujące zarówno z punktu widzenia twórców strony jak i jej użytkowników.
Przykłady to np. reklamy w komentarzach (czyli tzw. spam) niezależnie od tego czy
były wpisane przez ludzi czy przez boty, treści niecenzuralne lub chociażby
niezwiązane z tematem strony. Usuwanie i moderowanie tego typu treści na często
odwiedzanych stronach pochłania wiele czasu i w związku z tym także pieniędzy.
Nieraz może stać się konieczne zatrudnienie osoby, której jedynym zadaniem będzie
ciągłe usuwanie niechcianych komentarzy.
• Ewentualne błędy autorów i redaktorów widoczne są od razu –Przykładem może
być redaktor edytujący powitanie na stronie głównej – w przypadku zapisania
powitania z błędem, będzie ono widoczne dla wszystkich użytkowników dopóki błąd
nie zostanie poprawiony. Na szczęście większość CMS-ów umożliwia dokonanie
podglądu przed opublikowaniem zaktualizowanej wersji. Poza tym, co ciekawe,
niektóre CMS-y posiadają funkcję zapisywania aktualizowanego artykułu jako nowa
wersja-rewizja dzięki czemu w przypadku np. niechcianego usunięcia części jego
treści można przywrócić wcześniejszą wersję.
• Dłuższy czas realizacji strony – Utworzenie rozbudowanej strony opartej na systemie
CMS i posiadającej własny niepowtarzalny wygląd w większości przypadków zajmie
więcej czasu niż utworzenie tej samej strony bez systemu CMS.
12 API – Aplication Programming Interface – Interfejs Programowania Aplikacji, umożliwia komunikację z aplikacją. Dzięki API możliwe jest tworzenie programów korzystających z zasobów i funkcji wbudowanych w aplikację. Więcej na temat API przeczytać można pod adresem http://en.wikipedia.org/wiki/Application_programming_interface
29
• Wysoki koszt w przypadku skomplikowanych stron – W przypadku zamawiania
wymyślnych rozwiązań na własne potrzeby koszt może być bardzo wysoki ale później
i tak się nam zwróci ponieważ aktualizacji strony będzie można dokonywać samemu
więc nie będzie trzeba płacić za aktualizowanie treści i dodawanie nowych podstron.
1.4. PodsumowanieRozdział ten stanowił wprowadzenie do świata systemów CMS. Omówiłem wiele ważnych
rzeczy, których znajomość odgrywa istotną rolę podczas prac związanych z tworzeniem stron
www.
Nie ma wątpliwości, że aby osiągnąć sukces jako twórca stron internetowych, konieczne jest
umiejętne wykorzystywanie możliwości nowoczesnych technologii i znajomość dobrych
rozwiązań, takich jak niektóre systemy CMS.
Po przeczytaniu tego rozdziału powinno stać się jasne czym są systemy CMS, jakie są ich
wady i zalety, raz jakie są najważniejsze różnice pomiędzy dynamicznymi stronami opartymi
na systemach CMS, a tradycyjnymi statycznymi stronami HTML.
W następnym rozdziale zbadanych dokładnie zostanie kilka popularnych systemów
zarządzania treścią.
30
22. Porównanie wybranych systemów CMS typu
open source
W tym rozdziale przyjrzę się dokładnie kilku wybranym systemom CMS. Wiele osób
zastanawiających się nad rozpoczęciem swojej przygody z systemami CMS nie wie od
jakiego systemu zacząć ponieważ nie ma wystarczającej wiedzy aby móc dokonać
właściwego wyboru. Rozdział ten może pomóc w podjęciu decyzji – zwłaszcza jeśli niepewna
osoba wahała się pomiędzy niektórymi z opisanych tu CMS-ów. Osoby zastanawiające się
nad zmianą systemu CMS na inny również zachęcam do przeczytania zawartych tu
informacji. Dla osób nieplanujących zmiany systemu CMS rozdział ten może być ciekawym
porównaniem i kto wie, może skłoni do przejścia na inny system niż aktualnie używany.
Wewnątrz rozdziału dokonamy porównania wybranych systemów zarządzania treścią pod
względem funkcjonalności oraz wielu innych cech m.in. takich jak prostota obsługi i
intuicyjność, jakość i poprawność generowanego kodu HTML czy solidność i łatwość
wykorzystywania API. Odniesiemy się również do cech opisanych w poprzednim rozdziale.
Porównamy możliwości wybranych systemów z możliwościami innych systemów CMS
istniejących na rynku. W ostatnim podrozdziale dokonamy testów wydajnościowych
wybranych systemów i porównamy ich wyniki.
2.1. Wybór systemów do porównaniaSystemy CMS podzielić można w zasadzie na dwie grupy: komercyjne i niekomercyjne,
gdzie większość systemów niekomercyjnych to oprogramowanie typu open source.
Podstawowa różnica pomiędzy programami open source a komercyjnymi polega na tym, że te
pierwsze są darmowe a za te drugie trzeba zapłacić. Aby pomóc dobrze zrozumieć oba
wymienione typy, dokonam teraz omówienia systemów CMS open source oraz
komercyjnych.
31
2.1.1. Komercyjne systemy CMSGłówna rzecz, która przychodzi na myśl odnośnie komercyjnych systemów CMS to fakt, że
systemy te są płatne. Ceny takich systemów mogą być bardzo różne począwszy od około
1000 zł a na kliku set tysiącach skończywszy. Dokonując zakupu płatnego CMS-a należy
jednak pamiętać, że jakość nie zawsze idzie w parze z ceną.
Oprócz potencjalnie wysokich kosztów samego systemu należy pamiętać również o innych
dodatkowych kosztach:
• W przypadku komercyjnych systemów, prawie wszystkie dodatkowe moduły i
ulepszenia dla nich przeznaczone, również są płatne.
• Każdy system CMS wymaga aktualizowania go do nowszych wersji. O konieczności
wykonywania aktualizacji pisałem w poprzednim rozdziale. Systemy komercyjne
zazwyczaj posiadają w ramach ich zakupu roczny abonament umożliwiający ściągane
paczek aktualizacyjnych. Po upływie abonamentu należy opłacić kolejny okres
abonamentowy.
Choć systemy komercyjne wiążą się z wieloma wydatkami będącymi nieraz poza zasięgiem
właściciela strony www, to posiadają one pewne zalety, których nie znajdziemy w systemach
darmowych.
Główną zaletą jest solidne wsparcie techniczne. Dzięki temu system taki może być świetnym
rozwiązaniem dla firm posiadających odpowiedni budżet i wymagających szybkiego czasu
reakcji wsparcia technicznego w przypadku problemów ze stroną bądź np. konieczności jej
dynamicznej rozbudowy. Ponieważ systemy komercyjne są płatne, co w pewnym sensie jest
ich wadą, muszą posiadać inne cechy, którymi będą przewyższać systemy darmowe. Jeżeli
coś nie działa – wsparcie techniczne ma obowiązek szybko pomóc w rozwiązaniu problemu.
Ponadto komercyjne systemy CMS posiadają zazwyczaj bogatszą, bardziej przemyślaną
dokumentację. Informacje umieszczane w takiej dokumentacji są bardziej logicznie ułożone
co ułatwia szybkie poznawanie CMS-a. Oprócz dokumentacji wiele komercyjnych CMS-ów
jest sprzedawanych razem z kursem szkoleniowym. Dotyczy to zwłaszcza droższych
systemów.
Wiele tych CMS-ów zawiera wbudowane funkcje, które zazwyczaj wystarczą aby zbudować
zaprojektowaną wcześniej witrynę. Dzięki temu nie ma potrzeby doinstalowywania
32
jakichkolwiek dodatkowych modułów czy plugin-ów. W przypadku systemów open source
niestety zazwyczaj tak nie jest.
Twórcy płatnych systemów CMS aby zapewnić większą atrakcyjność swojego
oprogramowania, zazwyczaj bardzo dbają o to, aby CMS był przyjazny dla użytkownika,
nawet takiego, który nie posiada żadnej wiedzy informatycznej. W efekcie te systemy są
zazwyczaj łatwiejsze w obsłudze. Gdyby nie powyższa cecha komercyjne systemy
zarządzania treścią miały by bardzo nikłe szanse w rywalizacji z darmowymi systemami open
source. Dlaczego? Wyobraźmy sobie trudny w obsłudze płatny system CMS o nazwie „A”
oraz jego konkurenta w postaci darmowego i zarazem łatwego w obsłudze systemu o nazwie
„B”. Dla mnie oczywistym wyborem jest system „B”. Zmniejszmy jeszcze wsparcie
techniczne dla systemu „A” do minimum a zapewniam, że system ten zniknął by z rynku dość
szybko.
Niektórzy uważają też, że posiadanie płatnego systemu CMS daje nam pewność, że za kilka
lat nadal będzie on rozwijany. Osobiście uważam, że nie można aż tak tego uogólniać.
Systemy CMS tworzone przez wielkie korporacje faktycznie gwarantują pewną przyszłość.
Jednak płatne systemy tworzone przez nieduże firmy wcale nie dają większej pewności co do
przyszłości tych systemów niż wiodące systemy open source. Sporo darmowych systemów
jest wspierana przez tysiące ludzi tworzących społeczeństwo stale rozwijające swój system.
Ponadto część systemów open source jest też stale dofinansowywana przez firmy
wykorzystujące te systemy podczas tworzenia stron www dla swoich klientów.
Komercyjne systemy CMS posiadają także pewne wady. Istotnym problemem może okazać
się niewielkich rozmiarów społeczność. Przyczynia się to do słabszego wsparcia ze strony
społeczności oraz zmniejsza ilości praktycznych informacji publikowanych na forach
dyskusyjnych.
Płatne systemy CMS zazwyczaj nie oferują takiej ilości dodatków i modułów jak systemy
darmowe. Komercyjne systemy CMS posiadają wiele wbudowanych, przemyślanych funkcji,
ale gdy potrzeba dodać do systemu jakąś wyszukaną funkcjonalność, może okazać się, że
trzeba zaimplementować ją od podstaw. Systemy te posiadają również inne licencje niż
systemy darmowe. Licencje te w znacznym stopniu ograniczają prawa użytkownika,
związane np. z rozprowadzaniem elementów strony bądź systemu, co dla osób planujących
33
np. udostępniać do pobrania kopie wykonanej aplikacji www może być nie do
zaakceptowania.
2.1.2. Systemy CMS typu open sourceIdea oprogramowania typu open source opiera się na trzech zasadach:
• Oprogramowanie open source jest darmowe
• Kod źródłowy jest dostępny dla wszystkich.
• Programy open source można dowolnie modyfikować pod warunkiem, że ich
modyfikacje nadal pozostaną oprogramowaniem open source.
Oprogramowanie tego typu często określane jest „wolnym oprogramowaniem” właśnie ze
względu na to, że każdy może nie tylko korzystać ze tego oprogramowania ale także
modyfikować je i dystrybuować kod źródłowy, który został wykorzystany w jego utworzenia.
Zasady te są chronione specjalną licencją. Oprogramowanie open source jest często
współtworzone przez wiele osób, które poświęcają swój wolny czas na pisanie kodu. Dziś
całkiem sporo firm nie traktuje oprogramowania jako głównego źródła dochodu – zarabianie
pieniędzy odbywa się poprzez sprzedawanie usług wsparcia technicznego związanego z
wolnym oprogramowaniem.
CMS-y typu open source, oprócz ceny posiadają wiele zalet. Zerowy koszt powoduje, że
bardo wiele osób chętnie przyłącza się do społeczności tych CMS-ów. Dzięki temu fora
dyskusyjne wręcz przepełnione są od ilości postów, ciekawych informacji i porad.
Wzrastająca ilość użytkowników przyczynia się także do zwiększenia zapotrzebowania na
ulepszenia i dodatkowe funkcje. W rezultacie wiele osób podejmuje się wspierania CMS-ów
open source poprzez pisanie dodatkowych modułów i plugin-ów – a co najważniejsze,
większość z nich jest darmowa. Ilość dodatków w przypadku wiodących darmowych
systemów CMS wynosi zazwyczaj po kilka tysięcy. Dzięki temu wiele funkcji, które mogą
być wymagane podczas tworzenia wymyślnej strony, zostało już zaimplementowanych.
Podczas tworzenia nowej strony www, przed podjęciem się implementowania czegoś od
podstaw, warto zawsze sprawdzić czy ktoś inny już tego wcześniej nie zrobił.
34
Dla osób i firm zajmujących się tworzeniem stron www na zamówienie „darmowość” CMS-a
może być istotna pod tym względem, że umożliwia zaproponowanie klientowi niższej ceny,
nie zawierającej kosztów samego systemu CMS.
Niestety w przypadku systemów open source domyślna paczka, w przeciwieństwie do
komercyjnych CMS-ów, jest zazwyczaj niewystarczająca. W takiej sytuacji konieczne jest
dociąganie dodatkowych modułów. Jeżeli nie wiemy jak nazywają się moduły zapewniające
potrzebnych brakujących funkcji to musimy ich szukać. Poza tym może też się zdarzyć, że
dwa ściągnięte moduły nie są ze sobą kompatybilne. Mogą pojawić się wtedy dziwne błędy
na stronie lub strona może zupełnie przestać działać.
Z powyższego problemu wynika kolejny: czas realizacji strony opartej na systemie
zarządzania treścią open source jest zazwyczaj dłuższy niż w przypadku korzystania z
komercyjnych rozwiązań. Konieczne może też okazać się większe doświadczenie w
korzystaniu z CMS-a oraz w sposobach konfiguracji wyglądu witryny.
Systemy open source działają w oparciu o tworzącą je społeczność użytkowników. Wsparcie
techniczne w zasadzie ogranicza się do for internetowych i blogów. Często można skorzystać
z płatnej pomocy niektórych doświadczonych użytkowników jednak nadal nie ma podmiotu
odpowiedzialnego za poprawną prace systemu ponieważ oprogramowanie open source jest
dostarczane na zasadach „as is”13. W związku z tym organizacje szukające systemu z
solidnym wsparciem technicznym powinny wybierać spośród systemów komercyjnych.
Oprócz wyżej wymienionych problemów, darmowe systemy zarządzania treścią posiadają
zazwyczaj ubogą lub nieprofesjonalnie napisaną dokumentację, która może okazać się
niewystarczająca lub nieodpowiednia aby szybko i sprawnie rozpocząć korzystanie z nowego
systemu.
Szkolenia w zakresie darmowych systemów CMS są organizowane ale trzeba za nie płacić.
2.1.3. Wybór systemów do porównaniaPodsumowując przed chwilą wymienione cechy komercyjnych i darmowych systemów
zarządzania treścią, najważniejsze różnice dotyczą:
13 As is – w odniesieniu do oprogramowania określenie to oznacza, że zostało ono udostępnione z wykluczeniem odpowiedzialności jego autorów. Więcej na ten temat: http://en.wikipedia.org/wiki/As_is
35
• Ceny
• Czasu tworzenia strony www
• Jakości dokumentacji oraz dostępności szkoleń
• Wsparcia technicznego
• Możliwości rozbudowy systemu
Większość wykorzystywanych systemów CMS to systemy darmowe. Korzystają z nich
zarówno osoby prywatne czy organizacje, jak i małe, średnie i duże firmy. Do firm
korzystających z systemów CMS typu open source zaliczają się także wielkie korporacje takie
jak Adobe, IBM, Sun, Symantec, Sony czy chociażby Universal.
Systemy CMS open source są w zasięgu możliwości finansowych każdej osoby i firmy.
Dlatego CMS-y wybrane do porównania wszystkie należą do tej właśnie grupy.
Po zawężeniu kryteriów wyboru do grupy wolnego oprogramowania dalsze decyzje były
proste. Ponieważ praca ta ma być przydatna dla jak największej grupy odbiorców, wybrane
zostały te systemy, które cieszą się niepodważalnie największą popularnością wśród
systemów open source. Wybór padł na 3 systemy:
• WordPress – http://www.wordpress.org
• Joomla – http://www.joomla.org
• Drupal – http://www.drupal.org
2.2. Krótko o wybranych systemach CMSWybór systemów CMS do porównania może dla niektórych osób wydawać się
kontrowersyjny. Podkreślam, że nie oznacza on jednak, że wybrane systemy to trzy najlepsze
darmowe CMS-y jakie istnieją na rynku open source. Ogromna liczba użytkowników tych
systemów także jest nie bez znaczenia. To właśnie ze względu na ich popularność
postanowiłem dokładnie omówić je w tej pracy. Zanim jednak przejdziemy do ich omawiania
i porównywania, poznajmy historię każdego z nich.
2.2.1. WordPress
36
W 2001 roku Michel Valdrighi utworzył system CMS b2/cafelog służący do blogowania.
System ten był napisany w języku PHP i wykorzystywał bazę danych MySQL14. Dwa lata
później był on już wykorzystywany do obsługi około 2000 blogów i stał się dobrze
rozpoznawany pod skróconą nazwą b2. Gdy w 2003 roku Michel ogłosił, że system
zaprzestaje rozwijania systemu b2, do akcji wszedł Matt Mullenweg.
Używał on platformy b2 jako głównego systemu do blogowania na swojej stronie. Gdy
usłyszał, że b2 nie będzie już rozwijane ogłosił w 2003 roku na swoim blogu, że zamierza
utworzyć własny system blogowania oparty na kodzie systemu b2. Wkrótce skontaktował się
z nim Mike Little i niewiele później zaczęli pracować nad utworzeniem nowego systemu
CMS zgodnego ze standardami www i spełniającego wszystkie ich potrzeby.
Rysunek . Logo systemu WordPress
System WordPress w swojej pierwszej wersji 0.70 pojawił się 27 maja 2003 roku jako efekt
wspólnej pracy Matt-a Mullenweg-a i Mike-a Little. Nazwa WordPress została
zaproponowana przez Christine Selleck, przyjaciółkę Matt-a. Nr wersji wziął się stąd, że była
to aktualizacja istniejącej już wersji 0.62 systemu b2. Była to aktualizacja, na którą czekało
wiele osób. Zapewniała ona także zgodność z XHTML 1.1, posiadała nowe domyślne
szablony i nowy interfejs administracyjny.
W 2004 roku firma informatyczna Six Apart zmieniła zasady licencjonowania
współzawodniczącego z WordPress-em systemu Movable Type co spowodowało
przeniesienie się wielu użytkowników na system WordPress. Efektem było szybkie
zwiększanie się jego popularności.
W 2004 roku wyszła wersja 1.0. Od tej pory wszystkie wersje systemu WordPress miały
nazwy kodowe zaczerpnięte od sławnych twórców muzyki Jazzowej15.
14 MySQL – relacyjna baza danych, często wykorzystywana w aplikacjach internetowych napisanych w języku PHP. http://www.mysql.com/. Więcej na temat MySQL również w dalszej części rodziału.
15 Więcej na temat nazw kodowych systemu WordPress przeczytać można na stronie http://en.wikipedia.org/wiki/WordPress#Releases
37
Do pracy nad rozwijaniem systemu WordPress przyłączyło się wiele osób, wliczając w to
samego Michel-a Valdrighi. System był stale rozbudowywany i ulepszany, a jego popularność
wzrastała bardzo szybko. W 2006 roku paczka zawierająca system WordPress została
ściągnięta ze swojej strony domowej 1 545 703 razy, a w 2007 roku 3 816 965 razy. W 2006
roku 371 dodatkowych modułów pobrano 191 567 razy, a w 2007 ilość różnych pobranych
dodatków wzrosła do 1384 z ilością pobrań na poziomie 2 845 884.
38
2.2.2. Joomla!W 2000 roku w Melbourne powstała firma Miro Construct Pty Ltd. Od początku firma ta
zajmowała się rozwijaniem systemu zarządzania treścią o nazwie Mambo. W 2001 roku Miro
opublikowała system Mambo na licencji GPL czyniąc z niego oprogramowanie open source.
2 lata później firma zmieniła nazwę na Miro International Pty Ltd.
W 2005 roku firma Miro założyła niedochodową fundację Mambo Fundation mającą na celu
finansowanie projektu Mambo i jego ochronę prawną. Niestety duża cześć deweloperów
uważała, że wiele zasad i działań Fundacji było niezgodnych z wcześniej ustalanymi
zasadami. Ponadto nowe zasady były ustanowione bez ich wcześniejszego uzgodnienia z
najważniejszym posiadaczami akcji oraz były niezgodne z ideą oprogramowania open source.
W efekcie główni deweloperzy odeszli z firmy Mambo aby wspólnie tworzyć nowy system
CMS open source. Założyli oni też stronę www nazwaną OpenSourceMatters.org, którą
wykorzystywali w celu informowania użytkowników, designerów i społeczności.
Przewodniczący grupy, Andrew Eddie „MasterChief”, napisał otwarty listy do społeczności i
opublikował go na publicznym forum na mamboserver.com. W ciągu jednego dnia nieco
ponad tysiąc osób dołączyło do społeczności opensourcematters.org, ogłaszając poprzez posty
na forum chęć wspierania projektu. Odwiedzin było tak dużo, że strona
opensourcematters.org stała się niedostępna z powodu efektu slashdot.
Szef firmy Miro, Peter Lamont, w odpowiedzi na odejście deweloperów Mambo opublikował
artykuł „The Mambo open source controversy – 20 questions with Miro”16. Zdarzenie to
wzbudziło wiele kontrowersji i dyskusji dotyczących definicji oprogramowania open source.
Na forach internetowych inne projekty open source wyrażały swoje sprzeciwy i poparcia dla
obu stron.
1 września 2005 ogłoszono nową nazwę dla systemu CMS – Joomla! Nazwa ta wywodzi się z
angielskiej wymowy słowa „jumla” należącego do języka suahili i oznaczającego „wszyscy
razem”.
16 Post The Mambo open source controversy – 20 question with Miro dostępny jest na http://forum.joomla.org/viewtopic.php?f=48&t=3037
39
Rysunek . Logo systemu Joomla!
6 września 2005 zespół twórców systemu Joomla! ogłosił konkurs na logo oraz umożliwił
społeczności podjęcie decyzji poprzez głosowanie. 22 września 2005 nowe logo było już
wybrane.
Pierwsza wersja systemu Joomla! (wersja 1.0.0) została opublikowana 16 września 2005
roku. System Joomla! był wtedy nową odsłoną Mambo 4.5.2.3, który został dodatkowo
ulepszony poprzez dodanie poprawek oraz załatanie różnych luk związanych z
bezpieczeństwem.
2.2.3. DrupalW latach 1998 i 1999 dwaj studenci Uniwersytetu Gandawskiego w Belgii, Dries Buytaert i
Hans Snijder, zainteresowani nowymi wtedy jeszcze sieciami bezprzewodowymi postanowili
zbudować bezprzewodową sieć LAN aby współdzielić internetowe stałe łącze Hans-a
pomiędzy studentami mieszkającymi w różnych pokojach. Ponieważ potrzebne było coś co
umożliwiło by łatwą wzajemną komunikację i wymianę informacji dotyczących wspólnej
sieci, uczelnianych nowości bądź planów na najbliższe dni, Dries postanowił utworzyć proste
forum. Forum to zostało udostępnione w studenckiej sieci LAN. Po ukończeniu studiów Dries
postanowił opublikować swoje forum jako witrynę internetową dostępną dla wszystkich
znajomych dzięki czemu on i jego koledzy ze studiów mogli by między innymi łatwo
utrzymywać kontakt.
Początkowo Dries chciał zarejestrować nową domenę wykorzystując holenderskie słowo
„dorp” co oznacza małą wioskę. Wydawało się ono odpowiednią nazwa dla strony
obsługującej tak niedużą grupę osób. Podczas sprawdzania czy domena jest wolna popełnił
jednak błąd ortograficzny i zamiast „dorp” wpisał „drop”. Nazwa ta spodobała się mu
postanowił zarejestrować domenę Drop.org.
Po upływie prawie roku, w okolicach roku 2000 i 2001, forum dostępne pod adresem
Drop.org cieszyło się dużym zainteresowaniem. Duża liczba odwiedzających dyskutowała na
tematy związane z nowymi rozwiązaniami takimi jak np. moderowanie treści, kanały RSS,
ocenianie postów czy nowe metody uwierzytelniania. Drop.org powoli zamieniał się w
40
napędzane dyskusjami środowisko do prowadzenia eksperymentów. Omawiane nowe
pomysły były wypróbowywane na działającej stronie.
Równolegle ze wzrostem zainteresowania oprogramowaniem forum zwiększała się ilość
próśb o dodawanie nowych funkcji.
Pod koniec stycznia 2001, Dries zadecydował, że opublikuje oprogramowanie obsługujące
Drop.org jako „Drupal”. Dzięki temu inny użytkownicy mogli używać i rozbudowywać tą
eksperymentalną platformę oraz więcej osób mogło wspólnie pracować nad jej ulepszaniem.
Nazwa „Drupal” wywodzi się z holenderskiego słowa „druppel” co jest równoznaczne z
angielskim słowem „drop” oznaczającym kroplę.
26 kwietnia 2001 uruchomiona została witryna Drupal.org.
Po ustaleniu nowej nazwy przyszedł czas na zaprojektowanie logo. Jeden z początkowych
pomysłów, zaproponowany przez Steven-a Wittens-a, przedstawiał logo jako rysunkową
kroplę z twarzą. Ponieważ jego projekt był grafiką 3D, więc logo to nie było wystarczająco
przejrzyste.
Rysunek . Logo systemu Drupal
Nieco później Kristjan Jansen wymyślił aby połączyć dwie krople razem w taki sposób aby
utworzyły one znak nieskończoności. Umieszczony znak w środku koła przypominał twarz.
Po ostatecznym dopracowaniu logo systemu Drupal zostało ukończone: kropla z oczami
przypominającymi znak nieskończoności, nosem i lekkim uśmiechem.
2.3. Porównanie możliwości i ograniczeń wybranych systemów CMS
Pomysł na opracowanie porównania zawartego w tym rozdziale był głównym powodem dla
którego powstała ta praca. Pierwotny plan zakładał napisanie samego porównania systemów
CMS, dopiero później pojawiły się kolejne pomysły na wzbogacenie treści. Bardzo chciałem,
41
aby teksty były na tyle przystępne aby z łatwością dawały się czytać także osobom o naturze
nietechnicznej – stąd takie długie wprowadzenie do tematyki CMS-ów.
Wybrane wcześniej systemy biorące udział w porównaniu występują w różnych wersjach. Na
warsztat wzięte zostały następujące wersje tych systemów
• WordPress - wersja 3.0
• Joomla! - wersja 1.5 i 1.6 alpha
• Drupal – wersja 6 i 7 alpha
Porównywanie systemów zarządzania treścią zostało podzielone na cztery kategorie, dzięki
którym można było lepiej uporządkować porównania odpowiednich cech CMS-ów. Te
kategorie to:
• Cechy podstawowe
• Zaawansowane cechy i funkcje
• Pozostałe cechy
2.3.1. CECHY PODSTAWOWENiniejsza kategoria zawiera opisy i porównania dotyczące podstawowych cech i funkcji
systemów zarządzania treścią. Większość zaprezentowanych właściwości będzie istotna dla
wszystkich użytkowników posiadających lub decydujących się na instalację systemu CMS.
Łatwość instalacjiNie da się rozpocząć przygody z systemem CMS bez jego wcześniejszej instalacji, czy to
wykonanej samemu czy przez kogoś innego17. Ponieważ osobami korzystającymi z takich
systemów mogą być zarówno informatycy, designerzy jak i zwykli użytkownicy
nieposiadający wiedzy technicznej, instalacja powinna być łatwa i szybka.
Wszystkie trzy opisywane systemy CMS do poprawnej instalacji i uruchomienia wymagają
środowiska zawierającego zainstalowane następujące składniki:
17 niektóre firmy hostingowe udostępniają także skrypty automatyzujące instalację najpopularniejszych systemów CMS, w tym WordPress-a, Jooml-ę i Drupal-a
42
• PHP – Nazwa PHP jest akronimem od PHP Hypertext Preprocessor. Jest to język, w
którym napisane zostały porównywane CMS-y. PHP jest wykorzystywane w
Internecie przez multum różnorakich projektów i jest znane ze swojej łatwości
korzystania. Strona domowa języka PHP jest dostępna pod http://www.php.net
• Apache – Czyli serwer www, którego zadaniem jest przesyłanie stron www w
odpowiedzi na żądania przeglądarki użytkownika. Apache jest najpopularniejszym
serwerem www w Internecie, ale wiele innych alternatywnych serwerów (takich np.
jak Idea używana przez firmę Home.pl) także nada się na potrzeby opisywanych
systemów. Serwer Apache jest dostępny do pobrania na stronie http://www.apache.org
• MySQL – Oprogramowanie bazy danych, która będzie używana w celu
przechowywania wszystkich informacji potrzebnych do poprawnego funkcjonowania
systemu CMS i wspieranej przez niego witryny. Strona domowa bazy danych MySQL
to http://www.mysql.com. Uwaga: System Drupal obsługuje także bazę danych
PostrgreSQL.
Większość firm hostingowych zapewnia środowisko zawierające już wszystkie powyższe
składniki.
Środowisko takie można również zainstalować sobie lokalnie na własnym komputerze dzięki
czemu można testować systemy CMS bez korzystania z zewnętrznej firmy hostingowej.
Użytkownicy systemu Windows mogą skorzystać z gotowego pakietu XAMPP, zawierającego
m.in. PHP, Apache i MySQL. Pakiet ten można pobrać ze strony
http://www.apachefriends.org.
Dokładne wymagania stawiane przez wybrane systemy CMS dostępne są na ich stronach
domowych.
WordPress
Instalacja systemu WordPress wymaga pobrania plików tego CMS-a ze strony
http://www.wordpress.org. Po rozpakowaniu zawartości paczki i umieszczeniu plików w
katalogu serwera, konieczne jest utworzenie bazy danych w której WordPress będzie mógł
przechowywać wszystkie dane. Następnie wchodzimy w przeglądarce na adres naszego
serwera. Ten podstawowy krok jest identyczny dla wszystkich trzech porównywanych
systemów CMS.
43
Wyświetlona zostanie pierwsza strona instalatora systemu WordPress i zostaniemy poproszeni
o utworzenie pliku konfiguracyjnego poprzez wciśniecie przycisku widocznego na stronie.
Kolejny krok wyjaśnia jakie informacje są potrzebne aby skonfigurować system CMS do
pracy z bazą danych. Na następnej stronie kreatora instalacji pojawia się formularz w którym
należy wpisać dane dostępu do bazy danych. Wadą tego formularza jest nieukrywanie znaków
wpisywanego hasła, czego trzeba być świadomym w sytuacji gdy instalujemy system w
towarzystwie innej osoby.
Rysunek . Jeden z kroków instalatora systemu WordPress 3.0. Instalator ten cechuje przejrzystość i elegancja.
44
Po przygotowaniu tabel w bazie danych i umieszczeniu w nich odpowiednich informacji,
konieczne jest wypełnienie kolejnego formularza, w którym należy podać nazwę dla nowej
strony www oraz login i hasło, które chcielibyśmy przypisać kontu administracyjnemu nowej
witryny.
Instalator systemu WordPress jest przejrzysty, wygodny i łatwy w obsłudze a wszystkie kroki
i pola formularzy są dobrze opisane. W przypadku niepoprawności wpisywanych danych
system wyświetla stosowne komunikaty. Formularz wstępnej konfiguracji witryny na bieżąco
wyświetla informacje o sile i ewentualnej niezgodności hasła dla konta administratora. Udane
zakończenie instalacji jest potwierdzane wyraźnym komunikatem.
Aby zainstalować system WordPress w innej wersji językowej niż domyślna Angielska należy
pobrać gotowy pakiet instalacyjny w odpowiednim języku. Pakiety te są dostępne m.in. na
oficjalnej stronie systemu. Dla przykładu w celu pozyskania polskiej wersji językowej należy
przejść pod adres http://pl.wordpress.org. Innym sposobem jest pobranie pliku *.mo i
umieszczenie go w odpowiednim podfolderze systemu WordPress. Aby system zastosował
nowy język interfejsu użytkownika należy wtedy dokonać odpowiednich zmian w pliku wp-
config.php.
Joomla
Po pobraniu paczki instalacyjnej i umieszczeniu zawartych w niej plików na serwerze
przechodzimy pod adres www tego serwera. W przeglądarce pojawi się nam widok
pierwszego kroku instalatora systemu Joomla! Krok ten umożliwia wybranie języka w którym
prezentowane będą opisy kolejnych etapów instalatora. Po dokonaniu wyboru i wciśnięciu
dziwnie położonego przycisku „Next” przedstawione zostanie podsumowanie serwera na
którym instalujemy system CMS. Dzięki niemu jeszcze przed rozpoczęciem instalacji
dowiadujemy się które ewentualne wymagania nie są spełnione.
W następnym kroku wyświetlona zostaje treść licencji GPL.
Kolejny ekran zawiera formularz konfiguracji bazy danych – dla Joomli 1.5 był on mało
przejrzysty z uwagi na przepych tekstu. W wersji 1.6 zostało to poprawione aczkolwiek
formularz ten nadal nie jest zbyt elegancki i swoją przejrzystością nie dorównuje temu z
instalatora systemu WordPress. Istotną zaletą instalatora systemu Joomla! jest jego zdolność
do utworzenia nowej bazy danych. Aby skorzystać z tego udogodnienia wystarczy wpisać w
45
odpowiednim polu nazwę nieistniejącej bazy a zostanie ona za nas utworzona. Dzięki temu
nie trzeba przygotowywać bazy danych ręcznie przed rozpoczęciem instalacji.
Następny krok jest związany z konfiguracją konta FTP, z którego system Joomla! może
korzystać w celu poprawienia możliwości zarządzania plikami na serwerach opartych na
systemie z rodziny Unix bądź Linux. W przypadku instalacji na systemie Windows obsługa
plików przez FTP jest zbyteczna.
Ostatni krok instalatora umożliwia dokonania wstępnej konfiguracji czyli ustawienia nazwy
nowej witryny oraz podania danych logowania, które zostaną wykorzystane w celu
utworzenia konta administratora.
Rysunek . Krok instalatora systemu Joomla 1.6 umożliwiający dokonania wstępnej konfiguracji.
Instalator systemu Joomla jest dość wygodny i prosty w obsłudze aczkolwiek brakuje mu
przejrzystości napotkanej podczas korzystania z instalatora systemu WordPress. Wszystkie
kroki i pola formularzy są dokładnie opisane choć opisy te są mało czytelne. W przypadku
podania niepoprawnych danych wyświetlane są odpowiednie komunikaty informujące o
rodzaju błędu. Udane zakończenie instalacji jest potwierdzane stosownym komunikatem.
Równocześnie razem z potwierdzeniem udanej instalacji wyświetlana jest informacja o
konieczności usunięcia katalogu instalacyjnego z folderu systemu Joomla!
46
Odnośnik do informacji o możliwości używania systemu Joomla! w innej wersji językowej
niż domyślna angielska jest widoczny na dole strony z potwierdzeniem. Paczki zawierające
tłumaczenia systemu Joomla! dostępne są do ściągnięcia na stronie
http://community.joomla.org/translations.html.
Drupal
Pierwsze co pojawia się po otwarciu instalatora systemu Drupal to informacja o możliwości
instalacji systemu CMS w innej wersji językowej niż domyślna angielska. Wyświetlony tu
zostaje także link do strony, na której można przeczytać na temat sposobu dodawania innego
języka.
Przykładowo aby zainstalować system Drupal w języku polskim wystarczy ściągnąć paczkę
dostępną pod adresem http://drupal.org/project/pl i rozpakować jej zawartość do głównego
folderu plików Drupala na serwerze.
47
Rysunek Jeden z kroków instalatora systemu Drupal (fragment widocznego formularza został wycięty w celu zmniejszenia rozmiarów obrazka).
W kolejnym kroku instalator wyświetla podsumowanie serwera na którym instalujemy system
i sprawdza czy wymogi systemu są spełnione. Na tym etapie większość użytkowników
zobaczy informację o błędzie polegającym na braku pliku konfiguracyjnego w folderze
instalacji. Należy przejść do odpowiedniego podkatalogu na serwerze, utworzyć kopię pliku
default.settings.php i nazwać ją settings.php. Rozwiązanie to nie jest specjalnie wygodne ale
dzięki niemu zapewnione jest większe bezpieczeństwo serwera i znajdujących się już na nim
plików. Drupal jako jedyny uniemożliwia osobom niepowołanym instalację systemu, którego
pliki instalacyjne zostały już umieszczone na serwerze ale instalacja nie była jeszcze
wykonana.
48
Po utworzeniu pliku settings.php i przejściu do kolejnego kroku, pojawia się słynny już
formularz konfiguracji połączenia z bazą danych. Formularz ten jest przejrzysty oraz dobrze
opisany, choć nieco długi.
Po udanym połączeniu z bazą danych i zainstalowaniu wszystkich potrzebnych tabel,
wyświetlony zostaje formularz wstępnej konfiguracji strony. Ideowo nie różni się on
specjalnie od formularza pozostałych dwóch systemów CMS – umożliwia m.in. ustawienie
nazwy strony oraz wybór danych logowania do konto administratora.
Instalator systemu Drupal jest bardzo przejrzysty i łatwy w obsłudze. Wszystkie kroki
instalacji i pola formularzy są dobrze opisane. W przypadku podania niepoprawnych
wpisywanych danych system wyświetla stosowne komunikaty. Formularz wstępnej
konfiguracji witryny na bieżąco wyświetla informacje o sile i ewentualnej niezgodności hasła
dla konta administratora. Pomyślnie ukończona instalacja zasygnalizowana jest odpowiednim
komunikatem.
Wnioski
Wszystkie trzy omawiane systemy CMS posiadają instalatory proste i łatwe w obsłudze.
Instalator systemu Joomla jako jedyny umożliwia utworzenie bazy danych aczkolwiek pod
względem przejrzystości nie dorównuje on instalatorom pozostałych dwóch systemów.
Najbardziej przyjazny dla użytkownika jest przejrzysty instalator systemu WordPress,
aczkolwiek instalator systemu Drupal wydaje się być nieco bezpieczniejszy.
Funkcje wbudowaneDobry system CMS powinien posiadać pewien zbiór wbudowanych funkcji zwiększających
jego atrakcyjność i użyteczność. Wbudowane funkcje powinny między innymi:
• Umożliwiać łatwe i wygodne publikowanie i edytowanie treści
• Ułatwiać nawigację po stronie
• Zwiększać możliwości interakcji odwiedzających ze stroną
• Umożliwiać odwiedzającym łatwe śledzenie zmian na stronie
• Ułatwiać i upraszczać wykonywanie różnego typu zadań administracyjnych
49
Poniżej przedstawiona jest tabelka porównawcza zawierająca zestawienie funkcji
wbudowanych w trzy badane systemy CMS. Wymienione zostały tylko te funkcje, które
znajdują się co najmniej w jednym w badanych systemów.
Czerwonym znakiem przekreślenia oznaczone są funkcje niedostępne w podstawowej
dystrybucji systemu. Nie oznacza to, że funkcjonalności takich nie można osiągnąć poprzez
zainstalowanie dodatkowych modułów i rozszerzeń. W przypadku dostępności odpowiednich
modułów zostało to oznaczone „moduł dodatkowy”.
Funkcja/Cecha WordPress 3.0 Joomla! 1.6 Drupal 6 i 7ARTYKUŁY / POSTY / PODSTRONY
Lista najnowszych artykułów na stronie głównej,tylko „posty” wiele list,
bogata konfiguracjana stronie głównej,dowolne artykuły
Filtrowanie wpisywanych treści (np. pod względem znaczników HTML)
narzucone narzucone bogata konfiguracja
Edytor WYSIWYGTinyMCE TinyMCE moduł dodatkowy
Edytowanie kodu HTML
Możliwość umieszczania PHP w treści artykułu
moduł dodatkowy moduł dodatkowy
Podświetlanie i koloryzacja edytowanego kodu HTML
moduł dodatkowy edytor CodeMirror moduł dodatkowy
Rewizje artykułówmoduł dodatkowy
Ochrona przed równoległą edycją artykułu przez kilku użytkowników
częściowa
System workflowbardzo podstawowy moduł dodatkowy moduł dodatkowy
potężny
Zaplanowana automatyczna publikacjabardzo podstawowy moduł dodatkowy moduł dodatkowy
Opcja „Czytaj dalej” / skrót artykulu„excerpt” „read more” „teaser”
Opcja podziału artykułu na stronymoduł dodatkowy moduł dodatkowy
50
Nawigacja „następny” i „poprzedni”
Lista popularnych artykułów (często czytanych)
moduł dodatkowy moduł dodatkowy
Lista pokrewnych artykułówpoprzez kategorie poprzez kategorie
Prezentacja informacji o autorze artykułu
moduł dodatkowy moduł dodatkowy
Opcje publikacji (opublikowany, promowany na stronie głównej, itp.)
bogata konfiguracjaOpcje wyświetlania szczegółów artykułu (autor, kategorie, itp.)
Archiwum artykułówmoduł dodatkowy
Kosz z usuniętymi artykułamimoduł dodatkowy
Głosowanie / ocenianiemoduł dodatkowy moduł dodatkowy
Kategoryzacjawielopoziomowa wielopoziomowa wielopoziomowa
Chmura tagów (tag Cloud)moduł dodatkowy moduł dodatkowy
Lista artykułów należących do wybranej kategorii
Rozbudowana konfiguracja list prezentujących artykuły
moduły dodatkowe
Strona prezentująca hierarchię kategoriimoduł dodatkowy
Strona z podkategoriami artykułów z wybranej kategorii macierzystejHierarchiczne układanie postów jako rozdziałów książki
Definiowanie własnych pól danych w formularzu edycji artykułów
ograniczone moduł dodatkowy Drupal7,D6: mod. dodatkowy
Tworzenie podstrony, której zawartość wczytywana jest do <iframe>
moduł dodatkowy moduł dodatkowyKOMENTARZEKomentowanie artykułów
51
moduł dodatkowy
Lista najnowszych komentarzymoduł dodatkowy
Kolejka oczekujących do zatwierdzeniamoduł dodatkowy
MULTIMEDIA
Wgrywanie plików
Przeglądarka plików / Zarządzanie plikami
moduł dodatkowy
Flash uploadermoduł dodatkowy
Obsługa obrazów i wstawianie ich do artykułów Drupal 7,
D6: mod. dodatkowyOchrona plików przed pobieraniem ich przez nieuprawnionych użytkownikówZWIĘKSZANIE DOSTĘPNOŚCI TREŚCI
Syndykacja (np. RSS Feeds)
Wyszukiwarka i opcję wbudowanego indeksowania treści ograniczone
dodatkowy moduł
Przeszukiwanie kategorii i/lub użytkowników
moduł dodatkowy
Agregator RSS, RDF lub Atom i prezentacja pobranych treści
moduł dodatkowy
Kategoryzacja agregowanej treści i prezentacja wybranej kategorii
moduł dodatkowyAutomatyczne informowanie innych stron o nowościach / zmianachWYGLĄD
Menadżer zarządzania szablonami
Wyszukiwanie i automatyczne pobieranie nowych szablonów
Łatwość zmiany wyglądu strony
Łatwość zmiany wyglądu panelu administracyjnego
Definiowanie bloków wyświetlanych w pasku bocznym strony („sidebar”)
„widgets” „blocks”
52
Łatwa zmiana logo strony
Zmiana zdjęcia widocznego w nagłówku n/d
Łatwa zmiana nazwy strony
Ustawianie sloganu bądź misji strony
Łatwa zmiana treści stopki strony
Łatwe ustawianie widoczności pola tekstowego wyszukiwarki
Możliwość łatwej podmiany pliku ikonki strony („favicon”)
moduł dodatkowy moduł dodatkowy
Obsługa avatarów użytkownikówmoduł dodatkowy moduł dodatkowy
Włączanie i wyłączanie wyświetlania daty dodania artykułu
Zarządzanie kolorami witryny ograniczonemoduł dodatkowy
Edytor szablonówmoduł dodatkowy
NAWIGACJA
Zarządzanie nawigacją i menu
Breadcrumbsmoduł dodatkowy
Nawigacja po rozdziałach książki
UŻYTKOWNICYMożliwość umieszczenia na stronie bloku z formularzem logowania moduł dodatkowyUmożliwienie użytkownikom samodzielnej rejestracji
Automatyczne przypisywanie nowym użytkownikom określonej roli
moduł dodatkowyWysyłanie powiadomień o statusie konta, potwierdzenia emailReset hasła i/lub przypominanie nazwy użytkownika
Zarządzanie użytkownikami
Tworzenie i przypisywanie rólmoduł dodatkowy
53
Definiowanie uprawnień użytkownikówmoduł dodatkowy mocno ograniczone
Konfiguracja formularzy profili użytkowników
moduł dodatkowy moduł dodatkowy
Blokowanie dostępu na podstawie adresu IP lub adresu e-mail
moduł dodatkowy moduł dodatkowy
Logowanie przy użyciu OpenIDmoduł dodatkowy
Logowanie przy użyciu Google Idmoduł dodatkowy Drupal 7
Lista najnowszych użytkownikówmoduł dodatkowy
Informacja o użytkownikach dostępnych online
moduł dodatkowy
Użytkownicy mogą tworzyć własne menu z linkami do wybranych podstron Drupal 7,
D6: mod. dodatkowy
Prywatne wiadomości od innych użytkowników
moduł dodatkowy
Formularz kontaktowy lub strona z informacjami kontaktowymi
moduł dodatkowy
Zaawansowana konfiguracja systemu kontaktów
moduł dodatkowy
Masowe wysyłanie emaili od administratora do użytkowników
moduł dodatkowy moduł dodatkowy
Kategorie kontaktów
Lista osób należących do jednej kategorii kontaktów
moduł dodatkowyDODATKI
Sondy moduł dodatkowymoduł dodatkowy
Forum moduł dodatkowymoduł dodatkowy
Kalendarzmoduł dodatkowy moduł dodatkowy
54
Zarządzanie banerami i reklamamimoduł dodatkowy moduł dodatkowy
Poinformuj kogoś emailem o tej stronie moduł dodatkowymoduł dodatkowy
FUNKCJE ADMINISTRACYJNE
Wygodny panel kontrolny / dashboardbardzo porządny Drupal 7
Powiadamianie o dostępnych aktualizacjach
Automatyczne aktualizacjeDrupal 7
Statystyki, np. przeglądanych stron lub wystąpienia błędu 404
moduł dodatkowy moduł dodatkowyŚledzenie nowych postów użytkownikówLogowanie zdarzeń systemowych w bazie danychLogowanie zdarzeń systemowych w pliku dziennika serwera
Raport o stanie witryny
Informacje o systemie
Wbudowana pomocmocno ograniczona
SYSTEMŁatwe ustawianie zawartości strony głównej (np. na statyczną podstronę) Zarządzanie rozszerzeniami / modułami, instalowanie i odinstalowywanie
Wyszukiwarka rozszerzeń / modułów
Edytor rozszerzeń / modułów
Adresy URL przyjazne dla wyszukiwarek („mod_rewrite”)
Zarządzanie aliasami podstronograniczone ograniczone
Przekierowania aliasów, przekserowanie z brakujących stron
moduł dodatkowy moduł dodatkowy
55
Formaty datysłaba obsługa
Obsługa stref czasowych
Tryb maintenanceskomplikowana
obsługa
Ustawienia wydajności i cachingmoduł dodatkowy ograniczone
Autothrottling przyspieszający działanie witryn o dużym natężeniu ruchu
Ograniczanie dostępu do witrynyproste ulepszenie poprzez
moduły dodatkowe
Własne strony błędówmoduł dodatkowy
Meta tagi, np. „description” lub „keywords”
moduł dodatkowy moduł dodatkowyDefiniowanie wyzwalanych w odpowiednich momentach akcji
Ukrywanie adresów email przed spam botami
moduł dodatkowy moduł dodatkowy
Wysyłanie poczty poprzez dowolny serwer SMTP
moduł dodatkowy moduł dodatkowy
Narzędzia i opcje debugowaniamoduł dodatkowy ograniczone moduł dodatkowy
Publikowanie poprzez XML-RPCmoduł dodatkowy
Publikowanie poprzez emailmoduł dodatkowy moduł dodatkowy
Import / eksport danych z bazyczęściowy moduł dodatkowy moduł dodatkowy
WIELOJĘZYCZNOŚĆ
Podstawowe wsparcie dla wielojęzycznych stron
moduł dodatkowy moduł dodatkowy
56
Wielojęzyczny panel administracyjnymoduł dodatkowy
Formularz przeszukiwania i edycji tłumaczeń
Rozpoznawanie języka po adresie / domenie
moduł dodatkowy moduł dodatkowy
Przełącznik zmiany językamoduł dodatkowy
Poza wymienionymi wbudowanymi funkcjami porównywane systemy posiadają pokaźną
ilość dodatkowych modułów zapewniających im dodatkową funkcjonalność lub
usprawniających niektóre z wbudowanych funkcji. Dla poszczególnych systemów ilość
dodatkowych modułów wynosi (dane z lipca 2010)18:
• WordPress: 10 524
• Joomla: 5 360
• Drupal 6: 4 124
Dodatki do systemu WordPress określane są mianem wtyczek (plug-ins), do systemu Joomla mianem rozszerzeń (extensions), a do systemu Drupal mianem modułów (modules).
Warto tutaj zaznaczyć, że w odniesieniu do dodatkowych modułów liczy się ich jakość a nie
ilość.
Wnioski
Wszystkie trzy systemy CMS zostały bogato wyposażone w liczne funkcje usprawniające
zarówno korzystanie ze strony jak i zarządzanie nią. Brak jakiejś wbudowanej funkcji
zazwyczaj nie stanowi dużego problemu, ponieważ istnieje wiele dodatkowych modułów.
Planując zbudowanie strony www posiadającej funkcjonalność nie wchodzącą w skład jądra
systemu CMS, zawsze istnieje duża szansa, że ktoś inny już przed nami zaimplementował
określoną funkcję i opublikował ją w postaci dodatkowego modułu. W takiej sytuacji zakres
18 Informacje te pochodzą z oficjalnych stron omawianych systemów CMS: http://wordpress.org/extend/plugins/, http://extensions.joomla.org/ oraz http://drupal.org/node/206666
57
naszej pracy będzie ograniczał się jedynie do pobrania danego dodatku i aktywowania go w
systemie.
Prześledziłem listę funkcji wbudowanych w porównywane systemy CMS. Teraz nadszedł
czas na dokładne omówienie wybranych aspektów tych systemów. W pozostałej części tego
podrozdziału przyjrzę się dokładnie wielu istotnym zagadnieniom, zaczynając od tych
bardziej podstawowych, a na zaawansowanych kończąc.
Łatwość obsługi i intuicyjność. Jakość panelu administracyjnego.Łatwość obsługi oprogramowania to bardzo istotna cecha niezależnie od poziomu
zaawansowania korzystającego z niego użytkownika. Dzięki systemom i programom łatwym
w obsłudze użytkownicy potrzebują mniej czasu na wykonanie w nich tych samych zadań co
w systemach, których obsługa jest niewygodna. Warto dodać tu, że łatwość obsługi nie ma
dużego związku z intuicyjnością graficznego interfejsu użytkownika. Intuicyjny interfejs
bowiem pozwala użytkownikom nie znającym oprogramowania szybko zorientować się jak z
niego korzystać. Dzięki temu zużywają oni mniej czasu an zastanawianie się jak coś zrobić,
przez co ich praca w danym systemie jest bardziej płynna i wydajna. Intuicyjność systemu ma
znaczenie głównie dla nowych użytkowników, którzy nie nauczyli się jeszcze jak z niego
korzystać. Łatwość obsługi zaś jest istotna zarówno dla nowych użytkowników jak i dla tych,
którzy znają dane oprogramowanie na pamięć. Programy łatwe w obsłudze wymagają
mniejszego nakładu pracy podczas wykonania takich samych zadań co w systemach trudnych
w obsłudze.
Panel administracyjny w odniesieniu do systemów CMS to centralne miejsce, które
umożliwia nam łatwy dostęp do wszystkich istotnych funkcji i ustawień systemu. Zarządzanie
stroną www opartą na systemie CMS odbywa się zazwyczaj właśnie poprzez taki panel.
Dlatego jeśli panel taki jest dostępny, powinien być dobrze przemyślany i przyjazny dla
użytkownika.
WordPress
Panel administracyjny systemu WordPress jest bardzo przejrzysty i przyjazny dla
użytkownika. Kolory panelu są starannie dobrane i stonowane, przez co nie rozpraszają
podczas pracy. Pierwsze ogólne wrażenie jest bardzo pozytywne, wizualnie wszystko jest
dopracowane z dbałością o najmniejsze szczegóły.
58
Na stronie głównej panelu znajdują się elementy umożliwiające szybkie sprawdzenie ilości
podstron, kategorii i komentarzy, łatwe wpisanie nowego postu czy chociażby podgląd
najświeższych informacji dotyczących systemu WordPress wczytywanych ze strony
wordpress.org.
Większość podstron panelu administracyjnego posiada pewne wbudowane funkcje
konfiguracji ich wyglądu takie jak ustawianie ilości kolumn, w których wyświetlane mają być
informacje, czy definiowanie jakie informacje mają być widoczne.
Rysunek . Strona główna panelu administracyjnego systemu WordPress
Użytkownik zalogowany do panelu administracyjnego może z łatwością edytować dane
zapisane w swoim profilu, takie jak np. swój adres e-mail lub hasło.
W panelu systemu WordPress zabrakło możliwości konfigurowania menu administracyjnego i
funkcji umożliwiających jego większą reorganizację ale na szczęście nie stanowi to problemu
ze względu na małą ilość opcji wbudowanych w ten system. Domyślna instalacja CMS-a
WordPress posiada bowiem niewielkie możliwości konfiguracyjne więc wbudowany panel
administracyjny będzie świetnie wystarczał bardzo wielu użytkownikom. Zaawansowani
użytkownicy, posiadający zainstalowane w systemie liczne dodatkowe plugin-y, mogą
wymagać lepszej nawigacji panelu administracyjnego. Na szczęście nic nie stoi na
przeszkodzie aby pobrać z Internetu inny szablon administracyjny lub chociażby jakiś
dodatek umożliwiający konfigurację nawigacji w panelu.
59
Joomla
Panel administracyjny systemu Joomla nie jest już tak dopracowany wizualnie jak w
przypadku systemu WordPress. Dominują tu mocno nasycone kolory, niebieski i żółty,
pojawiające się głównie w ikonach. Moim zdaniem panel ten mógłby być trochę bardziej
przejrzysty. Wiele osób doceni liczne ikonki ułatwiające poruszanie się po panelu, aczkolwiek
osobiście niezbyt mi się one podobają ze względu na ich rozbieżność kolorystyczną, zbyt
cukierkowe kolory oraz nadmiar ich występowania. Panel systemu Joomla jest mało
intuicyjny i nowi użytkownicy na pewno będą musieli poświęcić więcej czasu na jego
poznanie niż w przypadku systemu WordPress.
Rysunek . Strona główna panelu administracyjnego systemu Joomla
Strona główna panelu zawiera odnośniki do stron umożliwiających wykonywanie
najczęstszych zadań administracyjnych, takich jak np. dodawanie artykułów czy zarządzanie
artykułami, kategoriami lub nawigacją. Widoczne są tu także małe listy ostatnio dodanych
artykułów i popularnych artykułów, oraz lista zalogowanych użytkowników.
Panel ten nie umożliwia niestety prawie żadnej sensownej konfiguracji jego wyglądu. Na
szczęście istnieje możliwość zamiany szablonu administracyjnego na inny więc
zaawansowani użytkownicy mogą w razie czego zainstalować sobie inny.
Zaskakujący jest fakt, że zalogowani do panelu administracyjnego użytkownicy, nie
posiadający uprawnień do zarządzania kontami użytkowników, nie znajdą w nim opcji
umożliwiającej edycję swojego profilu. Użytkownicy nie posiadający takich uprawnień mogą
edytować swoje profile jedynie poprzez „frontend” czyli stronę, którą widzą wszystkie osoby
odwiedzające naszą witrynę.
60
Dodatkową wadą panelu administracyjnego systemu Joomla jest automatyczne blokowanie
dostępu do paska nawigacyjnego podczas edycji niektórych ustawień. Funkcja ta jest irytująca
oraz spowalnia pracę, więc w przyszłości powinna zostać usunięta.
Drupal
W odniesieniu do poprzednich dwóch systemów CMS Drupal jest odmienny. Nie posiada on
bowiem oddzielnego panelu administracyjnego – zarządzanie systemem odbywa się
bezpośrednio na stronie. Rozwiązanie takie z jednej strony może wydawać się dziwne dla
użytkowników przyzwyczajonych do systemów CMS posiadających oddzielne zaplecze
służące do zarządzania stroną. Z drugiej strony jednak jest ono bardzo wygodne. Możliwość
zarządzania wszystkimi aspektami systemu, wliczając w to oczywiście edycję podstron, bez
konieczności przechodzenia do panelu administracyjnego przyśpiesza pracę. Wcześniej
omówione systemy też umożliwiają przechodzenie do edycji treści artykułów poprzez
kliknięcie jednego odnośnika widocznego na stronie z artykułem, jednak zarządzanie innymi
aspektami strony wymaga już zazwyczaj otwarcia oddzielnej podstrony z panelem.
Dodatkową korzyścią z posiadania zintegrowanego ze stroną panelu administracyjnego jest
to, że osoba która zamówiła wykonanie strony z systemem CMS silniej odczuwa, że jest na
swojej stronie niezależnie od tego czy ją w danej chwili edytuje czy tylko przegląda. Jest to
korzystne z punktu widzenia twórcy strony – klient, który taką stronę zamówił widzi zawsze
zamówiony przez siebie projekt, a nie zaplecze systemu CMS.
Osoby, które wolą mieć odmienny panel administracyjny, nie muszą się martwić, gdyż system
Drupal umożliwia ustawienie dla stron administracyjnych innego szablonu niż dla pozostałej
części strony. Jeszcze lepiej prezentuje się pod tym względem Drupal 7 - dostępny jest tu
oddzielny szablon przeznaczony specjalnie dla stron zarządzania CMS-em.
Opcjonalny szablon zarządzania systemem Drupal 7 jest bardzo przejrzysty i dużo bardziej
przyjazny niż było to w przypadku poprzedniej wersji tego CMS-a. Podobnie jak w systemie
WordPress dominują tu kolory szare, które nie dekoncentrują podczas pracy. Niestety
zarządzanie tym systemem nie jest zbyt wygodne dla nowych użytkowników. Brakuje tu
intuicyjności obsługi, również w systemie Drupal 7 nie zadbano odpowiednio o „przyjazność”
panelu administracyjnego.
Dla zaawansowanych użytkowników sposób zarządzania systemem Drupal będzie zapewne
wygodniejszy niż w przypadku pozostałych dwóch systemów CMS. Odnośnie nowych
61
użytkowników, pewne jest jednak, że będą oni musieli poświęcić więcej czasu na jego
opanowanie niż w przypadku systemu WordPress lub Joomla.
Administracyjna część systemu Drupal 6 posiada duże możliwości konfiguracyjne, które
zostały znacznie poszerzone w systemie Drupal 7. W systemie tym możemy m.in. definiować
jakie elementy pojawią się na stronie głównej panelu administracyjnego, zarządzać nawigacją
administracyjną czy chociażby zmieniać sposób wyświetlania ustawień administracyjnych.
Ponieważ strony administracyjne są wyświetlane w ramach witryny i mogą korzystać z
innego szablonu niż jej szablon główny, można ustawić wygląd „panelu” administracyjnego
oparty na dowolnym szablonie dostępnym dla systemu Drupal.
Rysunek Sekcja administracyjna systemu Drupal 7 - odpowiednie opcje pojawiają się "ponad" stroną.
Dostęp do profilu użytkownika zalogowanego do strony wymaga tylko jednego kliknięcia
niezależnie od strony na której użytkownik aktualnie przebywa.
Wadą stron administracyjnych systemu Drupal może dla niektórych być brak jakichkolwiek
ikon umożliwiających szybkie poruszanie się.
Wnioski
Porównywane systemy CMS posiadają zupełnie odmienne interfejsy administracyjne.
Najbardziej dopracowany wydaje się być interfejs systemu WordPress. Położono tu
stanowczy nacisk na jego przejrzystość, intuicyjność i prostotę obsługi. Z drugiej strony
system Drupal, ze swoim odmiennym sposobem administrowania, daje większe pole do
popisu zaawansowanym użytkownikom. Możliwości dość łatwego zarządzania wyglądem
62
panelu administracyjnego systemu Drupal powodują, że bardziej niż w przypadku systemu
WordPress nadaje się on do profesjonalnych zastosowań. Panel administracyjny systemu
Joomla! nie dorównuje niestety tym z pozostałych dwóch systemów. Brakuje mu pewnych
podstawowych funkcji oraz jest mało przejrzysty.
Łatwość dodawania i edytowania treściZarządzanie treścią to najważniejsza funkcja systemów CMS przeznaczonych do obsługi
stron www. Dlatego dodawanie i edycja artykułów lub podstron powinna być łatwa i
przyjemna. Użytkownicy edytujący zawartość witryny powinni móc robić to bez głębszego
zastanawiania się. Dzięki temu mogą skupić się na samej treści i nie zaprzątać sobie głów
sprawami technicznymi. Przyjrzę się teraz każdemu z trzech porównywanych systemów CMS
i omówię je pod tym kątem.
WordPress
System WordPress umożliwia łatwe dodawanie nowych podstron / artykułów poprzez swój
przejrzysty panel administracyjny. Po wejściu w odpowiednią opcję pojawia się nam strona z
rozbudowanym formularzem dodawania artykułu. Formularz ten zawiera dwa podstawowe
pola tekstowe – pole przeznaczone na wpisanie tytułu i pole przeznaczone na wpisanie treści
– oraz wiele dodatkowych opcji przydatnych podczas publikowania artykułów.
Pole wpisywania treści artykułu wykorzystuje edytor tekstowy TinyMCE posiadający
niestandardowy wygląd. Dzięki temu formularz dodawania artykułu jest równie elegancki jak
reszta panelu administracyjnego systemu WordPress. Oprócz standardowych opcji
formatowania tekstu, takich jak pogrubianie czcionki czy zmiana koloru liter, umożliwiono
nam łatwe wgrywanie zdjęć i innych multimediów.
Edytor TinyMCE umożliwia edycję kodu HTML w trybie WYSIWYG (z ang. What You See Is What You Get – co widzisz to otrzymasz). Edytory należące do tej grupy pozwalają na edytowanie treści bez konieczności znajomości języka HTML. Praca w takim edytorze przypomina korzystanie z programu Microsoft Word.
Dodatkowo dostępny jest także tryb edycji HTML dla nieco bardziej zaawansowanych
użytkowników. Niestety jest on mocno niedoskonały ponieważ pewne elementy języka
HTML są usuwane przez system. Dzieje się tak niezależnie od tego czy edytor WYSIWYG
jest włączony czy nie. Oczywiście słuszne jest ograniczanie wpisywania do pewnego
dopuszczalnego kodu (ze względów bezpieczeństwa) ale nie powinno ono dotyczyć np.
63
administratora systemu. Osoby potrzebujące możliwości umieszczania w treści artykułu
wszystkich istniejących znaczników HTML lub np. kodu PHP będą musiały pobrać dodatek
do systemu WordPress zmieniający ten stan rzeczy.
Inne opcje dostępne w formularzu dodawania nowego artykułu to np. opcje publikacji,
możliwość ustawienia aliasu czy lista wyboru kategorii (dostępna podczas dodawania
artykułu typu „post”).
Wszystkie bloki z opcjami można przesuwać, dzięki czemu te rzadziej wykorzystywane
można umieścić na dole strony, a te częściej używane na górze.
Możliwe jest też tworzenie tu dodatkowych pól formularza wpisywania danych. Informacje
wpisane w utworzonych własnych polach mogą być później wykorzystywane przez szablon
podczas wyświetlania strony.
Edycja istniejących artykułów jest równie łatwa jak ich dodawanie i odbywa się poprzez
identyczny formularz. Przejście do trybu edycji wybranego artykułu odbywa się na jeden z
dwóch sposobów:
• Poprzez znalezienie danego artykułu na liście wszystkich artykułów w panelu
administracyjnym i kliknięcie wyświetlanej przy nim opcji „edit"
• Poprzez kliknięcie odnośnika „edit” wyświetlanego na stronie z danym artykułem
podczas gdy jesteśmy zalogowani
System WordPress podczas edycji artykułu tworzy tak zwane rewizje. Oznacza to, że
zaktualizowana wersja artykułu jest zapisywana „obok” wersji poprzedniej. Dzięki temu w
każdej chwili można przywrócić wcześniejszą wersję artykułu. Może to się przydać np. w
sytuacji przypadkowego skasowania części treści artykułu podczas jego edycji. Wcześniejsze
wersje można przeglądać jedynie w panelu administracyjnymi – osoby odwiedzające witrynę
nie mają do nich dostępu.
Podsumowując, dodawanie i edycja artykułów w systemie WordPress są proste i przyjemne.
Jedyny problem może pojawić się gdy użytkownik będzie chciał umieścić w artykule kod np.
PHP. Kod taki zostanie usunięty.
64
Rysunek . Formularz dodawania nowego artykułu w systemie WordPress jest przejrzysty i wygodny
Joomla!
Dodawanie nowych artykułów w systemie Joomla! jest prawie tak łatwe jak w systemie
WordPress. Po przejściu do odpowiedniego formularza zobaczymy dwa standardowe pola
umożliwiające wpisanie odpowiednio tematu i treści artykułu. Podobnie jak w przypadku
systemu WordPress edycja treści odbywa się poprzez edytor tekstowy TinyMCE.
Poza standardowymi opcjami wbudowanymi w edytor, takimi jak formatowanie tekstu,
formularz edycji artykułu umożliwia łatwe wstawianie odnośników do istniejących artykułów
oraz wgrywanie i umieszczanie w tekście zdjęć. Ponadto można także ustawiać podział
artykułu na oddzielne podstrony co może być przydatne w przypadku bardzo długich
artykułów.
Edytor TinyMCE pozwala również otworzyć okno z kodem HTML edytowanego artykułu.
Edytując taki kod należy pamiętać jednak, że edytor TinyMCE usuwa niektóre elementy
języka HTML. Usuwane są również fragmenty zawierające kod PHP oraz JavaScript. Dlatego
podczas edycji kodu HTML nie możemy mieć gwarancji, że zostanie on zapisany w całości.
65
Rysunek . Formularz dodawania nowego artykułu w systemie Joomla posiada wiele opcji
W formularzu tym umieszczono także przycisk przełączający pomiędzy trybem z edytorem
TinyMCE a trybem bez edytora. Najlepiej przemyślany sposób działania takiego przycisku
umożliwiał by korzystanie z niego tylko przez administratora systemu. Przełączenie w tryb
kodu HTML umożliwiało by wtedy umieszczanie w ciele artykułu np. kodu PHP. Niestety nie
działa to w ten sposób. Według wbudowanej pomocy systemu Joomla, aby umieścić w ciele
artykułu np. kod JavaScript, należy przed jego utworzeniem zupełnie wyłączyć w globalnych
ustawieniach edytor TinyMCE. Następnie można dodać artykuł z kodem JavaScript. Po jego
zapisaniu można z powrotem włączyć edytor aczkolwiek należy pamiętać, że w przypadku
edycji powyższego artykułu w przyszłości należy ponownie tymczasowo dezaktywować
edytor TinyMCE.
Inne opcje dostępne w formularzu dodawania nowego artykułu są między innymi związane z
publikacją artykułu, wyborem kategorii czy ustawieniami wyświetlania informacji
dodatkowych. Dostępne są tu także ustawienia związane z meta-tagami odczytywanymi przez
wyszukiwarki internetowe. Wspomnieć należy też o możliwości ustawiania uprawnień do
edycji artykułu przez użytkowników należących do różnych grup.
Mylące może być tu pole tekstowe oznaczone jako „alias”. Można przypuszczać, że pole to
ma coś wspólnego z adresem www pod którym dostępny będzie artykuł. Niestety jest to
mylne założenie – alias wpisany w powyższym polu jest jedynie internalną nazwą systemową
66
artykułu. Dodawane artykuły nie są domyślnie dostępne poprzez żaden adres URL. Jest to
mechanizm bardzo niewygodny.
Aby udostępnić nowy artykuł na oddzielnej podstronie należy w polu wyboru kategorii
wybrać „Uncategorized”. Artykuł taki będzie dostępny pod adresem:
http://[domena]/ index.php?option=com_content&view=article&id=[id_artykułu]
Rozwiązanie to jest bardzo niewygodne. Publikacja artykułu na oddzielnej podstronie,
posiadającego przypisaną kategorię, jest niewykonalne.
Przejście do trybu edycji wybranego artykułu wymaga odnalezienia go na liście wszystkich
artykułów dostępnej w panelu administracyjnym. Po kliknięciu nazwy artykułu pojawi się
edytor.
Drupal
Dodawanie artykułów i podstron w systemie Drupal jest bardzo wygodne. Dostępne opcje
przypominają te znane z systemu WordPress lub Joomla. Istnieje jednak kilka istotnych
różnic.
Po pierwsze system Drupal nie posiada domyślnie zainstalowanego edytora WYSIWYG. Jest
to wygodne dla zaawansowanych użytkowników, którzy wolą edytować artykuły poprzez
bezpośrednią zmianę kodu HTML, ale nie musi się podobać wszystkim tym osobom, które
chcą łatwo i szybko dodawać bogate w treść artykuły bez konieczności uczenia się HTM.
Istnieje jednak kilka dodatkowych, bardzo dobrych modułów dla systemu Drupal,
umożliwiających używanie jednego z wielu edytorów WYSIWYG w ramach tego CMS-a.
Kolejną istotną różnicą jest możliwość wyboru formatu wejściowego wpisywanych danych.
Wybierając odpowiedni format możemy np. zezwolić na umieszczanie w treści artykułu
dowolnego kodu PHP lub JavaScript. Inne dostępne formaty mogą np. ograniczać dozwoloną
treść do samego HTML-a lub jego wybranej części. Korzystanie z różnych formatów jest
możliwe w zależności od roli użytkownika. Dla przykładu głównemu administratorowi
witryny możemy zezwolić korzystać z kodu PHP a redaktorom na przykład z samego HTML-
a lub tylko jego części.
Wygląd elementu umożliwiającego ustawianie formatu wejściowego dla treści artykułu
przedstawiony jest poniżej.
67
Rysunek . System Drupal umożliwia wybór formatu wejściowego dla treści artykułu. Dostępne są jedynie te formaty do korzystania z których użytkownik ma uprawnienia.
Drupal w wersji 6 nie posiadał wbudowanej funkcji umożliwiającej dołączanie zdjęć do
postów. Tego typu funkcjonalność można było osiągnąć jedynie poprzez instalację
odpowiednich modułów dodatkowych. System Drupal 7 jest pod tym względem odmienny –
posiada on bowiem sporo ciekawych wbudowanych funkcji umożliwiających przetwarzanie
obrazów i umieszczanie ich w postach.
System Drupal, tak samo jak system WordPress posiada funkcję tworzenia rewizji artykułów,
dzięki czemu ich treść jest bardziej zabezpieczona np. przed przypadkowym skasowaniem
jakiegoś fragmentu.
Również podobnie jak w systemie WordPress w Drupalu 7 możliwe jest tu definiowanie
własnych pól danych. Funkcja ta jest bardzo rozbudowana i bardziej przyda się
zaawansowanym użytkownikom. W systemie Drupal 6 funkcjonalność tą zapewnia moduł
CCK (Content Construction Kit).
Na końcu warto jeszcze wspomnieć, że w systemie Drupal możliwe jest dodanie nowego
elementu nawigacji, np. odnośnika w menu głównym strony, kierującego do podstrony z
danym artykułem, bezpośrednio podczas dodawania lub edycji tego artykułu.
68
Rysunek . Formularz dodawania artykułu w systemie Drupal 6 z zainstalowanym edytorem CK Editor. Większość opcji dostępnych w formularzu jest "zwiniętą".
Przejście w tryb edycji artykułu jest możliwe poprzez wybranie tego artykułu na liście
wszystkich artykułów. Lista ta dostępna jest na odpowiedniej stronie administracyjnej.
Drugim sposobem edytowania artykułu jest kliknięcie odnośnika „edit” wyświetlanego na
podstronie z danym artykułem.
Wnioski
Wszystkie trzy systemy CMS udostępniają rozbudowane formularze dodawania artykułów.
WordPress i Joomla posiadają wbudowane edytory WYSIWYG z możliwością łatwego
69
wgrywania zdjęć. W systemie Drupal edytor taki można łatwo dodać poprzez instalację
dodatkowego modułu. Funkcja wgrywania zdjęć w systemie Drupal jest wbudowana dopiero
w wersji siódmej – w wersji szóstej również konieczne będzie skorzystanie z dodatkowych
modułów.
Jedynie system Drupal posiada duże możliwości konfigurowania formatów wejściowych,
które można, w zależności od potrzeb, udostępniać wybranym grupom użytkowników.
Systemu WordPress i Joomla są pod tym względem mocno ograniczone.
Formularz systemu WordPress jest dużo bardziej elegancki niż w przypadku pozostałych
dwóch CMS-ów.
Ciekawą funkcją w systemach WordPress i Drupal jest możliwość konfigurowania
dodatkowych pól danych. W systemie Drupal funkcjonalność ta jest jednak dużo bardziej
rozwinięta i dopracowana. Funkcji tej nie znajdziemy w systemie Joomla, za to mamy w nim
możliwość konfigurowania meta-tagów, co w przypadku systemów WordPress i Drupal
wymaga zainstalowania dodatkowych modułów.
Systemy WordPress i Drupal umożliwiają bardzo łatwe przechodzenie w tryb edycji
przeglądanego artykułu, czego nie można powiedzieć o systemie Joomla. Posiadają one także
wbudowaną obsługę rewizji, które mogą okazać się nieocenione gdy np. przypadkowo
skasujemy istotną część artykułu.
Dodatkowym plusem formularza zawartego w systemie Drupal jest możliwość definiowania
elementów nawigacji bezpośrednio podczas dodawania lub edycji artykułu.
System Joomla posiada niestety dość niejasny mechanizm publikowania artykułów, który dla
nowych użytkowników może okazać się niewygodny. Wpisywane w formularzu tym aliasy
artykułów nie mają nic wspólnego z ich dostępnością poprzez adres URL. Publikowane
artykuły nie posiadają domyślnie swoich podstron, a domyślenie się jak udostępnić taki
artykuł na oddzielnej podstronie nie posiadającej odnośnika w menu witryny może być
trudne.
Możliwości prezentowania treściPrezentowanie treści to równie istotna rzecz jak jej dodawanie czy edycja. Systemy CMS
powinny udostępniać pewne mechanizmy ułatwiające konfigurowanie sposobu prezentowania
informacji na stronie.
70
Dosyć często spotykany jest w systemach CMS podział treści i elementów strony na elementy
prezentowane w głównej części ciała strony, określanej nieraz mianem „content”, oraz na
elementy prezentowane w pasku bocznym, określanym zazwyczaj jako „sidebar”, widocznym
po lewej lub prawej stronie.
Wszystkie trzy porównywane systemy CMS posiadają wbudowaną obsługą elementów paska
bocznego. Przyjrzyjmy im się dokładniej.
WordPress
Elementy wbudowane w system WordPress umożliwiają wyświetlanie podstron w oparciu o
szablon z paskiem bocznym „sidebar” lub bez niego. Ustawienie to dotyczy tylko artykułów
typu „Page”.
W pasku bocznym możemy wyświetlać bloki określane mianem „widgets”. Oprócz paska
bocznego system WordPress posiada także dodatkowe regiony umieszczone w stopce.
Dodanie nowego bloku do jednego z tych regionów powoduje pojawienie się tego regionu.
Regiony nie posiadające przypisanych żadnych bloków pozostają niewidoczne.
Domyślnie w systemie dostępnych jest 13 różnych widet-ów umożliwiających wyświetlanie
w pasku bocznym lub w stopce następujących elementów:
• Archiwum postów
• Listy kategorii
• Kalendarza
• Listy dodatkowych odnośników
• Dodatkowej menu nawigacyjnego
• Odnośników dla użytkowników (takich jak link do panelu logowania)
• Listy wszystkich podstron
• Listy najnowszych postów i komentarzy
• Kanałów RSS
• Chmury tagów
71
• Wyszukiwarki treści
Oprócz z góry zaprogramowanych widet-ów udostępniono nam także jeden o nazwie „Text”.
Umożliwia on umieszczenie dowolnej treści. Niestety ograniczenie jesteśmy tu do samego
HMTL-a.
Pobierając dodatkowe plug-iny możemy zapewnić sobie nowe widget-y posiadające funkcje
niewbudowane w system WordPress.
Większość widet-ów posiada pewne możliwości ich konfigurowania. Możliwe jest także
wyłączenie wyświetlanego widet-u bez usuwania jego konfiguracji. Nie jest to jednak
dopracowane – przypadkowe usunięcie ustawień jednego z aktywnych widet-ów jest zbyt
łatwe.
Poważną wadą jest brak możliwości konfigurowania na jakich podstronach witryny pojawią
się jakie widgety.
Joomla
System Joomla ma przewagę nad systemem WordPress pod względem ilości dostępnych
regionów w których można umieszczać bloki zwane tutaj „modułami”.
Modułów tych jest w systemie Joomla blisko 50. Cała funkcjonalność jest tutaj bardzo
zbliżona do tej z systemu WordPress. Również dostępny jest moduł umożliwiający
umieszczenie w dowolnym regionie własnego kodu HTML, z tym że edycja treści odbywa się
tu identycznie jak w przypadku dodawania artykułów – dostępny jest edytor WYSIWYG.
W odróżnieniu od systemu WordPress, możliwe jest konfigurowanie, które moduły będą
widoczne dla konkretnych podstron, choć dostępne tutaj opcje są mocno ograniczone.
Możliwe jest także ustawianie poziomu dostępu do modułów, dzięki czemu możemy
ograniczyć ich wyświetlane do pewnej grupy użytkowników.
W systemie Joomla możliwe jest również tworzenie podstron posiadających różnego rodzaju
treść budowaną automatycznie. Można np. dodać podstronę z listą wszystkich kontaktów lub
kategorii. Dodawanie takich podstron odbywa się poprzez zarządzanie nawigacją. Podczas
dodawania nowego elementu menu możemy wybrać typ elementu menu, od którego zależy co
pojawi się na stronie do którego dany element menu przenosi.
72
Drupal
W systemie Drupal wbudowanych jest prawie 20 bloków. Część z nich staje się widoczna
dopiero po włączeniu odpowiednich modułów wchodzących w skład standardowej instalacji
systemu.
Ilość regionów w których można te moduły wyświetlać w przypadku siódmej wersji Drupala
wynosi 15 + 2 regiony widoczne jedynie na stronach administracyjnych.
Bloki można łatwo wyłączać bez usuwania ich ustawień. Również tutaj możliwe jest
dodawanie bloków z własnym kodem HTML.
Istotna przewaga bloków HTML w systemie Drupal nad blokami HTML pozostałych dwóch
systemów CMS polega na możliwości definiowania formatu danych, tak jak to było możliwe
w przypadku artykułów. Ponadto wykorzystanie formatu danych z którego korzystać może
jedynie administrator systemu uniemożliwi np. redaktorom edycję takiego bloku (dotyczy to
także artykułów).
Również podobnie jak podczas edycji artykułów nie ma tutaj domyślnie zainstalowanego
edytora WYSIWYG, jednak dodanie go do systemu jest dość łatwe.
Przydatną, wbudowaną funkcją jest możliwość ustawiania widoczności modułu dla
wybranych ról użytkowników i/lub wybranych adresów podstron. Można ustawić
wyświetlania się bloków dla wszystkich podstron, których alias np. zaczyna się na
„aktualnosci/”. Dzięki temu blok taki będzie widoczny zarówno na podstronie
„aktualnosci/informacje_ogolne” jak i np. „aktualnosci/archiwum”.
Przenoszenie bloków pomiędzy regionami do których są przypisane odbywa się na zasadzie
przeciągnij-i-upuść.
Wnioski
Konfiguracja bloków wyświetlanych w przypadku systemu WordPress jest najuboższa. Nie
wbudowano tam wielu przydatnych ustawień, które znajdziemy w systemie Joomla lub
Drupal. W Joomli zarządzanie blokami nie posiada tak dopracowanych ustawień związanych
z ich dostępnością jak jest to w systemie Drupal.
Współdzielenie informacji z innymi stronami. Łatwe sprawdzanie nowości. Przeszukiwanie witryny.
73
Narzędzia ułatwiające i upraszczające przekaz informacji są w dzisiejszych czasach bardzo
pożądane. Dzięki funkcjom takim jak udostępnianie najnowszych aktualności poprzez kanały
RSS, możliwość przeszukiwania witryny dzięki wbudowanej wyszukiwarce, automatyczne
informowanie innych stron o nowych postach czy odczytywanie treści kanałów RSS
udostępnianych przez inne witryny ułatwiamy użytkownikom korzystanie z Internetu.
Wszystkie trzy omawiane systemy CMS posiadają wbudowaną funkcjonalność publikowania
poprzez RSS. Kanały RSS pozwalają pobierać informacje z witryny www bez
bezpośredniego jej odwiedzania. Informacje pobierane są ze strony w postaci XML i
wyświetlane w czytniku RSS. Czytniki RSS umożliwiają pobieranie informacji z wielu witryn
jednocześnie.
Możliwość przeszukiwania witryny także została wbudowana we wszystkie trzy CMS-y.
Istnieją jednak pewne różnice. System WordPress posiada bardzo prostą wyszukiwarkę, której
jedyne możliwości konfiguracji ograniczają się do jej włączania lub wyłączania. Joomla i
Drupal mogą pochwalić się dwoma widokami wyszukiwarki podstawowym, posiadającym
jedynie jedno pole tekstowe, oraz zaawansowanym widokiem ułatwiającym zadawanie
bardziej precyzyjnych zapytań wyszukiwania. Ponadto system Drupal umożliwia
konfigurowanie zachowywania się mechanizmu indeksującego oraz wyszukiwarki. Strona
wyników wyszukiwania w systemie Drupal, w odróżnieniu od wyszukiwarki Joomli,
wyświetla wyniki według ich trafności. Biorąc pod uwagę powyższe różnice śmiało można
powiedzieć, że funkcje indeksujące treść i umożliwiające przeszukiwanie witryny są w
Drupalu najbardziej rozwinięte.
Kolejną przydatną funkcją jest możliwość agregowania treści z kanałów RSS innych witryn i
wyświetlanie ich na swojej stronie www. Przydatna może okazać się możliwość
przypisywania zagregowanej treści kategorii. Obie te funkcje zostały wbudowane w systemy
Drupal i Joomla.
Ostatnią wbudowaną funkcją wymagającą tutaj omówienia są tzw. usługi aktualizacji, które
umożliwiają automatyczne powiadamianie innych osób o nowych postach lub artykułach na
stronie. Funkcjonalność taką wbudowano w systemy WordPress i Drupal. Powiadamianie o
zamianach polega na wysłaniu odpowiednich komunikatów poprzez XML-RPC19 za każdym
19 XML-RPC – zdalne wywołania procedur poprzez sięć. Więcej na ten temat: http://www.xmlrpc.com/
74
razem gdy dokonano aktualizacji na stronie. Powiadomienia o zmianach w treści strony
opartej na systemie Drupal jest przesyłane do usługi Pingomatic, która te powiadomienia
przekazuje innym usługom takim jak weblogs.com, Technorati, BlogRolling, Feedster.com
itp. W systemie WordPress umożliwiono nam podanie adresu dowolnej usługi. Domyślnie jest
tam wpisany Pingomatic.
75
Wnioski
Jeśli chodzi o funkcje ułatwiające współdzielenie i wyszukiwanie informacji nie da się ukryć,
że najlepiej wyposażony został tutaj system Drupal. Na szczęście najważniejsza funkcja
udostępniania kanału RSS wbudowana jest we wszystkie trzy systemy.
Dostępność darmowych szablonów i ich jakośćOgólnie mówiąc szablony umożliwiają łatwą zmianę wyglądu witryny. Na tym jednak ich
możliwości się nie kończą. Szablony umożliwiają dużo większą kontrolę nad prezentacją
treści i nie są ograniczone do kontrolowania samego designu.
Typowy szablon składa się z wielu współdziałających plików, które umożliwiają wyświetlanie
wszystkich treści w ramach zapewnionego przez szablon interfejsu graficznego. Szablony
zmieniają sposób prezentowania strony bez konieczności modyfikowania obsługującego
stronę systemu CMS. Wielką ich zaletą jest też fakt, że każda mała zmiana dokonana w
plikach szablonu jest widoczna od razu na wszystkich podstronach witryny korzystających z
tego szablonu.
W odniesieniu do szablonów osoby zakładające nową stronę www można by podzielić na
dwie grupy. Przedstawiciele pierwszej z nich tworzą lub zamawiają własne szablony, które
zapewniają ich witrynom niepowtarzalny wygląd. Założyciele takich stron to w większości
firmy, którym zależy m.in. na powiązaniu designu ich witryny z firmowymi kolorami oraz na
tym aby strona mocno kojarzyła się z przedmiotem ich działalności. Poza tym osoby
prywatne takie jak designerzy, fotograficy i innego rodzaju artyści, których twórczość jest
bezpośrednio związana ze zmysłem postrzegania, również decydują się na utworzenie
własnego szablonu. Dzięki temu mogą być pewni, że ich prace będą zaprezentowane w jak
najlepszy sposób.
Przedstawiciele drugiej grupy zaś wykorzystują do budowy strony zazwyczaj gotowe
szablony. Te z kolei można podzielić na darmowe oraz płatne. Osoby należące do tej grupy to
w większości indywidualiści, prowadzący strony hobbistyczne i/lub niedochodowe, które
starają się zbudować niskim kosztem.
Jeśli chodzi o płatne szablony, to naprawdę jest z czego wybierać. Dla przykładu, na stronie
www.templatemonster.com ilość dostępnych szablonów dla porównywanych systemów CMS
wynosi kolejno (dane z lipca 2010):
76
• WordPress – około 1020
• Joomla – około 540
• Drupal – około 500
Porównam teraz dostępność i jakość darmowych szablonów przeznaczonych dla wybranych
systemów CMS.
WordPress
Główne źródło darmowych szablonów dla systemu WordPress, określanych mianem
„themes”, znajduje się na oficjalnej stronie tego CMS-a pod adresem
http://www.wordpress.org/extend/themes. Imponująca jest ich ilość i wynosi 1 220.
Znajdziemy tu różnego typu szablony, zarówno proste jak i posiadające nietuzinkową grafikę.
Część z nich jest bardzo słaba, ale profesjonalnych „skórek” też nie trzeba długo szukać.
Dodatkowo w repozytorium szablonów dostępnym na stronie wordpress.org możemy
sprawdzić ile osób pobrało już dany szablon oraz jak został on oceniony. Można też zobaczyć
demo dowolnego szablonu bez pobierania go.
Joomla
System Joomla posiada wiele darmowych szablonów, zwanych tutaj „templates”. Niestety
system ten nie posiada na swojej oficjalnej stronie działu z szablonami. Pomimo ich sporej
liczby, pobieranie darmowych template-ów wymaga przeszukiwania Internetu poprzez
wyszukiwarkę, np. Google. Wśród wyników wyszukiwania pojawia się mnóstwo stron
posiadających więcej reklam niż darmowych szablonów. W związku z tym, szukanie
solidnych darmowych szablonów może być dla nowych użytkowników męczące.
Drupal
Drupal podobnie jak WordPress bezpłatne udostępnia szablony, zwane „themes”, poprzez
swoją oficjalną stronę dostępną pod adresem http://drupal.org/project/Themes. Dostępnych
jest tu ponad 600 szablonów niestety wiele z nich posiada bardzo ubogą szatę graficzną.
Spora część jest mało profesjonalna i nieatrakcyjna wizualnie, przez co repozytorium
szablonów systemu Drupal nie może konkurować z tym, które posiada system WordPress.
Dodatkową funkcją jest możliwość sprawdzania statystyk wykorzystania dowolnych
szablonów. Statystyki te są na bieżąco uaktualniane. Domyślna kolejność sortowania
77
szablonów jest zależna od ich popularności. Dzięki temu szablony najbardziej godne uwagi
pojawiają się na początku listy.
Wnioski
Największą ilością darmowych szablonów cieszy się system WordPress. Szablony dla tego
systemu można łatwo przeglądać i pobierać ze strony głównej tego CMS-a. System Drupal
również udostępnia wachlarz szablonów na swojej oficjalnej stronie, aczkolwiek dostępność
wśród nich porządnych i eleganckich szablonów jest bardzo mała. System Joomla zaś posiada
wiele darmowych szablonów ale żadne z nich nie są dostępne do pobrania z oficjalnej strony.
Wyszukiwanie tych szablonów wymaga przekopywania Internetu co może być męczące ze
względu na zaśmiecone wyniki wyszukiwania.
Dostępność dodatkówSystemy CMS posiadają wiele wbudowanych funkcji, aczkolwiek dla wielu stron www
funkcje te okażą się niewystarczające. Jest tak zwłaszcza gdy mowa o rozbudowanych
aplikacjach internetowych. Jednak nie trzeba ograniczać się do tego co oferuje nam system
CMS w swojej domyślnej konfiguracji. Funkcjonalność omawianych systemów może zostać
łatwo rozszerzona poprzez instalację specjalnych dodatków. Dodatki takie mogą nie tylko
zapewniać nowe funkcje ale także usprawniać działanie tych wbudowanych.
WordPress
Dodatki dla systemu WordPress zwane są „plugins”, co oznacza nic innego jak „wtyczki”.
Liczba wtyczek dostępnych dla tego systemu jest imponująca i wynosi ponad 10 000 (i cały
czas wzrasta). Tak duża ich liczba powoduje, że wiele funkcji, których mogą potrzebować
nawet najbardziej wybredni właściciele stron www, została już prawdopodobnie
zaimplementowana.
Główne źródło z którego można pobierać wtyczki to, tak samo jak w przypadku szablonów,
oficjalna strona systemu. Przeszukiwanie dostępnych wtyczek ułatwia możliwość wyboru
sortowania.
Niestety wiele dostępnych wtyczek jest mocno ograniczonych lub zostały napisane w sposób
niedbały.
Ponadto WordPress nie nakłada wystarczająco restrykcyjnych wymogów względem kodu
publikowanych dodatków przez co ich jakość oraz dokumentacja w postaci komentarzy PHP
78
bywa nieraz wątpliwa. Może to mieć znaczenie dla programistów studiujących np. sposób
działania wtyczki lub planujących utworzenie własnych dodatków w oparciu o kod już
istniejących.
Dodatkową wadą z punkt widzenia programistów jest moim zdaniem także fakt, że wszystkie
pliki z kodem PHP posiadają rozszerzenie *.php co utrudnia odróżnianie głównych plików
modułów od plików pomocniczych i bibliotek.
Joomla
Dodatki do systemu Joomla nazwano „extensions” co po Polsku znaczy „rozszerzenia”. Ich
liczba nie jest tak duża jak w przypadku systemu WordPress i wynosi 5378. Rozszerzenia te
zapewniają wiele dodatkowych funkcji ale nie aż tyle co wtyczki do systemu WordPress.
Główne miejsce z którego można przeszukiwać rozszerzenia do systemu Joomla to jej
oficjalna strona. Niestety paczki z rozszerzeniami widocznymi na tej stronie nie są
przechowywane bezpośrednio na serwerze Joomli lecz na różnych serwerach zewnętrznych,
należących zazwyczaj do twórców danego rozszerzenia. Nie jest to zbyt dobre rozwiązanie
ponieważ dostępność rozszerzeń staje się zależna od dostępności wielu zewnętrznych stron.
Niestety i tu wiele rozszerzeń jest napisanych w sposób bardzo niedbały. Więcej na ten temat
w podrozdziale „Jakość kodu”.
Drupal
Drupal udostępnia poprzez swoją oficjalną stronę około 4 tysiące dodatkowych modułów.
Moduły te są przechowywane w oficjalnym repozytorium CVS20 tego systemu CMS. Dzięki
temu programiści mogą pobierać te moduły nie tylko poprzez samą stronę www ale także
poprzez narzędzia umożliwiające łączenie się z usługą CVS.
To co odróżnia moduły Drupala od modułów pozostałych dwóch systemów zarządzania
treścią to bardzo wysoka jakość wykonania. Twórców dodatkowych modułów obowiązują
również bardzo rygorystyczne zasady dotyczące jakości kodu oraz umieszczania
20 CVS – Concurrent Version System – system kontroli wersji ułatwiający grupową pracę nad kodem aplikacji. Wiele interesujących iformacji na jego temat można przeczytać w książce Jennifer Vesperman Essantial CVS, wydanej przez O’Reilly - http://oreilly.com/catalog/9780596527037. Ciekawą pozycją jest również darmowa książka Open Source Development with CVS autorstwa Karla Fogela i Moshe Bar - http://cvsbook.red-bean.com/
79
obowiązkowych komentarzy co jest nieocenione dla programistów studiujących sposób
działania takich modułów.
Dodanie do swojej witryny opartej na Dupalu jakiejś określonej funkcji może nieraz
wymagać zainstalowania kilku dodatkowych modułów. Wynika to z tego, że wiele modułów
jest od siebie zależnych. Niektóre moduły nie zapewniają nawet żadnej dodatkowej
funkcjonalności same z siebie – udostępniają one jedynie pewien zbiór funkcji, z których
korzystają inne moduły.
Wiele rzeczy można łatwo zrobić w tym systemie aczkolwiek nieraz trzeba wiedzieć jakie
dodatkowe moduły należy zainstalować. Wiele rzeczy można także zrobić na wiele różnych
sposobów. Utrudnia to budowę strony początkującym użytkownikom.
Ponadto moduły przechowywane w repozytorium plików CVS są regularnie przeglądane
przez Drupal Security Team – zespół dbający o bezpieczeństwo systemu Drupal. Dzięki temu
nie trzeba się obawiać, że pobierany moduł może w jakiś sposób narazić stronę. Moduły
uznane za niebezpieczne są zawsze odpowiednio oznaczane tak aby pobierające je osoby
zdawały sobie sprawę z ryzyka.
Dodatkowo społeczeństwo Drupala udostępnia na oficjalnej stronie wiele modułów
posiadających bardzo zaawansowaną funkcjonalność, których odpowiedniki dla innych
systemów zarządzania treścią są często płatne.
Wnioski
Nie podlega wątpliwościom, że najwięcej solidnych darmowych dodatków dostępnych jest
dla systemu Drupal. Dodatki tę są pisane zgodnie z zasadami pisania kodu modułów dla
Drupala oraz są regularnie sprawdzane pod kątem bezpieczeństwa. Dodatki systemu
WordPress lub Joomla swoją ilością przewyższają ilość dodatków dla Drupala ale wiele z
nich nie jest wystarczająco solidna. Ponadto przechowywanie dodatków dla systemu Joomla
na zewnętrznych serwerach niepotrzebnie uzależnia użytkowników Joomli od stron innych
niż oficjalna strona tego CMS-a oraz może się przyczynić do zmniejszenia bezpieczeństwa.
Wsparcie dla multimediów (w tym zdjęć)Strony internetowe złożone z samego tekstu są mało atrakcyjne i mniej przyciągają
odwiedzających. Strony takie są też zdecydowanie słabiej zapamiętywane. Poza tym brak
ilustracji towarzyszących tekstom publikowanym na łamach witryny sprawia, że są one
80
zdecydowanie uboższe – rzeczywiście, nie da się niczego tak dobrze przedstawić jak jest to
możliwe poprzez odpowiednią fotografię lub rysunek.
Dlatego tak ważne jest aby system CMS umożliwiający administrację stroną pozwalał na
łatwe publikowanie multimediów, czyli nie tylko zdjęć ale też innych form przekazu takich
jak filmy wideo lub ścieżki audio.
Zarówno WordPress jak i Drupal czy Joomla posiadają duże wsparcie dla multimediów.
Związane ze zdjęciami funkcje wbudowane najlepiej prezentują się w systemie WordPress
chociaż Drupal 7 też ma się czym pochwalić. Systemy te umożliwiają stworzenie galerii
zdjęciowej bez konieczności instalowania jakichkolwiek dodatków. Ponadto system
WordPress umożliwia wstawianie do artykułów filmów oraz ścieżek audio. Oprócz tego
wszystkie porównywane systemy CMS umożliwiają wstawianie zdjęć do postów, choć w
systemie Drupal jest to mocno ograniczone, ponieważ wgrywane zdjęcia nie mogą być
automatycznie osadzane w środku tekstu – aby to osiągnąć należy ręcznie wpisywać
odpowiedni kod HTML. Automatyczne wstawianie śródliniowych zdjęć w Drupalu osiągnąć
można np. poprzez instalację modułów WYSIWYG oraz Insert.
W porównaniu do systemów Drupal i WordPress, system Joomla nie posiada zbyt wielu
wbudowanych funkcji umożliwiających łatwą publikację zdjęć, co jednak nie stanowi dużej
przeszkody, gdyż aby zapewnić sobie lepszą obsługę zdjęć wystarczy doinstalować
odpowiednie rozszerzenia.
Wiele zadań związanych z prezentowaniem fotografii, publikowaniem filmów czy muzyki,
wymaga rozszerzania możliwości systemu CMS poprzez instalację dodatków. Na szczęście
dodatków takich jest mnóstwo. Wystarczy zajrzeć na jedną z oficjalnych stron omawianych
CMS-ów aby się o tym przekonać. Dzięki dodatkom bez większego trudu zbudujemy stronę
www bogato wyposażoną w treści multimedialne.
Wnioski
Wszystkie trzy porównywane systemy pozwalają na łatwe wstawianie zdjęć do postów, choć
systemy WordPress i Drupal są pod tym względem lepiej wyposażone od systemu Joomla. W
rzeczywistości nie jest to jednak zbyt istotne, ponieważ obsługę multimediów możemy
usprawnić poprzez instalację jednych z wielu dostępnych dodatków, pozwalających na
budowę strony www bogato wyposażonej w multimedia.
81
Łatwość aktualizowania systemu, polityka publikowania aktualizacjiSystemy CMS, jak każde poważne oprogramowanie, są stale rozwijane i ulepszane. Oprócz
pojawiania się nowych funkcji, wypuszczane są poprawki, które mają na celu załatanie dziur
w oprogramowaniu oraz usprawnienie jego działania. Instalowanie aktualizacji zabezpieczeń
jest kluczowe z punktu widzenia bezpieczeństwa strony www i podpierającego ją CMS-a,
ponieważ chroni system przed wrogim działaniem złośliwych użytkowników i włamywaczy.
WordPress
System WordPress umożliwia bardzo łatwą automatyczną aktualizację. Zakres działań
wymaganych w celu zaktualizowania systemu do nowszej wersji ogranicza się do kliknięcia
jednego przycisku w panelu administracyjnym i potwierdzenia chęci aktualizacji. Dzięki temu
każdy może bez trudu zaktualizować swój system. Należy być jednak świadomym, że
aktualizacja nie musi zakończyć się powodzeniem, dlatego zalecane jest wykonanie kopii
zapasowej bazy danych i plików strony. Dzięki temu w przypadku wystąpienia problemów
można będzie przywrócić witrynę do stanu wcześniejszego.
Wersje systemu WordPress są oznaczane trzyczęściowym numerem, gdzie pierwsze dwa
numery oznaczają wersję systemu a ostatni numer odnosi się do aktualizacji zabezpieczeń i
innych poprawek. Dla przykładu wersja 3.0.1 nie jest w rzeczywistości trzecią wersją systemu
ponieważ pod drodze pojawiły się wersje takie jak 2.7.0 itp. Cyfra „1” oznacza tu pierwszą
poprawkę.
Polityka publikowania aktualizacji systemu WordPress polega na dość częstym publikowaniu
nowszych wersji posiadających nowe funkcje i ulepszenia. Zmianie ulegają wtedy pierwsze
dwie cyfry w oznaczeniu wersji (bądź sama druga cyfra). Poprawki zaś, czyli aktualizacje
zmieniające tylko ostatni człon numeru wersji, nie dodają nowych funkcjonalności.
Wraz z publikacją nowej wersji zmieniają się niektóre składniki systemu. Powoduje to, że
spora część wtyczek dla systemu WordPress musi być regularnie aktualizowana aby zapewnić
ich poprawne działanie w nowej wersji systemu.
Starsze wersje zaś przestają być wspierane, co oznacza, że przestają pojawiać się dla nich
aktualizacje zabezpieczeń. Poza tym wtyczki po dopasowaniu do wymogów nowszej wersji
mogą przestać działać w starszej wersji systemu.
82
Przykład: posiadamy rozbudowaną stronę opartą na systemie WordPress. System nasz
korzysta z napisanego na zlecenie dodatku. Wkrótce dodatek ten może okazać się niezgodny z
nowszą wersją systemu, przez co nie będziemy mogli zaktualizować swojego CMS-a. W
związku z tym nie będziemy mogli instalować aktualizacji zabezpieczeń przez co nasza strona
zostanie narażona na ataki hackerskie.
Joomla
System Joomla umożliwia dokonywanie automatycznych aktualizacji w podobny sposób jak
system WordPress. Aktualizacje te nie powinny przysporzyć nikomu kłopotu, pod warunkiem,
że pamiętamy o robieniu kopii zapasowej przed dokonaniem aktualizacji.
Oznaczenia wersji systemu Joomla są dokładnie identyczne jak w przypadku systemu
WordPress. Pierwsze dwie liczby to numer wersji, a ostatnia liczba to numer poprawki.
Polityka publikowania aktualizacji systemu Joomla również jest zbliżona do tej systemu
WordPress, z tą różnicą jednak, że nowe funkcje pojawiają się tu dość rzadko. Dotychczas
Joomla występowała jedynie w wersji 1.0.x, wersji 1.5.x oraz 1.6.x (teraźniejsza). Każda z
tych wersji posiadała nowe funkcje oraz była lepsza od swojego poprzednika. Zmiany w
systemie towarzyszące wypuszczeniu wersji 1.6 były na tyle duże, że wszelkie rozszerzenia
muszą być przerabiane tak aby w niej działały.
Publikacja nowej wersji oznacza koniec wsparcia wersji starszej. Aby zapewnić stronie
aktualizacje zabezpieczeń należy najpierw zaktualizować system CMS do najnowszej wersji.
Drupal
Również i Drupal umożliwia dokonywanie automatycznych aktualizacji systemu CMS oraz
zainstalowanych dodatkowych modułów.
Oznaczenia wersji, które stosuje ten CMS składają się z dwóch numerów, gdzie pierwszy to
numer wersji systemu a drugi to numer poprawki, np. 6.17.
Polityka publikowania aktualizacji dla systemu Drupal jest zupełnie odmienna niż w
przypadku systemów WordPress i Joomla. Częste poprawki usprawniające działanie systemu i
zapewniające mu większe bezpieczeństwo nie dodają nowych funkcji. Nowe funkcje
wbudowane w system pojawiają się tylko podczas wypuszczania nowej wersji, takiej jak 6.x
lub 7.x. Różnice pomiędzy kolejnymi wersjami systemu Drupal są tak duże, że nie są ze sobą
83
kompatybilne, przez co dodatkowe moduły napisane dla wersji 6.x nie będą działać w wersji
7.x.
Publikacja zupełnie nowej wersji Drupala nie oznacza końca wspierania wersji wcześniejszej.
Wystarczy wejść na oficjalną stronę tego systemu CMS aby się o tym przekonać. Aktualizacje
zabezpieczeń pojawiają się regularnie zarówno dla nowszej wersji jak i starszej wersji
systemu. W związku z tym nie trzeba aktualizować systemu do najnowszej wersji aby
zachować bezpieczeństwo witryny. Dzięki temu nie trzeba się przejmować
niekompatybilnością modułów dla różnych wersji.
Przykład: posiadamy rozbudowaną stronę opartą na systemie Drupal. System nasz korzysta z
napisanego na zlecenie dodatkowego modułu. Moduł ten będzie niezgodny z następną wersją
systemu Drupal przez co nie będziemy mogli zaktualizować systemu do nowszej wersji bez
uprzedniego zamówienia nowszej wersji naszego dodatkowego modułu. Jednak nie musimy
się tym przejmować ponieważ po pojawieniu się nowszej wersji systemu Drupal, używana
przez nas starsza wersja będzie nadal wspierana i będą pojawiać się dla aktualizacje
zabezpieczeń i poprawki.
Wnioski
Wszystkie trzy systemy CMS posiadają podobną funkcję automatycznej aktualizacji. Polityka
wypuszczania nowych wersji systemów WordPress i Joomla jest wątpliwa - brak wsparcia i
aktualizacji zabezpieczeń dla starszych wersji tych CMS-ów to podejście nieprofesjonalne.
Podobnie wyglądała by kwestia systemów z rodziny Windows, gdyby firma Microsoft po
wypuszczeniu nowszej wersji systemu, przestawała wspierać i tworzyć dodatki Service Pack
dla wersji starszych. Na szczęście polityka systemu Drupal jest odmienna – zapewnione jest
wsparcie dla dwóch najnowszych wersji tego CMS-a.
2.3.2. ZAAWANSOWANE CECHY I FUNKCJEWłaściwości i cechy opisane w tej kategorii będą istotne tylko dla bardziej zaawansowanych
użytkowników, którym zależy na bardziej zaawansowanych funkcjach, takich jak np.
workflow. Informacje zawarte w tej sekcji będą istotne dla osób tworzących strony
wielojęzyczne lub wymagających rozbudowanej kontroli dostępu i zarządzania
użytkownikami.
84
Jakość generowanego kodu HTMLNa początek przyjrzymy się kodom źródłowym stron generowanych przez trzy badane
systemy CMS. Jakość wynikowego kodu HTML ma znaczenie, ponieważ:
• Poprawia indeksowanie strony przez wyszukiwarki
• Dobrze napisany kod jest lżejszy przez co strona szybciej się ściąga
• Nie zawiera błędów dzięki czemu może lepiej działać
• Wygląda profesjonalnie i jest przejrzysty co ułatwia pracę nad stroną
WordPress
Generowany przez system WordPress kod jest w pełni zgodny ze standardem HTML 521 choć
póki co nie ma w nim elementów typowych dla HTML 5. Validator W3C po sprawdzeniu
strony głównej zwraca komunikat:
Wersja piąta języka HTML to jeden z najnowszych standardów sieciowych, który swoimi
możliwościami przypomina technologię Flash. System WordPress pod względem kodu
ewidentnie stara się być na czasie i mimo, że wykorzystano jedynie znaczniki XHTML 1.0
Strict zgodne z HTML 5, to system ten czeka już tylko na moment, w którym nowa wersja
języka HTML będzie szeroko obsługiwana przez przeglądarki.
Poza poprawnością składniową kodu źródłowego strony głównej systemu WordPress, kod
wynikowy jest przejrzysty i czytelny, a szablon strony jest prawidłowo oparty na znacznikach
<div> a nie na tabeli. Poniżej przykładowy fragment kodu nagłówka strony głównej:
<!DOCTYPE html><html dir="ltr" lang="en-US"><head> <meta charset="UTF-8" /> <title>Testing WordPress | Just another WordPress site</title> <link rel="profile" href="http://gmpg.org/xfn/11" /> <link rel="stylesheet" type="text/css" media="all" href="http://localhost/wordpress_3/wp-
21 HTML 5 – opis tego nowego standardu dostępny jest pod adresem http://dev.w3.org/html5/spec/Overview.html
85
content/themes/twentyten/style.css" /> <link rel="pingback" href="http://localhost/wordpress_3/xmlrpc.php" /> <link rel="alternate" type="application/rss+xml" title="Testing WordPress » Feed" href="http://localhost/wordpress_3/feed/" /> <link rel="alternate" type="application/rss+xml" title="Testing WordPress » Comments Feed" href="http://localhost/wordpress_3/comments/feed/" /> <link rel="EditURI" type="application/rsd+xml" title="RSD" href="http://localhost/wordpress_3/xmlrpc.php?rsd" /> <link rel="wlwmanifest" type="application/wlwmanifest+xml" href="http://localhost/wordpress_3/wp-includes/wlwmanifest.xml" /> <link rel='index' title='Testing WordPress' href='http://localhost/wordpress_3/' /> <meta name="generator" content="WordPress 3.0.1" /></head>
Joomla
Kod źródłowy strony głównej wygenerowanej przez system Joomla jest całkowicie zgodny ze
standardem XHTML 1.0 Transitional. Format ten wspiera pewne elementy języka HTML,
których wykorzystywanie jest niewskazane dlatego jest on uznawany za przestarzały i nie
zalecany. Validator zawraca komunikat o poprawności kodu:
Poza poprawną składnią, kod HTML generowany przez system Joomla jest dobrej jakości
choć miejscami mógłby być bardziej przejrzysty. Poniżej fragment kodu nagłówka strony:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-gb" lang="en-gb" dir="ltr" > <head> <base href="http://localhost/joomla_1.6/index.php/" /> <meta http-equiv="content-type" content="text/html; charset=utf-8" /> <meta name="robots" content="index, follow" /> <meta name="keywords" content="joomla, Joomla" /> <meta name="rights" content="" /> <meta name="language" content="en-GB" /> <meta name="description" content="Joomla! - the dynamic portal engine and content management system" /> <meta name="generator" content="Joomla! 1.6 - Open Source Content Management" />
86
<title>Home</title> <link href="/joomla_1.6/index.php?format=feed&type=rss" rel="alternate" type="application/rss+xml" title="RSS 2.0" /> <link href="/joomla_1.6/index.php?format=feed&type=atom" rel="alternate" type="application/atom+xml" title="Atom 1.0" /> <link href="/joomla_1.6/templates/beez_20/favicon.ico" rel="shortcut icon" type="image/vnd.microsoft.icon" /> <script type="text/javascript" src="/joomla_1.6/media/system/js/core.js"></script> <script type="text/javascript" src="/joomla_1.6/media/system/js/mootools-core.js"></script> <script type="text/javascript" src="/joomla_1.6/media/system/js/mootools-more.js"></script> <script type="text/javascript">
window.addEvent('domready', function() {$$('.hasTip').each(function(el) {
var title = el.get('title');if (title) {
var parts = title.split('::', 2);el.store('tip:title', parts[0]);el.store('tip:text', parts[1]);
}});var JTooltips = new Tips($$('.hasTip'), { maxTitleChars: 50,
fixed: false});});
function keepAlive() { var myAjax = new Request({method: "get", url: "index.php"}).send();} window.addEvent("domready", function(){ keepAlive.periodical(8999940000); }); </script>
<link rel="stylesheet" href="/joomla_1.6/templates/beez_20/css/template.css" type="text/css" /> <link rel="stylesheet" href="/joomla_1.6/templates/beez_20/css/position.css" type="text/css" media="screen,projection" /> <link rel="stylesheet" href="/joomla_1.6/templates/beez_20/css/layout.css" type="text/css" media="screen,projection" /> <link rel="stylesheet" href="/joomla_1.6/templates/beez_20/css/print.css" type="text/css" media="Print" /> <link rel="stylesheet" href="/joomla_1.6/templates/beez_20/css/general.css" type="text/css" /> <link rel="stylesheet" href="/joomla_1.6/templates/beez_20/css/general_mozilla.css" type="text/css" /> <link rel="stylesheet" href="/joomla_1.6/templates/beez_20/css/personal.css" type="text/css" /> <!--[if lte IE 6]>
87
<link href="/joomla_1.6/templates/beez_20/css/ieonly.css" rel="stylesheet" type="text/css" />
<style type="text/css">@@$$#css0-</style> <![endif]--> <!--[if IE 7]> <link href="/joomla_1.6/templates/beez_20/css/ie7only.css" rel="stylesheet" type="text/css" /> <![endif]--> <script type="text/javascript" src="/joomla_1.6/templates/beez_20/javascript/md_stylechanger.js"></script> <script type="text/javascript" src="/joomla_1.6/templates/beez_20/javascript/hide.js"></script> <script type="text/javascript" src="/joomla_1.6/templates/beez_20/javascript/html5.js"></script>
<script type="text/javascript"> var big ='72%'; var small='53%'; var altopen='is open'; var altclose='is closed'; var bildauf='/joomla_1.6/templates/beez_20/images/plus.png'; var bildzu='/joomla_1.6/templates/beez_20/images/minus.png'; var rightopen='Open info'; var rightclose='Close info'; </script>
</head>
Drupal
Strony generowane przez system Drupal są zgodne z, będącym równie na czasie jak HMTL 5,
standardem XHTML + RDFa22. Validator W3C po sprawdzeniu strony głównej zwraca
komunikat:
Drupal 7 posiada natywną obsługę standardu RDFa. Standard ten ma za zadanie ułatwić
maszynom przeszukującym sieć Internet zrozumienie treści. Np. pisząc „założyciele firmy
Google” mamy na myśli dwie konkretne osoby. Niestety wyszukiwarki nie będą wiedzieć, o
22 RDFa – standard pozwalający na umieszczanie w kodzie XHTML specjalnych meta danych odczytywanych przez wyszukiwarki. Dane te mają na celu informowanie wyszukiwarek czego dany fragment indeksowanej strony. Więcej o standardzie RDFa: http://en.wikipedia.org/wiki/RDFa.
88
kogo chodzi, więc można umieścić w kodzie HTML specjalną informację o tym kogo dotyczy
wspomniany zwrot. Dodatkowe informacje na temat RDFa znajdują się pod adresem
http://www.w3.org/TR/xhtml-rdfa-primer/.
Oprócz poprawności składniowej generowany przez system Drupal kod XHTML jest zadbany
i przejrzysty. Poniżej fragment kodu z nagłówka strony głównej:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd"><html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" version="XHTML+RDFa 1.0" dir="ltr" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/terms/" xmlns:foaf="http://xmlns.com/foaf/0.1/" xmlns:owl="http://www.w3.org/2002/07/owl#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:rss="http://purl.org/rss/1.0/" xmlns:sioc="http://rdfs.org/sioc/ns#" xmlns:sioct="http://rdfs.org/sioc/types#" xmlns:skos="http://www.w3.org/2004/02/skos/core#" xmlns:xsd="http://www.w3.org/2001/XMLSchema#">
<head profile="http://www.w3.org/1999/xhtml/vocab"> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <link rel="shortcut icon" href="http://localhost/_DRUPAL7/misc/favicon.ico" type="image/vnd.microsoft.icon" /> <meta name="Generator" content="Drupal 7 (http://drupal.org)" /> <link rel="alternate" type="application/rss+xml" title="Testing Drupal 7 RSS" href="http://localhost/_DRUPAL7/rss.xml" /> <title>Testing Drupal 7</title> <link type="text/css" rel="stylesheet" href="http://localhost/_DRUPAL7/sites/default/files/css/css_oApRS-gvZ9lxm7lFiX35ij-VWRHmiOZoCi9liznUGHg.css" media="all" /> <link type="text/css" rel="stylesheet" href="http://localhost/_DRUPAL7/sites/default/files/css/css_s-tbAaa61TPyadGqOqG-LJ0G-qSRA5VW-1sPhY6w35I.css" media="print" />
<!--[if lte IE 7]> <link type="text/css" rel="stylesheet" href="http://localhost/_DRUPAL7/themes/bartik/css/ie.css?l6gxjr" media="all" /> <![endif]-->
<!--[if IE 6]> <link type="text/css" rel="stylesheet" href="http://localhost/_DRUPAL7/themes/bartik/css/ie6.css?l6gxjr" media="all" /> <![endif]--></head>
89
Wnioski
Kod HTML stron generowanych przez poszczególne systemy CMS nie różni się zbytnio pod
względem jakości. Najlepiej wypada tu Drupal 7, który posiada natywne wsparcie dla
standardu RDFa. WordPress zaś stara się przygotować na HTML 5 czyniąc swój kod
XHTML-owy zgodnym z tym nowym standardem.
Własne typy podstronKażda złożona witryna posiada podstrony różnego typu. Mogą do nich należeć np.: zwykłe
podstrony, artykuły, wpisy aktualności, podstrony forum czy posty bloga. Dlatego tak ważne
jest aby móc dodawać nowe typy podstron. Dzięki podzieleniu podstron na różne rodzaje,
możemy łatwo wyświetlać listę podstron danego rodzaju.
System Drupal jako jedyny posiada natywną funkcjonalność umożliwiającą definiowanie
dowolnej liczby różnych typów podstron. Ponadto dzięki modułowi CCK
(http://www.drupal.org/project/cck) możliwe staje się definiowanie dowolnych dodatkowych
pól danych (w Drupal 7 opcja ta jest wbudowana w system), a moduł Views
(http://www.drupal.org/project/views) umożliwia tworzenie dynamicznych list prezentujących
wpisy dowolnego typu. Dzięki modułowi Views możliwe jest wyświetlanie nie tylko całych
postów ale także ich fragmentów, np. tylko załączonych zdjęć – w celu zbudowania ciekawej
galerii zdjęciowej. Wspomniane funkcje to tylko namiastka możliwości modułów CCK i
Views.
Niestety ani WordPress ani Joomla nawet po zainstalowaniu dodatkowych modułów
umożliwiających definiowanie nowych typów podstron nie posiadają takich możliwości jak
Drupal. Ciekawa jest wtyczka do systemu WordPress o nazwie Flutter. Umożliwia ona
definiowanie własnych typów podstron, aczkolwiek nie dorównuje ona podobnej
funkcjonalności wbudowanej w system Drupal.
Wnioski
Okazuje się, że pod pewnymi względami systemy WordPress i Joomla są dużo bardziej
ograniczone niż system Drupal. W systemach tych bowiem nie ma wbudowanej opcji
tworzenia własnych typów podstron co może utrudnić pracę podczas budowy bardzo złożonej
witryny.
Workflow
90
Jak wspomniałem w pierwszym rozdziale, dobry CMS powinien udostępniać jakiś system
typu workflow23. System workflow polega na automatyzacji pewnych procesów, podczas
której pewne zadania są przekazywane od jednego uczestnika do następnego. System
workflow powinien też uniemożliwiać nieuprawnionym użytkownikom pomijanie pewnych
kroków przez które musi przejść dane zadanie.
Gdy mowa o systemach CMS, workflow wiąże się zazwyczaj z przechodzeniem artykułów
przez pewne fazy zanim zostaną one opublikowane w sieci. Przykładowe kroki, które mogą
być wymagane przed opublikowaniem artykuł, to np.: artykuł do przejrzenia → artykuł do
poprawienia → artykuł do zatwierdzenia, przy czym każdy etap przetwarzania artykułu może
być realizowany tylko przez uprawnioną do tego osobę.
Dlatego w przypadku stron www prowadzonych przez więcej niż jedną osobę system
workflow może okazać się bardzo przydatny bądź wręcz pożądany. Przyjrzyjmy się zatem
możliwościom jakie oferują wybrane systemy CMS.
WordPress
System WordPress posiada kilka wbudowanych stanów dla postów: roboczy (draft), do
zatwierdzenia (pending review) oraz opublikowany (published). Możliwość zmiany tych
stanów przez różnych użytkowników wspólnie obsługujących jedną witrynę stanowi pewnego
rodzaju system workflow. Ilość stanów można zwiększyć poprzez instalację wtyczki Edit
Flow.
Niestety opisana wyżej funkcjonalność jest bardzo ograniczona ponieważ zmiany stanu
artykułu może dokonać dowolny użytkownik, który może tworzyć lub edytować artykuły.
Dlatego wbudowany w WordPress system workflow nie nadaje się dla dużych witryn
obsługiwanych przez bardzo wiele osób. Mechanizm ten będzie się sprawdzał w przypadku
witryny obsługiwanej przez 3 osoby, ale już nie, tak jak to jest np. w wydawnictwach, przez
całą redakcję.
Brak jest solidnych wtyczek udostępniających profesjonalny system workflow przez system
WordPress, raczej nie nadaje się dla stron, które takiej funkcjonalności wymagają.
Joomla
23 Garść informacji wyjaśniających dokładnie czym jest system workflow dostępna jest pod adresem http://en.wikipedia.org/wiki/Workflow
91
Joomla nie posiada wbudowanej obsługi nawet najbardziej podstawowego workflow.
Dostępny jest jeden płatny dodatek o nazwie Joomla Workflow, aczkolwiek nie jest nawet
trochę zbliżony swoimi możliwościami do możliwości systemu Drupal. Poza tym dodatkiem
ciężko jest znaleźć coś odpowiedniego dla tego systemu CMS.
Drupal
Jeśli chodzi o system workflow to trzeba przyznać, że CMS Drupal został wyposażony lepiej
niż wiele płatnych systemów zarządzania treścią, kosztujących tysiące dolarów. Wyposażenie
swojej kopii Drupala w workflow wymaga instalacji dodatkowego modułu dostępnego pod
adresem http://www.drupal.org/project/workflow.
Udostępniany przez społeczność Drupala system workflow posiada między innymi
następujące możliwości:
• Tworzenie dowolnej ilości stanów artykułów
• Przypisywanie różnych obowiązujących przebiegów w zależności od typu podstrony,
której dotyczą (patrz wcześniejszy podrozdział – Własne typy podstron)
• Przypisywanie uprawnień do przechodzenia pomiędzy stanami wybranym grupom
użytkowników. Grupy są wbudowaną funkcją systemu Drupal. Ogólnie oznacza to, że
można ograniczyć zakres działań np. recenzenta do zmiany stanu artykułów wyłącznie
ze stanu „wymaga sprawdzenia’ do np. stanu „gotowy do opublikowania”.
• Możliwość ustawiania komentarzy podczas przechodzenia między stanami.
• Możliwość śledzenia przebiegu workflow
Dodatkowo po włączeniu wbudowanego w Drupala modułu „Trigger”, możliwe staje się
skonfigurowanie np. wysyłania emaili powiadamiających o przejściu artykułu do nowego
stanu.
92
Rysunek . Użytkownik posiadający odpowiednie uprawnienia może zmienić stan artykułu. W tym przypadku jest to zmiana ze stanu „Needs review” na „Ready for publishing”.
93
Rysunek . Konfiguracja uprawnień grup użytkowników do zmieniania stanu artykułów. Ilość dostępnych kroków została skonfigurowana chwilę wcześniej.
Wnioski
Systemy WordPress i Joomla nie maja wbudowanej obsługi workflow ani nie posiadają
żadnych dodatków, które umożliwiły by dokładne kontrolowanie przechodzenia artykułów
94
przez kolejne stany. System Drupal zaś, posiada dostępny jako moduł dodatkowy,
rozbudowany system workflow, który wystarczy do obsługi nawet dużego wydawnictwa.
Zarządzanie użytkownikamiZarządzanie użytkownikami to można rzec jedna z podstawowych funkcji systemu CMS.
Ponieważ system CMS umożliwia zmianę treści na stronie, za której treść odpowiadamy, w
związku z tym dostęp do narzędzi administracyjnych musi być zabezpieczony hasłem.
Między innymi właśnie dlatego wykorzystywany jest mechanizm uwierzytelniania oparty na
zapisanych w systemie kontach użytkowników.
Z posiadania oddzielnych kont dla oddzielnych użytkowników wprowadzających zmiany na
stronie wynikają następujące korzyści:
• Kontrola uprawnień – Użytkownikom można przypisywać role, a tym z kolei
uprawnienia. Nadając odpowiednie uprawnienia możemy umożliwić konkretnym
użytkownikom wykonywanie jedynie pewnych określonych czynności.
• Śledzenie działań użytkowników – Większość systemów CMS rejestruje ważniejsze
poczynania swoich użytkowników.
• Blokowanie dostępu użytkowników do strony www lub jej części.
Przyjrzyę się teraz wybranym systemom CMS i porównam ich możliwości związane z
zarządzaniem użytkownikami.
WordPress
System WordPress pozwala na dodawanie do systemu dowolnej liczby użytkowników.
Użytkownikami tymi można łatwo zarządzać poprzez specjalną stronę administracyjną.
Domyślna instalacja systemu WordPress posiada pięć ról użytkowników. Są to:
• Administrator – posiada pełne uprawnienia do zarządzania witryną
• Editor – jego uprawnienia ograniczone są do zarządzania wszystkimi postami,
podstronami i komentarzami.
• Author – może dodawać i edytować posty.
• Contributor – może edytować i usuwać nieopublikowane posty.
95
• Subscriber – może przeglądać treść i dodawać komentarze.
WordPress nie posiada wbudowanej opcji zarządzania rolami, ale na szczęście jej dodanie nie
jest skomplikowane. Wystarczy pobrać wtyczkę dostępną pod adresem http://www.im-web-
gefunden.de/wordpress-plugins/role-manager/ i zainstalować ją w systemie. Wtyczka ta
pozwala edytować uprawnienia wszystkich ról, dodawać i usuwać role oraz zmieniać ich
nazwy.
Rysunek . Wtyczka Role Manager pozwala edytować uprawnienia dla dowolnej roli. Tu edycja roli "Editor".
Możliwość edycji uprawnień to ważna cecha aczkolwiek uważam, że poziom na jakim można
kontrolować działania użytkowników jest tu miejscami zbyt ogólnikowy (np. brak oddzielnej
opcji zezwalającej na włączanie i wyłączanie widet-ów wyświetlanych w pasku bocznym
strony).
Poza tym zarządzanie użytkownikami systemu WordPress jest dość ograniczone i wiele
podstawowych działań, takich jak chociażby blokowanie konta użytkownika bez jego
usuwania, zazwyczaj wymaga instalowania wtyczek. Obsługa tak podstawowej funkcji jak
konta użytkowników powinna być wbudowana w system CMS razem ze wszystkimi
istotnymi funkcjami.
Joomla
Zarządzanie użytkownikami w systemie Joomla jest trochę bardziej rozbudowane. Oprócz
zarządzania użytkownikami dostępne jest także wbudowane w system zarządzanie rolami,
96
zwanymi w Joomli „grupami”. Zaimplementowano tu także mechanizm dziedziczenia
uprawnień po rolach nadrzędnych. Standardowo dostępne role to:
• Registered – użytkownicy tej grupy mogą mieć dostęp do zastrzeżonej części witryny
niedostępnej dla gości.
o Author – autorzy mogą tworzyć artykuły
o Editor – edytorzy mogą edytować artykuły swoje oraz dowolnych innych
autorów
o Publisher – użytkownicy tej grupy mogą robić wszystko to co edytorzy oraz
mogą też publikować artykuły pisane przez edytorów i autorów
• Public
o Manager – ma te same uprawnienia co Publisher oraz dodatkowo ma dostęp do
panelu administracyjnego
o Administrator – użytkownicy należący do grupy administratorów oprócz
wszystkich zadań związanych z edycją artykułów mogą intalować rozszerzenia
systemu Joomla, zmieniać wygląd strony oraz ustawiać uprawnienia dla kont
użytkowników (oprócz tych należących do grupy Super User)
o Super Users – użytkownicy tej grupy mają dostęp do wszystkich opcji
wbudowanych w panel administracyjny systemu Joomla
Oprócz domyślnych ról użytkowników można też dodawać nowe role i przypisywać im
uprawnienia.
97
Rysunek . System Joomla - okno konfiguracji uprawnień dotyczących zarządzania użytkownikami.
W systemie Joomla 1.6 zaimplementowano zarządzanie uprawnieniami aczkolwiek sposób
zarządzania nimi jest dosyć nieprofesjonalny. Nie ma mianowicie jednej podstrony
zarządzania uprawnieniami tak jak to było w przypadku systemu WordPress – konfiguracja
uprawnień związanych z poszczególnymi aspektami witryny, np. artykułami lub
użytkownikami, jest dostępna w oknie opcji danej funkcjonalności. Czyli np. aby edytować
uprawnienia związane z publikacją artykułów należy przejść do managera artykułów. Efektem
tego jest niewygodna obsługa ustawień uprawnień. Aby np. sprawdzić wszystkie uprawnienia
dla danej roli konieczne jest prześledzenie jej ustawień na wielu oddzielnych podstronach
panelu administracyjnego.
Poza opcjami zarządzania rolami i uprawnieniami możliwe jest blokowanie użytkowników
bez kasowania ich kont
Drupal
System Drupal, tak jak Joomla i WordPress posiada rozbudowany panel zarządzania
użytkownikami, którym można przypisywać dowolne role. Dwie domyślne role wbudowane
w system to:
• Użytkownik anonimowy – użytkownicy należący do tej roli to wszystkie
niezalogowane osoby przeglądające aktualnie stronę.
• Użytkownik uwierzytelniony – do roli tej należą wszyscy użytkownicy, którzy są
zalogowani.
98
Pierwszy użytkownik utworzony podczas instalacji systemu, czyli ten posiadający numer
Id=1 jest tak zwanym super administratorem i posiada pełne uprawnienia do zarządzania
witryną niezależnie od przypisanych mu ról.
Oprócz powyższych ról systemowych dodawać można także dowolne inne role. Wszystkim
rolom można przypisywać uprawnienia.
Ustawienia uprawnień są w Drupalu zdecydowanie lepiej przemyślane niż w pozostałych
dwóch systemach CMS. Konfiguracja uprawnień odbywa się poprzez specjalną stronę panelu
administracyjnego. Dostępnych jest tu bardzo wiele opcji, których liczba zależy od ilości
włączonych modułów – zarówno tych wchodzących w skład domyślnej instalacji Drupala jak
i dodatkowych.
Ponadto system Drupal umożliwia m.in. blokowanie kont użytkowników bez ich usuwania
oraz blokowanie dostępu do strony (i blokowanie możliwości rejestrowania się) wybranym
użytkownikom na podstawie:
• Adresu IP lub domeny z której się łączą
• Adresu email, który podają przy rejestracji
• Nazwy użytkownika
Rysunek . Bardzo mały fragment długiej strony z ustawieniami uprawnień użytkowników systemu Drupal.
99
Należy zaznaczyć, że możliwe jest tu wykorzystywanie znaku % oznaczającego tu dowolną
ilość znaków (nawet zero) oraz znaku „_” oznaczającego dokładnie jeden znak. Dzięki temu
można np. zablokować wszystkie osoby łączące się z adresu zawierającego słowo
„zladomena” w nazwie poprzez wpisanie „%zladomena%”.
Wnioski
Wszystkie trzy systemy CMS umożliwiają zarządzanie użytkownikami i rolami. Niestety
systemy WordPress i Joomla mają tu pewne ograniczenia. System WordPress wymaga
zainstalowania dodatkowej wtyczki w celu dokładnego skonfigurowania uprawnień, które i
tak nie są wystarczająco dokładne, oraz nie posiada wbudowanej możliwości blokowania kont
użytkowników. Z kolej w systemie Joomla zarządzanie uprawnieniami jest mało wygodne ze
względu na brak jednego miejsca, z którego można by nimi zarządzać. Jedynie system Drupal
posiada solidne, wbudowane funkcje zarządzania uprawnieniami użytkowników. Dodatkowo
wbudowano w niego też możliwość blokowania dostępu do strony np. użytkownikom
łączącym się z określonej domeny lub adresu IP.
Logowanie zdarzeń systemowychWiele zdarzeń systemowych dzieje się poza naszą kontrolą i o wielu nie jest jesteśmy
bezpośrednio informowani. O niektórych wiemy, że nastąpiły ale nie pamiętamy kiedy.
Większość systemów informatycznych zapisuje jednak wszystkie najistotniejsze zdarzenia,
które wystąpiły w systemie. Dzięki temu możemy sprawdzić co wydarzyło się „za naszymi
plecami”. Funkcje logujące są bardzo pomocne i ułatwiają diagnozowanie m.in. przyczyn
ewentualnych problemów z witryną. Oto najważniejsze korzyści wynikające z posiadania
systemu zapisującego zdarzenia systemowe:
• Możliwość śledzenia poczynań użytkowników
• Możliwość śledzenia prób włamań
• Sprawdzanie czy wystąpiły jakieś błędy systemowe
• Śledzenie różnego rodzaju innych zdarzeń systemowych
Posiadanie systemu logowania jest koniecznością dla wszystkich witryn obsługujących wielu
użytkowników i wiele kont.
WordPress
100
System WordPress nie posiada wbudowanej funkcji logowania zdarzeń systemowych.
Logowanie zdarzeń systemu to jedna z podstawowych rzeczy, którą system CMS powinien
mieć wbudowaną. Niestety w przypadku CMS-a WordPress tak nie jest. Sytuacje tą można
poprawić instalując wtyczkę o nazwie WPSyslog2, aczkolwiek jej możliwości oraz zakres
zapisywanych zdarzeń są dość ograniczone, ponieważ nie wszystkie istotne zdarzenia
systemowe są zapisywane.
Joomla
Logowanie zdarzeń systemowych w Joomli jest dostępne – zdarzenia są zapisywane w
katalogu o nazwie logs podkatalogu głównego folderu systemu Joomla. Niestety i tu ilość
zapisywanych zdarzeń różnych typów jest mocno ograniczona. Zapisywane są próby
nieudanego logowania ale informacje np. o dodaniu nowych artykułów już nie. Mechanizm
logowania wbudowany w system Joomla zapewne nie sprostał by potrzebom rozbudowanej
witryny obsługującej wielu użytkowników.
Drupal
Jeśli chodzi o logowanie zdarzeń systemowych to trzeba przyznać, że w systemie Drupal
funkcja ta została bardzo dokładnie i precyzyjnie opracowana. Wpisy dodawane do dziennika
dotyczą bardzo wielu aspektów funkcjonowania systemu. Rozbudowana lista prezentująca
wpisy dziennika umożliwia także sprawdzanie danych szczegółowych.
101
Rysunek . Przykładowy fragment strony z wpisami dziennika systemu Drupal.
Rysunek . Dla każdego wpisu w dzienniku zdarzeń możliwe jest wyświetlenie szczegółowych informacji.
Systemowy dziennik Drupala pozwala też na wygodne filtrowanie i sortowanie
wyświetlanych w nim informacji, co pozwala np. na łatwe odnalezienie wszystkich błędów
krytycznych, które ostatnio wystąpiły.
102
Rysunek . Ustawienia filtrowania wpisów dziennika zdarzeń systemu Drupal.
Oprócz dziennika systemowego, CMS Drupal posiada on też wbudowaną obsługę statystyk
strony. Moduł statystyk umożliwia przeglądanie następujących informacji:
• Ostatnio odwiedzane strony
• Najczęściej odwiedzane strony
• Najczęstsze podstrony do których użytkownik nie miał praw dostępu
• Najczęściej odwiedzane adresy, które zwróciły błąd „Strona nie istnieje”
• Lista referentów wg ilości przekazanych odwiedzających
• Zapytania najczęściej wpisywane w systemowej wyszukiwarce
• Najczęściej odwiedzający nas użytkownicy
Wnioski
Logowanie zdarzeń systemowych w dzienniku to bardzo przydatna funkcja, ułatwiająca
analizowanie pracy systemu i pozwalająca na wyłapywanie niepożądanych działań ze strony
użytkowników. Zapisywanie działań użytkowników pozwala także na ewentualne pociąganie
odpowiednich osób do odpowiedzialności. Niestety w systemach WordPress i Joomla nie
zapewniono wystarczająco rozbudowanego mechanizmu logowania zdarzeń – w Joomli jest
on mocno ograniczony, a w systemie WordPress prostą funkcjonalność dziennika można
uzyskać jedynie poprzez instalację dodatku. W Drupalu wbudowane logowanie zdarzeń
systemowych jest profesjonalne, a zakres zapisywanych zdarzeń jest szeroki.
Wykonywanie kopii zapasowych bazy danych
103
Systemy CMS to aplikacje oparte na bazach danych. W bazie przechowywane są zarówno
treści podstron i artykułów jak i różne ustawienia systemu CMS. Dokonywanie większych
zmian w systemie, takich jak instalacja nowych nieznanych dodatków, wiąże się z pewnym
ryzykiem. Nie mamy bowiem pewności, że dane przechowywane w bazie nie zostaną
uszkodzone. Poza tym system CMS jest zawsze narażony na próby włamań ze strony
hackerów lub script-kiddies oraz może zostać niechcący uszkodzony przez obsługujących go
administratorów.
Uszkodzenie bazy danych stanowi zazwyczaj duży problem. Większość firm hostingowych
robi regularne codzienne kopie zapasowe baz danych swoich klientów. Kopie te są zazwyczaj
przechowywane przez kilka dni po czym są usuwane. Działanie to chroni nas przed
uszkodzeniem witryny ponieważ np. dziś uszkodzoną bazę danych można zawsze zastąpić jej
kopią z np. poprzedniego dnia. W przypadku gdy jednak odkryjemy problem w
funkcjonowaniu witryny po np. tygodniu, backupy zrobione przez firmę hostingową będą
zawierać obraz bazy danych po uszkodzeniu i nie umożliwią przywrócenia witrynie jej
poprawnego działania. W sytuacji takiej przyda się mieć własne kopie zapasowe.
Wszystkie trzy porównywane systemy zarządzania treścią posiadają dodatki umożliwiające
wykonywanie takich backupów. Polecane dodatki to:
• WordPress – WP DB Backup
• Joomla – Akeeba Backup
• Drupal – Backup and Migrate
WordPress
System WordPress posiada kilka różnych dodatków, o podobnej funkcjonalności,
umożliwiających wykonywanie kopii zapasowych bazy danych. Niestety ich możliwości
ograniczają się głównie do manualnego oraz automatycznego (zaplanowanego) wykonywania
kopii zapasowych. Kopie można zapisać na serwerze, pobrać bezpośrednio lub wysłać sobie
jako załącznik do emaila.
Joomla
Dodatek Akeeba Backup do systemu Joomla jest dużo bardziej rozbudowany niż te dostępne
dla systemu WordPress bo potrafi także umieścić w kopii zapasowej pliki strony. Inne
dostępne opcje to np. możliwość tworzenia wielu profili kopii zapasowych. Dodatek ten jest
104
darmowy ale dostępna jest także wersją komercyjna, która umożliwia skonfigurowanie
zaplanowanych automatycznych backupów oraz przywracanie witryny z kopii zapasowej.
Rysunek . Panel główny opcji dodatku Akeeba Backup dla systemu Joomla. Wersja darmowa.
Drupal
Moduł Backup and Migrate dostępny dla systemu Drupal jest dużo bardziej rozbudowany niż
było to w przypadku wymienionych przed chwilą dodatków. Dostępne funkcje to m.in.:
• Tworzenie kopi zapasowej dowolnej bazy danych lub jej fragmentu
• Zapis kopii zapasowej na serwerze lub bezpośrednie pobranie jej po utworzeniu
• Możliwość zaszyfrowania pliku kopii zapasowe algorytmem AES
• Przywracanie witryny z kopii zapasowej
• Możliwość konfiguracji różnych katalogów zapisywania backupów
• Możliwość tworzenia kopii dowolnej bazy danych, a nie tylko tej z której korzysta
system CMS
• Możliwość definiowania różnych profili tworzenia kopii zapasowych
Wnioski
Dodatki ułatwiające tworzenie i wgrywanie kopii zapasowych w trzech porównywanych
systemach CMS różnią się liczbą udostępnianych funkcji. W systemie WordPress brakuje
105
solidnego dodatku do obsługi backupów. Płatna wersja rozszerzenia AkeebaBackup dla
systemu Joomla oraz moduł Backup and Migrate systemu Drupal są do siebie dość zbliżone
pod względem funkcjonalności, aczkolwiek dodatek do systemu Drupal jest nieco lepszy
oraz zupełnie bezpłatny.
Rysunek . Fragment formularza wykonywania manualnego backupu bazy danych systemu Drupal.
Wsparcie dla stron wielojęzycznychW dzisiejszych czasach coraz częściej spotyka się strony wielojęzyczne. Wynika to między
innymi z chęci udostępnienia stron jak największym grupom odbiorców. Wszystkie popularne
strony o zasięgu międzynarodowym zostały już przetłumaczone na bardzo wiele języków.
Przykładami takich stron mogą być np. Facebook, Google oraz wiele stron firm takich jak
Microsoft lub Sony.
Tworząc stronę prezentującą treści w różnych językach lub planując przyszłą zamianę strony
jednojęzycznej na wielojęzyczną należy zaopatrzyć się w system zarządzania treścią
posiadający odpowiednie wsparcie dla tego typu stron.
106
Przebadam teraz systemy WordPress, Joomla i Drupal i porównam ich możliwości obsługi
witryn wielojęzycznych.
WordPress
System WordPress nie posiada wbudowanych funkcji umożliwiających obsługę
wielojęzycznych witryn. Aby móc zbudować tego typu witrynę należy zainstalować dodatek o
nazwie WPML Multilingual. Dodatek ten jest bardzo rozbudowany i umożliwia
przetłumaczenie całej witryny, zarówno postów jak i tekstów zdefiniowanych wewnątrz
dodatków i szablonów, pod warunkiem, że teskty są wstawiane przez funkcję __() lub _e().
Zalety WPML to:
• Możliwość tłumaczenia artykułów/podstron
• Możliwość tłumaczenia elementów szablonów i pluginów
• Możliwość skonfigurowania różnych menu wyświetlanych w zależności od języka
• Rozpoznawanie języka strony po domenie lub po prefiksie będącym częścią adresu
URL, np. www.domena..com/pl/artykul
• Możliwość przełączania języka w którym wyświetlany jest artykuł. Jest to możliwe
dzięki kontrolce wybory języka wyświetlanej na stronie
System ten posiada pewne ograniczenia:
• Liczba wspieranych języków jest ograniczona, a dodanie nowego może być dla
niektórych skomplikowane
• Funkcjonalność tego dodatku może być niewystarczająca dla bardzo rozbudowanych
witryn
Poza tym brak tu jest dobrych tłumaczeń dodatkowych plugin-ów i wiele prac związanych z
tłumaczeniem strony trzeba robić od zera.
Dodatek ten jest nastawiony na reklamowanie firmy zajmującej się tłumaczeniami. W panelu
administracyjnym wyświetlane są różne komunikaty mające zachęcać do skorzystania z usług
profesjonalnego tłumaczenia strony.
107
Mimo wymienionych wad, zbudowanie nieskomplikowanej wielojęzycznej strony w systemie
WordPress jest jak najbardziej możliwe, aczkolwiek powinno to być prostsze do osiągnięcia.
Joomla
System Joomla posiada wbudowaną obsługę wielojęzycznych witryn. Aby aktywować
możliwość tworzenia wielojęzycznych treści należy dodać do systemu pakiet językowy. Po
dodaniu pakietu dostępne będą dwa języki: wbudowany angielski oraz ten, który dodaliśmy.
Joomla zapewnia nam następujące funkcje:
• Rozpoznawanie języka strony po prefiksie będącym częścią adresu URL
• Wyświetlanie tylko tych elementów menu, które dotyczą podstron w danym języku
• Kontrolka umożliwiająca przełączenie języka strony
Brak tu możliwości tłumaczenia tekstów wyświetlanych przez moduły lub szablony,
aczkolwiek dostępne są paczki, których zainstalowanie zapewnia wystarczające tłumaczenia.
Gorzej może być w przypadku skorzystania z dodatków nie posiadających gotowych
tłumaczeń.
System wspierający w Joomli wielojęzyczne strony na pewno wystarczy na potrzeby prostych
stron ale może okazać się za słaby dla rozbudowanych stron społecznościowych.
Drupal
Obsługa wielojęzycznych witryn została także wbudowana w system Drupal. W systemie tym
bardzo duży nacisk kładzie się na jego wielozadaniowość, dlatego funkcje takie jak solidna
obsługa stron wielojęzycznych są tutaj niezbędne.
Podstawowe narzędzia Drupala umożliwiają nam:
• Definiowanie dowolnej ilości języków. Samo dodanie nowego języka nie zapewnia
nam tłumaczenia interfejsu systemu. Aby interfejs był dostępny w kilku językach
należy ściągnąć odpowiedni pakiet językowy. Język strony można ustawić już nawet
przed samą instalacją systemu CMS.
• Tłumaczenie artykułów
• Przełączanie języka wyświetlanego artykułu na inny
108
• Możliwość tłumaczenia elementów szablonów i modułów
• Rozpoznawanie języka strony po domenie, subdomenie lub po prefiksie będącym
częścią adresu URL, np. www.domena..com/pl/artykul. Opcja ta dotyczy także sekcji
administracyjnej oraz stron profili użytkowników.
• Rozpoznawanie języka przeglądarki użytkownika i wyświetlanie strony w tym samym
języku
Ponadto dostępny jest bardzo rozbudowany moduł dodatkowy o nazwie i18n, który
umożliwia stworzenie w pełni wielojęzycznej strony, nawet o charakterze skomplikowanej
aplikacji społecznościowej. Zapewniane przez ten moduł dodatkowe funkcje to m.in.:
• Możliwość definiowania języka bloków (czyli elementów wyświetlanych w pasku
bocznym strony – patrz podrozdział „Możliwości prezentowania treści”). Bloki w
języku polskim pojawią się tylko na polskich podstronach.
• Możliwość tłumaczenia elementów menu
• Możliwość tłumaczenia pytań i odpowiedzi ankiet tworzonych za pomocą
wbudowanego w system Drupal modułu „poll”
• Możliwość tłumaczenia nazw kategorii
Wnioski
Z porównywanych systemów CMS jedynie WordPress nie posiada wbudowanego wsparcia
dla stron wielojęzycznych, chociaż umożliwia programistom korzystanie z funkcji „__()”,
dzięki której możliwe jest późniejsze tłumaczenie tekstów na inny język. Aby jednak
wykorzystać tę funkcjonalność, oraz zapewnić wsparcie dla wielojęzycznej witryny, należy
najpierw zainstalować dodatkowy plugin, np. WMPL Multilingual CMS. Po doinstalowaniu
WMPL system WordPress staje się bardzo dobrą platformą dla nieskomplikowanych
wielojęzycznych stron www.
Systemy Joomla i Drupal posiadają wbudowaną obsługę wielojęzycznych witryn. Oba te
systemy umożliwią zbudowanie nieskomplikowanej strony wielojęzycznej, choć narzędzia
wspierające wielojęzyczność stron opartych na Drupalu są nieco lepsze. Z kolei do budowy
109
skomplikowanej wielojęzycznej strony społecznościowej system Joomla prawdopodobnie nie
wystarczy.
Łatwość korzystania z systemu szablonów oraz jego możliwościTworzenie szablonów nie powinno być zbyt trudne. Dobry system CMS powinien umożliwiać
tworzenie szablonów bez konieczności wielotygodniowego studiowania technik ich
tworzenia. Zbyt skomplikowany system szablonów może spowodować, że niewielu
użytkowników, którym zależy na niepowtarzalnym wyglądzie strony, będzie chciało podjąć
się pisania własnego szablonu. W sytuacji takiej użytkownicy ci być może będą chcieli
zatrudnić specjalistę, który utworzy dla nich gotowy szablon. Niestety skomplikowany system
szablonów wpłynie w tej sytuacji również na cenę wykonania takiego szablonu przez
designera lub programistę. Dlatego dość istotne jest aby proces pisania szablonów był
wygodny i łatwy do nauki.
110
WordPress
Tworzenie szablonów, zwanych w systemie WordPress „themes”, jest łatwe i przyjemne.
Typowy szablon tego CMS-a składa się z następujący plików:
• style.css – obowiązkowy główny plik stylów. Plik ten jest także wykorzystywany do
rozpoznawania szablonu przez system, dzięki umieszczonym na początku pliku
specjalnym komentarzom (np. „Theme Name: Twenty Ten”). Rozwiązanie dosyć
dziwne i mało profesjonalne aczkolwiek działa poprawnie.
• index.php – podstawowy obowiązkowy plik szablonu. Jest wykorzystywany zawsze
gdy dla danej wyświetlanej podstrony nie przygotowano oddzielnego szablonu.
• functions.php – plik w którym można definiować różne funkcje, do którym chcemy
móc odwoływać się ze wszystkich pozostałych plików *.php szablonu.
• Inne pliki *.php – zapewniają wyświetlanie różnych elementów strony, np. nagłówka
lub listy wyników wyszukiwania. Dokładniejsza lista poniżej.
• screenshot.png – plik przestawiający wygląd szablonu. Używany jedynie w panelu
administracyjnym.
• Inne pliki *.css – dodatkowe pliki styli CSS
• Pliki graficzne
Przykładowy komentarz w pliku style.css, umożliwiający systemowi WordPress
zidentyfikowanie szablonu, wygląda następująco (długie fragment usunięto):
/*Theme Name: Twenty TenTheme URI: http://wordpress.org/Description: The 2010 theme for WordPress is stylish, customizable, simple, and readable (...)Author: the WordPress teamVersion: 1.1Tags: black, blue, white, two-columns, fixed-width, (...)*/
W celu zapewnienia różnym podstronom i/lub elementom indywidualnego wyglądu, można
korzystać również z następujących plików:
111
• rtl.css – plik stylów dla języków czytanych od prawej do lewej strony
• comments.php – szablon dla komentarzy
• front-page oraz home.php – szablony strony głównej
• single.php – szablon dla pojedynczego postu. Dla tego typu szablonu oraz wszystkich
następujących, w przypadku ich braku użyty zostanie szablon index.php
• single-[typ-postu].php – szablon dla pojedynczego postu określonego typu
• page.php – szablon dla indywidualnych podstron (typu „page”)
• category.php – szablon listy kategorii
• tag.php – szablon listy tagu
• taxonomy.php – szablon dla poszczególnego określenia z wybranej kategorii
• author.php – szablon autora
• date.php – szablon listy wg daty
• archive.php – szablon archiwum
• serach.php – szablon wynikow wyszukiwania
• attachment.php – szablon pojedynczego załącznika
• image.php – szablon pojedynczego załącznika-zdjęcia
• 404.php – szablon wyświetlany podczas błędu 404 („nie odnaleziono strony”)
Dzięki dużej liczbie rozpoznawanych przez system WordPress pod-szablonów używanych do
wyświetlania różnych elementów witryny możliwe jest zapewnienie oryginalnego i
odmiennego wyglądu wszystkich elementów wchodzących w skład strony. Więcej na temat
rozpoznawanych pod-szablonów na stronie http://codex.wordpress.org/Template_Hierarchy.
W przypadku skorzystania z kilku takich pod-szablonów możliwy jest ich wybór podczas
dodawania nowej podstrony. Dzięki temu można łatwo definiować, które podstrony mają
wykorzystywać które szablony.
112
System WordPress udostępnia także mnóstwo funkcji służących do wstawiania istotnych
elementów witryny do szablonów. Elementy takie to np. treść lub części nagłówka HTML.
Pełna lista funkcji z których można korzystać wewnątrz szablonów znajduje się na stronie
http://codex.wordpress.org/Function_Reference.
Niestety system WordPress umożliwia wstawianie elementów strony jedynie poprzez funkcje.
Zwiększa to trud i nakład pracy jaki muszą wykonać nowi użytkownicy budujący swój
własny szablon. Dobrą pomocą na początek jest dostępny w Internecie oficjalny poradnik
dotyczący tworzenia szablonów: http://codex.wordpress.org/Theme_Development.
W systemie WordPress zabrakło także możliwości tworzenia nie tylko pod-szablonów dla
różnych podstron ale i dla bloków określanych jako „widgets”.
Poniżej przedstawiono kod pod-szablonu single.php odpowiedzialnego za wyświetlanie
pojedynczego postu. Plik pochodzi z domyślnego szablonu Twenty Ten.
<?php/** * The Template for displaying all single posts. * * @package WordPress * @subpackage Twenty_Ten * @since Twenty Ten 1.0 */ get_header(); ?>
<div id="container"> <div id="content" role="main">
<?php if ( have_posts() ) while ( have_posts() ) : the_post(); ?>
<div id="nav-above" class="navigation"> <div class="nav-previous"> <?php previous_post_link( '%link', '<span class="meta-nav">' . _x( '←', 'Previous post link', 'twentyten' ) . '</span> %title' ); ?> </div> <div class="nav-next"> <?php next_post_link( '%link', '%title <span class="meta-nav">' . _x( '→', 'Next post link', 'twentyten' ) . '</span>' ); ?></div> </div><!-- #nav-above -->
<div id="post-<?php the_ID(); ?>" <?php post_class(); ?>> <h1 class="entry-title"><?php the_title(); ?></h1>
<div class="entry-meta"> <?php twentyten_posted_on(); ?> </div><!-- .entry-meta -->
113
<div class="entry-content"> <?php the_content(); ?> <?php wp_link_pages( array( 'before' => '<div class="page-link">' . __( 'Pages:', 'twentyten' ), 'after' => '</div>' ) ); ?> </div><!-- .entry-content -->
<?php if ( get_the_author_meta( 'description' ) ) : ?> <div id="entry-author-info"> <div id="author-avatar"> <?php echo get_avatar( get_the_author_meta( 'user_email' ), apply_filters( 'twentyten_author_bio_avatar_size', 60 ) ); ?> </div><!-- #author-avatar --> <div id="author-description"> <h2><?php printf( esc_attr__( 'About %s', 'twentyten' ), get_the_author() ); ?></h2> <?php the_author_meta( 'description' ); ?> <div id="author-link"> <a href="<?php echo get_author_posts_url( get_the_author_meta( 'ID' ) ); ?>"> <?php printf( __( 'View all posts by %s <span class="meta-nav">→</span>', 'twentyten' ), get_the_author() ); ?> </a> </div><!-- #author-link --> </div><!-- #author-description --> </div><!-- #entry-author-info --> <?php endif; ?>
<div class="entry-utility"> <?php twentyten_posted_in(); ?> <?php edit_post_link( __( 'Edit', 'twentyten' ), '<span class="edit-link">', '</span>' ); ?> </div><!-- .entry-utility --> </div><!-- #post-## -->
<div id="nav-below" class="navigation"> <div class="nav-previous"> <?php previous_post_link( '%link', '<span class="meta-nav">' . _x( '←', 'Previous post link', 'twentyten' ) . '</span> %title' ); ?> </div> <div class="nav-next"> <?php next_post_link( '%link', '%title <span class="meta-nav">' . _x( '→', 'Next post link', 'twentyten' ) . '</span>' ); ?> </div> </div><!-- #nav-below -->
<?php comments_template( '', true ); ?>
<?php endwhile; // end of the loop. ?>
</div><!-- #content --></div><!-- #container -->
<?php get_sidebar(); ?><?php get_footer(); ?>
114
Joomla
Tworzenie szablonów dla systemu Joomla również nie jest trudne. Szablony systemu Joomla
mają trochę inną budowę niż te z dla systemu WordPress. Przede wszystkim inna jest lista
standardowych plików:
• templateDetails.xml – obowiązkowy plik zawierający informacje na temat szablon:
m.in. jak się nazywa, kto jest jego autorem, jakie pliki wchodzą w jego skład itp
• index.php – podstawowy obowiązkowy plik szablonu
• template_thumbnail.png – plik przestawiający wygląd szablonu. Używany jedynie w
panelu administracyjnym
• css/template_css.css – domyślny plik styli CSS
• pliki graficzne – dowolne pliki graficzne szablonu
Wszystkie pliki wchodzące w skład szablonu muszą być wymienione w pliku
templateDetails.xml. Ponadto katalog z plikami szablonu powinien mieć taką samą nazwę jak
sam szablon. Poniżej przedstawiono przykładową zawartość pliku konfiguracyjnego
templateDetails.xml.
<?xml version="1.0" encoding="utf-8" ?><!DOCTYPE install PUBLIC "-//Joomla! 1.6//DTD template 1.0//EN" "http://www.joomla.org/xml/dtd/1.6/template-install.dtd"><install version="1.6" type="template" client="site">
<name>beez_20</name><creationDate>25 November 2009</creationDate><author>Angie Radtke</author><authorEmail>[email protected]</authorEmail><authorUrl>http://www.der-auftritt.de</authorUrl><copyright>Copyright (C) 2005 - 2010 Open Source Matters, Inc. All
rights reserved.</copyright><license>GNU General Public License version 2 or later; see
LICENSE.txt</license><version>1.6.0</version><description>TPL_BEEZ2_XML_DESCRIPTION</description>
<files><folder>css</folder><folder>html</folder><folder>images</folder><folder>javascript</folder><folder>language</folder>(...)<filename>index.php</filename><filename>params.ini</filename>
115
<filename>templateDetails.xml</filename><filename>template_thumbnail.png</filename><filename>favicon.ico</filename><filename>cmponent.php</filename>
</files>
<positions> <position>position-0</position> <position>position-1</position>(...)</positions> <languages>
<language tag="en-GB">en-GB.tpl_beez_20.ini</language></languages><config>
(...)</config>
</install>
Powyższy plik jest wykorzystywany podczas instalacji szablonu. Jak widać opcji
konfiguracyjnych jest dużo więcej niż było to w przypadku konfiguracji szablonów systemu
WordPress, aczkolwiek zmuszanie twórców szablonów do umieszczania w tym pliku listy
wszystkich innych plików szablonu wydaje się zbędne, ponieważ PHP posiada możliwość
sprawdzania zawartości folderu. Z listy plików korzysta instalator rozszerzeń systemu
Joomla.
System Joomla nie umożliwia tworzenia pod-szablonów i wykorzystywania ich do
wyświetlania podstron różnego typu, co sprawia, że szablony dla tego systemu są mocno
ograniczone. Jedyny sposób wpływania na wygląd poszczególnych podstron polega na
możliwości przypisywania różnych szablonów głównych dla różnych podstron. Przykład: aby
zmienić design np. nagłówka dla jednej wybranej podstrony należy wykonać kopię szablonu
używanego przez witrynę, następnie dokonać zmian w tej kopii po czym wgrać go z
powrotem do Joomli i ustawić aby korzystała z niego tylko ta jedna wybrana podstrona.
Rozwiązanie takie jest jednak bardzo niewygodne i posiada wiele wad. Poza tym jedynym
ograniczeniem, szablony systemu Joomla posiadają podobne cechy jak szablony systemu
WordPress.
Wstawianie treści do szablonów odbywa się w systemie Joomla poprzez specjalne znacznik
„jdoc” oraz poprzez zmienne. Ich zastosowanie widać na poniższym listingu
przedstawiającym kod pliku index.php głównego szablony systemu Joomla.
<?php/**
116
* @version $Id: index.php 18060 2010-07-08 16:04:59Z dextercowley $ * @package Joomla.Site * @subpackage tpl_beez2 * @copyright Copyright (C) 2005 - 2010 Open Source Matters, Inc. All rights reserved. * @license GNU General Public License version 2 or later; see LICENSE.txt */ // No direct access.defined('_JEXEC') or die; // check modules$showRightColumn = ($this->countModules('position-3') or $this->countModules('position-6') or $this->countModules('position-8'));$showbottom = ($this->countModules('position-9') or $this->countModules('position-10') or $this->countModules('position-11'));$showleft = ($this->countModules('position-4') or $this->countModules('position-7') or $this->countModules('position-5')); if ($showRightColumn==0 and $showleft==0) { $showno = 0;} JHTML::_('behavior.mootools'); // get params$color = $this->params->get('templatecolor');$logo = $this->params->get('logo');$navposition = $this->params->get('navposition');$app = JFactory::getApplication();$templateparams = $app->getTemplate(true)->params; ?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml" xml:lang="<?php echo $this->language; ?>" lang="<?php echo $this->language; ?>" dir="<?php echo $this->direction; ?>" ><head> <jdoc:include type="head" /> <link rel="stylesheet" href="<?php echo $this->baseurl ?>/templates/beez_20/css/template.css" type="text/css" /> <link rel="stylesheet" href="<?php echo $this->baseurl ?>/templates/beez_20/css/position.css" type="text/css" media="screen,projection" /> <link rel="stylesheet" href="<?php echo $this->baseurl ?>/templates/beez_20/css/layout.css" type="text/css" media="screen,projection" /> <link rel="stylesheet" href="<?php echo $this->baseurl ?>/templates/beez_20/css/print.css" type="text/css" media="Print" /> <?php $files = JHtml::_('stylesheet','templates/beez_20/css/general.css',null,false,true); if ($files): if (!is_array($files)): $files = array($files); endif; foreach($files as $file): ?> <link rel="stylesheet" href="<?php echo $file; ?>" type="text/css" /> <?php endforeach; endif; ?> <link rel="stylesheet" href="<?php echo $this->baseurl ?>/templates/beez_20/css/<?php echo $color; ?>.css" type="text/css" /> <?php if ($this->direction == 'rtl') : ?>
117
<link rel="stylesheet" href="<?php echo $this->baseurl ?>/templates/beez_20/css/template_rtl.css" type="text/css" /> <?php endif; ?> <!--[if lte IE 6]> <link href="@@$$#php16-/templates/beez_20/css/ieonly.css" rel="stylesheet" type="text/css" /> @@$$#php17- <style type="text/css">@@$$#css0-</style> @@$$#php18- <![endif]--> <!--[if IE 7]> <link href="@@$$#php19-/templates/beez_20/css/ie7only.css" rel="stylesheet" type="text/css" /> <![endif]--> <script type="text/javascript" src="<?php echo $this->baseurl ?>/templates/beez_20/javascript/md_stylechanger.js"></script> <script type="text/javascript" src="<?php echo $this->baseurl ?>/templates/beez_20/javascript/hide.js"></script> <script type="text/javascript" src="<?php echo $this->baseurl ?>/templates/beez_20/javascript/html5.js"></script> <script type="text/javascript"> var big ='<?php echo $this->params->get('wrapperLarge'); ?>%'; var small='<?php echo $this->params->get('wrapperSmall'); ?>%'; var altopen='<?php echo JText::_('TPL_BEEZ2_ALTOPEN',true); ?>'; var altclose='<?php echo JText::_('TPL_BEEZ2_ALTCLOSE',true); ?>'; var bildauf='<?php echo $this->baseurl ?>/templates/beez_20/images/plus.png'; var bildzu='<?php echo $this->baseurl ?>/templates/beez_20/images/minus.png'; var rightopen='<?php echo JText::_('TPL_BEEZ2_TEXTRIGHTOPEN',true); ?>'; var rightclose='<?php echo JText::_('TPL_BEEZ2_TEXTRIGHTCLOSE'); ?>'; </script></head><body><div id="all"> <div id="back"> <div id="header"> <div class="logoheader"> <h1 id="logo"> <?php if ($logo): ?> <img src="<?php echo $this->baseurl ?>/<?php echo $logo; ?>" alt="<?php echo $templateparams->get('sitetitle'); ?>" /> <?php endif; ?> <?php if (!$logo ): ?> <?php echo $templateparams->get('sitetitle'); ?> <?php endif; ?> <span class="header1"> <?php echo $templateparams->get('sitedescription'); ?> </span> </h1> </div><!-- end logoheader --> <ul class="skiplinks"> <li><a href="#main" class="u2"><?php echo JText::_('TPL_BEEZ2_SKIP_TO_CONTENT'); ?></a></li> <li><a href="#nav" class="u2"><?php echo JText::_('TPL_BEEZ2_JUMP_TO_NAV'); ?></a></li> <?php if($showRightColumn ): ?> <li><a href="#additional" class="u2"><?php echo JText::_('TPL_BEEZ2_JUMP_TO_INFO'); ?></a></li> <?php endif; ?> </ul> <h2 class="unseen"><?php echo JText::_('TPL_BEEZ2_NAV_VIEW_SEARCH'); ?></h2>
118
<h3 class="unseen"><?php echo JText::_('TPL_BEEZ2_NAVIGATION'); ?></h3> <jdoc:include type="modules" name="position-1" /> <div id="line"> <div id="fontsize"> <script type="text/javascript"> //<![CDATA[ document.write('<h3><?php echo JText::_('TPL_BEEZ2_FONTSIZE'); ?></h3><p class="fontsize">'); document.write('<a href="index.php" title="<?php echo JText::_('TPL_BEEZ2_INCREASE_SIZE'); ?>" onclick="changeFontSize(2); return false;" class="larger"><?php echo JText::_('TPL_BEEZ2_BIGGER'); ?></a><span class="unseen"> </span>'); document.write('<a href="index.php" title="<?php echo JText::_('TPL_BEEZ2_REVERT_STYLES_TO_DEFAULT'); ?>" onclick="revertStyles(); return false;" class="reset"><?php echo JText::_('TPL_BEEZ2_RESET'); ?></a> '); document.write('<a href="index.php" title="<?php echo JText::_('TPL_BEEZ2_DECREASE_SIZE'); ?>" onclick="changeFontSize(-2); return false;" class="smaller"><?php echo JText::_('TPL_BEEZ2_SMALLER'); ?></a><span class="unseen"> </span></p>'); //]]> </script> </div> <h3 class="unseen"><?php echo JText::_('TPL_BEEZ2_SEARCH'); ?></h3> <jdoc:include type="modules" name="position-0" /> </div> <!-- end line --> </div><!-- end header --> <div id="<?php echo $showRightColumn ? 'contentarea2' : 'contentarea'; ?>"> <div id="breadcrumbs"> <p> <?php echo JText::_('TPL_BEEZ2_YOU_ARE_HERE'); ?> <jdoc:include type="modules" name="position-2" /> </p> </div> <?php if ($navposition=='left' AND $showleft) : ?> <div class="left1 <?php if ($showRightColumn==NULL){ echo 'leftbigger';} ?>" id="nav"> <jdoc:include type="modules" name="position-7" style="beezDivision;" headerLevel="3" /> <jdoc:include type="modules" name="position-4" style="beezHide;" headerLevel="3" state="0 " /> <jdoc:include type="modules" name="position-5" style="beezTabs;" headerLevel="2" id="3" /> </div><!-- end navi --> <?php endif; ?> <div id="<?php echo $showRightColumn ? 'wrapper' : 'wrapper2'; ?>" <?php if (isset($showno)){echo 'class="shownocolumns"';} ?>> <div id="main"> <?php if ($this->countModules('position-12')): ?> <div id="top"> <jdoc:include type="modules" name="position-12" /> </div> <?php endif; ?> <?php if ($this->getBuffer('message')) : ?> <div class="error"> <h2><?php echo JText::_('JNOTICE'); ?></h2> <jdoc:include type="message" /> </div> <?php endif; ?> <jdoc:include type="component" /> </div><!-- end main --> </div><!-- end wrapper -->
119
<?php if ($showRightColumn) : ?> <h2 class="unseen"> <?php echo JText::_('TPL_BEEZ2_ADDITIONAL_INFORMATION'); ?> </h2> <div id="close"> <a href="#" onclick="auf('right')"> <span id="bild"> <?php echo JText::_('TPL_BEEZ2_TEXTRIGHTCLOSE'); ?> </span> </a> </div> <div id="right"> <a name="additional"></a> <jdoc:include type="modules" name="position-6" style="beezDivision;" headerLevel="3"/> <jdoc:include type="modules" name="position-8" style="beezDivision;" headerLevel="3" /> <jdoc:include type="modules" name="position-3" style="beezDivision;" headerLevel="3" /> </div><!-- end right --> <?php endif; ?> <?php if ($navposition=='center' AND $showleft) : ?> <div class="left <?php if ($showRightColumn==NULL){ echo 'leftbigger';} ?>" id="nav" > <jdoc:include type="modules" name="position-7" style="beezDivision;" headerLevel="3" /> <jdoc:include type="modules" name="position-4" style="beezHide;" headerLevel="3" state="0 " /> <jdoc:include type="modules" name="position-5" style="beezTabs;" headerLevel="2" id="3" /> </div><!-- end navi --> <?php endif; ?> <div class="wrap"></div> </div> <!-- end contentarea --> </div><!-- back --> </div><!-- all --> <div id="footer-outer"> <?php if ($showbottom) : ?> <div id="footer-inner"> <div id="bottom"> <div class="box box1"><jdoc:include type="modules" name="position-9" style="beezDivision;" headerlevel="3" /></div> <div class="box box2"> <jdoc:include type="modules" name="position-10" style="beezDivision;" headerlevel="3" /></div> <div class="box box3"> <jdoc:include type="modules" name="position-11" style="beezDivision;" headerlevel="3" /></div> </div> <jdoc:include type="modules" name="debug" /> </div> <?php endif ; ?> <div id="footer-sub"> <div id="footer"> <jdoc:include type="modules" name="position-14" /> <p> <?php echo JText::_('TPL_BEEZ2_POWERED_BY'); ?> <a href="http://www.joomla.org/">Joomla!</a> </p> </div><!-- end footer --> </div>
120
</div></body></html>
Jak widać na powyższym listingu, kod domyślnego szablonu Joomli jest niedbale napisany i
nieprzejrzysty.
Drupal
Drupal pozwala na dużo większą kontrolę nad wyglądem strony niż pozostałe dwa systemy
CMS. Drupal korzysta z profesjonalnego systemu szablonów o nazwie PHP Template.
Rozpoznawanie szablonów odbywa się dzięki plikom o rozszerzeniu „info” posiadającym
nazwy zgodne ze schematem [nazwa_szablonu].info. Przykładowa zawartość pliku info
wygląda następująco:
121
name = Garlanddescription = Tableless, recolorable, multi-column (...)version = VERSIONcore = 6.xengine = phptemplatestylesheets[all][] = style.cssstylesheets[print][] = print.cssscripts[] = script.js
Wpis „engine = phptemplate” mówi Drupalowi, że dany szablon wykorzystuje system PHP
Template. Wpis ten jest obowiązkowy ponieważ Drupal obsługuje także kilka innych
systemów szablonów, np. Smarty (http://www.smarty.net/).
Plik info jest jedynym wymaganym plikiem szablonów, jednak szablon nie posiadający
żadnych innych plików nie będzie miał sensu. Aby szablon taki miał własny wygląd należy
dołączyć do niego chociaż jeden plik CSS lub plik „page.tpl.php” z osadzonymi stylami.
Rysunek . Fragment strony opartej na Drupalu, wykorzystującej szablon złożony jedynie z pliku *.info.
122
Poza plikiem info i plikiem styli CSS najczęściej spotykane pliki współtworzące szablon to:
• page.tpl.php – plik zawierający główny szablon stron
• node.tpl.php – plik z szablonem używanym do wyświetlania artykułów
• block.tpl.php – plik z szablonem używanym do wyświetlania bloków
• template.php – plik w którym można definiować różne funkcje, do którym chcemy
móc odwoływać się ze wszystkich plików *.tpl.php szablonu (o nich za chwilę)
• screenshot.png – plik przestawiający wygląd szablonu. Używany jedynie w panelu
administracyjnym.
Pliki z rozszerzeniem „tpl.php” służą do definiowania układu strony i zawierają kod HTML i
PHP. Drupal posiada wbudowany zbiór takich plików, z których korzysta zawsze gdy
wykorzystywany szablon nie dostarczył własnych. Pliki te to pod-szablony, które umożliwiają
dokładne kontrolowanie wyglądu różnych elementów witryny. Ich rola jest identyczna jak
było to z podobnymi plikami php w systemie WordPress, aczkolwiek Drupal posiada ich
znacznie więcej. Domyślnie wbudowane w system są pliki:
• aggregator-feed-source.tpl.php
• aggregator-item.tpl.php
• aggregator-summary-item.tpl.php
• aggregator-summary-items.tpl.php
• aggregator-wrapper.tpl.php
• block.tpl.php
• block-admin-display-form.tpl.php
• book-all-books-block.tpl.php
• book-export-html.tpl.php
• book-navigation.tpl.php
• book-node-export-html.tpl.php
• box.tpl.php
123
• comment.tpl.php
• comment-folded.tpl.php
• comment-wrapper.tpl.php
• forum-icon.tpl.php
• forum-list.tpl.php
• forums.tpl.php
• forum-submitted.tpl.php
• forum-topic-list.tpl.php
• forum-topic-navigation.tpl.php
• maintenance-page.tpl.php
• node.tpl.php
• page.tpl.php
• poll-bar.tpl.php
• poll-bar-block.tpl.php
• poll-results.tpl.php
• poll-results-block.tpl.php
• poll-vote.tpl.php
• profile-block.tpl.php
• profile-listing.tpl.php
• profile-wrapper.tpl.php
• search-block-form.tpl.php
124
• search-result.tpl.php
• search-results.tpl.php
• search-theme-form.tpl.php
• user-picture.tpl.php
• user-profile.tpl.php
• user-profile-category.tpl.php
• user-profile-item.tpl.php
Ich nazwy są bardzo wymowne i łatwo się domyślić za wygląd jakich elementów
odpowiadają. Główny plik to „page.tpl.php” – odpowiada on za układ strony. Podobnie jak w
systemie WordPress możliwe jest definiowanie różnych pod-szablonów dla różnych podstron,
np.:
• page-front.tpl.php – dla strony głównej
• page-about.tpl.php – dla podstrony posiadającej alias „about” (www.domena.pl/about)
• node-article.tpl.php – dla postów typu „article”
• itp…
Dzięki bardzo dużej liczbie plików tpl.php, z których można korzystać, system Drupal
pozwala na dokładną i precyzyjną kontrolę wyglądu witryny oraz zapewnia dużą
elastyczność. Więcej na temat plików tpl.php można przeczytać na stronie
http://drupal.org/theme-guide/6
Tworzenie plików tpl.php jest w systemie Drupal łatwiejsze i bardziej przyjazne niż w
systemie WordPress. Wstawianie treści odbywa się poprzez specjalne zmienne. Lista
zmiennych dostępnych dla każdego pliku tpl.php znajduje się w jego domyślnej wersji,
przechowywanej przez system Drupal w podkatalogach folderu „Modules”. Poza tym w
plikach tpl.php również mamy dostęp do funkcji systemowych.
125
Poniżej przedstawiony jest przykładowy kod pliku „page.tpl.php” wchodzącego w skład
głównego szablonu systemu Drupal 6. Jest on wyraźnie przejrzystszy od podobnego kodu
pozostałych dwóch systemów CMS.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><html xmlns="http://www.w3.org/1999/xhtml" xml:lang="<?php print $language->language ?>" lang="<?php print $language->language ?>" dir="<?php print $language->dir ?>"> <head> <?php print $head ?> <title><?php print $head_title ?></title> <?php print $styles ?> <?php print $scripts ?> <!--[if lt IE 7]> @@$$#php7- <![endif]--> </head> <body<?php print phptemplate_body_class($left, $right); ?>>
<!-- Layout --> <div id="header-region" class="clear-block"><?php print $header; ?></div>
<div id="wrapper"> <div id="container" class="clear-block">
<div id="header"> <div id="logo-floater"> <?php // Prepare header $site_fields = array(); if ($site_name) { $site_fields[] = check_plain($site_name); } if ($site_slogan) { $site_fields[] = check_plain($site_slogan); } $site_title = implode(' ', $site_fields); if ($site_fields) { $site_fields[0] = '<span>'. $site_fields[0] .'</span>'; } $site_html = implode(' ', $site_fields); if ($logo || $site_title) { print '<h1><a href="'. check_url($front_page) .'" title="'. $site_title .'">'; if ($logo) { print '<img src="'. check_url($logo) .'" alt="'. $site_title .'" id="logo" />'; } print $site_html .'</a></h1>';
126
} ?> </div>
<?php if (isset($primary_links)) : ?> <?php print theme('links', $primary_links, array('class' => 'links primary-links')) ?> <?php endif; ?> <?php if (isset($secondary_links)) : ?> <?php print theme('links', $secondary_links, array('class' => 'links secondary-links')) ?> <?php endif; ?>
</div> <!-- /header -->
<?php if ($left): ?> <div id="sidebar-left" class="sidebar"> <?php if ($search_box): ?><div class="block block-theme"><?php print $search_box ?></div><?php endif; ?> <?php print $left ?> </div> <?php endif; ?>
<div id="center"><div id="squeeze"><div class="right-corner"><div class="left-corner"> <?php print $breadcrumb; ?> <?php if ($mission): print '<div id="mission">'. $mission .'</div>'; endif; ?> <?php if ($tabs): print '<div id="tabs-wrapper" class="clear-block">'; endif; ?> <?php if ($title): print '<h2'. ($tabs ? ' class="with-tabs"' : '') .'>'. $title .'</h2>'; endif; ?> <?php if ($tabs): print '<ul class="tabs primary">'. $tabs .'</ul></div>'; endif; ?> <?php if ($tabs2): print '<ul class="tabs secondary">'. $tabs2 .'</ul>'; endif; ?> <?php if ($show_messages && $messages): print $messages; endif; ?> <?php print $help; ?> <div class="clear-block"> <?php print $content ?> </div> <?php print $feed_icons ?> <div id="footer"><?php print $footer_message . $footer ?></div> </div></div></div></div> <!-- /.left-corner, /.right-corner, /#squeeze, /#center -->
<?php if ($right): ?> <div id="sidebar-right" class="sidebar"> <?php if (!$left && $search_box): ?><div class="block block-theme"><?php print $search_box ?></div><?php endif; ?> <?php print $right ?> </div> <?php endif; ?>
127
</div> <!-- /container --> </div><!-- /layout -->
<?php print $closure ?> </body></html>
Wnioski
Tworzenie szablonów24 to złożony proces, który wymaga odpowiednich narzędzi.
Zbudowanie witryny o zróżnicowanym wyglądzie jest możliwe we wszystkich trzech
porównywanych systemach CMS, choć system Joomla ma bardzo słabe wsparcie dla witryn
wymagających odmiennego wyglądu różnych podstron. Jedynie systemy WordPress i Drupal
umożliwiają tworzenie rozbudowanych szablonów posiadających różne pod-szablony
przeznaczone dla podstron określonych typów. Poziom kontroli wyglądu witryny oraz jej
wszystkich elementów jest jednak w Drupalu nieporównanie wyższy niż pozostałych dwóch
CMS-ach.
Trud wymagany w celu zbudowania stronyZbudowanie strony www to złożone zadanie. Systemy CMS ułatwiają jej utworzenie i
późniejsze zarządzanie nią. Trud wymagany w celu zrealizowania tego zadania zależy tu od
dwóch rzeczy. Po pierwsze liczy się poziom skomplikowania samej witryny – rozbudowane
strony www pochłoną dużo więcej czasu niż budowa prostego bloga. Po drugie istotne jest jak
dużo pracy wymaga od nas sam system CMS, aby uruchomić nową witrynę.
WordPress
Budowa strony w oparciu o system WordPress jest łatwa, zwłaszcza wtedy gdy wystarczy
nam wbudowana funkcjonalność tego CMS-a oraz gdy decydujemy się na wykorzystanie
jednego z gotowych szablonów. Ich duża ilość w wielu przypadkach pozwoli na znalezienie
takiego, który będzie w znacznym stopniu spełniał nasze oczekiwania. Poza tym zawsze
można wykonać różne modyfikacje szablonu tak aby zapewnił naszej stronie dokładnie taki
wygląd jakiego potrzebowaliśmy.
24 Dokładne omówienie sposobów tworzenia szablonów dla każdego z prezentowanych systemów CMS przeczytać można w książkach dotyczących tej tematyki, wymienionych w bibliografii.
128
W przypadku gdy wbudowane w system WordPress funkcje są dla nas niewystarczające i
potrzebujemy nieskomplikowanych opcji dodatkowych, również nie stanowi to problemu.
Instalowanie dodatkowych modułów i ich konfiguracja to zazwyczaj zadanie trywialne.
Dzięki powyższym zaletom uruchomienie nowej strony opartej na systemie WordPress jest
bardzo łatwe, pod warunkiem, że nie zależy nam na nietypowej funkcjonalności i zupełnie
oryginalnym wyglądzie.
Joomla
Budowa strony www w oparciu o system Joomla jest nieco trudniejsza niż było to w
przypadku systemu WordPress. Wbudowana w system Joomla funkcjonalność powinna
wystarczyć na potrzeby sporej ilości witryn, aczkolwiek brak tu trochę łatwo dostępnych
darmowych szablonów (np. na oficjalnej stronie nie znajdziemy działu z szablonami). Aby
takie znaleźć, trzeba przeszukiwa
zasoby Internetu, w czym przeszkadzają zaśmiecone wyniki wyszukiwania (podrozdział
„Dostępność darmowych szablonów”). Problem ten nie dotyczy oczywiście osób kupujących
gotowe szablony oraz zamawiających nowe.
Na szczęście utworzenie szablonu dla systemu Joomla jest zadaniem prostszym niż dla
systemów WordPress i Drupal, przy założeniu, że wszystkie strony mają zbliżony wygląd
(podrozdział „Łatwość tworzenia własnych szablonów”).
Ponadto interfejs administracyjny oraz sposób dodawania nowych podstron jest w systemie
Joomla dosyć niewygodny.
Z powyższych cech wynika, że skonfigurowanie działającej witryny posiadającej własny w
pełni oryginalny wygląd będzie prostsze do wykonania niż w systemach WordPress i Drupal.
Drupal
Budowa witryny w oparciu o system Drupal wymaga dużo więcej pracy niż w przypadku
dwóch pozostałych porównywanych systemów zarządzania treścią. Jest to cecha, która
zniechęca wiele osób.
Po pierwsze dla systemu Drupal nie ma zbyt wielu dobrych darmowych szablonów, co
oznacza, że przyszły szablon trzeba będzie utworzyć samemu lub zamówić u profesjonalisty.
129
Po drugie standardowa instalacja systemu Drupal nie zawiera kilku podstawowych funkcji,
których oczekuje większość użytkowników. Funkcje takie to np. edytor WYSIWYG czy
możliwość łatwego załączania zdjęć. Jest tak ponieważ idea Drupala jest taka, że do
pobranego systemu CMS dogrywamy sobie tylko to czego potrzebujemy.
Trzeci problem stanowi sposób w jaki napisana jest dokumentacja (podrozdział „Jakość
dokumentacji”). Brak wbudowanych wielu pożądanych funkcji oraz nieprzystępność
dokumentacji dla nowicjuszy powoduje, że wiele osób nie podejmuje się korzystania z tego
systemu CMS.
Wnioski
Zdecydowanie najprościej jest rozpocząć swoją przygodę z CMS-ami od systemu WordPress.
Bardzo niecierpliwi lub zupełnie nie mający czasu użytkownicy będą z tego systemu
zadowoleni gdyż nie wymaga on zbyt wiele wkładu pracy w celu uruchomienia atrakcyjnej,
choć nie posiadającej oryginalnego wyglądu i rozbudowanej funkcjonalności, witryny.
System Joomla wymaga średniej ilości nakładu pracy wymaganej w celu uruchomienia strony
www. Nowicjusze zdecydowanie najwięcej będą musieli napracować się podczas tworzenia
strony opartej na Drupalu.
Jakość kodu PHP, komentarzeTo czy program jest dobrze napisany nie wynika wyłącznie z wygody jego obsługi i solidnego
działania. Istotna, z punktu widzenia programistów, jest także jakość kodu źródłowego
programu. Słaby jakościowo kod może wiązać się m.in. z niektórymi z następujących
problemów:
• Jest nieprzejrzysty
• Jest napisany niezgodnie z ogólnymi zasadami pisania kodu
• Nazwy zmiennych umieszczonych w kodzie są niejasne, przez co czytanie go jest
męczące
• Jest napisany w sposób niezapewniający szybkiego działania programu
• Zawiera miejsca w których mogą wystąpić błędy
130
Dlatego bardzo istotne jest dbanie o to aby kod źródłowy był jak najwyższej jakości. Dzięki
temu programiści nie będący współtwórcami oprogramowania mogą bez zbyt dużych
problemów studiować kod źródłowy.
Omawiane systemy CMS napisane są w języku PHP. Pliki z kodem PHP przechowywane są
w postaci nieskompilowanej, co oznacza, że w każdej chwili możliwe jest obejrzenie ich
zawartości. Ponadto, jak już wspomniano, omawiane systemy CMS są oprogramowaniem
open source dzięki czemu wszelki kod napisany w ramach ich projektów można swobodnie
przeglądać, modyfikować i kopiować w celu ponownego wykorzystania. Powiedziałbym
nawet, że studiowanie go jest zalecane.
Aby przeglądanie kodu CMS-ów było wygodne oraz aby działały one jak najlepiej, kod PHP
musi być napisany profesjonalnie i z zachowaniem najwyższej jakości.
WordPress
Kod źródłowy systemu WordPress jest napisany dość profesjonalnie. Sposób w jaki został on
wystylizowany bardzo ułatwia jego przeglądanie – przejścia do nowego wiersza stosowane są
odpowiednio często, a same linie kodu nie są za długie. Rozmieszczenie plików z kodem jest
logiczne i nie utrudnia ewentualnego studiowania sposobu działania systemu WordPress. Ilość
komentarzy w plikach źródłowych jest odpowiednia. W zbadanych trzech istotnych plikach
systemu, ilość linii z komentarzy była następująca:
• clases.php o długości 1701 wierszy – 747 linii z komentarzami, stosunek: 0.44
• functions.php o długości 4301 wierszy – 1726 linii z komentarzami, stosunek: 0.40
• wp-db.php o długości 1595 wierszy – 838 linii z komentarzami, stosunek: 0.53
Komentarze w plikach systemu WordPress są zrozumiałe i szczegółowe. Opisują m.in.
zastosowanie funkcji, przyjmowane parametry oraz zwracane wartości.
Dokładna analiza kodu systemu WordPress dała następujące wyniki:
Język Linie kodu Linie komentarz
y
Stosunek Puste linie Wszystkich linii
PHP 87 799 40 667 31.7% 18 893 147 359JavaScript 24 441 2 282 8.5% 3 399 30 122
CSS 14 658 484 3.2% 2 383 17 525
131
HTML 8 878 53 0.6% 1 191 10 122XML 37 0 0% 7 44
Przykładowy kod PHP (funkcja usuwająca z tekstu znaczniki HTML) został przedstawiony
poniżej:
/** * Strips all of the HTML in the content. * * @since 2.1.0 * * @param string $data Content to strip all HTML from * @return string Filtered content without any HTML */function wp_filter_nohtml_kses($data) {
return addslashes ( wp_kses(stripslashes( $data ), array()) );} /** * Filters content and keeps only allowable HTML elements. * * This function makes sure that only the allowed HTML element names, attribute * names and attribute values plus only sane HTML entities will occur in * $string. You have to remove any slashes from PHP's magic quotes before you * call this function. * * The default allowed protocols are 'http', 'https', 'ftp', 'mailto', 'news', * 'irc', 'gopher', 'nntp', 'feed', 'telnet, 'mms', 'rtsp' and 'svn'. This * covers all common link protocols, except for 'javascript' which should not * be allowed for untrusted users. * * @since 1.0.0 * * @param string $string Content to filter through kses * @param array $allowed_html List of allowed HTML elements * @param array $allowed_protocols Optional. Allowed protocol in links. * @return string Filtered content with only allowed HTML elements */function wp_kses($string, $allowed_html, $allowed_protocols = array ()) {
$allowed_protocols = wp_parse_args( $allowed_protocols, apply_filters('kses_allowed_protocols', array ('http', 'https', 'ftp', 'ftps', 'mailto', 'news', 'irc', 'gopher', 'nntp', 'feed', 'telnet', 'mms', 'rtsp', 'svn') ));
$string = wp_kses_no_null($string);$string = wp_kses_js_entities($string);$string = wp_kses_normalize_entities($string);$allowed_html_fixed = wp_kses_array_lc($allowed_html);$string = wp_kses_hook($string, $allowed_html_fixed,
$allowed_protocols); // WP changed the order of these funcs and added args to wp_kses_hook
return wp_kses_split($string, $allowed_html_fixed, $allowed_protocols);
132
}
133
Joomla
Kod źródłowy systemu Joomla również został wystylizowany w sposób ułatwiający jego
studiowanie, choć jest nieco mniej przejrzysty od kodu systemu WordPress. Poza tym sposób
rozmieszczenia plików z kodem jest wątpliwy – nieprzyjazna struktura folderów i plików
systemu Joomla na pewno nie spodoba się programistom zaczynającym swoją przygodę z tym
systemem.
Ilość komentarzy w kodzie plików systemu Joomla jest odpowiednia choć bardzo często
komentarze te są zbyt ogólnikowe lub nietreściwe. W przypadku komentarzy pojawiających
się przy definicjach funkcji, podawane są przyjmowane parametry oraz zwracane wartości. W
trzech zbadanych istotnych plikach systemowych ilość komentarzy była następująca:
• application.php o długości 926 wierszy – 407 linii z komentarzami, stosunek: 0.44
• database.php o długości 817 wierszy – 409 linii z komentarzami, stosunek: 0.50
• form.php o długości 1752 wierszy – 664 linii z komentarzami, stosunek: 0.38
Przebadanie wszystkich plików systemu Joomla dało następujące wyniki:
Język Linie kodu Linie komentarz
y
Stosunek Puste linie Wszystkich linii
PHP 499 455 244 039 32.8% 156 922 900 416JavaScript 128 002 20 269 13.7% 29 061 177 332
CSS 56 517 4 253 7.0% 12 540 73 310HTML 112 407 1 159 1.0% 24 042 137 608XML 43 748 302 0.7% 2 135 46 185SQL 10 108 2 406 19.2% 1 953 14 467
Przykładowy kod PHP (fragment funkcji usuwającej z tekstu znaczniki HTML) został
przedstawiony poniżej:
/** * Internal method to strip a string of certain tags * * @param string Input string to be 'cleaned' * @return string 'Cleaned' version of input parameter * @since 1.5 */protected function _cleanTags($source){
134
// In the beginning we don't really have a tag, so everything is postTag
$preTag = null;$postTag = $source;$currentSpace = false;$attr = ''; // moffats: setting to null due to issues in migration
system - undefined variable errors
// Is there a tag? If so it will certainly start with a '<'$tagOpen_start = strpos($source, '<');
while ($tagOpen_start !== false) {
// Get some information about the tag we are processing$preTag .= substr($postTag, 0,
$tagOpen_start);$postTag = substr($postTag, $tagOpen_start);$fromTagOpen = substr($postTag, 1);$tagOpen_end = strpos($fromTagOpen, '>');
// Let's catch any non-terminated tags and skip over themif ($tagOpen_end === false) {
$postTag = substr($postTag, $tagOpen_start +1);
$tagOpen_start = strpos($postTag, '<');continue;
}
// Do we have a nested tag?$tagOpen_nested = strpos($fromTagOpen, '<');$tagOpen_nested_end = strpos(substr($postTag,
$tagOpen_end), '>');if (($tagOpen_nested !== false) && ($tagOpen_nested <
$tagOpen_end)) {$preTag .= substr($postTag, 0,
($tagOpen_nested +1));$postTag = substr($postTag,
($tagOpen_nested +1));$tagOpen_start = strpos($postTag, '<');continue;
} (...)
Drupal
Przeglądając kod źródłowy systemu Drupal daje się mocno odczuć rygor jaki nakłada na
programistów Drupala jego społeczność. Kod ten jest wystylizowany z dbałością o
najmniejsze szczegóły. Dzięki temu studiowanie kodu jest nieco łatwiejsze, niż w przypadku
pozostałych dwóch systemów CMS.
To co ucieszy nowych użytkowników-programistów to świetnie rozmieszczone pliki systemu:
pliki odpowiedzialne za konkretne funkcje dodatkowe znajdują się w pod-folderach folderu
135
„modules” natomiast wszystkie pliki systemowe (np. te związane z łączeniem się z bazą
danych lub budowaniem dynamicznych formularzy) w folderze „includes”. Trzeba przyznać,
że plików systemu nie dało się rozmieścić w sposób bardziej logiczny i umożliwiający
wygodniejsze przeglądanie ich.
Komentarze w kodzie źródłowym systemu Drupal są bogatsze i bardziej treściwe niż w
przypadku systemów WordPress i Joomla. W trzech zbadanych istotnych plikach
systemowych ilość komentarzy była następująca:
• bootstrap.inc o długości 1208 wierszy – 557 linii z komentarzami, stosunek: 0.46
• form.inc o długości 2553 wierszy – 1217 linii z komentarzami, stosunek: 0.48
• Database.inc o długości 602 wiersze – 324 linii z komentarzami, stosunek: 0.53
Przebadanie wszystkich plików systemu Drupal dało następujące wyniki:
Język Linie kodu Linie komentarz
y
Stosunek Puste linie Wszystkich linii
PHP 145 870 69 074 32.1% 19 298 234 242JavaScript 4 489 2 568 36.4% 773 7 830
CSS 8 318 802 8.8% 827 9 947HTML 1 984 6 0.3% 219 2 209XML 478 3 0.6% 6 487
Przykładowy kod PHP (fragment funkcji usuwającej z tekstu znaczniki HTML) został
przedstawiony poniżej:
/** * Encode special characters in a plain-text string for display as HTML. * * Uses drupal_validate_utf8 to prevent cross site scripting attacks on * Internet Explorer 6. */function check_plain($text) { return drupal_validate_utf8($text) ? htmlspecialchars($text, ENT_QUOTES) : '';} /** * Checks whether a string is valid UTF-8. * * All functions designed to filter input should use drupal_validate_utf8 * to ensure they operate on valid UTF-8 strings to prevent bypass of the
136
* filter. * * When text containing an invalid UTF-8 lead byte (0xC0 - 0xFF) is presented * as UTF-8 to Internet Explorer 6, the program may misinterpret subsequent * bytes. When these subsequent bytes are HTML control characters such as * quotes or angle brackets, parts of the text that were deemed safe by filters * end up in locations that are potentially unsafe; An onerror attribute that * is outside of a tag, and thus deemed safe by a filter, can be interpreted * by the browser as if it were inside the tag. * * This function exploits preg_match behaviour (since PHP 4.3.5) when used * with the u modifier, as a fast way to find invalid UTF-8. When the matched * string contains an invalid byte sequence, it will fail silently. * * preg_match may not fail on 4 and 5 octet sequences, even though they * are not supported by the specification. * * The specific preg_match behaviour is present since PHP 4.3.5. * * @param $text * The text to check. * @return * TRUE if the text is valid UTF-8, FALSE if not. */function drupal_validate_utf8($text) { if (strlen($text) == 0) { return TRUE; } return (preg_match('/^./us', $text) == 1);}
Wnioski
Wszystkie trzy CMS posiadają solidny kod źródłowy, który łatwo się czyta. Komentarze w
kodzie ułatwiają jego zrozumienie. Pod tym względem system Drupal jest nieco lepszy od
swoich konkurentów – komentarze są tu bardziej treściwe i zrozumiałe (przykłady powyżej
aby porównać).
Rozmieszczenie plików z kodem najlepiej przemyślano w systemach Drupal i WordPress.
Niestety w hierarchii plików i folderów systemu Joomla panuje nieład, co nie sprzyja nowym
użytkownikom-programistom w studiowaniu sposobu działania tego systemu CMS.
Obsługa wielu witryn przez 1 instalację CMS-a (multisite)Opisywane CMS-y świetnie nadają się do budowania pojedynczych niezależnych witryn,
jednak w wielu sytuacjach przydatna jest możliwość zbudowania kilku (lub nawet kilkuset)
oddzielnych witryn działających w oparciu o jedną fizyczną instalację wybranego systemu
CMS. Na czym dokładnie polega ta konfiguracja?
137
Zazwyczaj tworząc różne witryny instalujemy ten sam system CMS na oddzielnych
serwerach fizycznych lub wirtualnych. W podejściu tym każda strona działa w oparciu o
oddzielną kopię plików systemu CMS. Konfiguracja typu „multisite” pozwala na
uruchomienie wielu oddzielnych witryn korzystających z jednego zbioru plików systemu
CMS.
Zalety takiej konfiguracji to:
• Jedno współdzielony kod systemu CMS
• Tylko jeden system CMS do aktualizowania
• Tylko jeden zbiór plików systemu CMS do testowania w poszukiwaniu błędów
• System taki nadal posiada elastyczność przypisywania różnych modułów różnym
witrynom
• Współdzielenie modułów i szablonów jeśli potrzeba
• Możliwość wykorzystywania tej samej bazy danych lub różnych
• Możliwość współdzielenia informacji pomiędzy witrynami, np. kont użytkowników
Wiele zalet konfiguracji typu „multisite” sprawia, że bardzo wiele firm korzysta z takich
rozwiązań. Porównam teraz możliwości tworzenia tego typu środowisk za pomocą systemów
WordPress, Joomla i Drupal.
WordPress
System WordPress posiada bardzo ograniczone wsparcie dla multiinstalacji. Pozwala on na
skonfigurowanie wielu witryny działających w zakresie jednej domeny głównej. Dostęp do
każdej witryny zapewniają tu tzw. subdomeny. Przykładem takiej multiinstalacji jest zbiór
blogów dostępnych w serwisie WordPress.org. Pojedyńcze blogi są tu dostępne pod adresami
zgodnymi ze schematem „[subdomeny].wordpress.com”.
System WordPress nie posiada mechanizmu rozpoznawania domen poprzez które następują
odwiedziny. W związku z tym nie można np. skonfigurować dwóch zupełnie niezależnych
witryn posiadających inne domeny (np. www.witryna1.pl i www.strona2.com).
Joomla
138
System Joomla od wersji 1.6 ma wspierać instalacje typu multi. Ponieważ jednak system ten
nie został jeszcze oficjalnie wydany, a możliwości tworzenia multiinstalacji nie zostały
jeszcze dokładnie udokumentowane, ciężko jest cokolwiek więcej na ten temat napisać.
Drupal
Wbudowana w system Drupal obsługa wielu witryn przez jedną instalację pozwala na
udostępnianie tych witryn zarówno poprzez różne domeny, subdomeny jak i prefiksy. Dzięki
możliwości konfigurowania oddzielnych domen dla oddzielnych stron system ten idealnie
nadaje się do tworzenia instalacji typu multi.
Ponadto w Drupalu w środowisku „multi” możliwe jest przypisywanie dodatkowych
modułów i szablonów tylko wybranym witrynom. Dzięki takiemu działaniu moduły wgrane
na potrzeby jednej witryny mogą pozostać niewidoczne dla pozostałych witryn. Zapewnia to
większy poziom kontroli nad środowiskiem.
Wnioski
Drupal posiada ewidentną przewagę nad systemem WordPress jeśli mowa o możliwościach
tworzenia wielu witryn korzystających z jednej instalacji systemu. Co do systemu Joomla
ciężko na razie jeszcze się wypowiadać – w tym przypadku trzeba poczekać, aż nowa wersja
tego CMS-a zostanie lepiej udokumentowana.
2.3.3. CECHY POZOSTAŁETa ostatnia kategoria zawiera cechy niezwiązane bezpośrednio z możliwościami samych
CMS-ów choć pośrednio ich dotyczy. Omówię tu jakość ich dokumentacji oraz poziom
wsparcia ze strony społeczności.
Jakość dokumentacjiDokumentowanie oprogramowania jest istotne, zwłaszcza jeśli mowa o programach i
systemach udostępnianych publicznie, niezależnie od typu licencji, czy to komercyjnej czy też
GPL. Brak dokumentacji bądź niewystarczająca dokumentacja nieraz powoduje frustrację
użytkowników próbujących poznać i nauczyć się korzystać z nowego oprogramowania. Jest
tak zwłaszcza wtedy gdy mowa o użytkownikach nietechnicznych.
Nie inaczej ma się sprawa dokumentowania systemów CMS. Ponieważ systemy te to bardzo
złożone struktury posiadające wiele funkcji i dodatkowych modułów, o samym API już nie
wspominając, brak solidnej i treściwej dokumentacji prawdopodobnie bardzo negatywnie by
139
się odbił na popularności takiego systemu. Bez odpowiedniej dokumentacji nawet
informatycy (oprócz weteranów oraz samych twórców programu) niechętnie by sięgali po
dany system CMS. Nic dziwnego. Brak jasnej dokumentacji oznacza dłuższy czas realizacji
projektu, co z koleji oznacza gorszy zarobek i więcej godzin zmarnowanych na poszukiwaniu
rozwiązań.
Podsumowując, solidna dokumentacja umożliwia szybsze wykonywanie nowych zadań,
których nie robiło się do tej pory, dlatego wszystkie porządne CMS-y powinny je posiadać.
Dotyczy to także systemów zarządzania treścią wybranych do porównania, dlatego przyjrzę
się ich dokumentacjom.
WordPress
Pełna dokumentacja systemu WordPress dostępna jest pod adresem
http://codex.wordpress.org. Solidnie uporządkowane informacje o tym CMS-ie podzielone
zostały na następujące działy:
• Dla początkujących
• Ogólne informacje nt. korzystania z systemu WordPress
• Tematyka dotycząca wyglądu witryny
• Tematyka zaawansowana
• Wsparcie techniczne i odpowiedzi na często zadawane pytania
• Dokumentacja dla programistów i deweloperów
Informacje opublikowane w dokumentacji zostały podzielone w dobrze przemyślany sposób,
dzięki czemu przeglądanie jej jest przyjemne i wygodne. Wiele poszczególnych stron posiada
dodatkową nawigację ułatwiającą poruszanie się wewnątrz strony. Część podstron jest
również dostępnych w kilku językach, aczkolwiek z bardziej uniwersalnych mamy zazwyczaj
do wyboru tylko angielski i hiszpański.
Dokładne opisy wielu podstawowych aspektów systemu ułatwią początkującym
użytkownikom rozpoczęcie przygody z systemem WordPress. Oczywiście nie zapomniano też
o deweloperach i programistach – dział opisujący zagadnienia związane z tworzeniem
140
szablonów i wtyczek też jest dobrze rozbudowany. Zaglądając do tego działu napotykamy
komunikat:
Rysunek . Komunikat ostrzegający o możliwości pojawienia się listingów z kodem wita osoby, które wejdą na główną stronę działu "Dla deweloperów".
Opisy dotyczące tworzenia szablonów i wtyczek są na dobrym poziomie, aczkolwiek
nowicjusze i tak będą musieli się napracować zanim utworzą swój własny szablon (zakładając
oczywiście, że nie zajmowali się wcześniej podobną tematyką). Również dokumentacja
systemowego API jest porządna choć poważnym problemem jest jej niekompletność.
Podsumowując, każdy oprogramowanie powinno posiadać tak solidną, przejrzystą i łatwo
czytającą się dokumentację.
Dodatkowo poza oficjalną dokumentacją w Internecie dostępnych jest dużo tutoriali, blogów
opisujących ciekawe rozwiązania oraz filmów wideo ułatwiających opanowywanie wielu
technik. Dosyć popularne są też podcasty. Mnóstwo książek na temat systemu WordPress
zostało wydanych w bardzo przyzwoitym wydawnictwie Packt Publishing
(http://www.packtpub.com) chociaż na razie nie zostały one wydane po Polsku.
Joomla!
Dokumentacja systemu Joomla jest dostępna pod adresem http://docs.joomla.org/. Po wejściu
na stronę główną dokumentacji pierwsze co rzuca się w oczy to brak przemyślanej nawigacji.
Oprócz setek różnych informacji dostępnych na stronie głównej, pojawi się nam lista z trzema
odnośnikami do trzech działów dokumentacji:
• Dla administratorów
• Dla web designerów
• Dla developerów
141
Podział dokumentacji jest w rzeczywistości szerszy – dokumentacja posiada specjalne
podstrony przeznaczone dla następujących grup osób:
• Dla początkujących
• Osoby sprawdzające czy Joomla nadaje się do wykonania danego projektu
• Osoby tworzące treść
• Edytorzy
• Wydawcy
• Administratorzy
• Web designerzy
• Web deweloperzy
• Deweloperzy
• Testerzy
• Tłumacze
• Osoby prowadzące szkolenia
• Osoby dokumentujące system Joomla
Mimo ciekawego sposobu podziału dokumentacji, ogólne rozmieszczenie informacji jest
bardzo źle przemyślane. Nie zadbano także o solidną, spójną nawigację. Dokumentacja ta jest
dość amatorska i panuje w niej spory nieład.
Poza wymienionymi niedogodnościami dokumentacja systemu Joomla jest bardzo bogata w
różne informacje. Dostępność sekcji dla początkujących ułatwi szybkie rozpoczęcie przygody
z tym CMS-em.
Również dla Joomli dostępna jest rozbudowana dokumentacja API (http://api.joomla.org),
jednak i tu nawigacja jest nieprzyjazna.
142
Wiele tutoriali internetowych, filmów dostępnych online i ciekawych podcastów ułatwi
poznawanie systemu Joomla. W wydawnictwie Pack Publishing zakupić można wiele książek
na temat Joomli.
Drupal
Bardzo bogata dokumentacja systemu Drupal dostępna jest na oficjalnej stronie tego CMS-a,
pod adresem http://www.drupal.org/handbook. Informacje zawarte w dokumentacji
podzielone zostały na następujące sekcje:
• Dla początkujących
• Tworzenie witryny
o Przygotowywanie struktury strony
o Budowa witryny
o Tworzenie szablonów
• Pisanie własnego kodu
o Tworzenie modułów
o API
o Przykłady dla deweloperów
• Dodatki
o Gotowe skrawki kodu
o Rozwiązywanie problemów
o Odpowiedzi na często zadawane pytania
• Tutoriale
• Społeczność Drupala
o O Drupalu
143
o Angażowanie się w współtworzenie
o Współtworzenie dokumentacji
Informacje zawarte w tej dokumentacji zostały rozmieszczone w dość logiczny sposób.
Dostępne są zarówno sekcje przeznaczone dla początkujących jak i zaawansowanych
użytkowników. Mimo tego poruszanie się w niej może nowym użytkownikom nastręczyć
nieco problemów. Dotyczy to zwłaszcza osób, które nie miały dotychczas żadnych
doświadczeń w korzystaniu z systemów CMS. Wynika to z faktu, że w wielu miejscach
dokumentacji systemu Drupal poruszane są zagadnienia zaawansowane, przez co czytając tą
dokumentację nieraz ma się wrażenie, że jest ona tworzona bardziej z myślą o programistach
niż zwykłych użytkownikach.
Pomimo logicznego podziału informacji zawartych w dokumentacji Drupala, sporo rzeczy
ciężko jest w niej odnaleźć (polecam przeszukiwać za pomocą Google). Wynika to zapewne
po części z tego, że dokumentacja ta jest bardzo obszerna oraz z tego, że tworzy ją duża liczba
osób jednocześnie.
Opisy dotyczące tworzenia szablonów i wtyczek są dużo bardziej rozbudowane niż było to w
przypadku pozostałych dwóch systemów CMS, choć brakuje tu „łagodnych” wprowadzeń,
które umożliwiłyby laikom płynne zgłębienie się w nową tematykę.
Dodatkowo dostępna jest też profesjonalna dokumentacja API (http://api.drupal.org), którą
doceni każdy programista pracujący w Drupalu. Imponujący fakt, że dokumentacja API
zawiera opisy wszystkich funkcji wbudowanych w Drupala. Wynika to z tego, że wszystkie
nowe wersje systemu Drupal są przetrzymywane w fazie alfa lub beta tak długo dopóki
dokumentacja API nie zostanie uzupełniona o opisy nowo dodanych funkcji.
Dodatkowo dokumentacja systemu Drupal posiada wiele podstron dokumentujących
korzystanie z różnorakich dodatkowych modułów nie wchodzących w skład domyślnej
instalacji Drupala. Niestety odnajdywanie tych podstron może nieraz być niewygodne.
Również w przypadku systemu Drupal dostępnych jest wiele tutoriali internetowych, filmów
wideo i ciekawych podcastów. Wydawnictwo Packt Publishing także dla użytkowników
systemu Drupal oferuje wiele pozycji na temat tego CMS-a.
Wnioski
144
Wszystkie trzy systemy CMS zostały solidnie udokumentowane. Bez porządnej dokumentacji
prawdopodobnie nie odniosły by sukcesu i nie byłyby dziś tak popularne.
Z punktu widzenia zwykłego użytkownika zdecydowanie najbardziej przyjazna jest
dokumentacja systemu WordPress – zarówno pod względem zawartych informacji jak i ich
rozmieszczenia. Dokumentacja systemu Drupal wydaje się być nieco bogatsza od
dokumentacji systemu WordPress, choć sposób w jaki została zbudowana oraz fakt, że
pojawia się w niej wiele zaawansowanych zagadnień, sprawia wrażenie jak by była
przeznaczona bardziej dla programistów niż nowicjuszy. Dokumentacja systemu Joomla jest
najmniej wygodna i najmniej przyjazna, choć także bogata. Nawet wprawieni programiści
mogą być zirytowani sposobem organizacji zawartych w niej treści.
Wsparcie ze strony społeczności, jakoś i czas reakcji forumMimo tego, że omawiane systemy CMS posiadają bogate dokumentacje, na wiele problemów
nie znajdziemy w nich odpowiedzi. Niemożliwe bowiem jest przewidzenie wszystkich
zagadnień, z którymi użytkownicy nie będą mogli sobie poradzić podczas korzystania z
oprogramowania.
Dlatego bardzo dużą popularnością cieszą się fora internetowe, na których przedstawiciele
społeczności systemów CMS mogą publikować posty z zapytaniami o pomoc lub po prostu
poradami dla innych użytkowników. Fora te umożliwiają wzajemną komunikację. Z aktywnie
prowadzonych dyskusji na temat systemów CMS wynika wiele nowych pomysłów, które
nieraz są wykorzystywane podczas ulepszania oprogramowania, którego dotyczą.
Oczywiście sam fakt istnienia for nie wystarczy. Aby działały one sprawnie konieczne jest
także zaangażowanie oraz chęć pomocy ze strony społeczności. Bez tych elementów forum
nigdy nie będzie godne uwagi.
Życie społeczności systemów CMS nie ogranicza się do brania udziału w dyskusjach na
forum. Jest wiele innych działań, które można podjąć aby pomóc w rozwijaniu
oprogramowania.
WordPress
Forum systemu WordPress jest bardzo aktywne – codziennie pojawia tam mnóstwo nowych
postów o charakterze informacyjnym oraz pytań i odpowiedzi. Ilość topików w momencie
145
pisania tej pracy wynosiła 417 221, a postów 1 581 892, czyli dokładnie 3.79 postów na topik.
Forum to można znaleźć pod adresem http://wordpress.org/support/. Jego zawartość została
bardzo dobrze podzielona.
Rysunek . Strona główna forum społeczności systemu WordPress.
Osoby początkujące będą na pewno zadowolone z funkcjonowania forum systemu
WordPress. Dzięki niesamowitej jego aktywności i przyjazności nowicjusze bez problemu
uzyskają pomoc w trudnej sytuacji.
Inne ciekawe miejsca, które mogą okazać się pomocne podczas korzystania z systemu
WordPress, to między innymi:
• Oficjalne kanały IRC systemu WordPress: http://codex.wordpress.org/IRC
• Aktualności systemu WordPress: http://wordpress.org/news/
Joomla
Forum społeczności systemu Joomla cechuje imponująca aktywność – zdecydowanie większa
niż jest to w przypadku pozostałych dwóch systemów CMS. W czasie pisania tej pracy ilość
topików wynosiła 476 991, a postów 2 058 518 co daje 4.32 postów na topik. To ponad dwa
razy więcej niż w przypadku forum systemu Drupal.
146
Na forum Joomli użytkownicy bardzo chętnie udzielają pomocy dlatego forum to jest idealne
zwłaszcza dla osób początkujących.
Rysunek . Fragment strony głównej forum społeczności systemu Joomla
Również i tu dokonano podziału na kategorie, których jest bardzo dużo co bardzo ułatwia
przeglądanie forum.
Poza samym forum dostępnych jest bardzo wiele źródeł przydatnych informacji. Do
najważniejszych należą między innymi:
• Oficjalny blog systemu Joomla: http://community.joomla.org/blogs/community.html
• Oficjalny kanał na Twitterze: http://twitter.com/joomla
• Lista międzynarodowych społeczności Joomla: http://community.joomla.org/user-
groups.html
• Nadchodzące wydarzenia: http://community.joomla.org/events.html
• Open Source Matters – organizacja opiekująca się projektem Joomla:
http://opensourcematters.org
147
• Joomla Security Center: http://developer.joomla.org/security.html
Drupal
Rozbudowane forum internetowe społeczności systemu Drupal, dostępne pod adresem
http://www.drupal.org/forum, podzielono na wiele działów. Duża ilość topików (429 665) i
postów (848 699) ułatwia odnajdywanie odpowiedzi na pytania, które swoją tematyką
wykraczają poza dokumentację systemu. Niestety pewną wadą tego forum jest często długi
czas oczekiwania na odpowiedź. Wiele dyskusji prowadzonych na forum zawiera wypowiedzi
wykraczające poza zakres pojmowania przeciętnych użytkowników. Również spora część
pytań pozostaje bez odpowiedzi. Forum to cechuje się najgorszym stosunkiem pytania-
odpowiedzi (1.95). To prawie dwa posty dla jednego topiku. Wynika to zapewne z natury
systemu Drupal – wiele osób decydujących się na korzystanie z tego systemu to zapracowani
użytkownicy zaawansowani.
Poza samym forum wiele ciekawych rzeczy można dowiedzieć się poprzez oficjalne grupy
dyskusyjne (http://groups.drupal.org). Dostępne są także różne grupy mailingowe. Pełną ich
listę można zobaczyć pod adresem http://www.drupal.org/mailing-lists.
Inne przydatne miejsca to:
• Odnośniki do kanałów IRC systemu Drupal: http://drupal.org/node/108355
• Grupa do spraw bezpieczeństwa systemu Drupal („Drupal Security Team”):
http://drupal.org/security-team
• Aktualności dotyczące bezpieczeństwa: http://drupal.org/security
• Lista społeczności z różnych krajów: http://drupal.org/language-specific-communities
• Oficjalna strona Stowarzyszenia Drupala: http://association.drupal.org/
148
Rysunek . Fragment strony głównej forum społeczności systemu Drupal.
Wnioski
Społeczności wszystkich trzech porównywanych systemów CMS posiadają bardzo dobrze
funkcjonujące fora internetowe. Najbardziej przyjazne jest forum Joomli. Użytkownicy
znacznie częściej odpisują tam na prośby o pomoc, niż na forum Drupala, które pod tym
względem jest najsłabsze. Ponadto forum to skupia się w dużej mierze wokół tematyki
zaawansowanej, która może być nieodpowiednia dla początkujących użytkowników.
Oprócz samych for, systemy Joomla i Drupal nieco bardziej niż WordPress udostępniają wiele
dodatkowych informacji poprzez grupy, międzynarodowe strony lokalnych społeczności, listy
mailingowe czy kanały IRC.
2.3.4. PODSUMOWANIE PORÓWNANIAPorównałem dotąd bardzo wiele aspektów systemów WordPress, Joomla i Drupal. Na
podstawie porównań przypiszę odpowiednim systemom punkty, według następującego
klucza:
• 1 – Ograniczona funkcjonalność
• 2 – Dobre lub umiarkowane wsparcie danej funkcji / cechy
149
• 3 – Perfekcyjne wsparcie danej funkcji
Zestawienie wyników porównań w przedstawiono w poniższej tabelce:
Funkcja / Cecha WordPress Joomla DrupalŁatwość instalacji 3 3 3Funkcje wbudowane 2 2 2Łatwość obsługi i intuicyjność. Jakość panelu administracyjnego.
3 2 2
Łatwość dodawania i edytowania treści 3 2 3Możliwości prezentowania treści 2 2 3Współdzielenie informacji z innymi stronami. Łatwe sprawdzanie nowości. Przeszukiwanie witryny.
2 2 3
Dostępność darmowych szablonówi ich jakość
3 1 1
Dostępność solidnych dodatków 3 2 3Wsparcie dla multimediów 2 2 2Łatwość aktualizowania systemu i polityka aktualizacji
2 2 3
Jakość generowanego kodu HTML 3 2 3Własne typy podstron 1 1 3Workflow 1 1 3Zarządzanie użytkownikami 2 2 3Logowanie zdarzeń systemowych 1 1 3Backup bazy danych 1 2 3Wsparcie dla stron wielojęzycznych 2 2 3Możliwości systemu szablonów oraz łatwość korzystania z niego
2 1 3
Trud wymagany w celu zbudowania strony
3 2 1
Jakość kodu PHP, komentarze 2 2 3Jakość dokumentacji 2 2 2Wsparcie ze strony społeczeństwa. Czas reakcji forum.
3 3 2
RAZEM 48 41 57
Po podsumowaniu zdobytych punktów można zobaczyć, że najwięcej otrzymał ich system
Drupal. Osiągnięta przez niego liczba wyniosła 57. Maksymalna liczba punktów do zdobycia
wynosiła 66, a minimalna 22. Pozostałe systemy zdobyły kolejno: WordPress – 48 punktów, i
Joomla – 41.
2.4. Testy porównawcze
150
Niestety samo badanie możliwości funkcjonalnych systemów CMS to nie wszystko. Bardzo
istotna jest także ich wydajność. Ma to duże znaczenie zwłaszcza podczas korzystania z nich
przez witryny o dużym natężeniu ruchu. W podrozdziale tym porównam wyniki testów
wydajnościowych.
2.4.1. Środowisko testowe Prędkość działania aplikacji zależy nie tylko od niej samej ale także od warunków panujących
w środowisku, w którym jest uruchamiana. Dlatego zanim porównam wyniki testów, opiszę
konfigurację sprzętową serwera na którym zainstalowane i uruchamiane były systemy
WordPress, Joomla i Drupal:
Procesor: Intel Core i7 930 64-bitowy (czterordzeniowy z technologią HT, 2.80 GHz)
Pamięć operacyjna: OCZ DDR3 Triple channel, 3x2048MB 1600MHz CL8
Płyta główna: Asus P6X58D Premium X58 LGA 1366
Dysk twardy: Seagate SATA 2, 7200 rpm
Oprogramowanie serwera składało się z Windows 7 Professional oraz pakietu XAMPP 1.7.0,
w którego skład wchodzą:
• Serwer Apache 2.2.11
• MySQL 5.1.30
• PHP 5.2.8
Systemy CMS testowano przy pomocy programu JMeter25 skonfigurowanego w następujący
sposób:
• Program symulował pracę jednego użytkownika
• Wykonanych zostało 1000 zapytań do serwera
• Zapytania były zadawane tak szybko jak tylko to możliwe
25 Strona domowa programu JMeter jak i rozbudowany poradnik opisujący jak korzystać z tego narzędzia znajduje się pod adresem http://jakarta.apache.org/jmeter/
151
Testy symulujące pracę wielu użytkowników jednocześnie nie będą wykonane ponieważ
zaburzyły by one wyniki. Najszybszy czas ładowania da się zbadać wyłącznie sprawdzając
prędkość odpowiedzi podczas odwiedzania strony przez jedną osobę.
2.4.2. Testowane konfiguracjeZe względu na to, że systemy Joomla 1.6 oraz Drupal 7 nie zostały jeszcze oficjalnie wydane,
testowane były następujące wersje CMS-ów:
• Drupal 6.17
• Joomla 1.5.20
• WordPress 3.0.1
Badane systemy CMS zostały przetestowane w czterech następujących konfiguracjach:
• Świeżo zainstalowany system CMS z jednym opublikowanym artykułem i z
wyłączonym buforowaniem
• Świeżo zainstalowany system CMS z jednym opublikowanym artykułem i z
włączonym buforowaniem
• Gotowa prosta witryna z 11 artykułami i wyłączonym buforowaniem
• Gotowa prosta witryna z 11 artykułami i włączonym buforowaniem
Aby uczynić testowe świeże instalacje „równymi” zastosowano następujące ustawienia:
• WordPress domyślnie wyświetla formularz przeszukiwania witryny – formularz taki
wyświetlono także w Drupalu i Joomli
• WordPress i Joomla nie posiadają domyślnie wyświetlonego bloku z formularzem
logowania do witryny – formularz został ukryty również w Drupalu
• WordPress wyświetla menu główne z odnośnikiem do strony głównej – podobne menu
zostało skonfigurowane w Joomli i Drupalu
• Do wszystkich trzech systemów CMS dodano jeden testowy artykuł podzielony z
odnośnikiem „Czytaj więcej”
152
• WordPress i Joomla wyświetlają w pasku bocznym dodatkową nawigację – dodatkowa
nawigacja została wyświetlona również w Drupalu
• WordPress posiada wbudowane zarządzanie aliasami artykułów. Zarządzanie aliasami
z wykorzystaniem mod_rewrite włączono także w Joomli i Drupalu.
• W systemie WordPress ukryto wszystkie dodatkowo wyświetlane w pasku bocznym
bloki
Gotowe proste witryny zbudowane w oparciu o porównywane systemu CMS składały się
identycznej ilości elementów:
• Nawigacja główna z 6 odnośnikami, w tym dwa wewnętrzne i 4 zewnętrzne
• Nawigacja boczna z 2 odnośnikami, w tym jeden wewnętrzny
• Wyświetlany w pasku bocznym blok z tekstem powitalnym
• Pole wyszukiwarki treści wyświetlone w pasku bocznym
• Prezentacja na stronie głównej 10 ostatnich postów. W systemie Joomla wymagało to
dodatkowej konfiguracji, w pozostałych dwóch systemach CMS jest to domyślne
zachowanie.
• Łącznie 11 opublikowanych postów – o jeden więcej niż się mieści na stronie głównej.
Ma to na celu wymuszenie wyświetlania podziału listy artykułów na strony.
• Wszystkie posty podzielone na dwie części z opcją „Czytaj dalej”.
Testy z włączonym buforowaniem przeprowadzone były z włączonymi wszystkimi
wbudowanymi w systemy CMS funkcjami poprawiającymi wydajność.
Funkcje poprawiające wydajnoś
w systemie Drupal są następujące:
• Buforowanie stron, tryb buforowania: zwykły
153
• Kompresja gzip26
• Buforowanie bloków
• Optymalizacja CSS
• Optymalizacja JavaScript
W systemie Joomla:
• Buforowanie stron
• Kompresja gzip
System WordPress nie udostępnia żadnych wbudowanych narzędzi umożliwiających
konfigurowanie buforowania.
Liczby zaprezentowane w wynikach mają na celu jedynie porównanie prędkości działania
poszczególnych systemów i nie są dokładnym odwzorowaniem ich rzeczywistej szybkości.
Wynika to np. z tego, że testujący program JMeter, nie jest przeglądarką www i jedyne co
robi polega na pobraniu danych z serwera. Testowane strony nie są jednak renderowane, a
skrypty JavaScript nie są przetwarzane.
26 Gzip – format kompresji danych często wykorzystywany do kompresji plików strony www przed przesłaniem ich do przeglądarki www. Działanie to zmniejsza czas transferu. Strona domowa formatu Gzip dostępna jest pod adresem http://www.gzip.org/
154
2.4.3. Wyniki testówWyniki testów przedstawiono w milisekundach. Podane wartości to mediana czasu ładowania
wyliczona ze wszystkich zapytań. Czas ładowania jest czasem liczonym od momentu
wysłania żądania do momentu załadowania całej strony.
Do zaprezentowania wyników wybrano medianę a nie średnią, ponieważ w przypadku
mediany wartości skrajne nie zaburzają wyniku.
Niższe wartości oznaczają lepszy wynik. Szybciej ładujące się strony zapewniają bardziej
komfortowe korzystanie z nich.
2.4.4. WnioskiDrupal jest znacznie szybszy od systemów Joomla i WordPress we wszystkich czterech
konfiguracjach.
W przypadku świeżej instalacji bądź gotowej witryny włączenie w systemie Drupal
buforowania skraca czas ładowania o około 84%. W systemie Joomla włączenie buforowania
w przypadku świeżej instalacji skraca czas ładowania o około 41%, zaś w przypadku gotowej
strony o około 51%.
Wyniki dla systemu WordPress w rubrykach „z buforowaniem” są identyczne jak dla tych
„bez buforowania”. Jest tak ponieważ WordPress nie posiada wbudowanych opcji
konfiguracji buforowania w związku z czym jego ustawienia odnośnie wydajności były za
każdym razem takie same.
2.5. Wybór najlepszego systemuWszystkie porównane systemy CMS to solidne aplikacje. Każda z nich ma swoje dobre i złe
strony. Podsumowanie najistotniejszych cech każdego z nich przedstawiam poniżej.
WordPress
Głównym atutem systemu WordPress jest prostota jego obsługi. Łatwość instalacji i
szybkiego uruchomienia gotowej działającej strony sprawia, że system ten jest idealny dla
osoby nieznającej technik tworzenia stron www.
155
WordPress posiada bardzo intuicyjny formularz dodawania nowych postów i podstron.
Wbudowano w niego edytor tekstowy TinyMCE, który pozwala na formatowanie tekstu bez
konieczności zapoznawania się z językiem HTML. Ponadto wbudowany menadżer
multimediów ułatwi zarządzanie m.in. zdjęciami, które można z łatwością osadzać w tekstach
postów i podstron.
Ograniczona liczba wybudowanych funkcji i opcji zmniejsza poziom skomplikowania tego
CMS-a i upraszcza jego obsługę osobom początkującym. W przypadku konieczności dodania
nowej funkcjonalności można poszukać dodatkowych wtyczek do systemu, które poszerzają
jego możliwości. Wiele z tych wtyczek nie jest tak profesjonalna, jak jest to w przypadku
systemu Drupal. Również sporo wtyczek posiada duplikującą się funkcjonalność, co świadczy
o kiepskim współdziałaniu tworzących je programistów.
Dodatkowo dostępność wielu estetycznych i atrakcyjnych darmowych szablonów umożliwi
każdemu stworzenie witryny o charakterze poważnej wizytówki firmy lub krzykliwego bloga,
bez konieczności tworzenia własnego szablonu lub zamawiania takowego w firmie
designerskiej. Należy pamiętać jednak, że strony oparte na gotowych szablonach nie
posiadają oryginalnego wyglądu.
System WordPress posiada także wiele poważnych ograniczeń:
• Ograniczone zarządzanie użytkownikami i uprawnieniami
• Ograniczone wsparcie dla stron wielojęzycznych
• Ograniczone wsparcie dla instalacji typu „multi”
• Brak możliwości łatwego definiowania nowych typów podstron
• Brak dobrego systemu workflow
• Brak wbudowanego funkcji logowania zdarzeń systemowych
• Kiepskie wtyczki ułatwiające tworzenie i przywracanie kopii zapasowych
• Nieco ograniczony system szablonów
• Bardzo niska wydajność
156
Podsumowując powyższe zalety i wady, system WordPress jest idealnym wyborem dla osób
rozpoczynających swoją przygodę z stronami www. Świetnie nadaje się on do obsługi bloga
lub niewielkiej witryny, której w przyszłości nie planujemy poważnie rozbudować.
Niestety na potrzeby dużych rozbudowanych stron np. społecznościowych, korporacyjnych
czy usprawniających pracę w firmie system ten nie wystarczy.
Joomla
Nauczenie się systemu Joomla wymaga dużo więcej czasu niż w przypadku systemu
WordPress, przez co system ten jest mniej odpowiedni dla osób początkujących.
Rozbudowany interfejs administracyjny posiada wiele podstron, na których konfigurować
można przeróżne aspekty witryny – niektóre zupełnie niezrozumiałe dla nowicjuszy.
Wbudowanych zostało tu wiele funkcji, które wystarczą do zbudowania niejednej
nieskomplikowanej strony.
Dodawanie artykułów jest łatwe choć ich późniejsza edycja jest średnio wygodna – wymaga
przechodzenia do panelu administracyjnego. Zawarty w systemie edytor umożliwiający
formatowanie tekstu ułatwi pracę osobom nieznającym języka HTML. Zapewniono również
wygodne zarządzanie multimediami poprzez specjalnie do tego przystosowany menadżer.
Dostępnych jest wiele dodatkowych rozszerzeń zwiększających zakres funkcji pełnionych
przez system Joomla, choć wiele z nich jest płatnych.
Wytrwałe osoby znajdą również odpowiadające im darmowe szablony, choć trzeba ich dobrze
poszukać w Internecie. Dostępne są także płatne szablony – te da się łatwo znaleźć. Niestety
na oficjalnej stronie Joomli nie ma repozytorium darmowych szablonów.
System Joomla posiada średniej jakości wbudowane wsparcie dla stron wielojęzycznych. W
miarę dobrze rozwinięto tutaj także możliwości zarządzania użytkownikami i grupami, choć
ustawianie uprawnień dla grup jest bardzo niewygodne.
Poza wieloma wbudowanymi opcjami oraz rozbudowanych panelem administracyjnym,
system Joomla posiada następujące ograniczenia:
• Brak wbudowanej możliwości tworzenia własnych typów podstron
• Brak dobrego systemu workflow
157
• Ograniczone możliwości systemu szablonów
• Bardzo ograniczone logowanie zdarzeń systemowych w bazie danych
• Trudność ze znalezieniem solidnych darmowych szablonów
• Nie intuicyjny, średnio wygodny panel administracyjny
• Mało wydajny choć dużo szybszy od systemu WordPress
System Joomla najlepiej nadaje się do budowy średniej wielkości strony. Skomplikowany
panel administracyjny oraz mnogość funkcji może zniechęcić początkujących użytkowników
planujących zbudowanie prostej strony lub uruchomienie bloga. Do budowy prostych stron
lepszy wydaje się być system WordPress.
System ten nie jest też wystarczająco rozbudowany i profesjonalny aby nadawał się do
tworzenia wielkich aplikacji wymagających np. rozbudowanego zarządzania użytkownikami,
rolami, uprawnieniami, typami podstron oraz korzystającego z workflow.
Drupal
Drupal cechuje się tym, że posiada wiele mocno rozwiniętych istotnych funkcji systemowych,
takich jak np. definiowanie bardzo dokładnych uprawnień użytkowników czy możliwość
konfigurowania wielu zupełnie różnych witryn wykorzystujących te same pliki systemu, ale
posiadających różne domeny. Poza tymi wieloma dopracowanymi zaawansowanymi opcjami
niespecjalnie zadbano o wrażenia użytkowników obsługujących system. Wiele
„standardowych” elementów, które mogą wydać się niezbędne dla zwykłych użytkowników
nie ma domyślnie zainstalowanych w systemie. Mimo, że dla wielu osób może wydać się to
wadą, wiążą się z tym następujące korzyści:
• Wiele elementów, które mogą się wydawać koniecznością, są zbędne dla
programistów i deweloperów
• System jest „lekki” ponieważ posiada tylko te elementy, które są danej aplikacji
potrzebne
• W wielu przypadkach pewną dodatkową funkcjonalność da się osiągnąć na wiele
różnych sposobów. Zapewnia to większe możliwości.
158
Ostatnia cecha może stanowić problem dla nowicjuszy. Brak jednego konkretnego sposobu na
dodanie do systemu nowej funkcjonalności sprawia, że nowi użytkownicy są zakłopotani i nie
wiedzą na co się zdecydować.
Przykładowym „standardowym” elementem, w który nie wyposażono domyślnej instalacji
systemu Drupal to edytor WYSIWYG.
Zbudowanie w Drupalu solidnej strony www wymaga zazwyczaj instalacji minimum 15
dodatkowych modułów. Problem polega na tym, że trzeba wiedzieć jakie są dodatkowe
moduły i do czego służą. Cecha ta odpycha początkujących użytkowników, dla których
system Drupal wydaje się być trudny i nieprzyjazny.
Dla systemu Drupal nie ma prawie żadnych dostępnych solidnych i eleganckich darmowych
szablonów. Płatne szablony są dostępne.
Mimo przeszkód system Drupal posiada wiele istotnych cech, które powodują, że
wielokrotnie przewyższa swoimi możliwościami pozostałe dwa systemy CMS. Niektóre z
nich to:
• Zarządzanie formatami wejściowymi treści podstron i bloków
• Możliwość definiowania nowych typów podstron
• Rozbudowany system workflow lepszy od wielu wbudowanych w płatne systemy
CMS
• Rozbudowane zarządzanie użytkownikami, rolami i uprawnieniami
• Większe niż w przypadku pozostałych systemów CMS możliwości prezentowania
treści
• Potężny moduł do tworzenia i przywracania kopii zapasowych
• Najbardziej rozwinięte wbudowane opcje wyszukiwania oraz współdzielenia
informacji z innymi stronami
• Rozbudowane logowanie zdarzeń systemowych w bazie danych
• Solidne dodatkowe moduły, regularnie kontrolowane przez zespół ds. bezpieczeństwa
159
• Dużo większa wydajność niż w przypadku systemów Joomla i WordPress
2.5.1. WnioskiNa podstawie zawartego w tym rozdziale porównania funkcjonalnego oraz wydajnościowego,
stwierdzam, że największe możliwości posiada system Drupal, co pod względem możliwości
czyni go najlepszym z trzech porównanych systemów CMS.
2.6. PodsumowanieW podrozdziale tym dokładnie omówiłem i porównałem trzy wybrane systemy CMS:
WordPress, Joomla i Drupal. W efekcie wyłoniony został najlepszy z nich: Drupal.
160
33. Projekt i realizacja aplikacji testowej
Wybrany w poprzednim podrozdziale system CMS, Drupal, posiada bardzo duże możliwości.
W tej części pracy przedstawiony i zrealizowany zostanie projekt aplikacji testowej, którą
będę starał się zbudować w oparciu o ten system.
3.1. Opis aplikacjiProjektowana aplikacja oparta na systemie Drupal ma prezentować w Internecie firmę Zakład
Badań Geotechnicznych Geotest. Oprócz bogatego prezentowania firmy udostępniane mają
być artykuły i porady. Aplikacja ma umożliwiać dokładne kontrolowanie uprawnień osób
współpracujących nad stroną.
Wykorzystany zostanie Drupal w wersji szóstej ze względu na fakt, że Drupal 7 nie został
jeszcze oficjalnie wydany i występuje na razie wyłącznie w wersji alfa.
3.1.1. Opis działalności firmyKażdą inwestycję budowlaną poprzedza faza projektowa. Na etapie projektowania sporządza
się dokumentację geotechniczną, która opisuje warunki wodno-gruntowe panujące na terenie
planowanej inwestycji. Na przekrojach geologiczno-inżynierskich pokazany jest układ warstw
gruntu i zaznaczone są poziomy wód gruntowych. W części opisowej zestawione są
parametry geotechniczne, mówiące o właściwościach fizycznych i mechanicznych każdej
warstwy i umożliwiające wykonanie projektu fundamentów.
Dokumentacje geotechniczne wykonywane są na podstawie badań: terenowych oraz
laboratoryjnych i sporządzane przez firmy geotechniczne. Na terenie projektowanych
inwestycji wykonuje się otwory badawcze, które umożliwiają rozpoznanie budowy
geologicznej oraz pomiar głębokości występowania wód gruntowych. Z otworów pobierane
są próby gruntu do badań laboratoryjnych. W terenie przeprowadza się także różnego typu
161
sondowania gruntów, które pozwalają określić ich nośność czyli zdolność do przenoszenia
obciążeń.
W Warszawie działa spora grupa firm geotechnicznych. Do tej grupy należy Zakład Badań
Geotechnicznych GEOTEST.
Firma ta działa nieprzerwanie od 1990 roku. Zakres jej działalności obejmuje sporządzanie
dokumentacji geotechnicznych i geologiczno-inżynierskich. Dokumentacje geologiczno-
inżynierskie są szczególnym typem dokumentacji, które sporządza się dla dużych projektów
budowlanych (budynki wysokie, budynki z wielopoziomowymi garażami podziemnymi, itp.).
W firmie przygotowuje się też projekty prac geologicznych, które są podstawą do
opracowania dokumentacji geologiczno-inżynierskich. Geotest zajmuje się ponadto
badaniami zanieczyszczenia środowiska. W pobranych próbach wody i gruntu określa się
zawartość metali ciężkich i substancji ropopochodnych. W celu oznaczenia wahań poziomów
wód gruntowych firma instaluje na badanym terenie specjalne studnie, tzw. piezometry, które
pozwalają monitorować poziom wody gruntowej.
Firma Geotest wykonuje także:
• kontrolę zagęszczenia gruntu
• badania geotechniczne dla składowisk odpadów
• projekty drenaży budowlanych
• projekty zabezpieczeń skarp wykopów
• obliczenia stateczności skarpy
• określa przyczyny spękań budynków
• określa przyczyny zawilgocenia piwnic
• a także prowadzi wszelkiego rodzaju konsultacje geotechniczne
3.1.2. Cel aplikacjiSzeroka działalność firmy Geotest oraz duża liczba prowadzonych przez tą firmę badań
wymaga posiadania specjalistycznego sprzętu oraz grupy odpowiednio wyszkolonych
pracowników.
162
Firma Geotest chce zaprezentować poprzez stronę www swoje możliwości. Planowane jest
udostępnienie następujących informacji:
• Generalne informacje o firmie
• Opis historii firmy
• Prezentacja firmowych specjalistów
• Lista niektórych wykonanych realizacji
• Prezentacja zdjęć budynków wykonanych w oparciu o badania firmy
• Prezentacja innych zdjęć (np. z terenu)
• Dokładna prezentacja specjalistycznego sprzętu
• Aktualności firmowe
• Informacje kontaktowe
• Bogaty poradnik dla budujących
• Informacje o firmowym archiwum
• Strona z podstawowymi informacjami po angielsku
3.2. Założenia projektowe - opis głównych zadań które będzie musiała realizować aplikacja
Na podstawie listy informacji, które firma chce zaprezentować w sieci, opracowano podział
witryny.
W kategorii ogólnej znajdą się następujące podstrony:
• O nas – ogólne informacje o firmie
• Aktualności – lista aktualności firmowych opisujących czym ostatnio zajmowała się
firma
• Historia – od założenia firmy do teraźniejszości
163
• Pracownicy – prezentacja firmowych specjalistów
• Realizacje – lista niektórych istotnych budowli, dla których firma Geotest wykonała
badania geotechniczne
• Kontakt – dane kontaktowe oraz informacje do faktur
Po zdefiniowaniu listy specjalistycznego sprzętu geotechnicznego, który ma zostać
zaprezentowany, w kategorii „sprzęt” wydzielono następujące podstrony.
• Unimogi – prezentacja firmowych samochodów Mercedes Unimog
• Wiertnice – prezentacja wiertnic zamontowanych na Unimogach
• Sonda CPT
• Lekka płyta dynamiczna
• Wiertnica spalinowa
• Laboratorium – prezentacja laboratorium geotechnicznego
Ponadto dostępna ma być również podstrona z pełną listą posiadanego sprzętu.
Trzecia kategoria będzie dotyczyła galerii zdjęć. Przygotowane zostaną tu następujące
podstrony:
• Realizacje – zdjęcia budynków zbudowanych w oparciu o badania geotechniczne
Geotestu
• Wiercenia – zdjęcia przedstawiające prace terenowe
• Sondowanie – jw.
• Katastrofy – zdjęcia przedstawiające wypadki podczas budów
Dział „poradnik dla budujących” podzielono na następujące podstrony:
• Badania gruntu – opis istoty badań gruntu
164
• Artykuły – różne artykuły mające na celu pomoc w podejmowaniu dobrych decyzji
podczas budowy
• Trudne realizacje – lista terenów w Warszawie niesprzyjających budowom
• Fundamentowanie – krótka prezentacja firm zajmujących się fundamentowaniem
Poza powyższymi kategoriami, utworzona zostanie podstrona „Archiwum firmy” oraz strona
„About” prezentująca podstawowe informacje o firmie w języku angielskim.
Ponadto oprócz wydzielonych podstron aplikacja ma wyświetlać:
• Informacyjne bloki w pasku bocznym
• Małe, zmieniające się zdjęcia sprzętu w stopce
• Listę ostatnio dodanych aktualności w stopce
3.2.1. Planowane typy podstron i wiążące się z nimi funkcjeNa potrzeby witryny zdefiniowane zostaną następujący typy podstron:
• Zwykła podstrona
• Aktualności
• Pracownik
• Slajd
• Sprzęt
• Zdjęcie
Dzięki takiemu podziałowi będzie można przygotować specjalnie dostosowane dla danego
typu formularze dodawania i edycji podstron. Ilość pól formularza będzie zależeć od tego
jakiego typu stronę dodajemy.
Również dzięki podziałowi na różne typy możliwe będzie wyświetlanie informacji pobranych
z podstron wybranego typu na odpowiednich listach.
Zwykła podstrona
165
Najbardziej podstawowy typ to „zwykła podstrona”. Podczas dodawania „zwykłej podstrony”
możliwa będzie konfiguracja następujących jej elementów.
• Tytuł
• Treść
• Alias – fragment adresu URL, pod którym dostępna będzie dana podstrona.
Aktualności
Podstrony typu „aktualności” będą automatycznie pojawiać się na liście z aktualnościami
firmy. Dodatkowo odnośniki do najnowszych aktualności będą automatycznie wyświetlane w
bloku widocznym w stopce.
Podczas dodawania nowych aktualności możliwa będzie konfiguracja następujących
elementów:
• Tytuł
• Treść
• Zdjęcie – główne zdjęcie aktualności
• Mini galeria zdjęć – pole umożliwiające wgranie dodatkowych zdjęć
Zdjęcia dodawane do aktualności będą automatycznie dopasowywane. Wbudowana w
aktualności mini galeria zdjęć umożliwi publikację dowolnej ilości zdjęć.
Pracownik
Podstrony typu „pracownik”, są pewnego rodzaju profilami prezentującymi pracowników.
Informacje wpisane w tych profilach będą automatycznie wyświetlane na podstronie
„Pracownicy”. Podstrony typu „pracownik” nie będą bezpośrednio dostępne dla
odwiedzających. Jedynym ich celem jest umożliwienie łatwego dodawania profili
pracowników.
166
Podczas dodawania nowego profilu pracownika, możliwa będzie konfiguracja następujących
elementów:
• Imię i nazwisko
• Zdjęcie
• Wykształcenie
• W firmie od
• Opis
Zdjęcia pracowników będą automatycznie zmniejszane i kadrowane tak aby pasowały do
projektu graficznego strony.
Slajd
Podstrony typu „slajd” umożliwią dodawanie zmieniających się slajdów, prezentujących w
stopce sprzęt geotechniczny. Podobnie jak w przypadku stron typu „pracownik” nie będą one
bezpośrednio dostępne dla odwiedzających.
Dostępne pola formularza dodawania slajdu to:
• Tytuł
• Zdjęcie
Dodawane zdjęcia będą automatycznie zmniejszane i kadrowane tak aby idealnie wypełniały
przestrzeń dostępną w bloku, w którym będą wyświetlane.
Sprzęt
Podstrony typu „sprzęt” będą umożliwiały dodawanie informacji o specjalistycznym sprzęcie
geotechnicznym. Dodane podstrony będą wymienione na liście sprzętu geotechnicznego.
Ponadto podczas odwiedzania działu „sprzęt”, w odpowiednim bloku widocznym w pasku
bocznym witryny pojawi się lista odnośników do wszystkich stron z opisami sprzętu.
Podczas dodawania opisu nowego sprzętu możliwa będzie konfiguracja następujących
elementów:
• Nazwa
167
• Główne zdjęcie sprzętu – prezentowane u góry strony opisującej dany sprzęt
• Ikonka – mały obrazek, który będzie wyświetlany w bloku z odnośnikami do podstron
prezentujących sprzęt
• Opis
• Krótki opis – przeznaczony do wyświetlania na liście dostępnego sprzętu
• Średnie zdjęcie – również przeznaczone do wyświetlania na liście dostępnego sprzętu
• Mini galeria zdjęć – zastosowanie identyczne jak w przypadku Aktualności
Zdjęcie
Podstrony typu „zdjęcie” umożliwią dodawanie zdjęć. Zdjęcia te będą wyświetlane w ramach
galerii zdjęciowych.
Dostępne pola formularza dodawania zdjęcia to:
• Tytuł
• Kategoria - galeria w której ma się pojawić
• Zdjęcie
3.2.2. Inne funkcjePoza dodawaniem i edytowaniem podstron, dostępne będą następujące funkcje:
• Zarządzanie nawigacją
• Zarządzanie galeriami
• System workflow
Zarządzanie nawigacją
Projektowana witryna będzie udostępniała dwupoziomową nawigację. Kategorie główne takie
jak „O Firmie” czy „Poradnik” będą zawierały podkategorie. Zarządzanie nawigacją będzie
łatwe i wygodne.
Zarządzanie galeriami
168
Aplikacja ma umożliwiać łatwe zarządzanie galeriami. Możliwe będzie dodawanie dowolnej
ilości galerii i zdjęć. Dostępna będzie także opcja przenoszenia zdjęć pomiędzy galeriami.
Nowe galerie będą dostępne pod odpowiednim adresem URL. Przykładowo dodanie nowej
galerii do strony będzie wymagało:
• Dodania nowej pustej galerii
• Dodania nowych podstron typu „zdjęcie” z jednoczesnym przypisaniem ich do nowo
dodanej galerii
• Dodanie elementu nawigacji skierowującego na podstronę z nową galerią
System workflow
Aktualności będą dodawane do systemu przez uprawnionych do tego pracowników. W celu
zapewnienia najwyższej jakości treści dostępnej na stronie, wszystkie aktualności będą
wymagały zatwierdzenia ze strony szefa firmy zanim zostaną opublikowane. Dokładną
kontrolę nad przepływem aktualności zapewni system workflow.
3.3. Projekt graficznego interfejsu użytkownikaInterfejs użytkownika jest na ogół pierwszą rzeczą, na którą uwagę zwraca użytkownik
odwiedzając nową witrynę. W czasach, kiedy strony www miały charakter wyłącznie
tekstowy, programiści nie musieli martwić się projektowaniem graficznego interfejsu
użytkownika.
W dzisiejszych czasach coraz większą uwagę zwraca się nie tylko na funkcjonalność, ale
także na estetykę Aplikacji. Najważniejsze cechy, które powinien posiadać każdy graficzny
interfejs użytkownika to:
• Przejrzystość
• Intuicyjność
• Logiczna konstrukcja
• Stonowana kolorystyka
Dodatkowo często spotyka się grafiki związane wyłącznie z estetyką, a nie pełniące innych
funkcji.
169
Podczas tworzenia GIU (Graphical User Interface) dla projektowanej aplikacji, uwzględnione
zostały wszystkie wymienione powyżej aspekty.
Na potrzeby witryny firmy Geotest opracowałem projekt szaty graficznej. Przygotowany
projekt graficzny składa się następujących elementów:
1. Skróty nawigacyjne widoczne u góry strony
• Skróty te będą umożliwiać łatwe przechodzenie do kilku istotnych podstron
• Ułatwią one również nowym odwiedzającym poznanie istotnych informacji o
firmie
• Powyższymi skrótami można w pełni zarządzać poprzez panel
administracyjny
2. Nagłówek strony
• W skład nagłówka wchodzi grafika tła oraz logo i nazwa firmy
3. Menu nawigacyjne
• Główna nawigacja, wielopoziomowa
• Zarządzanie nawigacją poprzez system CMS
4. Ciało strony
• Ciało strony jest inne dla każdej podstrony i zmienia się w zależności od tego,
na jakiej stronie znajduje się użytkownik. W skład ciała strony wchodzi tytuł
danej podstrony serwisu oraz zawartość indywidualna dla danej strony
5. Panel boczny (tzw. „sidebar”)
• Prezentuje dodatkowe informacje dotyczące np. ofert specjalnych
• Udostępnia linki do polecanych artykułów poradnika
• Podczas gdy zalogowany do strony jest administrator, pracownik lub edytor w
panel bocznym wyświetlane są odnośniki do stron administracyjnych
170
6. Panel dolny
• Prezentuje dodatkowe informacje
• Zawiera odnośniki do najnowszych aktualności
• Wyświetlane są tu naprzemiennie zdjęcia pokazujące sprzęt geotechniczny
7. Stopka
171
Rysunek . Wygląd szaty graficznej aplikacji testowej
3.4. Opis etapów implementacjiTworzenie aplikacji internetowej to złożony proces, który wymaga dokładnego zaplanowania
wszystkich poszczególnych etapów. Tworzenie aplikacji testowej, podobnie jak w przypadku
wielu innych projektów stron internetowych, zostało podzielone na następujące kroki:
172
1. Ustalenie potrzeb i wymogów względem aplikacji – w tym pierwszym kroku
spisywana jest tzw. specyfikacja funkcjonalna, opisująca aplikację, pełnione przez nią
funkcje oraz inne aspekty zgodnie z którymi wykonany zostanie projekt. W tym
przypadku specyfikacją był podrozdział „Założenia projektowe”.
2. Realizacja szaty graficznej – po ustaleniu specyfikacji aplikacji, wykonywany jest
zazwyczaj projekt szaty graficznej. Wykonanie go nie jest możliwe przed ustaleniem
potrzeb i wymogów stawianych aplikacji, ponieważ w dużym stopniu opiera się on na
spisanych w pierwszym kroku założeniach. Po zaakceptowaniu i zatwierdzeniu przez
zamawiającego szaty projektu szaty graficznej, można przejść do realizacji kolejnych
kroków.
3. Utworzenie szablonu strony – w oparciu o projekt szaty graficznej utworzony zostaje
szablon strony. Alternatywnie szatę graficzną i szablon można wykonać po
ukończeniu kroków 4-6, choć osobiście uważam, że wygodniej jest najpierw wykonać
szablon, a później budować korzystającą z niego aplikację.
4. Instalacja i konfiguracja systemu CMS – po przygotowaniu szablonu i
zainstalowaniu go w systemie CMS, można rozpocząć prace związane z konfiguracją
wbudowanych funkcji systemu. Na etapie tym warto także utworzyć niezawierające
jeszcze oficjalnej treści podstrony – finalna treść zostanie dodana w na późniejszym
etapie.
5. Określenie wymaganych dodatkowych modułów - w kroku tym przygotowujemy
zbiór wymaganych fukcji, których nie zapewnia domyślna instalacja systemu CMS.
6. Instalacja i konfiguracja dodatkowych modułów – mając listę wymaganych
dodatkowych funkcji instalujemy dodatkowe moduły: gotowe lub własne napisane
specjalnie na potrzeby danej aplikacji. Po zainstalowaniu dodatków należy też
odpowiednio je skonfigurować.
7. Wypełnienie strony treścią – gotową „pustą” stronę zapełniamy treścią dostarczoną
przez zleceniodawcę.
8. Doszlifowywanie strony – wykończoną, zawierającą wszystkie podstrony,
wypełnioną treścią stronę warto jeszcze doszlifować, poprawiając ewentualnie
niedoróbki i błędy. Dzięki temu wykonana aplikacja będzie w pełni profesjonalna.
173
Wymogi względem aplikacji testowej oraz jej szata graficzna zostały już wykonane. W
podrozdziale „Realizacja projektu” opisany został przebieg kroków 3-8.
3.5. Realizacja projektu„Projekt” jest zbiorem powiązanych ze sobą aktywności, które zmierzają do osiągnięcia
jakiegoś celu. Celem jest zazwyczaj wytworzenie produktu, usługi lub rezultatu. Projekt
posiada zaplanowany z góry początek i koniec.
Standardowo projekt podzielić można na następujące fazy
• Inicjacja
• Planowanie
• Realizacja
• Zakończenie
Pierwsze dwa etapy zostały już wykonane, w dalszej części pracy opiszę realizację aplikacji
testowej.
3.5.1. Utworzenie szablonuPrzygotowanie szablonu wymaga najpierw pocięcia zaprojektowanej grafiki na odpowiednie
fragmenty, które zostaną umieszczone w ciele strony, w taki sposób aby strona wyglądała
identycznie jak było to w projekcie.
Fragmenty designu muszą zostać w taki sposób podzielone aby witryna dobrze wyglądała
niezależnie od ilości treści podstron. Inaczej mówiąc musi posiadać możliwość wydłużania
się w miarę potrzeb.
Poniżej przedstawiono kilka wybranych wycinków wykorzystanych do budowy szablonu
witryny firmy Geotest (grafiki zostały przeskalowane w różnym stopniu aby lepiej mieściły
się w pracy):
174
Rysunek . Tło nagłówka. Lewa krawędź pasuje do prawej dzięki czemu grafika ta płynnie zapełni dowolnej szerokości okno przeglądarki.
Rysunek . Logo posiada przezroczyste tło.
Rysunek . Jeden z obrazów tła głównej części strony.
Rysunek . Inny fragment współtworzący tło strony.
175
Rysunek . Tło panelu dolnego znajdującego się ponad stopką.
W celu zbudowania szablonu pocięto grafikę na 13 kawałków, które następnie zapisano jako
oddzielne pliki graficzne. Ponadto przygotowano 9 ikon.
Poza wspomnianymi plikami graficznymi przygotowany szablon składa się następujących
plików:
• geotest.info – plik definiujący szablon. Informacje zawarte w tym pliku są
odczytywane przez system Drupal. Dzięki temu plikowi szablon wyświetli się na
stronach administracyjnych i będzie można go aktywować.
• screenshot.png – plik z miniaturą całego szablonu. Używany do wyświetlania
wyglądu szablonu w panelu administracyjnym.
• page.tpl.php – główny plik wykorzystywany przez system PHP Template do
budowania podstron. To w nim zdefiniowany jest cały układ strony, opisany w
podrozdziale „Projekt graficznego interfejsu użytkownika”.
• node.tpl.php – plik systemu PHP Template używany do budowania ciała artykułów i
podstron. Jest odpowiedzialny za zawartość 4. elementu czyli ciała strony.
• block.tpl.php – również plik PHP Template. block.tpl.php jest pewnego rodzaju
szablonem używanym do budowy bloków wyświetlanych w panelu bocznym (5.)
• template.php – zbiór dodatkowych funkcji wykorzystywanych wewnątrz plików
*.tpl.php.
• style.css – główny plik arkusza styli CSS. Pliki CSS nie są przetwarzane przez system
CMS – są jedynie dołączane do generowanych podstron.
176
• fix-ie6.css – dodatkowy plik styli korygujących, odczytywany tylko przez
przeglądarkę Internet Explorer 6
• fix-ie7.css – dodatkowy plik styli korygujących, odczytywany tylko przez
przeglądarkę Internet Explorer 7
• geotest4.js – plik JavaScript zawierający skrypty wspomagające działanie strony oraz
zapewniające dodatkowe dyskretne efekty, takie jak np. płynnie rozwijające się menu
nawigacyjne. Plik ten również nie jest przetwarzany przez system.
• favicon.ico – plik ikonki aplikacji, wyświetlany m.in. w pasku adresu przeglądarki
podczas odwiedzania podstron realizowanej witryny.
Poniżej przedstawiono kod pliku page.tpl.php:
<?php// $Id: GEOTEST 4.0 page.tpl.php $ ?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="pl" lang="pl" dir="ltr"> <head> <title><?php print $head_title ?></title> <?php print $head ?> <?php print $styles ?> <?php print $scripts ?> <?php if (!(isset($admin))) : ?> <script type="text/javascript"> /* Remove if showed in frame */ if (top.location != self.location) { top.location = self.location; } </script> <? endif; ?> <!--[if IE 6]> @@$$#php7- <![endif]--> <!--[if IE 7]> @@$$#php8- <![endif]--> </head> <body<?php print phptemplate_body_class($left, $right); ?>> <div id="TopMenu"> <div id="TopMenuInner">
177
<div id="TopLinks"> <?php if (isset($primary_links)) : ?> <?php print theme('links', $primary_links, array('class' => 'links secondary-links')) ?> <?php endif; ?> </div> <div id="TopNav"> <?php if (isset($secondary_links)) : ?> <?php print theme('links', $secondary_links, array('class' => 'links secondary-links')) ?> <?php endif; ?> </div> </div> </div> <div id="Header"> <div id="HeaderInner">
<h1><a href="<?php print check_url($front_page) ?>"><span><?php print check_plain($site_name) ?></span></a></h1> </div> </div> <div id="MainMenu"> <div id="MainMenuInner"> <?php print $mainmenu ?> </div> </div> <div id="Mainpart"> <div id="MainpartBottomBg"> <div id="MainpartInner"> <div id="PageBgBottom"> <div id="PageBgTop"> <div id="Content"> <div id="ContentInner">
<?php //print $breadcrumb; ?> <?php //if ($mission): print '<div id="mission">'. $mission .'</div>'; endif; ?> <?php if ($tabs): print '<div id="tabs-wrapper" class="clear-block">'; endif; ?> <?php if ($title): print '<h2'. ($tabs ? ' class="with-tabs"' : '') .'>'. $title .'</h2>'; endif; ?> <?php if ($tabs): print '<ul class="tabs primary">'. $tabs .'</ul></div>'; endif; ?> <?php if ($tabs2): print '<ul class="tabs secondary">'. $tabs2 .'</ul>'; endif; ?> <?php if ($show_messages && $messages): print $messages; endif; ?> <?php print $help; ?> <div class="clear-block main-content-div"> <?php print $content ?> </div> <?php print $feed_icons ?> </div>
</div><!--end Content--> <div id="Sidebar">
178
<?php //print $search_box ?> <?php if ($sidebar): ?> <div id="SidebarNormal" class="sidebar"> <?php print $sidebar ?> </div> <?php endif; ?>
<?php if ($sidebar_lower): ?> <div id="SidebarLower" class="sidebar"> <?php print $sidebar_lower ?> </div> <?php endif; ?> </div><!-- end Sidebar --> <br style="clear: both;;" /> </div> </div> </div> </div> </div><!-- end Mainpart --> <div id="BottomBoxes"> <div id="BottomBoxesInner"> <div id="BoxLeft"> <?php print $footer_box_left ?> </div> <div id="BoxMiddle"> <?php print $footer_box_middle ?> </div> <div id="BoxRight"> <?php print $footer_box_right ?> </div> </div> </div><!-- end BottomBoxes --> <div id="Footer"> <div id="FooterInner"> © <?php print date("Y") .' '. $footer_message ?> <span id="Designer"> Projekt i realizacja strony: <a href="http://www.traczynski.pl" title="Paweł Traczyński - projektowanie stron www">Paweł Traczyński</a> </span> </div> </div><!-- end Footer --> <?php print $closure ?> </body></html>
3.5.2. Konfiguracja systemu CMS
179
Po zainstalowaniu świeżej wersji systemu Drupal 6 i dodaniu do niego utworzonego szablonu,
dokonano pełnej konfiguracji wszystkich wbudowanych w system funkcji.
Utworzone zostały typy podstron, zgodnie z listą przedstawioną we wcześniejszym
podrozdziale. Domyślnie wszystkie podstrony posiadają tutył i treść. Wszystkie inne
dodatkowe pola formularzy dodawania podstron (opisane wcześniej) będą wymagały
zainstalowania dodatkowych modułów. Jedyny typ podstrony, który nie został jeszcze dodany
to „Zdjęcie” – wynika to z tego, że typ ten pojawi się automatycznie po zainstalowaniu
dodatkowego modułu do obsługi zdjęć.
Włączono wbudowany w system moduł „Path”, który umożliwia definiowanie własnych
aliasów podstron.
W systemie skonfigurowano następujące elementy nawigacyjne:
• Menu główne
• Lewe menu dodatkowych odnośników wyświetlanych u góry strony
• Prawe menu dodatkowych odnośników wyświetlanych u góry strony
• Menu polecamy, które będzie wyświetlane w pasku bocznym
Utworzone zostały tymczasowe puste podstrony posiadające już odpowiednie aliasy. Dzięki
temu można już było dodać do nawigacji odpowiednie odnośniki do tych podstron,
skierowujące pod poprawne adresy URL.
Zdefiniowane zostały statyczne bloki wyświetlające dodatkowe informacje w pasku bocznym
oraz panelu dolnym umiejscowionym nad stopką strony. Konieczne będzie jeszcze dodanie
bloku prezentującego 6 ostatnich wpisów aktualności oraz bloku prezentującego odnośniki do
wszystkich podstron prezentujących sprzęt. Bloki te będą jednak utworzone w późniejszym
etapie ponieważ dodanie ich będzie wymagało zainstalowania w systemie kilku dodatkowych
modułów.
Aktywowany został moduł „Locale” umożliwiający tłumaczenie elementów interfejsu. Do
systemu dodany został język polski, który został ustawiony jako domyślny.
W systemie skonfigurowane zostały następujące formaty wejściowe:
180
• format filtrowanego HTML’a pozwalający na korzystanie z ograniczonej liczby
znaczników HTML
• format pełnego HTML’a pozwalający na korzystanie ze wszystkich znaczników
HTML
• format pełnego HTML’a dopuszczający również kod PHP i JavaScript
Zdefiniowane zostały następujące role użytkowników:
• Edytor – rola przypisywana do kont pracowników, pozwala na pisanie aktualności
firmowych bez możliwości ich publikowania
• Publisher – rola przypsana szefowi firmy, pozwala na zarządzanie wszystkimi
istotnymi aspektami witryny. Rola ta pozwala także na publikowanie napisanych przez
pracowników aktualności.
W systemie skonfigurowano także wiele innych podstawowych ustawień systemu takich jak
np. format daty, ścieżki do folderów, nazwa strony czy treść informacji wyświetlanej w
stopce.
Aktywowano również moduły „Database logging” oraz „Statistics” umożliwiające śledzenie
działania strony.
3.5.3. Określenie wymaganych dodatkowych modułów oraz ich instalacjaDrupal to system modularny, zbudowany w sposób, który z góry zakłada, że podczas budowy
strony www prawdopodobnie konieczne będzie doinstalowanie garstki dodatkowych
modułów. I faktycznie w przypadku wszystkich poważnych stron www budowanych w
oparciu o system Drupal konieczna jest instalacja różnego rodzaju rozszerzeń.
Podobnie było także w przypadku aplikacji testowej. Aby zapewnić pewne funkcjonalności,
konieczne było zainstalowanie wielu dodatkowych modułów.
CCK, FileField, ImageField
Moduł CCK (Content Construction Kit) umożliwił zdefiniowanie nowych pól danych w
formularzach dodawania i edycji podstron. Moduł ten pozwala na definiowanie m.in. pól
tekstowych, ale nie umożliwia definiowania pól przeznaczonych do wgrywania plików.
Funkcjonalność ta została osiągnięta za pomocą współpracującego z modułem CCK
181
rozszerzeniem FileField. Osiągnięta funkcjonalność wykorzystana została do wgrywania
zdjęć.
Niestety zdjęcia pojawiały się jedynie jako załączniki – kliknięcie na wyświetlony odnośnik
pozwalało na pobranie grafiki. Aby umożliwić osadzanie wgrywanych zdjęć bezpośrednio w
kodzie HTML zainstalowano moduł ImageField. Wzbogaca on działanie FileField o
możliwość prezentowania zdjęć w wyżej opisany sposób.
Za pomocą trzech powyższych modułów zdefiniowano wszystkie dodatkowe pola danych
wymienione we wcześniejszym podrozdziale. Pola te były następujące:
• Aktualności: Zdjęcie
• Aktualności: Mini-Galeria
• Pracownik: Nazwisko
• Pracownik: Zdjęcie
• Pracownik: Wykształcenie
• Pracownik: W firmie od
• Slajd: Zdjęcie
• Sprzęt: Główne zdjęcie sprzętu
• Sprzęt: Ikonka
• Sprzęt: Krótki opis
• Sprzęt: Mini-Galeria
• Sprzęt: Średnie zdjęcie sprzętu
Trzy powyższe moduły wchodzą w skłąd jądra systemu Drupal 7. Jednak dla systemu w
wersji szóstej, w którym tworzymy aplikację testową, wymagane jest oddzielne ich pobranie.
Image API, ImageCache
182
Aby zapewnić odpowiedni wygląd wszystkim wgrywanym zdjęciom zainstalowany został
moduł ImageCache oraz wymagany przez niego Image API. Moduł ImageCache umożliwia
m.in. pomniejszanie i kadrowanie zdjęć. Dzięki temu zdjęcia prezentowane na stronie będą
miały identyczne rozmiary i proporcje, dzięki czemu strona będzie estetyczna. Wgrywanie
dużych grafik nie będzie stanowiło problemu ponieważ i tak będą one pomniejszane.
Moduły te są częścią systemu Drupal 7. Dla systemu Drupal 6 dostępne są jako rozszerzenia.
Contemplate
Aby wystylizować wygląd wszystkich podstron posiadających dodatkowe pola danych
wykorzystano moduł Contemplate, który umożliwia zmianę kodu wynikowego dla
wybranych podstron i artykułów.
Przykładowy własny kod odpowiedzialny za wygląd wpisów aktualności przedstawiam
poniżej:
<div class="aktualnosci_body"> <?php if ($node->content['field_inline_photo'] ['field']['items']['#children']) : ?> <?php print $node->content['field_inline_photo'] ['field']['items']['#children'] ?> <?php endif; ?>
<?php print $node->content['body']['#value'] ?></div>
<?php if ($node->field_gallery_textfield[0]) : ?> <?php if ($node->field_gallery_textfield[0]['value'] != "") { print '<strong class="mini-gallery-header">Mini Galeria:</strong>'; } ?> <div class="mini_gallery"> <?php print $node->field_gallery_textfield[0]['safe'] ?> </div><?php endif; ?>
<?php print $node->content['files']['#value'] ?>
183
Image, Image Assist, Lightbox 2
W celu utworzenia galerii zdjęć dodany został moduł Image zawierający w pakiecie także
modul Image Gallery. Ponadto dodano moduł ImageAssist, który pozwolił na umieszczanie
zdjęć w polach Mini-Galeria dostępnych w aktualnościach oraz podstronach sprzętu.
Dzięki modułom tym możliwe jest wygodne zarządzanie galeriami i mini-galeriami z
poziomu panelu administracyjnego.
Dodatkowy moduł Lightbox 2 pozwala wyświetlać zdjęcia „ponad stroną”. Użytkownik po
kliknięciu w miniaturę zobacz podgląd dużej wersji fotografii.
DDBlock (Dynamic Display Block)
Zdjęcia wyświetlane naprzemiennie w bloku widocznym tuż ponad stopką wykorzystują
moduł DDBlock, który korzysta z pluginu jQueryCycle – biblioteki JavaScript umożliwiające
tworzenie pokazu slajdów.
Nice Menus
Nawigacja witryny wykorzystuje wbudowany w Drupala system tworzenia menu,
obsługujący wielokrotne zagnieżdżanie. Przykładowy fragment strony konfiguracyjnej
prezentuje zagnieżdżone odnośniki.
Dzięki modułowi Nice Menus możliwe jest wyświetlanie na stronie rozwijanego menu
nawigacyjnego, którego elementy dokładnie odpowiadają tym ustawionym w konfiguracji
systemu.
184
Rysunek . Zarządzanie główna nawigacją strony. Możliwe jest zagnieżdżanie elementów menu.
Rysunek . Hierarchia elementów nawigacji na stronie jest zgodna z tą ustawioną w systemie.
Menu nawigacyjne do swojego działania wykorzystuje odpowiednio przygotowane style CSS.
Dodatkowy JavaScript dodaje efekty płynnego pojawiania się i chowania rozwijanych gałęzi.
Brak włączonej obsługi skryptów w przeglądarce klienta nie spowoduje dysfunkcji nawigacji
– jedyna różnica będzie polegać na braku efektu płynności.
Views
185
Moduł Views umożliwia definiowanie automatycznie wypełnianych treścią widoków
zawierających listy różnych podstron lub ich wybranych elementów. Przykładowo można
utworzyć widok przentujący wszystkie zdjęcia dodane do podstron określonego typu za
pomocą pola danych zapewnionego przez moduł ImageField.
Tworzenie widoków jest dość skomplikowane ze względu na mnogość różnych ustawień. W
naszej aplikacji zdefiniowane zostały następujące widoki:
• Aktualności – ten widok prezentuje listę ostatnio dodanych aktualności
• Pracownicy – lista pracowników
• Slide – specjalny widok wstawiający do kodu strony zdjęcia prezentowane u dołu
strony. Widok ten jest wykorzystywany przez moduł DDBlock do wyświetlania
pokazu slajdów.
• Sprzęt – lista z odnośnikami do podstron opisujących specjalistyczny sprzęt
geotechniczny
Panel konfiguracyjny umożliwiający definiowanie ustawień widoku przedstawiony jest
poniżej.
186
Rysunek . Konfiguracja widoku odpowiedzialnego za wyświetlanie listy pracowników.
Rysunek . Fragment automatycznie tworzonej listy sprzętu geotechnicznego. Nowo dodany sprzęt pojawi się na liście samoczynnie.
PathAuto, Token
Moduł PathAuto jest odpowiedzialny za automatyczne tworzenie aliasów dla nowo
dodawanych podstron. Aliasy te, podobnie jak w systemie WordPress, są tworzone na
podstawie tytułu. Polskie znaki są transliterowane na ich odpowiedniki nie posiadające
„ogonków”.
187
XML Sitemap
Moduł XML Sitemap automatycznie tworzy na podstawie istniejących w systemie podstron
ich listę w formacie XML sitemap. Listy zgodne z tym standardem są odczytywane przez
wyszukiwarki. Dzięki nim wiedzą one o istnieniu wszystkich podstron – nawet tych, które nie
zostały jeszcze zaindeksowane. Znacznie poprawi to dostępność strony poprzez
wyszukiwarki.
Fragment zawartości pliku sitemap.xml testowej aplikacji przedstawiono poniżej.
<urlset xsi:schemaLocation="http://www.sitemaps.org/schemas/sitemap/0.9 http://www.sitemaps.org/schemas/sitemap/0.9/sitemap.xsd"> <url> <loc>http://www.geotest.pl/</loc> <lastmod>2010-08-07T20:34:06+00:00</lastmod> <changefreq>weekly</changefreq> <priority>1.0</priority> </url> <url> <loc>http://www.geotest.pl/aktualnosci/</loc> <lastmod>2010-08-04T15:42:21+00:00</lastmod> <changefreq>daily</changefreq> <priority>1.0</priority> </url> <url> <loc>http://www.geotest.pl/historia</loc> <lastmod>2010-09-11T21:38:59+00:00</lastmod> <changefreq>monthly</changefreq> <priority>0.8</priority> </url></urlset>
SpamSpan
Moduł SpamSpan rozpoznaje adresy email wpisane w treści podstron i dokonuje rozbicia ich
na części w celu ukrycia ich przez automatami skanującymi witryny w poszukiwaniu adresów
email na które można by wysyłać spam. Podczas przeglądania witryny adresy email są
składane z powrotem za pomocą JavaScript, dzięki czemu prawdziwi użytkownicy nie
zauważą żadnej różnicy.
DHTML Menu, Ed Readmore, jToolTips
DHTML Menu to mały moduł usprawniający działanie menu administracyjnego.
Ed Readmore zmienia położenie odnośników „Czytaj więcej” widocznych na stronie z
aktualnościami.
188
Moduł jToolTips jest odpowiedzialny za wyświetlanie dymków z podpowiedziami. Dymki te
pojawiają się po najechaniu na jeden z dodatkowych odnośników widocznych u samej góry
strony.
Moduły te nie są krytyczne ale usprawniają działanie strony i poprawiają nieco doznania
odwiedzających.
3.5.4. Wypełnienie strony treściąPo wykonaniu wszystkich zadań związanych z budowaniem i konfigurowaniem witryny,
pozostała do wstawienia docelowa treść podstron. Cała treść razem ze zdjęciami została
dostarczona przez osobę zamawiającą stronę.
189
Rysunek . Przykładowy wygląd ciała podstrony po wypełnieniu jej treścią.
3.5.5. Dopracowywanie stronyDopracowywanie dotyczyło zarówno strony wizualnej jak i logiki aplikacji.
190
Poprawianie aspektów wizualnych polegało głównie na przeglądaniu wszystkich
utworzonych podstron witryny w następujących popularnych przeglądarkach:
• Mozilla Firefox 3
• Apple Safari 5
• Google Chrome
• Opera
• MS Internet Explorer 6, 7 i 8
W przypadku wykrytych artefaktów graficznych lub innych problemów dotyczących
niepoprawnego wyświetlania się strony, były one od razu poprawiane. Zmiany te dotyczyły
kodu HTML, CSS i JavaScript.
Poprawianie działania logiki aplikacji polegało na dokonywaniu zmian w konfiguracji
systemu CMS oraz w konfiguracji dodatkowych modułów za każdym razem gdy zauważono
niepoprawne działanie aplikacji.
Budowa całej witryny była bardzo skomplikowanym procesem, który wymagał bardzo dobrej
znajomości:
• Systemu Drupal
• Narzędzi umożliwiających tworzenie grafiki. Same narzędzia to nie wszystko –
konieczne jest też posiadanie wyczucia dotyczącego estetyki wyglądu oraz
odpowiednich umiejętności twórczych.
• Sposobów tworzenia szablonów w oparciu o projekt graficzny. Konieczna jest tu
dobra znajomość HTML, CSS i PHP. JavaScript jest również przydatny.
• Wielu dodatkowych modułów. Istotna jest tu nie tylko sama znajomość wielu
dodatkowych modułów ale także umiejętność ich odpowiedniego skonfigurowania.
Podsumowując, wykonanie projektu witryny oraz jej późniejsza realizacja zajęły ponad 2
tygodnie pracy.
191
3.6. Testy wydajnościowePorzedni rozdział, zawierający porównanie trzech wybranych systemów CMS, zakończyłem
testami wydajnościowymi. W testach tych Drupal osiągnął najlepszy wynik. Czas potrzebny
na wygenerowanie strony głównej w „świeżej” instalacji systemu z wyłączonym
buforowaniem wynosił 102 ms. Po włączeniu buforowania czas ten zmniejszał się do
zaledwie 16 ms.
Po wykonaniu aplikacji dla firmy Geotest, ponownie poddałem system testom
wydajnościowym.
Zbudowana aplikacja różni się od czystej instalacji kilkoma zasadniczymi aspektami:
• Kilka wbudowanych modułów standardowo nieaktywnych zostało włączonych
• Zainstalowano i aktywowano kilkanaście dodatkowych modułów
• Zbudowano własny szablon, który jest bardziej złożony niż szablon domyślny – w
związku z czym kod jego jest dłuższy
• Wypełniono podstrony treścią
Tak zmodyfikowany system CMS został powtórnie przetestowany pod względem wydajności
za pomocą programu JMeter. Środowisko testowe było takie samo jak podczas
wcześniejszych testów. Wyniki testów były następujące:
3.7. PodsumowanieW rozdziale tym zaprojektowana oraz wykoanana została rozbudowana strona www oparta na
systemie Drupal. Do systemu dodany został nowy, zaprojektowany specjalnie na potrzeby
strony, szablon. Dodanych zostało także kilkanaście dodatkowych modułów oraz wypełniono
stronę dużą ilością treści.
Ukończona aplikacja została poddana testom wydajnościowym. Podczas testowania aplikacji
z włączonym buforowaniem (co jest ustawieniem zalecanym) nie wykryto znaczącego spadku
wydajności w porównaniu z „świeżą” instalacją systemu Drupal. Czas generacji stron w
przypadku czystej instalacji systemu wynosił 16 ms, zaś dla zbudowanej witryny 28-30 ms.
192
193
44. Metody poprawiania wydajności aplikacji
wykonanej w wybranym systemie CMS
Pod koniec trzeciego rozdziału zaprezentowano wyniki testów wydajnościowych gotowej
aplikacji zbudowanej w oparciu o system Drupal. Szybkość działania aplikacji z włączonym
buforowaniem była imponująca. Przeprowadzone testy symulujące pracę jednego
użytkownika mające na celu sprawdzenie czasu oczekiwania na wygenerowanie strony dały w
wyniku 28 ms dla pojedynczego artykuły ze strony głównej oraz 30 ms dla strony
dynamicznej wyświetlającej wszystkie profile pracowników.
Mimo dokładnego wykonania należy pamiętać, że powyższe testy miały na celu zbadanie
jedynie czasu generowania dokumentu HTML a nie czasu ładowania całej strony.
Rzeczywisty czas ładowania pełnej strony będzie dłuższy ponieważ załadowane zostaną także
pliki, które podczas wcześniejszych testów były pominięte. Należą do nich:
• pliki stylów CSS
• pliki skryptów JavaScript
• obrazki
• inne ewentualne pliki
Podczas przeglądania strony przez odwiedzających prędkość wczytywania podstron będzie
zależna m.in. od następujących czynników:
1. ilości plików CSS, JavaScript i obrazów, które trzeba pobrać
2. prędkości łącza internetowego
194
3. czasu wymaganego na wygenerowanie i przesłanie pliku HTML
4. ilości osób jednocześnie przeglądających witrynę
Na drugi i czwarty punkt administratorzy witryn nie mają wpływu. Aby więc poprawić
wydajność należy skupić się punktach: pierwszym i trzecim.
Istnieje także wiele innych czynników mających wpływ na czas oczekiwania na wyświetlenie
się owiedzanej strony, takich jak zmniejszanie rozmiaru plików graficznych, aczkolwiek
czynniki te wykraczają poza tematykę tej pracy.
W rozdziale tym omówione zostaną następujące zaawansowane metody zwiększania
wydajności aplikacji opartej na systemie Drupal:
• wbudowane w system:
o buforowanie podstron i bloków
o kompresja podstron
o optymalizacja plików CSS
o optymalizacja plików JavaScript
• kompresja plików CSS
• minimalizacja i kompresja plików JavaScript
• przyspieszanie pracy skryptów PHP
• generowanie statycznych podstron
4.1. Wbudowane opcje poprawiania wydajnościSystm Drupal posiada kilka wbudowanych funkcji zwiększających wydajność aplikacji. W
poprzednich dwóch rozdziałach funkcje te były wykorzystywane podczas testów
wydajnościowych. W tym rozdziale zostaną one w skrócie omówione.
4.1.1. Buforowanie podstronDrupal niezależnie od ustawień w panelu administracyjnym buforuje następujące dane:
195
• Elementy nawigacji
• Skróty artykułów i typy formatów wejściowych
• Tłumaczenia językowe elementów interfejsu
• Informacje o włączonych szablonach i modułach
• Ustawienia szablonów i modułów
Dzięki buforowaniu powyższych elementów system nie musi przy każdym wyświetleniu
strony sprawdzać jakie elementy nawigacji są definiowane przez poszczególne moduły ani
jakie moduły czy szablony są dostępne w systemie.
Ponadto poprzez panel sterowania, możliwe jest włączenie buforowania stron. Buforowanie
stron polega na zapisywaniu w bazie danych gotowych stron generowanych przez system.
Dzięki temu często odwiedzane podstrony nie muszą być powtórnie generowane – zamiast
tego wyświetlane są ich wersje zapisane w bazie danych.
Wadą buforowania podstron jest np. to, że zmiany dokonane na stronie są widoczne dopiero
po przedawnieniu się buforu (lub jego ręcznym usunięciu). Do usuwania wybranych
elementów buforu Drupal posiada zbiór specjalnych funkcji, np. funkcja „cache_clear_all”
czyści całą zawartość buforu27.
Bufor systemu Drupal jest przechowywany w odpowiednich tabelach w bazie danych:
• cache – ogólna tabela buforowanych danych. Przechowywane są tu np. wartości
zmiennych z tabeli variables w postaci jednego rekordu zawierającego wszystkie
zmienne i ich wartości.
• cache_block – bufor bloków
• cache_filter – przechowuje przefiltrowane wersje artykułów (np. z usuniętymi
niektórymi znacznikami HTML). Dostępna tutaj treść poszczególnych artykułów jest
zależna od formatu danych wejściowych wybranego podczas dodawania artykułu.
27 Dokładny opis wszystkich funkcji dostępnych w systemie Drupal znajduje się pod adresem http://api.drupal.org
196
• cache_form – buforowanie formularzy www
• cache_menu – buforowanie elementów nawigacji
• cache_page – bufor podstron
• cache_update – bufor informacji o dostępnych aktualizacjach systemu
Dodatkowe moduły dla systemu Drupal mogą korzystać z głównej tabeli lub tworzyć swoje
własne tabele do przechowywania buforowanych danych.
Rysunek . Przykładowy fragment zawartości tabeli cache_page systemu Drupal.
Jak pokazały wcześniejsze testy po włączeniu buforowania stron czas oczekiwania spadł z
346 na 28 ms.
Należy tutaj również zaznaczyć, że buforowanie podstron i bloków działa tylko podczas
odwiedzania strony przez anonimowych (niezalogowanych) użytkowników. Zalogowani
użytkownicy nadal będą mieli czas oczekiwania na poziomie 346 ms.
4.1.2. Kompresja podstronPoza zmniejszeniem czasu ładowania poprzez przyspieszenie samego generowania podstron,
możliwe jest także włączenie kompresji GZip dla przesyłanych do klienta plików HTML.
Pliki skompresowane programem GZip mają mniejszą objętość dzięki czemu są szybciej
przesyłane przez sieć.
Za pomocą przeglądarki Google Chrome wykonano testy sprawdzające różnicę w objętości
skompresowanej oraz nieskompresowanej wersji dokumentu HTML.
Przed włączeniem kompresj podstron strona główna testowej aplikacji miała wielkość
27.19KB i wczytywała się najczęściej w 65-90 ms. Po włączeniu kompresji GZip objętość
197
pliku HMTL wyniosła 6.92KB a czas wczytywania zmniejszył się do 60-75 ms.
Należy zaznaczyć tu, że wszystkie testy prowadzone były na jednej fizycznej maszynie, co
oznacza, że pobierane dane nie były przesyłane przez sieć. W przypadku wykonywania
podobnych testów, ale wykorzystujących dwie różne maszyny komunikujące się przez sieć,
czas ładowania byłby wyższy.
Ponadto zaobserwowano różnice w stosunku czasu opóźnienia28 do faktycznego czasu
przesyłania strony. Przy wyłączonej kompresji opóźnienie było prawie o połowę mniejsze od
czasu przesyłania, zaś przy włączonej kompresji oba czasy były w miarę równe. Wynika to z
tego, że przy włączonej kompresji przygotowanie strony do przesłania do przeglądarki
wymaga więcej czasu, ponieważ strona ta musi zostać skompresowana. Samo przesyłanie zaś
odbywa się szybciej ponieważ skompresowany plik ma mniejszą objętość.
4.1.4. Optymalizacja plików CSS i JavaScriptOstatnią istotną wbudowaną w system Drupal funkcją pozwalająca na poprawę wydajności
jest tzw. optymalizacja plików CSS i skryptów JavaScript. Optymalizacja ta polega na
połączeniu wszystkich oddzielnych plików CSS w jeden plik oraz scaleniu wszystkich
skryptow JavaScript w jednym pliku. Ponadto z kodu CSS usuwane są komentarze oraz
niepotrzebne spacje.
Powyższa optymalizacja nie dotyczy skryptów dołączanych na niektórych podstronach
administracyjnych. Ponieważ skrypty te nie są potrzebne podczas odwiedzin zwykłych gości,
więc nie wchodzą w skład zoptymalizowanego pliku.
W testowej aplikacji ilość plików CSS wczytywanych podczas odwiedzania strony wynosi
16, a plików JavaScript 14. Złożoność ta wynika z tego, że wiele modułów zapewnia swoje
własne style i skrypty, które muszą być dołączone do strony www. Łączny rozmiar plików
CSS wynosił 64.63KB z średnim czasem pobierania na poziomie 70 ms. Rozmiar plików
JavaScript wynosił 150.85KB z średnim czasem pobierania 190 ms.
28 Czas opóźnienia jest mierzony od momentu wysłania zapytania do serwera aż do chwili gdy nadejdzie pierwszy bit będący początkiem odpowiedzi.
198
Po włączeniu funkcji optymalizacji znacząco zmniejszyła się ilość zapytań http wysyłanych
do serwera. Ilość plików CSS zmalała do dwóch. Ich łączny rozmiar wyniósł 43.1KB. Czas
potrzebny na ich pobranie oscylował wokół 35 ms. Zawartość wszystkich skryptów
JavaScript zostala umieszczona w jednym pliku o rozmiarze identycznym jak było to
wcześniej. Jedyną korzyścią w tym wypadku było zmniejszenie ilości zapytań http
związanych z plikami skryptów, ponieważ średni czas ładowania wydłużył się tu do 215 ms.
Powyższy spadek wydajności po zoptymalizowaniu plików JavaScript wynika z faktu, że
wcześniej przeglądarka Google Chrome mogła pobierać pliki JavaScript równolegle co
sprzyjało szybkiemu pobieraniu strony. Gdyby jednak uwzględnić opóźnienia panujące w
rzeczywistej sieci zapewne okazało by się, że jeden plik JavaScript jest pobierany szybciej niż
14 plików o identycznej wadze. Należy bowiem pamiętać, że testy wydajnościowe były w
tym wypadku prowadzone na jednej fizycznej maszynie, bez udziału sieci.
Rysunek . Wygenerowane przez system pliki CSS.
Ponadto częstą praktyką jest umieszczanie plików JavaScript na końcu kodu pliku HTML.
Dzięki takiemu działaniu skrypty te pobierane są po wyświetleniu całego dokumentu. W
przypadku umieszczenia skryptów u góry strony opóźniają one pobieranie dokumentu HTML.
4.2. Kompresja plików CSSCzas wymagany na przesłanie plików CSS można zmniejszyć poprzez skompresowanie ich
algrytmem GZip. W systemie Drupal można to osiągnąć instalując dodatkowy moduł o
nazwie CSS GZip dostępny do pobrania pod adresem http://www.drupal.org/project/css_gzip.
Instalacja tego dodatku powoduje pojawienie się w panelu administracyjnym odpowiednich
opcji umożliwiających aktywowanie kompresji.
199
Rysunek . Poniżej ustawień optymalizacji CSS widoczne są opcje dostępne po zainstalowaniu modułu CSS GZip.
Po włączeniu kompresji system skompresował style CSS i zapisał je w postaci plików *.gz.
Od tej pory przeglądarki kompatybilne z formatem GZip będą pobierać skompresowane style.
Rysunek . Wygenerowane przez system pliki skompresowanych styli CSS (*.css.gz)
Dzięki kompresji styli udało się zmniejszyć ich rozmiar do 9KB. Duży spadek objętości
plików wynika z wykorzystania największej siły kompresji. Najmocniejsza kompresja
zajmuje więcej czasu niż słabsza kompresja, ale w przypadku testowanej aplikacji nie ma to
znaczenia ponieważ skompresowany plik styli CSS musi być wygenerowany tylko raz (a nie
przy każdym otwarciu strony).
Porównanie rozmiarów i czasów ładowania wszystkich styli CSS przedstawiono na
poniższych wykresach.
200
Niewielka różnica w czasie przesyłania pomiędzy wersją zoptymalizowaną a skompresowaną
może wynikać z tego, że testy przeprowadzone były na jednej maszynie tzn. bez udziału sieci.
4.3. Kompresja plików JavaScriptKolejnym krokiem, który umożliwi poprawę wydajności aplikacji jest kompresja plików
JavaScript. Oprócz możliwości połączenia wszystkich skryptów w jeden plik oraz
skompresowania tego pliku za pomocą algorytmu GZip możliwa jest wcześniejsza
minifikacja kodu JavaScript.
Minifikacja jest procesem polegającym na usunięciu z kodu wszystkich zbędnych białych
znaków oraz komentarzy podobnie jak miało to miejsce podczas optymalizacji kodu CSS. Do
minifikacji skryptów JavaScript wykorzystany zostanie napisany w PHP skrypt JSMin29.
Aby aktywować w systemie Drupal minifikację i kompresję kodu JavaScript należy pobrać
dodatkowy moduł o nazwie JavaScript Aggregator dostępny pod adresem
http://www.drupal.org/project/javascript_aggregator. Po zainstalowaniu tego modułu
podobnie jak w przypadku modułu CSS GZip w panelu administracyjnym pojawiły się
dodatkowe opcje.
Rysunek . Poniżej ustawień optymalizacji skryptów widoczne są opcje dostępne po zainstalowaniu modułu JavaScript Aggregator
Minifikacja działa zawsze gdy moduł JavaScript Aggregator jest włączony. Rozmiar
zoptymalizowanego kodu JavaScript po zminifikowaniu go algorytmem JSMin wyniósł
113KB. Średni czas przesyłania spadł do 195 ms.
29 Skrypt JSMin można bezpłatnie pobrać na stronie http://github.com/rgrove/jsmin-php
201
Po zbadaniu korzyści wynikających z minifikacji, włączona została kompresja GZip.
Zoptymalizowany, zminifikowany oraz skompresowany kod JavaScript miał już tylko 25KB.
Czas jego pobierania wyniósł 180 ms.
4.4. APC (Alternative PHP Caching)Dotychczas omówione sposoby poprawiania wydajności polegały na wprowadzaniu
odpowiednich zmian w aplikacji. W tym podrozdziale przedstawiona zostanie metoda
wymagająca jedynie zmian w ustawieniach serwera.
System Drupal jest napisany w języku PHP. Istotną cechą tego języka jest to, że kod źródłowy
nie wymaga kompilacji po każdym dokonaniu w nim nawet najmniejszych zmian. Jest tak
ponieważ podczas uruchamiania programu napisanego w PHP (tutaj systemu CMS) jego kod
jest automatycznie kompilowany przy każdym wywołaniu.
Podejście to ma wiele zalet. Oprócz tego, że nie trzeba samemu kompilować kodu po
dokonaniu w nim zmian, ten sam kod daje się uruchomić niezależnie od systemu
operacyjnego.
Niestety charakter języka PHP niesie ze sobą także pewne wady. Główny problem polega na
obniżeniu wydajności. Oczywiste jest, że kod który wymaga każdorazowej kompilacji
podczas uruchamiania aplikacji będzie działał wolniej niż kod, który został już wcześniej
skompilowany.
Aby poprawić tę sytuację wymyślone zostały tzw. akceleratory PHP, których zadanie polega
na kompilacji kodu PHP do postaci tzw. kodu operacji. Zapisany w ten sposóbod kod jest
uruchamiany zamiast kodu PHP. Dzięki temu podczas uruchamiania aplikacji pomijana jest
m.in. kompilacja PHP.
Akceleratory PHP znacząco przyspieszają działanie aplikacji napisanych w PHP. Wadą tych
akceleratorów jest to, że zmiany dokonane w kodzie PHP nie będą widoczne dopóki dany
akcelerator nie dokona ponownej kompilacji do kodu operacji. Akceleratory niekoniecznie
sprawdzają czy w kodzie zostały dokonane zmiany, więc korzystanie z nich w środowisku
deweloperskim jest niewskazane.
202
APC30, czyli Alternative PHP Caching, to jeden z takich akceleratorów. Akcelerator ten jest
domyślnie zawarty w wykorzystywanym przeze mnie pakiecie XAMPP, choć jest on
nieaktywny. Aktywacja APC wymaga usunięcia znaku komentarza w odpowiedniej linii w
pliku konfiguracji PHP.
Z linijki zawierającej „;extensions=php_apc.dll” usunięty został znak średnika. Nastepnie
zrestartowano serwer Apache aby wczytane zostały nowe ustawienia.
W wyniku włączenia akceleratora APC czas generacji dokumentu HTML dla strony głównej
spadł do 22 ms – wcześniej wynosił on 28 ms. Test przeprowadzono za pomocą
wykorzystanego i opisanego wcześniej programu JMeter oraz za pomocą przeglądarki Google
Chrome.
4.5. Moduł „Boost”Użytkowników aplikacji można podzielić na anonimowych (niezalogowanych) oraz
autoryzowanych (zalogowanych). Poszczególne podstrony mogą wyglądać różnie dla różnych
zalogowanych użytkowników. Mogą różnić się chociażby wyświetlaną nazwą użytkownika
czy wyświetlanymi danymi w części panelu administracyjnego do której użytkownicy mają
dostęp. Dla anonimowych użytkowników zaś konkretne podstrony wyglądają często tak samo
– nie ma np. danych wyświetlanych dla konkretnych osób lub grup.
Jeżeli budowana aplikacja nie posiada elementów często zmieniających się, np. co minutę,
takich jak chociażby dynamiczna lista ostatnio dodanych artykułów lub komentarzy, to można
by utworzyć statyczne wygenerowane przez system CMS kopie wszystkich podstron i
prezentować je anonimowym użytkownikom za każdym razem gdy przeglądają oni witrynę.
W ten sposób podczas odwiedzin anonimowych użytkowników aplikacja wczytywała by się
szybciej ponieważ przeglądane podstrony nie musiały by być generowane wielokrotnie dla
wszystkich odwiedzających.
30 Strona główna APC znajduje się pod adresem http://pecl.php.net/package/APC. Dokładn
203
System Drupal posiada dodatkowy moduł, który pozwala osiągnąć taką funkcjonalność.
Moduł ten nazywa się Boost. Można go pobrać ze strony http://www.drupal.org/project/boost.
Potrafi on tworzyć statyczne kopie nie tylko dokumentów HTML ale także np. XML,
używanych przez RSS.
Po zainstalowaniu modułu Boost w sekcji administracyjnej pojawiła się nowa podstrona z
bardzo dużą liczbą różnych opcji konfiguracyjnych. Opcja generowania statycznych stron
www jest domyślnie włączona. Domyślny czas przechowywania zbuforowanych stron wynosi
godzinę – w przypadku naszej aplikacji testowej można ustawić dłuższy ponieważ strona ta
nie będzie aktualizowana częściej niż raz dziennie. Ustawienie na 12 godzin jest w tym
przypadku jak najbardziej odpowiednie. Statyczne podstrony, które będą przechowywane w
systemie dłużej niż 12 godzin będą usuwane oraz generowane będą ich nowe, świeższe
wersje.
Pośród wielu opcji najbardziej istotne wydają się być:
• możliwość buforowania również stron zawierających parametry w adresie (np. ?
page=1 dla list z podziałem na strony)
• możliwość zdefiniowania, które podstrony mają być buforowanne lub które nie
• możliwość nakazania modułowi Boost sprawdzać kiedy były dokonywane ostatnie
zmiany w serwisie (na podstawię dat zapisanych w bazie danych). Jeśli wykryte
zostaną zmiany tymczasowe statyczne podstrony zostaną automatycznie usunięte.
Dostępne są także przyciski usuwające statyczne podstrony z buforu.
204
Rysunek . Fragment długiego formularza konfiguracyjnego modułu Boost. Widoczne są ustawienia długości czasu przechowywania zbuforowanych statycznych kopii podstron oraz przyciski usuwające dane z buforu.
Chociaż buforowanie w postaci statycznych podstron jest domyślnie włączone, konieczne jest
wykonanie kilku dodatkowych operacji zanim moduł Boost zacznie serwować statyczne
podstrony. Po skonfigurowaniu wszystkich ustawień modułu Boost należy przejść do strony
„Boost htaccess rulet generation”. Na podstronie tej wyświetlony zostanie kod, który należy
umieścić w głównym pliku .htaccess31 systemu Drupal. Kod ten jest częściowo zależny od
ustawień modułu Boost i wygląda następująco:
31 .htaccess – plik konfiguracyjny serwera Apache umożliwiający zmianę konfiguracji dla konkretnego katalogu. Więcej informacji o plikach .htaccess można przeczytać na stronie http://en.wikipedia.org/wiki/Htaccess.
205
206
### BOOST START ### AddDefaultCharset utf-8 <FilesMatch "(\.html|\.html\.gz)$"> <IfModule mod_headers.c> Header set Expires "Sun, 19 Nov 1978 05:00:00 GMT" Header set Cache-Control "no-store, no-cache, must-revalidate, post-check=0, pre-check=0" </IfModule> </FilesMatch> <IfModule mod_mime.c> AddCharset utf-8 .html AddCharset utf-8 .css AddCharset utf-8 .js AddEncoding gzip .gz </IfModule> <FilesMatch "(\.html|\.html\.gz)$"> ForceType text/html </FilesMatch> <FilesMatch "(\.js|\.js\.gz)$"> ForceType text/javascript </FilesMatch> <FilesMatch "(\.css|\.css\.gz)$"> ForceType text/css </FilesMatch> # Gzip Cookie Test RewriteRule boost-gzip-cookie-test\.html cache/perm/boost-gzip-cookie-test\.html\.gz [L,T=text/html] # GZIP - Cached css & js files RewriteCond %{HTTP_COOKIE} !(boost-gzip) RewriteCond %{HTTP:Accept-encoding} !gzip RewriteRule .* - [S=2] RewriteCond %{DOCUMENT_ROOT}/GT_TEST/cache/perm/%{SERVER_NAME}%{REQUEST_URI}_\.css\.gz -s RewriteRule .* cache/perm/%{SERVER_NAME}%{REQUEST_URI}_\.css\.gz [L,QSA,T=text/css] RewriteCond %{DOCUMENT_ROOT}/GT_TEST/cache/perm/%{SERVER_NAME}%{REQUEST_URI}_\.js\.gz -s RewriteRule .* cache/perm/%{SERVER_NAME}%{REQUEST_URI}_\.js\.gz [L,QSA,T=text/javascript] # NORMAL - Cached css & js files RewriteCond %{DOCUMENT_ROOT}/GT_TEST/cache/perm/%{SERVER_NAME}%{REQUEST_URI}_\.css -s RewriteRule .* cache/perm/%{SERVER_NAME}%{REQUEST_URI}_\.css [L,QSA,T=text/css] RewriteCond %{DOCUMENT_ROOT}/GT_TEST/cache/perm/%{SERVER_NAME}%{REQUEST_URI}_\.js -s RewriteRule .* cache/perm/%{SERVER_NAME}%{REQUEST_URI}_\.js [L,QSA,T=text/javascript] # Caching for anonymous users # Skip boost IF not get request OR uri has wrong dir OR cookie is set OR request came from this server OR https request RewriteCond %{REQUEST_METHOD} !^(GET|HEAD)$ [OR] RewriteCond %{REQUEST_URI} (^/GT_TEST/(admin|cache|misc|modules|sites|system|openid|themes|node/add))|(/(comment/reply|edit|user|user/(login|password|register))$) [OR] RewriteCond %{HTTP_COOKIE} DRUPAL_UID [OR] RewriteCond %{HTTP:Pragma} no-cache [OR]
207
RewriteCond %{HTTP:Cache-Control} no-cache [OR] RewriteCond %{HTTPS} on RewriteRule .* - [S=3] # GZIP RewriteCond %{HTTP_COOKIE} !(boost-gzip) RewriteCond %{HTTP:Accept-encoding} !gzip RewriteRule .* - [S=1] RewriteCond %{DOCUMENT_ROOT}/GT_TEST/cache/normal/%{SERVER_NAME}%{REQUEST_URI}_%{QUERY_STRING}\.html\.gz -s RewriteRule .* cache/normal/%{SERVER_NAME}%{REQUEST_URI}_%{QUERY_STRING}\.html\.gz [L,T=text/html] # NORMAL RewriteCond %{DOCUMENT_ROOT}/GT_TEST/cache/normal/%{SERVER_NAME}%{REQUEST_URI}_%{QUERY_STRING}\.html -s RewriteRule .* cache/normal/%{SERVER_NAME}%{REQUEST_URI}_%{QUERY_STRING}\.html [L,T=text/html] ### BOOST END ###
Po umieszczeniu powyższego kodu w odpowiednim miejscu głównego pliku .htaccess moduł
Boost został poprawnie skonfigurowany.
Rysunek . Moduł Boost zapisał wszystkie podstrony jako statyczne pliki HTML.
Dostępne w testowej witrynie podstrony zostały zapisane jako statyczne pliki HTML oraz
GZip. Od tego momentu podczas przeglądania podstron przez niezalogowanych
użytkowników zauważono wyraźny spadek czasu wczytywania podstron. Czas pobierania
dokumentu HTML w przeglądarce Google Chrome spadł do 22 ms. Czas zmierzony przez
program JMeter wyniósł 18 ms.
208
Pomimo tego, że podczas serwowania zapisanych statycznych kopii stron akcelerator APC nie
jest używany, warto pozostawić go włączonego, ponieważ nadal będzie on przyspieszał
generowanie stron oglądanych przez zalogowanych użytkowników (w przypadku aplikacji
testowej będą to osoby obsługujące stronę).
Wyczerpujący poradnik dotyczący instalacji, konfiguracji i korzystania z modułu Boost
dostępny jest pod adresem http://drupal.org/node/545908.
4.8. PodsumowanieW rozdziale tym przedstawiono różne sposoby poprawiania wydajności wykonanej aplikacji
oraz udowodniono, że aplikacja ta może działać z bardzo dużą szybkością. Dzięki
omówionemu APC oraz modułowi Boost znacząco obniżono czas generowania
poszczególnych podstron, a agregacja, minifikacja i kompresja plików CSS i JavaScript
pozwoliła zmniejszyć ilość pobieranych kilobajtów oraz ograniczyć ilość wykonywanych
zapytań http. Poniżej na wykresach przedstawiono podsumowanie efektów poprawiania
wydajności.
Jak widać na poniższych wykresach łączna waga strony spadła z 241 KB do jedynie 41 KB
czyli dokładnie o 588%. Czas ładowania nie zmniejszył się aż tak znacznie bo z 337 ms do
231 ms. Niewielka różnica w czasie ładowania wynikać może z faktu, że testy były
przeprowadzone na jednej fizycznej maszynie tzn. bez udziału sieci.
209
55. Podsumowanie
5.1. Najcenniejsze doświadczenie wyniesione z pisania pracyTematyka systemów CMS zawsze była dla mnie interesująca. Z omówionymi systemami
CMS – Joomlą, WordPress’em i Drupalem – miałem styczność już wielokrotnie jednak nigdy
wcześniej nie dokonywałem tak szerokiego ich porównania.
Podczas pisania tej pracy konieczne było wielogodzinne, bardzo dokładne studiowanie tych
systemów. W związku z tym realizacja niektórych jej cześci trwała bardzo długo a pisanie
całej pracy zajęło dwa miesiące.
To z czego jestem bardzo zadowolony to zdobyta wiedza dotycząca porównywanych
systemów CMS oraz fakt, że pisałem o tym co mnie pasjonuje i z czym wiażę swoją
najbliższą przyszłość.
Oprócz samej wiedzy o systemach CMS bardzo interesujące były dla mnie wyniki porównań
wydajnościowych zbudowanej aplikacji testowej. Nie spodziewałem się aż takiego wzrostu
wydajności po zastosowaniu technik opisanych w czwartym rozdziale.
5.2. Czy cele zostały osiągnięte?Pozwolę sobie przytoczyć cel pracy:
„Celem pracy jest dokonanie dogłębnego porównania wybranych systemów zarządzania treścią oraz wybranie zwycięskiego systemu. Następnie wykonana zostanie implementacja aplikacji www w oparciu o wyłoniony system CMS, przeprowadzone zostaną testy wydajnościowe tej aplikacji oraz zaprezentowane zostaną liczne sposoby poprawiania wydajności zbudowanej aplikacji.”
Wybrane systemy CMS zostały dokładnie porównane. Rozdział porównujący wyszedł dużo dłuższy i bogatszy niż pierwotnie planowałem. Dzięki porównaniu osoby wahające się przy wyborze systemu CMS open source mogą opierając się na tej pracy podjąć lepszą decyzję.
210
Implementacja aplikacji testowej została wykonana w stu procentach zgodnie z wstępnymi założeniami projektowymi oraz oczekiwaniami firmy zamawiającej. Mam nadzieję na przyszłe jej rozwijanie.
Wykonane testy wydajnościowe oraz wdrożone sposoby poprawiania wydajności udowodniły, że wytypowany jako najlepszy system Drupal w pełni nadaje się do tworzenia wydajnych i rozbudowanych aplikacji. Udowodniono, że jest on wielokrotnie szybszy od swoich konkurentów.
Pisanie tej pracy było dla mnie cennym doświadczeniem, chociaż gdybym wiedział, że zajmie mi ona aż tyle czasu to prawdopodobnie wybrałbym inny temat. W niedalekiej przyszłości planuję opublikować ją także w języku angielskim.
211
6. Bibliografia[ 1 ] Oficjalna strona systemu Joomla! – www.joomla.org
[ 2 ] Dokumentacja systemu Jooma! – docs.joomla.org
[ 3 ] Hagen Graf „Building Websites with Joomla! 1.5”, Packt Publishing 2008
[ 4 ] Tessa Blakeley Silver „Joomla! 1.5 Template Design”, Pack Publishing 2009
[ 5 ] Oficjalna strona systemu WordPress – www.wordpress.org
[ 6 ] Dokumentacja systemu WordPress – codex.wordpress.org
[ 7 ] April Hodge Silver, Hasin Hayder „WordPress 2.7 Complete”, Pack Publishing 2009
[ 8 ] Tessa Blakeley Silver „WordPress 2.8 Theme Design”, Packt Publishing 2009
[ 9 ] Heather R. Wallace „WordPress 3 Site Blueprints”, Packt Publishing 2010
[ 10 ] Oficjalna strona systemu Drupal – www.drupal.org
[ 11 ] Dokumentacja systemu Drupal – www.drupal.org/handbook
[ 12 ] David Mercerr „Drupal 6”, Packt Publishing 2008
[ 13 ] Ric Shreves „Drupal 6 Themes”, Packt Publishing 2008
[ 14 ] John Van Dyk „Pro Drupal Development”, APress 2008
[ 15 ] Trevor James „Drupal 6 Performance Tips”, Packt Publishing 2010
212