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&#347;&#263;_pliki/image001.png" o:title="2.2. Logo Drupal"/></v:shape><![endif]--><![if !vml]><img width=605 height=185src="Testowa%20tre&#347;&#263;_pliki/image002.gif" alt="2.2. Logo Drupal.png"v:shapes="Obraz_x0020_0"><![endif]></span></p><p class=MsoNormal>Testowa tre&#347;&#263;, testowa tre&#347;&#263;, testowatre&#347;&#263;.</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 &raquo; Feed" href="http://localhost/wordpress_3/feed/" /> <link rel="alternate" type="application/rss+xml" title="Testing WordPress &raquo; 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&amp;type=rss" rel="alternate" type="application/rss+xml" title="RSS 2.0" /> <link href="/joomla_1.6/index.php?format=feed&amp;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( '&larr;', 'Previous post link', 'twentyten' ) . '</span> %title' ); ?> </div> <div class="nav-next"> <?php next_post_link( '%link', '%title <span class="meta-nav">' . _x( '&rarr;', '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">&rarr;</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( '&larr;', 'Previous post link', 'twentyten' ) . '</span> %title' ); ?> </div> <div class="nav-next"> <?php next_post_link( '%link', '%title <span class="meta-nav">' . _x( '&rarr;', '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>a.radtke@derauftritt.de</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">&#160;</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">&#160;</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"> &copy; <?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