Archiv tagů w3c standardy

Vytváření sociálních sítí

Základním prvkem aplikací, které podporují vznik virtuálních sociálních sítí, je vznik veřejného nebo částečně veřejného uživatelského profilu, se kterým je svázán seznam jiných uživatelů s nějakým spojením na majitele profilu – tzv. Přátelé1. Tento seznam Přátel je viditelný i pro ostatní uživatele, kterým nabízí možnost ho procházet a zkoumat sociální spojení daného uživatele (Boyd, 2007). Ačkoliv původní myšlenka je zobrazení sociální sítě Přátel v přímé spojitosti s uživatelem, další přidanou hodnotu nabízejí tyto aplikace ve spojení s umělou inteligencí, pomocí které bývají na základě podobnosti dat, která se váží k profilu, vyhodnocována možná nová spojení na Přátele s podobnou charakteristikou (viz doporučující systém v popisu služby Last.fm).

Většina systémů nabízí vnitřně možnost zasílání zpráv jiným uživatelům či vkládání delších příspěvků v podobě blogů či žurnálů. Uživatelé tak nejsou nuceni používat žádné jiné prostředky pro komunikaci. Zprávy či příspěvky jiných se zobrazují po přihlášení v rámci profilu, který slouží jako komunikační portál.

Bližší popis „velkých“ služeb, jako jsou MySpace, Friendster či Facebook je mimo rozsah této práce, jistě by si zasloužily hlubší analýzu v podobě navazující práce hlavně z hlediska sociologického. Jednotlivé aspekty využití sociálních sítí v rámci speciálních aplikací budou popisovány v kapitole s popisem Web 2.0 aplikací (zejména Last.fm). Pro představu uvedu pouze základní popis dvou základních služeb, a sice MySpace a Facebook.

MySpace
Služba MySpace byla spuštěna v roce 2003, od roku 2005 ji vlastní společnost Fox Broadcasting. Podle údajů z Wikipedie patří mezi pět nejvíce navštěvovaných sídel na celém světě. Značnou popularitu si vydobyla, zvláště v ČR, částí zaměřenou na hudbu. Po přihlášení do této části má každý možnost vložit do systému několik mp3 souborů, které se stanou součástí jeho profilu. V mnoha případech zde bývají uveřejňovány zatím nevydané písně, takže uživatelé mají možnost „nahlédnout muzikantům přímo do kuchyně“. Další informační hodnotu má kalendář plánovaných akcí, kterých se hudebník zúčastní. Uživatel nemusí být nutně pouze fyzická osoba, takže jsou nabízeny profily kapel a klubů. Systém je též částečně otevřen pro zásuvné moduly třetích stran (API), takže stránku lze obohatit například o seznam skladeb prodávaných mp3 obchodem s možností přímého nákupu.

Kontroverzní vlastností je možnost personalizovat vzhled profilu pomocí HTML a kaskádových stylů. Autor této práce se například kvůli této vlastnosti aplikaci vyhýbá velkým obloukem. Není totiž výjimkou, že profilová stránka má při načítaní přes 1MB. O přístupnosti takových stránek pro speciální zařízení (čtečky pro nevidomé nebo i mobilní telefony) je lépe pomlčet.

Vlastností, která v důsledku může ohrozit i reálné vztahy mezi lidmi, je nutnost nějakým způsobem třídit Přátele. MySpace zobrazuje na hlavní profilové stránce výběr tzv. „Top“ Přátel a je nutné rozhodnout, kteří to budou. Nabízí se pak otázka, kdo je větší Přítel a kdo menší (Boyd, 2006b).

Facebook
Původní určení aplikace, která byla spuštěna v roce 2005, bylo vytváření sociálních akademických sítí. V roce 2006 byla otevřena pro širokou veřejnost. Oproti MySpace nabízí subjektivně lepší grafické rozhraní. Kromě základních vlastností jako vytváření hlavní skupiny Přátel má uživatel po registraci například možnost připojit se k sítím (networks) vztahujícím se k jeho osobě. Tak je například možné připojit se k síti (i bývalých) studentů Univerzity Karlovy nebo k síti svého zaměstnavatele. Tyto sítě mohou být v relaci s vytvářenými skupinami (groups, česky by asi znělo lépe klub), například „Jinonický bufet fan club“, který má v současné době kolem 450 členů.

Facebook sice nemá zcela otevřené API, ale nabízí vývojářům Facebook Framework, který mohou za pomoci speciálního jazyka použít k doprogramování nových součástí systému. Pro širší souvislosti lze nabídnout oslavný článek Davida Antoše na serveru Lupa (Antoš, 2007a).

  1. Jelikož povaha virtuálního přátelství je odlišná od skutečného, uvádí se většinou s velkým písmenem na začátku.

Technologické aspekty Web 2.0

S vývojem zobrazovacích technologií a levného broadbandového přístupu se rozvíjely i technologie a standardy pro zobrazování webového obsahu. Prvotní neúspěch DHTML, které bylo založené na kaskádových stylech CSS (cascading style sheets) a skriptovacím jazyce Javascript, byl zřejmě způsoben zuřící válkou browserů. Pro nestandardní interpretace jazyků bylo nutné (a doposud je) optimalizovat webové zdroje pro různé typy prohlížečů. Uživatelé zároveň chtěli něco víc než blikající nadpisy. V té době se také masivně rozšířila technologie Flash od firmy Macromedia (dnes Adobe).

Pro tyto zdroje, které se v mnohém dokázaly chovat jako běžné aplikace spustitelné na PC, se vžilo pojmenování Rich Internet Applications (RIA). Ale zřejmě to, že je nutné pro zobrazení flashových aplikací instalovat speciální zásuvný modul a že pro vývoj těchto aplikací je nutné vlastnit placenou licenci, zapříčinilo, že Flash byl vždy vnímán jako pouze doplňkový (chcete-li okrášlující či prezentační) prvek na klasických HTML stránkách. Určitá nevýhoda Flashe se také objevila v nesnadné portaci zásuvného modulu na jiná zařízení než klasické prohlížeče na PC (mobilní telefony, PDA). Další technologie, které nebyly příliš úspěšné, jsou aplety napsané v jazyce Java a ActiveX společnosti Microsoft (Loosley, 2006).

Svou roli také zřejmě sehrál vznik open source projektu Mozilla. V roce 1998 jej založil Netscape po krachu svého prohlížeče Netscape Navigator, kdy uvolnil převážnou část zdrojových kódů (které ovšem byly později zcela přepsány). Start projektu Firefox přinesl značné oživení obecného povědomí o W3C standardech. Odborná veřejnost se začala více zajímat, jak jsou jejich stránky zobrazovány. Přibližně ve stejné době zveřejnila skupina W3C jazyk HTML 4.01 a hlavně XHTML, který byl reformulací HTML jazyka za použití XML.

Nic z toho ovšem nespustilo revoluci1, o které jsme v předchozích kapitolách mluvili jako o Web as Platform. Tím bylo až, jak říká O’Reilly, spuštění dvou aplikací společností Google: Gmail a Google Maps (O’Reilly, 2005b). V těchto aplikacích byl, krom tradičního HTML, spojen jazyk Javascript (na straně klienta) a jazyk XML (na straně serveru). Jazyk Javascript se používá v asynchronním módu pro načítání částí stránky. Tím byla v podstatě poprvé použita sada technologií označená jako Asynchronous Javascript + XML – zkráceně AJAX. Zmíněným asynchronním přístupem se značně snížila doba odezvy RIA aplikací:

  • informace jsou načítány ze serveru s předpokladem dalších možných požadavků uživatele (například načítání okolních čtverců zobrazené mapy, aby byl pohyb myší ve všech směrech plynulý),
  • prvky na stránce mohou být překresleny po částech namísto nutnosti nového načtení celé stránky,
  • vstupy od uživatele je možné serveru posílat v předem zvalidovaných dávkách (validace probíhá pomocí Javascriptu již na straně klienta),
  • odezvy na některé vstupy uživatele mohou být generovány bez komunikace se serverem,
  • data, která už jednou byla zpracována serverem, mohou být uložena na straně klienta pro pozdější použití.
  1. Která je ve skutečnosti evolucí.

AJAX

Toto označení bylo poprvé použito Jesse James Garretem v roce 2005 v článku AJAX: New Approach to the Web Application na serveru společnosti Adaptive Path. Autor píše:

„AJAX není jedna technologie. Ve skutečnosti je to několik technologií, na sobě nezávislých a samočinných, které při společném nasazení nabízejí další možnosti využití. AJAX zahrnuje:

  • na standardech založené zobrazování pomocí XHTML a CSS;
  • dynamické zobrazování a interakci pomocí Document Object Model;
  • výměnu a manipulaci dat pomocí XML a XSLT;
  • asynchronní příjem dat pomocí XMLHttpRequest;
  • Javascript, který všechno to spojuje dohromady.“ (Garret, 2005)

Jedna z velkých nevýhod pro uživatele tradičních stránek založených na čistém HTML či XHTML je čas strávený čekáním na načítání stránek poté, co byla vyslána žádost kliknutím na některý prvek na stránce. Jak již bylo zmíněno, během let bylo učiněno několik pokusů přinést stránkám větší dynamiku za použití jednotlivých technologií jako Javascript, skryté rámce, DHTML, kaskádové styly a ActiveX prvku XMLHttpRequest od Microsoftu.

Tradiční komunikace klient–server při načítání webových stránek
Obrázek 7 – Tradiční komunikace klient–server při načítání webových stránek

Oproti standardnímu modelu komunikace webových aplikací, kde je prohlížeč zodpovědný za iniciaci žádosti webovému serveru a za zpracování odpovědi, AJAX model poskytuje zprostředkující mezivrstvu – AJAX Engine, která zajišťuje tuto komunikaci. AJAX Engine je obyčejně javascriptový objekt volaný¨vždy, kdykoli mají být od serveru přijata další data. To je zásadní rozdíl proti tradičnímu přístupu, kde dojde pouze k poskytnutí odkazu na další (externí) zdroj/URL, jehož načtení musí klient potvrdit (např. uživatel kliká na šipku pro posun mapy). V pojetí AJAXu může být odkaz na zdroj vyvolán a zpracován pomocí AJAX Engine. Požadavek je zpracován asynchronně, což znamená, že požadavek bude vyslán, ale nebude se čekat na odpověď, namísto toho se bude dále provádět kód klienta a odpověď bude zpracována později.

Server, který obyčejně dodává klientům na základě jejich požadavku HTML dokumenty, CSS šablony vzhledu nebo javascriptový kód, je kromě toho nakonfigurován tak, že vrací i data, která umí AJAX Engine interpretovat. Tato data jsou nejčastěji ve formě XML, ale lze použít jakýkoliv jiný formát, který AJAX Engine podporuje.

V okamžiku, kdy obdrží AJAX Engine odpověď ze serveru, může provést příslušnou akci – parsování dat, změnu podoby uživatelského rozhraní či poskytnutí zaslaných informací uživateli. Díky tomu, že tento proces zahrnuje přenos menšího množství informací než tradiční webový aplikační model a uživatelské rozhraní je aktualizováno rychleji a bez nutnosti překreslování celého výsledného aplikačního okna, uživatel může pracovat rychleji (Toth, 2007; Loosley, 2006).

Komunikace klient–server za pomoci AJAXu.
Obrázek 8 – Komunikace klient–server za pomoci AJAXu

Použití standardů a přístupnost významných blogů

Pokud jsme v předešlých kapitolách nastínili, že základními principy blogů i Web 2.0 aplikací jsou vysoká míra otevřenosti a uživateli generovaný obsah, je podstatné, aby tyto principy mohl využít každý, například i ten, který je nucen v důsledku svého zdravotního stavu používat vybavení speciální.
Otázka používání standardů a přístupnosti (accessiblity) při vytváření webových stránek je jedním z nejvíce diskutovaných problémů mezi webmastery. Na počátku všech problémů stojí velmi překotný vývoj webu v devadesátých letech minulého století, kdy ustoupila do pozadí původní myšlenka webové stránky jako celistvého dokumentu, který byl propojen s ostatními pomocí hypertextových odkazů. S postupující komercionalizací webu a s ní spojenými marketingovými aspekty byly do stránek přidávány elementy, které spíše než obsahovou funkci plnily funkci prezentační, s jejich použitím mohly být stránky uživatelsky přitažlivější. Protože se vývojáři jednotlivých prohlížečů snažili (např. Microsoft, Netscape) vyhovět těmto trendům co nejrychleji a protože konsorcium W3C1 nebylo schopné na tyto trendy rychle reagovat, byla do zobrazovacích jader prohlížečů implementována vlastní jednostranná řešení. Výsledkem byla vzájemná nekompatibilita při zobrazování jednotlivých zdrojů.

Bylo by asi dobré poznamenat, že se konsorcium vůbec v průběhu vývoje nechovalo příliš racionálně. Například navrhované standardy a jejich vývojové stupně postrádají logické návaznosti (nekompatibilita CSS, CSS2 a budoucího CSS3 atd.).

Počátek nového století (poté co splaskla internetová bublina a poté co se objevilo množství nových technologií) znamená návrat k původním myšlenkám webu. Je kladen důraz na oddělení formátovací části stránek od obsahové a dodržování sémantických vlastností jednotlivých značkovacích jazyků. Tím je umožněno například rozdílné zobrazení (naformátování) na mobilním zařízení při zachování stejného obsahu (tzn. fyzicky existuje jeden HTML/XHTML, XML dokument a větší množství instrukcí v podobě CSS souborů pro konečné zformátování). Dodržení sémantiky je vhodné zvlášť u systémů pro automatickou obsahovou analýzu – zejména u vyhledávačů, které jsou pak schopny zohlednit „důležitost“ jednotlivých prvků stránek2. Neméně důležité jsou pak sémantická struktura a oddělení formátování pro různé čtečky (např. pro zrakově postižené – screen readers) a optimalizace pořadí aktivních prvků stránky (hyperlinky, formuláře) pro snadnou navigaci v obsahu stránky bez pomoci myši (např. klávesou Tab) (Gibson, 2007).

Zároveň se objevuje opět princip „uzamčení“, kdy jsou výrobci prohlížečů bohužel nuceni zachovávat možnost zobrazení i nestandardizovaných obsahů, kterých je v prostředí internetu (kvůli zmíněnému překotnému vývoji) stále mnoho (mrtvé a již neaktualizované stránky se zajímavým obsahem). Autoři stránek tedy nejsou ničím nuceni, aby standardy dodržovali.

Bohužel stále není na světě standard, který by dokázal oddělit hlavní obsah stránky (ve smyslu hlavního podstatného sdělení) například od navigačních prvků nebo prvků doplňkových (např. stejná hlavička nebo zobrazení kontaktní adresy na všech stránkách sídla). Toho se možná dočkáme, například při použití mikroformátů, až v tzv. sémantickém webu (někdy bývá označován jako Web 3.0) (Skenák, 2007).

Zásadním dokumentem pro tvorbu webových stránek, který se po přelomu století objevil, je soubor doporučení pro tvorbu webových zdrojů Manifest Dogma W4 sepsaný skupinou českých vývojářů kolem výrazné osobnosti českého internetu Petra Staníčka (Pixy). Ačkoliv tento Manifest vznikl v roce 2003 a může se zdát zastaralý, autor této práce jej považuje za nadčasový a nepřekonaný. V dokumentu se například doporučuje striktní dodržování standardů značkovacích jazyků konsorcia W3C při plném zachování sémantických významů jednotlivých značek (tagů – například nepoužívání tabulek k formátování vzhledu stránky) a využití alternativních popisů pro netextové informace použité na stránkách (například atribut alt v tagu img).

Podívejme se nyní na reálné aplikování těchto principů v prostředí blogů. Při výběru analyzovaných blogů byly použity osobní archiv odkazů, statistika Top100 vyhledávače Technorati (první dva) a statistika kategorie „Weblogy“ webového počitadla navrcholu.cz (první dva). Analýza kódu proběhla pomocí služby W3C Markup Validation Service (W3CV), validátoru kaskádových stylů W3C CSS Validator (W3CCSS), přístupnost byla testována službou Site Valet (SV). Doplňkově byl proveden test pro extrakci sémantiky službou Semantic Data Extractor (SDE). Analyzována byla vždy hlavní stránka bez uživatelských komentářů, které by mohly (ale správně neměly) výsledky ovlivnit v případě vložení nevalidního kódu komentujícím.

Techcrunch: Blog zabývající se internetem a novými technologiemi. Testováno 12. 4. 2008, 21.22.

  • W3CV: Použitý Doctype: XHTML 1.0 Transitional, 99 chyb – mnoho chyb způsobených nezakódováním speciálních znaků v URL adresách, ale objevují se i neplatné atributy, některé atributy scházejí úplně.
  • W3CCCS: 4 chyby.
  • SV: Stránka testem neprošla, ze zásadních chyb: chybí údaj o použitém jazyku, některé odkazy jsou otevírány do zvláštního okna prohlížeče bez předchozího upozornění uživatele, chybí textové alternativní popisy obrázků a objektů.
  • SDE: Test neproveden, nevalidní kód.

Engadget: Blog vlastněný společností AOL, zabývá se novými technologiemi. Testováno 12. 4. 2008, 23.06.

  • W3CV: Použitý Doctype: XHTML 1.0 Transitional, 164 chyb – např. není definován atribut type u javascriptových kódů, chybné kódování URL, chybějící uvozovky u atributů atd.
  • W3CCCS: 27 chyb.
  • SV: Stránka testem neprošla, ze zásadních chyb: tabulky nemají vyžadované záhlaví, chybí údaj o použitém jazyku, u některých formulářů chybí tlačítko pro odeslání, chybí metadata v záhlaví stránky (autor atd.).
  • SDE: Test neproveden, nevalidní kód.

Maxiorel.cz: Český magazínový blog o softwaru, poradenství a webových stránkách. Testováno 13. 4. 2008, 11.02.

  • W3CV: Použitý Doctype: XHTML 1.0 Transitional, 25 chyb – např. neukončené tagy, špatná sémantika (zdvojené tagy).
  • W3CCCS: Stránka je plně validní.
  • SV: Stránka testem neprošla, ze zásadních chyb: u formulářů chybí popis textových prvků pomocí
  • SDE: Test neproveden, nevalidní kód.

Marigold.cz: Osobní blog Patricka Zandla. Testováno 13. 4. 2008, 11.10.

  • W3CV: Použitý Doctype: XHTML 1.0 Transitional, 186 chyb – např. neukončené tagy, chybějící uvozovky u atributů, chybné kódování URL.
  • W3CCCS: 15 chyb.
  • SV: Stránka testem neprošla, ze zásadních chyb: chybějící záhlaví a popis u tabulek, pro formátování je užit tag font.
  • SDE: Test neproveden, nevalidní kód.

A List Apart: Magazínový blog o tvorbě www stránek. Testováno 13. 4. 2008, 11.25.

  • W3CV: Použitý Doctype: XHTML 1.0 Transitional, stránka plně validní.
  • W3CCCS: Stránka je plně validní.
  • SV: Stránka testem prošla s výhradami.
  • SDE: Sémantika byla analyzována, ovšem chybí některé navigační prvky.

Testovány byly i další náhodně vybrané blogy se stejnými výsledky. Jejich obsah ve velké většině není validní, výjimky tvoří pouze některé blogy, které se zabývají tvorbou webových stránek. V některých případech je nevalidita způsobena chybami v jed¬notlivých příspěvcích, v některých případech je nevalidní celá stránka. Nevalidita příspěvků by se snadno dala odstranit zabudováním vnitřního parseru do blogovací aplikace, jehož kontrolním mechanizmem by prošly všechny publikované příspěvky. Tím jsou nevalidní prvky buď automaticky opraveny, anebo nejsou publikovány. V případě nevalidity mimo příspěvky jde o nedbalost webmasterů, kteří zřejmě spoléhají na to, že většina prohlížečů obsah jejich blogů beztak zobrazí.

  1. Jehož hlavním posláním je vývoj standardů pro internet.
  2. Což je pak snadno „zneužitelné“ disciplínou SEO (optimalizace stránek pro vyhledávače). Je otázkou, nakolik by měl vyhledávač být strojový a nakolik by měl simulovat při posuzování důležitosti reálné zobrazení pro člověka/uživatele.

Spuštění blogu na http://dp.pleska.net

V této kapitole budou na ukázkách vlastního blogu popsány základní „stavební prvky“ blogů. Ukázkový blog využívá blogovací systém WordPress ve verzi 2.3.3 (nainstalovaný na http serveru Apache s podporou PHP a modulu mod_rewrite, jako databáze je používána MySQL).

Instalace
Instalace předpokládá správné nastavení webového serveru a záznamu typu A na jmenných serverech pro práci se zvoleným doménovým jménem (v našem případě dp.pleska.net) a přístup pro zápis do vytvořené databáze. Po nahrání souborů WordPressu na server a jednoduché editaci konfiguračního souboru pro práci s databází je uživatelem spuštěn automatický skript pro vytvoření tabulek v databázi a další nastavení (např. soubor httaccess v kořenovém adresáři serveru) a vygenerování uživatelského hesla. V případě, že vše funguje tak, jak má, není instalace – díky tomu, že je vše vytvořeno automaticky – složitá a zvládne ji každý zkušenější uživatel.

Po instalaci je možné změnit nastavení uživatele či přidat další s možností nastavení práv pro jednotlivé funkcionality blogu: Administrátor (plná práva), Redaktor (plná práva pro publikování Příspěvků, jejich editaci, správu komentářů a seznamu odkazů – blogrollů), Autor (pouze publikování Příspěvků a editace vlastních), Přispívající (pouze vložení Příspěvku do systému bez možnosti publikování, publikaci provede Administrátor nebo Redaktor), Návštěvník (přihlášení pouze pro komentáře).

Základní administrační rozhraní aplikace WordPress
Obrázek 16 – Základní administrační rozhraní aplikace WordPress

Témata, Šablony, zásuvné moduly, syndikace
V administračním rozhraní pak může proběhnout další donastavení celé aplikace ke spokojenosti uživatele. Grafická podoba blogu je spravována prostřednictvím volby Vzhled, kde lze použít motiv vzhledu (téma, Theme) vytvořený jinými uživateli (soubory vzhledu se kopírují do zvláštního adresáře na serveru) s možností jeho editace, nebo vytvořit motiv vlastní. Jednotlivá témata jsou složena z tzv. Šablon (Templates) pro jednotlivé prvky stránek blogu (např. hlavní stránka, postranní lišta, záhlaví, zápatí atd.).

Pokud jde o funkcionality, lze použít předpřipravené zásuvné moduly (Plugins – soubory je opět nutné nahrát na server) pomocí volby Pluginy, po jejich aktivaci proběhne implementace do systému. V některých případech je nutno ručně editovat Šablonu, ve které se zásuvný modul využije. V posledních verzích WordPressu je také možné užití Widgetů pro zásuvné moduly, jejich umístění do postranní lišty probíhá pomocí drag and drop funkce v AJAXu.

Úprava vzhledu editací Šablony
Obrázek 17 – Úprava vzhledu editací Šablony

Jak už bylo zmíněno, celá struktura stránek blogu je vytvářena Šablonami, které jsou ve své podstatě soubory se skripty spouštěnými na straně serveru v jazyce PHP nebo funkcemi, které jsou předpřipraveny v jádře systému. (To znamená, že uživatel není nucen například při výpisu tagů vázaných k Příspěvku použít složité SQL dotazy pro vygenerování tohoto výpisu z databáze, ale použije namísto toho připravenou funkci the_tags.) Editace Šablon (php souborů) může probíhat přímo v prostředí WordPressu nebo nahráním upravených verzí na patřičné místo v systému.
Na našem testovacím blogu byl doinstalován a „počeštěn“ vzhled Facebook Layouts Wordpress Theme 1.0 a doinstalovány tyto zásuvné moduly:

  • Addicted To Live Search – pro „živé“ vyhledávání v Příspěvcích pomocí AJAXu,
  • Akismet – pro boj s komentářovým spamem,
  • Quoter – pro možnost citování v Komentářích,
  • WP-OpenID – pro možnost využití OpenID v Komentářích a při administraci.

WordPress nativně a automaticky generuje syndikační feed Příspěvků a syndikační feed komentářů všech Příspěvků nebo jen Příspěvku jednotlivého, a to ve formátu RSS 2.0 i ATOM. V administraci systému lze nastavit, zda bude nabízen celý obsah Příspěvku nebo jen jeho část.

Stránky, Příspěvky, Rubriky, Tagy, permalinky
Obsahovou část blogu obstarávají Stránky (Pages) a Příspěvky (Posts). Stránky mohou sloužit k zobrazení statických informací (např. v našem případě O dp.pleska.net) nebo pomocí speciálních Šablon pro zobrazení jakéhokoliv obsahu (např. výpis Rubrik, výpis Příspěvků z určité kategorie – případně i externích obsahů; díky otevřenosti aplikace a jazyku PHP, jsou možnosti téměř neomezené). Speciální Stránkou je pak tzv. Hlavní stránka, kde jsou vylistovány Příspěvky ve známém reverzně chronologickém pořadí.

Úprava Stránky O dp.pleska.net
Obrázek 18 - Úprava Stránky „O dp.pleska.net“

Hlavní částí blogu jsou bezpochyby Příspěvky (Posts, někdy též Entires). Ve WordPressu máme možnost zadat Příspěvek v podobě Nadpisu a textu obohaceného o tagy značkovacího jazyka1. Tak lze publikovat i jiný než textový obsah. Příspěvek lze rozdělit na dvě části vložením <!--more-->, a tím ovlivnit podobu Příspěvku na hlavní stránce (a všude tam, kde se načítá více Příspěvků naráz, např. archivy), kde je pak zobrazena pouze jeho první část (ideálně ve formě perexu, kdy je v úvodu shrnutí celého textu).

Vložení a editace Příspěvku
Obrázek 19 – Vložení a editace Příspěvku

Každý Příspěvek je identifikován jedinečným URI (jedinečná URL adresa) – permalinkem2, který v případě dostupnosti modulu mod_rewrite serveru Apache může mít podobu vygenerovanou například z názvu či data publikování Příspěvku3. Tento typ tvoření je jednak příjemný pro uživatele, ale také má vliv při indexaci vyhledávači. Stejné URI se používá i pro vygenerování trackback adresy.
Jednotlivé Příspěvky můžeme přiřadit do Rubrik (Categories), které lze dál hierarchicky pořádat. Rubriky slouží pro další navigaci a jsou rovněž identifikovány pomocí permalinku4, po jehož vyvolání WordPress nabídne výčet Příspěvků dané Rubriky. Ačkoliv lze přiřadit Příspěvku více Rubrik, v naší ukázce odpovídají první a druhé úrovni nadpisů práce a každý Příspěvek bude zařazen právě v jedné Rubrice. Příspěvky dané Rubriky lze také odebírat pomocí syndikačních feedů.

Také Tagy (Tags)5 slouží pro další navigaci a identifikaci. Ve WordPressu byly nabídnuty poté, co po nich volali uživatelé, kterým nestačilo řazení do Rubrik a kteří chtěli více specifikovat povahu Příspěvků a další funkcionality (např. vážený tag cloud). Stejně jako u Rubrik je zde možnost permalinku s výpisem Příspěvků označených stejným Tagem6.

Pro další navigaci v Příspěvcích je možné použít Archivů (Archives), kde je využíváno datum publikace. Pokud tedy zvolíme v Archivu například rok 2008, jsou vypsány Příspěvky publikované v tomto období a podobně s měsíci.

Komentáře
Ke každému Příspěvku lze povolit možnost interakce se čtenáři pomocí Komentářů (Comments). V základní verzi WordPressu můžeme nastavit, zda mají být moderované (zda je Komentář před publikací schvalován některým z administrátorů) nebo volné. U Komentářů by bylo dobré upozornit, že v zápalu boje se spamem a nerelevantními Příspěvky se objevují metody, jak autorsky či uživatelsky hodnotit jednotlivé přispěvatele (karma uživatele). V naší ukázce jsou používány volné Komentáře a speciální zásuvný modul pro možnost citací Komentářů a zobrazení v hierarchické struktuře .

Seznamy linků
Seznamy linků (Blogroll) slouží pro informování čtenářů o zajímavých nebo spřízněných informačních zdrojích v podobě výpisu formou odkazů (většinou v postranní liště blogu). WordPress umožňuje, krom vložení názvu a URL, vložit doplňující obrázek a naznačit XFN vazbu (viz kapitola o Mikroformátech).

  1. Zde bychom upozornili, že WordPress nemá vnitřní parser pro kontrolu tagů, takže použité tagy jsou publikovány ve tvaru, jak je uživatel zadal. To je třeba mít na paměti, pokud chceme, aby generované stránky byly validní dle W3C standardů.
  2. Permalink = Permanent link.
  3. Například http://dp.pleska.net/temata-sablony-zasuvne-moduly-syndikace
  4. Například http://dp.pleska.net/category/uvod
  5. V české verzi WordPressu jsou „tagy“ překládány jako „značky“. Zde se držíme terminologie používané na jiných místech této práce.
  6. Například http://dp.pleska.net/tag/web-20