Vysoká škola ekonomická v Praze

Transkript

1 Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Katedra informačních technologií Student : Pavel Sklenář Vedoucí bakalářské práce : Ing. Luboš Pavlíček Oponent bakalářské práce : doc. Ing. Alena Buchalcevová, Ph.D. TÉMA BAKALÁŘSKÉ PRÁCE KOMPONENTOVÝ VÝVOJ WEBOVÝCH APLIKACÍ ROK : 2010

2 Prohlášení Prohlašuji, ţe jsem bakalářskou práci zpracoval samostatně a ţe jsem uvedl všechny pouţité prameny a literaturu, ze kterých jsem čerpal. V Praze dne podpis 2

3 Poděkování Rád bych zde poděkoval Ing. Luboši Pavlíčkovi za trpělivé vedení mé bakalářské práce a za cenné rady a připomínky. 3

4 Abstrakt Práce popisuje moţnosti vývoje webové aplikace a zaměřuje se na komponentový přístup při vývoji komponent do redakčního systému Wordpress. Jsou vysvětleny pojmy jako komponenta, rozhraní komponenty a komponentová architektura, aby byly posléze komponentové principy dokázány u tohoto redakčního systému srovnáním s jinou, na komponentách zaloţenou platformou Eclipse RCP. Jsou popsány principy fungování Wordpressu a v jedné z dalších kapitol jsou vysvětleny i moţnosti tvorby vlastních komponent a jejich následné nasazení. V praktické části je popsáno konkrétní nasazení systému na Vysoké škole ekonomické v Praze a jeho zhodnocení. V závěru autor navrhuje doporučení přispívající ke zlepšení současného stavu na škole. This work describes the possibility of development web applications and focuses on component approach in developing components for CMS Wordpress. There are explained a component, component interface and component architecture, that were later proven principles of this content management system compared to another, component-based platform Eclipse RCP. In one of the chapters are explained the possibilities to create custom components and their subsequent deployment, which could be problematic under certain conditions. The practical part describes the specific use of this system on The University of Economics in Prague and its evaluation. In conclusion, the author proposes recommendations of contributing to improve the present state. 4

5 Obsah Obsah... 5 Úvod Webová aplikace Bezpečnost komunikace a další rizika Moţnosti tvorby webové aplikace Psaní prostého kódu bez jakékoli další podpory Vyuţití frameworků Vyuţítí CMS pro vytváření vlastních webových aplikací Přehled CMS Komponentový vývoj Komponenta Definice komponenty Rozdíl mezi komponentou a objektem Rozhraní komponenty Komponentová architektura Vlastnosti komponent v závislosti na pouţité architektuře Nasazení komponenty v komponentové architektuře Metody a přístupy k vývoji komponentové architektury Technologické standardy pro komponentový vývoj Porovnání Eclipse RCP s redakčním systémem Wordpress Pouţití redakčního systému Wordpress Instalace Wordpressu Struktura adresáře s instalací Wordpressu Administrace Správa uţivatelů Wordpress hooks Tagy a funkce Zkratky pro funkce neboli Shortcode API Automatické zjišťování nových verzí Pluginy Tvorba vlastních pluginů Název pluginu Soubory pluginu

6 Ukládání dat pluginů do databáze Vyuţití pluginu na stránce Umístění nastavení v administrativní části Popis současného stavu redakčních systémů na Vysoké škole ekonomické v Praze Popis distribuované verze Školní pluginy Další nainstalované pluginy Úpravy v oddělení Zhodnocení současného řešení Doporučení a návrh budoucího řešení Závěr Seznam pouţité literatury Terminologický slovník

7 Úvod Webové aplikace si získávají v dnešní době stále větší popularitu díky novým technologiím, které tak přispívají k tomu, ţe tyto aplikace jsou plně interaktivní a dokáţou mnoha způsoby reagovat na činnosti uţivatele, který nečeká a má pocit, ţe se stále něco děje. Klasickým tahounem na poli webových aplikací je v dnešní době např. ová schránka na serveru Gmail 1 nebo velmi oblíbená sociální síť Facebook 2. Samozřejmě, ţe existuje i řada dalších vynikajících webových aplikací, ale tyto nejznámější dvě můţeme nazvat weby, které určují trendy a hranice, kam aţ lze ve světě webových aplikací zajít. Podle těchto trendů se řídí ať uţ přímo či nepřímo tvorba ostatních vznikajících aplikací kopírujících velmi často například vzhled a chování jednotlivých prvků na stránce. Vysoká oblíbenost webových aplikací je i z důvodu malých nároků na jejich provoz, protoţe ve většině případů si vystačíme pouze s webovým prohlíţečem. Nejsme tedy omezeni ţádnou konkrétní platformou, coţ můţe být v mnoha případech klíčové. Protoţe je pojem webová aplikace příliš rozsáhlý jak z hlediska desítek technologií, tak i oblastí, ve kterých se s nimi můţeme setkat, zaměřil jsem se ve své práci na komponentové webové aplikace, tzn. aplikace poskládané z různých částí. I komponentová webová aplikace můţe být implementována různými technologiemi, a proto jsem se ve své práci zaměřil na komponentové aplikace postavené na redakčním systému Wordpress, se kterým mám dost zkušeností a který je v kategorii redakčních systémů jeden z nejpouţívanějších a nejoblíbenějších. Pro praktickou ukázku bych uvedl jeho konkrétní nasazení na Vysoké škole ekonomické v Praze v Oddělení síťové infrastruktury Výpočetního centra, kde jsem se podílel na jeho zavedení. Moje práce by tedy měla na začátku nastínit moţnosti tvorby webových aplikací, poté bych objasnil pojem komponenta a komponentový vývoj. Dále bych chtěl na příkladu a porovnání s jinou komponentovou architekturou dokázat, ţe i systém Wordpress pouţívá komponentové principy. Na závěr bych popsal jeho nasazení na škole a doporučení, která vyplývají z mých zkušeností a znalostí získaných z literatury

8 1. Webová aplikace Webová aplikace je aplikace přístupná přes webový prohlíţeč. Díky novým technologiím jako např. AJAX (Asynchronous JavaScript and XML) vzrůstá obliba interaktivních webových aplikací, které jsou pouţitelné kdekoli, kde je k dispozici prohlíţeč. S webovými aplikacemi se tak dnes setkáváme při posílání ů z webového klienta, nakupování v internetovém obchodě nebo při nahrávání fotek do naší on-line fotogalerie. Vedle výhod v podobě ţádné nutnosti instalace klienta (webový prohlíţeč je většinou součástí operačního systému) musíme zváţit před vývojem takové aplikace i negativa, která s sebou přináší její pouţívání Bezpečnost komunikace a další rizika Protoţe veškerá komunikace klienta a serveru probíhá přes síť (většinou Internet), existuje zde reálné riziko odposlechu dané komunikace v podobě přenášených hesel nebo jiných citlivých údajů. V horším případě můţeme komunikovat s úplně někým jiným, neţ s kým chceme. Napsat konzistentní aplikaci fungující naprosto stejně napříč všemi (alespoň nejvíce pouţívanými) prohlíţeči bývá často nelehký úkol. Na vině je nejen programátor, ale hlavně různé specifikace prohlíţečů při interpretaci jazyka HTML, kaskádových stylů nebo JavaScriptu. Mezi další problémy při pouţívání webových aplikací patří i pomalost JavaScriptu, který při hojném pouţití na stránce můţe práci velmi zpomalit i na relativně silném stroji (klientském počítači). Při tvorbě aplikace je programátor omezen i skutečností, ţe uţivatel je nucen pro ovládání pouţívat převáţně myš. Pokud si i přesto si zvolíme za cíl napsat webovou aplikaci, nabízí se několik moţností, jak ji vytvořit Možnosti tvorby webové aplikace Psaní prostého kódu bez jakékoli další podpory. Tento způsob "tvorby na zelené louce" s sebou přináší výhodu psát aplikaci na míru konkrétním poţadavkům, ale obnáší také nutnost naprogramovat si i nejzákladnější prvky aplikace, jako můţe být např. práce se souborem nebo s databází. Při této variantě a špatném počátečním návrhu se můţeme zbavit moţnosti snadné rozšiřitelnosti aplikace 8

9 v budoucnu. I kdyţ můţe být aplikace zpočátku zamýšlena jako malá, časem se mohou poţadavky změnit nebo rozšířit a následná úprava můţe být dosti nákladná Využití frameworků Framework je softwarová struktura obsahující programy, knihovny nebo i návrhové vzory, které poskytují funkcionalitu celé aplikaci. Zatímco knihovny poskytují většinou pouze specifickou funkci, framework nabízí širší moţnosti pouţití a zahrnuje větší funkcionalitu. Vyuţití některého z frameworků, které jiţ nabízí knihovny a sluţby pro práci s databází, můţe pomoci programátorovi zabývat se programováním aplikace na vyšší úrovni. Frameworky se liší programovacím jazykem, ve kterém byly vytvořeny, a sluţbami, které nabízejí. V praxi se tak můţeme setkat s frameworky, které jsou zaměřeny na bezpečnost, na práci s databázemi, nebo se snaţí nabídnout celou škálu sluţeb a aţ programátor si vybere, které balíčky (komponenty) bude pouţívat. Výhody vyuţití frameworků v porovnání s předchozím způsobem vývoje aplikace jsou zřejmé, opět se ale můţeme setkat s rozšířením poţadavků na aplikaci. Můţe například později vyvstat poţadavek na implementaci uţivatelských úrovní (rolí) do aplikace. Nezbývá nám tedy nic jiného, neţ poţadovanou funkcionalitu doplnit (ať jiţ za pomoci daného frameworku, pokud to podporuje). Příklady frameworků Programovací jazyk JAVA: Většina frameworků v Javě je postavena na platformě Java EE (Enterprise Edition) nebo s ní spolupracují. Nejznámější z nich jsou JavaServer Faces, Spring nebo Struts. Společným jmenovatelem Java framworků je oddělení uţivatelského interface od aplikační logiky. Definice uţivatelského rozhraní je postavena na jazyku XML. Programovací jazyk C# a VB.NET Velmi populární způsob vytváření webových aplikací je za pomoci Microsoft ASP.NET platformy. Ta umoţňuje programátorům vyuţívat celé portfolio podporovaných jazyků z.net. Programovací jazyk PHP Velmi oblíbený a často pouţívaný jazyk pro psaní webových aplikací, i přestoţe kvůli svým charakteristikám se na rozsáhlejší projekty příliš nehodí. Nevýhody nejen v podobě příliš benevolentních pravidel při psaní kódu se snaţí částečně eliminovat frameworky. Mezi 9

10 nejznámější patří objektově orientovaný Zend Framework, robusní framework Symfony a například český Nette Framework, který je zaměřen na rychlost a bezpečnost. Ostatní jazyky Při psaní aplikace můţeme vyuţít i frameworky napsané v programovacích jazycích Perl (Catalyst), Python (framework web2py) nebo Smalltalk a JavaScript Využítí CMS pro vytváření vlastních webových aplikací CMS (Content Managment System) neboli systém pro správu webového obsahu (někdy také nazýván redakčním systémem) slouţí primárně pro publikování a správu dokumentů. Pokročilé redakční systémy obsahují nebo je moţno přidat celou řadu funkcí, jako například řízení přístupu k dokumentům (řízení přístupových práv), správu obrázků, galerií, moţnost moderování diskuzí pod obsahem stránky. Rozdíl oproti frameworkům je v tom, ţe v případě CMS jsme omezeni jeho konkrétní implementací. V praxi to můţe znamenat, ţe nemůţeme pouţívat libovolnou databázi, ale pouze např. MySQL. I samotná struktura ukládání dat je jiţ předem stanovena a máme pouze omezené moţnosti vycházející z konkrétního systému. Pokud jsme schopni akceptovat daná omezení, odměnou nám bude jiţ hotová implementace systému s okamţitou moţností pouţití. V praxi se můţeme setkat s CMS, které vyuţívají různé frameworky a jejich funkčnost z nich vychází. (např. systém DotNetNuke pouţívá.net Framework) Při vývoji rozšíření pro tyto systémy je tedy nutná i znalost práce s daným frameworkem. Moderní redakční systémy mohou být rozšířeny o mnoho komponent (často nazývány jako moduly nebo pluginy, ale vţdy se jedná o totéţ). Význam slova komponenta bude blíţe objasněn v následující kapitole. Mezi běţně dostupné komponenty pak patří statistiky přístupů, elektronické obchody nebo optimalizování pro webové vyhledávače. Tvorba sloţitějších komponent s sebou přináší i nutnost vytvořit dostatečně kvalitní prostředí pro jejich integraci do systému. Některá CMS jsou dnes proto povaţována za jakýsi framework, protoţe samy o sobě jiţ nabízí mnoho sluţeb a funkcí, které mohou nově implementované moduly/komponenty vyuţívat. Moţnost tvořit vlastní kompomenty s vyuţitím funkcí nabízených redakčním systémem se proto jeví jako další moţnost psaní vlastních webových aplikací. Snadná rozšiřitelnost v budoucnu je zajištěna moţností doplnění vlastních pluginů nebo vyuţití funkcí nabízených samotným CMS. Pokud by stejně jako v předchozím příkladu vznikl poţadavek na rozšíření aplikace o správu uţivatelských účtů, řešení jiţ máme skoro hotové, protoţe většina těchto systémů jiţ správu účtů obsahuje. 10

11 Řada těchto velmi kvalitních CMS je nabízena jako svobodný software, existují však i komerční řešení implementovaná aţ podle poţadavků zákazníka. V mé práci bych se chtěl věnovat pouze open source systému Wordpress, který je zdarma dostupný ke staţení jako hotový produkt. Výhody open source řešení: Jsou zdarma. V případě rozšířených redakčních systému existuje velká jak programátorská, tak i uţivatelská základna. Přístupné zdrojové kódy a moţnost jejich editace v rámci licence, pod kterou jsou vydané. Můţeme vyuţít modulů, které jiţ jednou někdo naprogramoval. Jsou napsané většinou v programovacím jazyku PHP a vyuţívají MySQL databázi. Nevýhody open source řešení: Protoţe nejsou vyrobené na míru poţadavkům, mohou být některé příliš rozsáhlé s mnoţstvím nepotřebných funkcí. Můţe se stát, ţe některá součást systému nebude pracovat jak má. V takovém případě máme pouze moţnost zvolit si jiný CMS nebo pročítat fóra, která se věnují problémům s konkrétním systémem. Nemůţeme se obrátit na podporu s urgentním poţadavkem na vyřešení. Nemusí pokrývat všechny naše poţadavky. V případě potřeby lze právě proto tvořit vlastní moduly. U komerčních CMS by tato situace, zdůrazňuji, neměla vůbec nastat vzhledem k implementaci na míru. Zde je tvorba vlastních modulů ovlivněna ať uţ pozitivně či negativně smlouvou, ve které můţe být dána povinnost nezasahovat do programového kódu či vůbec jejich neuveřejnění zadavateli. Vývoj nemáme ve vlastních rukách, proto nám aplikace nebo celý systém můţe po čase přestat fungovat. Pokud vyuţíváme zdarma nabízený plugin, v novějších verzích se můţe změnit rozhraní a přestat fungovat. Naopak pokud si vyvíjíme vlastní pluginy, nemusí v novějších verzích CMS pracovat správně. S oběma problémy se můţeme samozřejmě setkat i v případě komerčních řešení. Není zaručena zpětná kompatibilita s našimi stávajícími aplikacemi. V případě komerčních řešení můţe být opět problém řešen povinností kompatibility vyplývající 11

12 ze smlouvy. Musíme si však uvědomit, ţe s těmito poţadavky roste i cena poţadovaného softwaru a konečnou, byť i jedinou a tím zásadní nevýhodou můţe být právě vysoká cena komerčního systému v porovnání se zdarma nabízeným softwarem. Proto je vţdy potřeba zváţit, zda výhody, které nám přináší komerční řešení, nejsou vykoupeny příliš vysokou cenou. Pro vývoj webové aplikace, u které uvaţujeme o moţnosti rozšíření do budoucna, připadá tedy pouţití frameworku nebo řešení vyuţívající CMS. Pro detailnější analýzu v následujících kapitolách jsem si vybral druhou moţnost, tedy vývoj komponent do stávajícího CMS Přehled CMS Podle databáze DMOZ 3 shromaţďující redakční systémy je 80 procent z celkového počtu napsáno v programovacím jazyku PHP. Většina z nich pouţívá databázi MySQL a díky tomu (pokud nemají nějaké speciální poţadavky) je lze snadno nainstalovat i na běţný, zdarma nabízený webhosting. Můţeme se setkat se specifickými CMS, které se věnují například pouze blogům 4, psaním diskusních fór nebo obrázkovým galeriím. Vedle úzce profilovaných systémů existují i komplexní systémy, které jednak obsahují základní podporu pro psaní příspěvků, vkládání obrázků, ale jsou i připraveny pro další rozšiřování a přizpůsobování. Jejich funkčnost můţe být snadno rozšířena o další dostupné komponenty. Server PACKT PUBLISHING 5, který mj. vydává zatím v podstatě veškerou literaturu týkající se redakčních systémů, zvolil jako Best Open Source CMS 2009 systém Wordpress. V kategorii Hall of Fame Award 2009, tedy něco jako síň slávy zvítězily redakční systémy Joomla a Drupal. Drupal navíc získal cenu Best Open Source PHP CMS 2009, coţ můţe být volně přeloţeno jako velmi kvalitně udělaný systém v jazyce PHP. 3 nt/ 4 Aplikace zobrazující příspěvky jednoho nebo více autorů většinou v chronologickém pořadí

13 Krátce bych zmínil jejich hlavní přednosti: Drupal Naprogramován v jazyce PHP umoţňuje pouţívat nejen MySQL databázi, ale i PostgreSQL a plánu je i databáze Oracle. Drupal je známý pro svoji přehlednost v kódu a otevřenost svého API (rozhraní pro další moduly). Joomla Další z oblíbených redakčních systémů umoţňující na základní kostře postavit např. zpravodajský portál, internetový obchod nebo rezervační systém. O velké uţivatelské základně svědčí její lokalizace do 50 jazyků včetně češtiny. Wordpress Původně blogovací systém napsaný v PHP vyuţívající MySQL se stal díky rozšiřitelnosti v podobě komponent, zde nazývané jako pluginy, velmi oblíbenou variantou při vytváření webových aplikací. Díky systému trvalých odkazů, dodrţování standardů XML, XHTML a CSS, moţnosti pingback 6 a trackback 7 je velmi dobře hodnocen nejen mezi uţivateli, ale i mezi webovými vyhledávači, které ho tak řadí na první místa ve výsledcích hledání. Další předností je i snadná instalace, údrţba a moţnost automatické aktualizace celého systému. Administrátor můţe tak pomocí pár kliknutí aktualizovat nejen Wordpress, ale i všechny nainstalované pluginy společně. Pokud k tomu připočteme moţnost vytváření vlastních vzhledů, máme tu nejen skvělý blogovací nástroj, ale i systém potencionálně pouţitelný pro firemní weby. Server Technorati.com 8 udrţuje pravidelně aktualizovaný seznam 100 nejlepších 9 blogů celosvětově. Ze seznamu vyplývá, ţe 27 blogů z celkového počtu vyuţívá Wordpress a tím se tato platforma umístila jednoznačně na prvním místě. Zajímavé je, ţe pouze 8 blogů ze 100 vyuţívá vlastní systém. Jaké konkrétní weby se umístily na špici uţ tak zajímavé není, protoţe se jedná o cizí weby. Pro příklad, jakým způsobem lze získat popularitu a dostat se na přední příčky, mohu uvést, ţe na druhém místě je v tuto chvíli server Gizmodo 10 6 Redakční systém shromaţďuje weby (stránky), které se na naši stránku odkazují. 7 Podobné jako u pingback, méně odolný vůči spamu K určení pořadí pouţívá vlastní metriku, která mj. zahrnuje mnoţství odkazů zvenčí na daný blog, mnoţství diskuzí a je vyjádřena na stupnici

14 uveřejňující pravidelně novinky převáţně ze světa mobilních technologií. Popularitu mu nepochybně i přineslo předčasné zveřejnění nové podoby mobilního telefonu iphone od firmy Apple, kdy se nenašel snad ţádný domácí zpravodajský server, který by tuto zprávu s odvoláním na server Gizmodo nezveřejnil. Wordpress pouţívá i Vysoká škola ekonomická v Praze pro jednotlivé fakultní weby, proto bych se chtěl dále věnovat pouze tomuto systému a ukázat moţnosti tvorby komponent do tohoto systému. 14

15 2. Komponentový vývoj Komponentový vývoj přímo souvisí s cílem mé práce, tedy bliţšího prozkoumání redakčního, na komponentách zaloţeného systému Wordpress. V této kapitole bych chtěl proto blíţe definovat komponentu a moţné přístupy k jejich vývoji a aţ poté se věnovat samotným komponentám ve Wordpressu Komponenta Definice komponenty V softwarové oblasti se pouţívá pojem komponenta v mnoha souvislostech. Často je pouţívána ve smyslu dílčí část neboli součást. Také bývá dávána do souvislostí s jejími vlastnostmi, tedy moţnost sestavení a výměny. Různé definice komponenty: Komponenta je kus zkompilovaného kódu nabízející službu určitého druhu. [1] V metodice RUP se pod pojmem komponenta rozumí zapouzdřená, v ideálním případě netriviální, nezávislá a vyměnitelná část systému, která plní svoji funkci v rámci předem definované architektury. [2] Komponenta je fyzický kus implementace systému, zahrnujícího programový kód (zdrojový, binární nebo spustitelný) či jeho ekvivalenty jako skripty nebo příkazové soubory. [3 str. 29] Komponenta je netriviální, téměř nezávislá a nenahraditelná část systému, plnící funkci v kontextu stanoveném architekturou. [4 stránky 42-50] Softwarová komponenta je jednotka z celku s určitým vyspecifikovaným rozhraním a jednoznačnými závislostmi. Softwarová komponenta může být nasazena nezávisle a tím podléhat kompozici od třetí osoby. [5] Komponenta je část systému a zároveň jednotkou designu, konstrukce, konfigurace, řízení a substituce. [6 str. 2] Softwarová komponenta je dynamicky svázaný balík jednoho nebo více programů, daných do jednoho celku v jednotku, která je přístupná přes zdokumentovaná rozhraní, která mohou být volána za běhu programu. [7] Komponenta je znovupoužitelný softwarový balíček, který je nezávislé vyvinutý a může být kombinován s ostatními komponentami, aby vznikly větší jednotky. [8] Komponenta je definovaná jako nejmenší samostatně fungující nezávislá část systému, který může být nasazena v různých prostředích. [9 str. 13] Business komponenta jako softwarová implementace anonymního business konceptu nebo procesu, která se skládá ze softwarových artefaktů nezbytných pro jejich reprezentaci, implementaci a nasazení. [10] 15

16 Komponenta je modulární jednotka systému se zapouzdřeným obsahem, který je dostupný přes rozhraní. Jako samostatná jednotka je během svého běhu vyměnitelná. [11] Různé definice mají společnou snahu definovat komponentu jako zásuvný objekt, jehoţ struktura a chování se odvíjí od pouţité technologie. Historický vývoj komponent začal pouţíváním grafických doplňků pouţitelných v různých kombinacích beze změny jejich zdrojových kódů. Komunikace mezi komponentami probíhá přes volání procedur. Příkladem technologie vyuţívající popsané principy je Java Beans. O krok dále jsou komponenty vyvinuté ze samostatných aplikací, které získaly API (Application Program Interface) pro vzdálené volání komponenty. Umoţňuje to psaní komponent v různých jazycích a přidělení vlastního vlákna procesoru pro jednotlivé komponenty. V tomto případě komunikace mezi komponentami probíhá na úrovni operačního systému. Příkladem technologií vyuţívajících API pro své komponenty můţe být COM (Component Object Model), OLE (Object Linking and Embedding), Apple Events nebo Unix pipes. Nejpokročilejší jsou v tomto směru distribuované komponenty pracující na různých strojích v různých lokalitách. Komunikace probíhá přes síť většinou s vyuţitím protokolu TCP/IP na spodní vrstvě v kombinaci s tradičními protokoly na horní vrstvě, např. protokolu FTP. Další moţností je vyuţití RMI (Remote Method Invocation), která umoţňuje volat vzdálené komponenty a jejich procedury jako by byly místní. Při komunikaci se také vyuţívá protokol TCP/IP, ale na vyšší vrstvě jsou pouţity vlastní protokoly jednotlivých technologií. Příkladem takové technologie můţe být Java RMI, která pro komunikaci pouţívá vlastní protokol JRMP (Java Remote Method Protocol). Novější verze Java RMI se nazývá RMI/IIOP. Prakticky jde o RMI přes protokol IIOP (Internet Inter-Orb Protocol) a má za cíl kompatibilitu při komunikaci a spolupráci s platformou nezávislým systémem CORBA (Common Object Request Broker Architecture), který vyuţívá distribuované, objektově orientované aplikace Rozdíl mezi komponentou a objektem Komponenta má některé podobné vlastnosti s objekty, a proto bývají tyto dva pojmy občas zaměňovány. Komponenty i objekty poskytují své sluţby přes rozhraní a své vnitřní implementace mají ukryty. Komponentový vývoj má být další krok v přístupu k vývoji po objektově orientovaném programování [12]. 16

17 Szyperski [5] uvádí, ţe komponenty přichází k životu skrze objekty, protoţe obsahují jednu nebo více tříd či statických objektů. Tento vztah ovšem nemusí být klíčový a v komponentách můţeme najít i jiné odlišnosti od tříd. Komponenty mohou být například realizovány jako více objektů z různých tříd. Komponenty navíc vyuţívají stálá úloţiště dat (soubory, databáze), objekty naopak vyuţívají pro svá data výhradně hlavní paměť určenou pro běh aplikace. Komponenty mohou obsahovat tradiční procedury, globální proměnné realizované nejen pomocí objektového přístupu, ale i funkcionálního [13]. Z toho plyne, ţe komponenta můţe být implementována pomocí jedné nebo více tříd, které jsou součástí objektového programování, nebo tradičními procedurami s pouţitím neobjektově orientovaného programovacího jazyka. Komponenty mají navíc všeobecně širší sadu dorozumívacích mechanismů, objekty vyuţívají většinou pouze mechanismus zaloţený na posílání zpráv jednotlivým (konkrétním) objektům. V definici UML (Unified Modeling Language) standardu [14] mají komponenty mnoho společného s třídami, existují však i určité rozdíly: Třídy představují logickou abstrakci, komponenty jsou spíše fyzická záleţitost. Komponenty představují fyzické zabalení logických elementů a jsou proto na jiné úrovni abstrakce neţ třídy. Třídy mají atributy a operace přístupné přímo, komponenty mají operace přístupné pouze přes rozhraní. Třída můţe být komponentou tehdy, pokud splňuje pravidla pro pouţití v nějaké komponentové technologii. Je tedy zřejmé, ţe i přes mnoho podobností nacházíme několik zásadních rozdílů a konfliktů mezi komponentami a objekty. Ve skutečnosti je ale opak pravdou, protoţe objektově orientovaná analýza, návrh a implementace se velmi často pouţívá při vývoji komponent Rozhraní komponenty Rozhraní komponenty umoţňuje její pouţití i přes neznalost její implementace. Rozhraní tak separuje vnitřní a vnější část a při pouţití komponenty se ptáme pouze, co dělá, ale ne jak to dělá. Vnitřek komponenty je skrytý a není důleţitý pro její nasazení. Nejdůleţitější jsou sluţby, které komponenta poskytuje navenek. 17

18 V UML je rozhraní definováno jako pojmenovaná kolekce operací použitých ke specifikaci služeb třídy nebo komponenty. [14] Szyperski [5] definuje rozhraní jako specifikaci přístupových bodů komponenty. Klienti přistupují ke sluţbám skrze definované přístupové body. Pokud komponenta nabízí více přístupových bodů, nabízí tím i více sluţeb a má tudíţ i více rozhraní. Je důleţité podotknout, ţe rozhraní nenabízí ţádnou z implementací jeho sluţeb. Poskytuje pouze seznam dostupných operací s jejich jmény a definicemi. Toto umoţňuje změnu vnitřní implementace komponenty beze změny rozhraní a celého systému vyuţívajícího tuto komponentu. Dle [13] můţeme rozlišovat dva druhy rozhraní. Komponenta můţe nabízet nebo naopak poţadovat rozhraní ve vztahu k systému, ve kterém běţí a který můţe zahrnovat i další komponenty. Poskytované rozhraní reprezentuje sluţby a operace poskytované systému. Naopak poţadované rozhraní ukrývá sluţby a operace, které komponenta poţaduje pro svůj běh. Poţadované rozhraní nemusí být uspokojeno pouze systémem, ale i jinou komponentou, na které tím vzniká závislost a je nutná její bezpodmínečná přítomnost v systému pro správnou funkčnost instalované komponenty. Pro popis rozhraní se pouţívají speciální jazyky Interface Definition Language (IDL). Pro platformu COM je to například Microsoft Interface Definition Language 11. Podle [12] jsou nejdůleţitější elementy definované v rozhraní následující: Názvy dostupných operací Jejich parametry Přijatelné typy parametru Szyperski [5] zmiňuje ještě nutnost standardizace komunikačních zpráv, schémat a protokolů z důvodu různých kombinací vyuţívání internetových (IP, UDP, TCP, SNMP a dalších) a webových (HTTP, HTML) standardů. Pro dosaţení sémantické jistoty a jednoznačnosti zasílaných zpráv je vhodné vyuţít XML formátu, který umoţňuje i vyuţití schémat pro kontrolu validity zpráv. Validace je proces ověření shody XML dokumentu nebo XML zprávy se schématem. Umožňuje odhalit nekonzistenci dat, které by pak mohly vadit při dalším zpracování. [15]

19 Komponentová architektura Koncept komponent, jejich skládání, nebo naopak rozklad a pouţití rozhraní dává za vznik komponentové architektury. Stojanovic [13] definuje komponentovou architekturu jako organizovanou strukturu a k ní asociované chování, kdy je moţné celý systém rekurzivně rozloţit na části (komponenty) komunikující spolu pomocí rozhraní. TOGAF (Open Group Architecture Framework) 12 definuje architekturu dvěma způsoby podle kontextu [16]: Formální popis systému nebo jeho detailní plán na komponentové úrovni pro pochopení implementace celého systému. Struktura komponent, znázornění vztahů mezi nimi, principů a pravidel pro jejich návrh a vývoj v budoucnu. V materiálech [2] o metodice RUP (Rational Unified Process) zaměřených na popis vývoje komponentové architektury je architektura definována jako sada významných rozhodnutí o organizaci softwarového systému, výběru dílčích komponent a jejich rozhraní, ze kterých se systém skládá. Společně s jejich chováním je specifikována spolupráce mezi komponentami, jejich skládání ve větší podsystémy Vlastnosti komponent v závislosti na použité architektuře Podle [13] můţeme rozdělit vlastnosti komponent na základní a pokročilé. Základní vlastnosti jsou konkrétní komponentovou technologií vyţadovány, pokročilé naopak u moderních komponent očekávány. Komponentové technologie vyuţívají při svém návrhu a vývoji komponentovou architekturu. Základní vlastnosti: Nezávislost pouţití - komponenta je spjata s konkrétní technologií a v rámci této technologie je vyměnitelná. Definované rozhraní - kapitola Uznávaný mezinárodní standard pro řízení Enterprise architektury 19

20 Znuvupouţitelnost - komponenta je pouţitelná v různých systémech, které však pouţívají stejnou komponentovou technologii a stejnou architekturu (např. klientserver) Některé pokročilé vlastnosti Umoţnit tvorbu balíčků poskládaných z různých komponent (zvyšuje se znuvupouţitelnost) Snadnost nasazení - komponenta můţe být nasazena, pokud existuje definovaný postup pro její individuální sestavení, nastavení, instalaci a pouţití. Moţnost nasazení v jednom systému vícekrát, pokaţdé s jinou úlohou. Interoperabilita - pokud komponenta vyuţívá standardní mechanismy, např. pro výměnu dat, můţe snadno komunikovat i s jinými komponentami a systémy. Mezi vlastnostmi můţeme nalézt několik implikací. Pokud má být komponenta nezávisle nasaditelná, měla by být zároveň i dobře oddělitelná od prostředí, ve kterém běţí, a od ostatních komponent. Pokud má být komponenta nasazená v prostředí třetí strany (stále však v rámci jedné architektury), měla by být dostatečně samostatná s jednoznačnou definicí poţadavků na běh a definicí poskytovaných sluţeb Nasazení komponenty v komponentové architektuře Nasazení komponenty neboli deployment je jednou z klíčových vlastností při pouţití komponentové architektury. Jde vlastně o integraci jednotlivých komponent do systému. Uţ při vývoji by měl být proto kladen důraz na aktivity spojené s nasazením komponenty do systému tj. [17]: Vydání jde o shromáţdění všech potřebných instalačních, konfiguračních a ostatních souborů potřebných pro instalaci do systému. Instalace konfigurace a sestavení všech příslušných úkonů potřebných pro běh komponenty v konkrétním systému a zaevidování do tohoto systému. Aktivace úkon, kterým se komponenta stane pouţitelná. Kontroluje se například, zda jsou uspokojeny závislosti na jiných pluginech. Deaktivace uvolnění všech pouţívaných zdrojů systému a uvedení do stavu, kdy nemůţe být komponenta pouţita. 20

21 Rekonfigurace změna v nainstalované/aktivované konfiguraci dle vlastních poţadavků. Adaptace změna v nainstalované/aktivované konfiguraci dle změn v prostředí systému, ve kterém je nasazena. Aktualizace změna v nainstalované verzi komponenty se zachováním původních nastavení Odinstalace odebrání nainstalovaných součástí ze systému. Odebrání vydání komponenty se stane nedosaţitelné. Součástí nasazení komponenty jsou i jednoznačně definované závislosti, neboli poţadovaná rozhraní. [5] Komponenta poţaduje jinými slovy určité sluţby a operace po prostředí, ve kterém je (má být) nasazena. Závislosti mohou být uspokojeny buďto samotným systémem nebo dalšími nainstalovanými komponentami. Samotná instalace je tak provedena ve dvou fázích (Obrázek 1) [18]. První fáze ověří, zda je instalace moţná ověřením závislostí na komponentách (D) v konkrétním prostředí (C). Tato fáze zajistí tedy validitu výrazu C+D v prostředí instalovaného systému. Pokud je instalace moţná, přecházíme do druhé fáze, vlastní instalace, ve které je ovlivněno vlastní prostředí systému (C ), a proto je nutná jeho aktualizace. Obrázek 1: Instalační fáze [18] 21

22 Obrázek 2: Nasazení komponenty [19] 2.2. Metody a přístupy k vývoji komponentové architektury I přestoţe jsou technologie nezbytnou součástí jakéhokoli řešení, samy o sobě nestačí. Nutné jsou i metody a techniky pro vývoj komponentních aplikací vycházejících z obchodních poţadavků. Při vývoji systému nebo jako v našem případě webové komponentové aplikace je nutné, aby byly na úvod stanoveny základní poţadavky na systém z pohledu managmentu, uţivatelů a v neposlední řadě moderních trendů. Je tedy nutné si stanovit, jak by měla výsledná aplikace vypadat [20]: cíle systému (co má aplikace, komponenta vykonávat) všechny uţivatelské poţadavky podporující dosaţení stanovených cílů integrace o o datová - jednou uloţená data by měla být dostupná v rámci celého systému, nemělo by docházet k zbytečné redundanci dat. softwarová - jednotlivé komponenty by měly být vzájemně propojeny v rámci navazujících procesů a naopak je také ţádoucí se vyvarovat zbytečné závislosti v rámci implementace, aby nebyla porušena podstata komponentové architektury. 22

23 o hardwarová - jednotlivé hardwarové komponenty by měly být propojitelné např. v rámci celopodnikové sítě. otevřenost systému - architektura by měla snadno akceptovat parametrické změny nebo změny v podobě nových komponent. aplikace by měla být snadno pochopitelná pro uţivatelskou sféru, design zaměřený na uţivatele. Architektura tedy představuje celkový koncept budoucího systému. Zachycuje jednotlivé komponenty a jejich vazby. Podle úplnosti a oblasti pokrytí jednotlivých dimenzí se rozlišuje na architekturu sluţeb, aplikační a technologickou architekturu [21]. Definování architektury a její následná dokumentace usnadňuje nejen samotný vývoj ale i znovupouţití navrţeného designu a vzorů v budoucích projektech. Jednou z mnoha metodik zajišťujících pokrytí výše uvedených bodů s důrazem na komponentovou architekturu je např. metodika Rational Unified Process (RUP) nebo Select Perspective Technologické standardy pro komponentový vývoj V současné době je k dispozici několik implementačních modelů pro vytváření komponentové architektury. Modely jsou často nazývány jako komponentový middleware nebo implementační standardy pro komponenty, které definují sadu norem pro implementaci, pojmenovávání, efektivní spolupráci uvnitř systému, individuální změny, kompozici, vývoj a nasazení. [12] Zahrnuje i standardy pro definici rozhraní a spolupráci s ostatními komponentami. Mezi oblíbené komponentové implementační modely patří Microsoft COM+/.NET a Enterprise Java Beans (EJB) od firmy Sun nebo velmi obecný CORBA Components [13]. Zatímco zmíněné implementační modely jsou velmi rozsáhlé a dosti obecné (ať uţ úplně, nebo z větší části), existují i konkrétnější řešení pro psaní aplikací. Příkladem můţe být Eclipse RCP (Rich Client Platform) nebo Netbeans RCP, které mají např. k systému Wordpress o poznání blíţe, proto jsem si na komponentách zaloţenou platformu Eclipse RCP vybral pro porovnání s tímto redakčním systémem, abych tím dokázal komponentový přístup i v systému Wordpress. 23

24 2.2. Porovnání Eclipse RCP s redakčním systémem Wordpress Open source platforma Eclipse RCP vznikla v roce 2004 původně z Java IDE (vývojové prostředí pro psaní Java aplikací). Aby si vývojáři zjednodušili práci, vytvořili si z něj Framework IDE, tedy framework pro psaní vývojového prostředí. Poté jiţ vznikl Application Framework (framework pro psaní aplikací), tedy výsledná RCP platforma a v současné době je IDE distribuován pouze jako modul. Vytvořená aplikace je tak poskládána ze znovupouţitelných komponent, které jsou součástí platformy (např. správce oken), a z komponent, které jsou charakteristické pro konkrétní účel aplikace (např. komponenty pro zdravotnictví, školství apod.). Wordpress má s Eclipse RCP společné nejen datum vzniku (také 2004), ale i mnoho principů komponentového přístupu. I přesto, ţe systém Wordpress není ještě tak vyzrálá platforma jako Eclipse, můţeme jej s trochou nadsázky nazvat také aplikačním frameworkem, který nám pomáhá při tvorbě našich aplikací. Jeho rozsáhlá základna nám poskytuje mnoho funkcí, které můţeme vyuţít pro psaní dalších komponent a ve výsledku nové aplikace. Rozdíl mezi oběma platformami ukazují následující 2 obrázky. Obrázek 3: Princip Eclipse RCP [22] 24

25 Obrázek 4: Princip systému Wordpress V Eclipse RCP vidíme, ţe i samotná platforma se skládá z několika komponent. Pravdou je, ţe je nutné mít alespoň nainstalované a aktivované dva základní pluginy [23] (org.eclipse.ui a org.eclipse.core.runtime). Ve Wordpressu působí základní platforma jako jeden celek, i kdyţ je zřejmá její implementace s pouţitím všech funkcí a sluţeb, které platforma nabízí i pro komponenty (pluginy). Můţe to být proto pouze mezikrok k fungování na stejném principu, jako u platformy Eclipse, tj. moţnost poskládat si základní systém dle svých potřeb a vynechat tak například jeden z moţných budoucích pluginů Správa uţivatelů, Psaní komentářů, které jsou teď přímo součástí instalace (ne v podobě samostatných pluginů). V obou platformách je tedy moţnost doinstalovat si komponenty vlastní nebo od třetích stran. Eclipse RCP pro správu komponent pouţívá vlastní implementaci standardu OSGi 13 pod názvem Equinox a nabízí navíc oproti Wodpressu následující sluţby: Komponentě nabízí moţnost definovat poţadovanou verzi komponent, na kterých je daná komponenta závislá. Při aktivaci komponenty se automaticky nahrají i komponenty, na kterých je daná komponenta závislá (Pokud jsou k dispozici)

26 Lze jednoznačně definovat třídy a funkce, které budou viditelné ostatním komponentám. Obě platformy nabízí řešení pro případ, ţe chceme, aby dvě libovolné komponenty, které o sobě neví, spolu mohly spolupracovat. Například existuje komponenta, ve které můţe uţivatel něco vybírat, a komponenta, která na výběr reaguje. První komponenta proto začne vysílat nějakou událost a druhá z komponent se k této události registruje a naslouchá. Samozřejmě naslouchající komponenta musí oznámeným událostem rozumět. Shodně jsou také na tom Wodpress a Eclipse v moţnostech, jak přidat novou poloţku do některého z existujících (nebo i nového) menu. V obou případech můţe jedno menu obsahovat poloţky z různých pluginů a lze určovat i jejich pořadí. Rozdíl je pouze v tom, ţe ve Wordpressu nelze definovat na poloţku různé akce dle aktuálního kontextu. Smysl by to mělo například tehdy, pokud bychom měli v administraci klasické menu Soubor, ve kterém by bylo tlačítko Smazat. Pokud bychom měli aktuálně otevřené komentáře, tímto tlačítkem by se dal smazat komentář. Pokud bychom měli právě otevřený seznam našich příspěvků, stejným tlačítkem Smazat bychom mohli smazat i příspěvek. Samozřejmě, ţe se jedná o ukázkový příklad, ale moţnost vyuţít kontext by byla přínosem i v jiných případech. Jednou z hlavních výhod Eclipse RCP oproti CMS Wordpress, která ale přímo nesouvisí s pokročilostí implementace komponentových principů, je přítomnost vlastního vývojového prostředí (jako jedné z moţných z komponent) pro tvorbu např. vlastních pluginů. Z menu pouhým kliknutím myši můţeme vytvořit plugin, jehoţ vývojem nás provede přítomný vizuální průvodce. Během několika okamţiků tak můţeme pracovat na konkrétní implementaci poţadovaných funkcí a nemuset se zaobírat implementací vedlejších úkonů, jako např. instalace a aktivace komponenty apod. V případě Wordpressu jsme odkázáni na některý z PHP editorů, které nejsou většinou tak vyspělé 14 jako vývojová prostředí pro jazyk Java a v kaţdém případě si musíme vţdy celý kód napsat sami. 14 Mám zkušenosti s Eclipse PDT ( a Netbeans s PHP modulem ( Obě prostředí by měla patřit ke špičkám na trhu, avšak nenabízí tolik komfortu např. při krokování atd. 26

27 3. Použití redakčního systému Wordpress Wordpress stejně jako ostatní CMS pomáhá snadno vytvářet a aktualizovat obsah webových stránek. Funkčnost systému můţe být rozšířena o mnoţství pluginů, které si buďto sami vytvoříme nebo vyuţijeme a pouţijeme jiţ hotového pluginu staţením z globálního úloţiště Instalace Wordpressu Jak uţ bylo řečeno v přehledu CMS, Wordpress vyniká jednoduchou instalací. Poţadavky na provozování Wordpressu jsou velmi základní. Server pro verzi Wordpressu 2.9 by měl minimálně podporovat: PHP ve verzi 4.3 nebo vyšší (doporučena je verze 5.2 a vyšší nejen z důvodu vyšší bezpečnosti) MySQL databáze ve verzi nebo vyšší (doporučena verze 5.0 a vyšší) Pro samotnou instalaci potřebujeme přístup (např. pomocí protokolu FTP) k webovému adresáři pro nakopírování sloţek a souborů, které jsme si předtím stáhli ze stránek Wordpress.org 16. Pokud chceme provozovat web na doméně stačí nakopírovat soubory do kořenového adresáře webového serveru. Pro konfiguraci můţeme buď přejmenovat soubor wp-config-sample.php na wp-config.php a zeditovat jej (doplnit především přihlašovací údaje k databázi), nebo vygenerovat konfigurační soubor z webu, v našem případě na adrese V konfiguračním souboru jde mj. i nastavit jazyk nebo vynutit, aby administrativní rozhraní komunikovalo přes zabezpečený protokol HTTPS. Posledním krokem je otevření adresy na které dojde k dokončení instalace (vytvoření tabulek v databázi a vloţení dat) Struktura adresáře s instalací Wordpressu Kořenová sloţka obsahuje vedle souborů jako např. index.php i tři sloţky. wp-admin sloţka se soubory pro administrativní rozhraní

28 wp-content důleţitá sloţka obsahující sloţku s pluginy a sloţku s tématy (vzhledy). wp-includes sloţka s knihovnami, které jsou v různých částech Wordpressu pouţívány. Výchozí instalace obsahuje dva pluginy: akismet modul chránící náš web před spamem. hello ukázkový plugin s velmi typickou hláškou Hello World. Výchozí ukázková témata jsou také dvě, ale samozřejmě se předpokládá pouţití vlastních. Témata slouţí pro potřeby aplikace vlastního vzhledu na provozovaný web. Během okamţiku tak můţe být web vzhledově stylizovaný do podoby odpovídající jeho obsahu. Obrázek 5: Struktura adresáře s instalací Wordpressu 28

29 3.3. Administrace Z administrativního rozhraní máme moţnost psát příspěvky na web, měnit vzhled webu, instalovat a nastavovat pluginy nebo zakládat nové uţivatele. Moţnosti vkládání příspěvků obsahujících obrázky, hudbu či dokonce video nejsou témata mojí práce. Stejně tak zde není prostor pro popis, jakým způsobem fungují jednotlivá témata a jakým způsobem si lze vytvořit vlastní. Proto bych se chtěl z této oblasti zmínit krátce pouze o uţivatelských právech v administrátorské části, které se dají vyuţít i při tvorbě pluginů Správa uživatelů Nastavení práv ostatně souvisí i s aplikacemi, které na webu poběţí. Za uţivatele nebudu v následujícím textu (pokud neuvedu jinak) povaţovat návštěvníka webové stránky, ale osoby, které mají určitá privilegia související se správou webového obsahu. Protoţe Wordpress klade důraz na snadnou obsluhu, je zřejmé, ţe vkládat a editovat stránky nemusí pouze zkušený administrátor, ale i uţivatel bez znalostí jazyka HTML. Právě z nutnosti odlišit práva jednotlivých uţivatelů na vertikální úrovni vznikly role s jiţ definovanými právy a omezeními, díky kterým například nezkušený a neznalý uţivatel nemůţe záměrně (či bez něj) poškodit fungování Wordpressu nějakým nekorektním zásahem. Přístupové úrovně a k nim uţivatelské role ve Wordpressu jsou: Administrátor Redaktor Autor Přispívající Návštěvník Administrátor je osoba, která má absolutní práva, tedy neexistuje nic, co by nemohl. V praxi jako jediný můţe měnit nastavení, aktivovat a deaktivovat plugin, zakládat a mazat uţivatele nebo měnit témata (vzhled) webu. Redaktorovi je povoleno psát vlastní příspěvky, navíc má moţnost editovat příspěvky ostatním uţivatelům, moderovat diskuzi nebo spravovat jednotlivé kategorie. 29

30 Autor můţe psát pouze vlastní příspěvky, nemůţe je v ţádném případě editovat ostatním. Přispívající má povoleno napsat příspěvek s tím, ţe před publikováním bude muset být tento příspěvek schválen administrátorem, redaktorem, nebo autorem. Návštěvník je sice registrovaným uţivatelem v administrátorské části, ale jeho práva jsou stejná s cizím návštěvníkem webu. Oba mají dovoleno pouze číst si jednotlivé příspěvky. Smysl role Návštěvník má pouze v případě, ţe chceme například někomu krátkodobě odebrat všechna práva, ale zároveň si jej uchovat jako registrovaného uţivatele. Není bohuţel moţné definovat si vlastní role. Z popisu vlastností rolí je zřejmé, ţe jednotlivé role nemají svá speciální práva, typická pouze pro ně a které by jejich nadřazená role neměla. Proto například autor má všechna práva přispívajícího a svá vlastní. Redaktor má všechna práva autora včetně svých vlastních. Administrátor má mj. právo na cokoli, co se objevilo v definici předchozích práv u jednotlivých rolí. Při psaní aplikace (v tomto případě pluginu) můţeme proto nastavit i určitá omezení, která mohou zamezit vkládání např. anket, formulářů nebo galerií s fotografiemi do stránky určitým rolím Wordpress hooks Různé funkce a pluginy potřebují pro svoji činnost moţnost reagovat na činnosti uţivatele nebo spíše na činnosti vyvolané samotným Wordpressem. Bude se jednat o jakési rozhraní vyţadované pluginem po prostředí, ve které běţí, aby mohly vykonávat svoji úlohu. V oficiálním dokumentu [24] se označují jako hooks tedy jako háčky. Ze slova je patrný tedy i jejich význam, na háčky zavěsíme naše funkce. Já bych je spíše nazval událostmi, u kterých je moţno registrovat funkce, které budou při vyvolání určité události vykonány. Wordpress pouţívá události dvojího typu: filtry filter a akce - action. Paleta jejich pouţití je opravdu široká, současná aktuální verze Wodressu obsahuje na 1142 (dle [25]) různých událostí ve formě akcí a filtrů. Pokud by nám z nějakého důvodu nestačily, můţeme si vytvořit a vyvolat vlastní události ve formě jak akcí, tak i filtrů. Filtry Filtry se pouţívají v případě, ţe chceme modifikovat základní chování Wordpressu, především se pouţívají pro modifikaci většinou textového obsahu. 30

31 Pokud bychom chtěli přidat logo ke všem titulkům u všech článků zobrazujících se návštěvníkovi, máme dvě moţnosti. Poţadovanou změnu můţeme promítnout přímo do šablony stránky s pouţívaným tématem vzhledu. Řešení je velmi jednoduché s pouţitím základních znalostí HTML, ale můţe nám to způsobit problémy v budoucnu, kdyţ bychom chtěli změnit vzhled webu změnou tématu nebo pouţívat více témat. V prvním případě bychom ztratili veškeré změny a provedené úpravy, v druhém případě bychom museli znovu zeditovat novou šablonu. Druhou moţností, jak docílit poţadované změny titulku, je vyuţití filtru, který zajistí změnu titulku před jeho zobrazením v prohlíţeči (v našem případě to bude přidání obrázku k textovému titulku). Vyuţijeme filtru s názvem the_title. Funguje tak, ţe Wordpress před posláním samotného titulku prohlíţeči k zobrazení pošle titulek kaţdé funkci registrované k události the_title. Jednotlivé funkce modifikují titulek dle vlastní implementace a vrací vţdy upravený titulek. Prohlíţeči je pak poslán výsledek zpracování všech těchto funkcí. Za určitých okolností je nutné stanovit pořadí volání jednotlivých funkcí, proto je moţné při registraci uvést i prioritu s jakou jsou volány. Definice funkce add filter pro registraci určité funkce k události [24]: add_filter( $nazev_filtru, $nazev_registrujici_funkce, $priorita, $poce t_akceptovatelnych_argumentu ); $nazev_filtru Povinný parametr typu String udává název události, ke které bude registrována funkce, v našem případě bude the_title. $nazev_registrujici_funkce Povinný parametr obsahující název funkce, ve které má být titulek před posláním prohlíţeči modifikován. Funkce by měla samozřejmě existovat a obsahovat návratovou hodnotu typu String. Tyto poţadované atributy však nejsou testovány Wordpressem, proto by mělo být na programátorovi zajistit a ošetřit případné chyby. $priorita Nepovinný parametr typu integer bývá pouţit pro upřesnění priority. Defaultní hodnota je 10, pokud chceme větší prioritu, nastavíme menší hodnotu a naopak. Funkce se stejnou prioritou jsou volány v pořadí přidání do seznamu registrovaných funkcí. 31

32 $pocet_akceptovatelnych_argumentu Nepovinný parametr typu integer definuje počet parametrů registrované funkce. Defaultní hodnota je nastavena na 1. Příklad uţití filtru následující kód lze vloţit do nového pluginu, nebo do souboru functions.php,který je umístěn ve sloţce s tématem vzhledu a při kaţdém zobrazení jakékoli stránky dojde k jeho spuštění. /* Přidání obrázku logo.gif před každý titulek */ function MujTitleFilter($title) { return <img src="logo.gif" alt="logo">.$title; } /* Registrace funkce k události */ add_filter('the_title', 'MujTitleFilter'); Příklady dalších filtrů the_content filtr je aplikován na text příspěvku před jeho zobrazením comment_text filtr je aplikován na komentář před jeho zobrazením Akce Akce jsou události vyvolané určitou činností, jakou můţe být zaloţení nového příspěvku, vloţení komentáře k příspěvku nebo změna zobrazení administrátorské stránky. Jejich pouţití je stejné jako u filtrů pouze s tím rozdílem, ţe parametr předávaný registrovaným funkcím není modifikován a slouţí pouze pro předání určité informace. Funkce nemusí proto obsahovat ţádnou návratovou hodnotu. Akce mohou být pouţívány například pro zasílání ů při vloţení komentáře k příspěvku nebo pro úpravu vzhledu Wordpressu při určité události. Definice funkce add_action pro registraci funkce k určité události typu akce: add_action( $tag, $function_to_add, $priority, $accepted_args ); Význam jednotlivých parametrům je naprosto analogický jako u funkce add_filter. Ukázkovým příkladem pouţití události akce můţe být poslání u v případě publikování nového příspěvku a jeho komentování. se bude posílat definovaným uţivatelům. 32

33 Nejprve si vytvoříme funkci, která bude posílat . Příklad uţití akce následující kód lze vloţit do nového pluginu, nebo do souboru functions.php,který je umístěn ve sloţce s tématem vzhledu a při kaţdém zobrazení jakékoli stránky dojde k jeho spuštění. //Parametr předaný událostí (ID příspěvku) function posli ($post_id){ //Seznam ů, na které se má poslat. $komu = 'muj @example.com, mujdruhy @example.com'; //S využitím funkce mail() zašleme s URL stránkou změny. mail($komu, 'Aktualizace mého blogu', 'Můj blog byl aktualizován na stránce: '.get_settings('home'). '?p='.$post_id); } Poté registrujeme tuto funkci u poţadovaných akcí: add_action('publish_post', 'posli '); add_action('comment_post', 'posli '); Jak u filtrů, tak i u akcí lze v průběhu běhu programu určitou funkci odhlásit z odběrů těchto událostí. Je důleţité poznamenat, ţe pokud ve funkci add_action/add_filter uvedeme více parametrů jako například prioritu nebo počet argumentů, je nutné při odhlašování uvést opět tyto všechny parametry ve volání funkce remove_action/remove_filter. Můţeme také globálně aktivovat/deaktivovat spouštění událostí určitého typu Tagy a funkce Často je potřeba v tématu nebo i v pluginech získat dynamické informace týkající se aktuální stránky nebo statické informace ohledně celého webu. Pro tyto případy Wordpress definuje tzv. tagy, které usnadňují přístup spíše ke statickým proměnným a funkce pro přístup k dynamickým proměnným. Příklady tagů [24] get_header(), get_footer() při zavolání vloţí záhlaví/zápatí na místo, odkud byla funkce volána. Zjednodušeně jde o vloţení obsahu souboru header.php/footer.php umístěného ve sloţce s tématem vzhledu. 33

34 bloginfo('name'), bloginfo('url') vloţí název/url adresu blogu. the_time(get_option('date_format')) vypíše aktuální čas dle formátu nastaveného v administraci. wp_list_pages($args) vypíše seznam stránek, pomocí argumentu můţeme specifikovat určitá omezení týkající se např. zobrazení autora stránky, data vytvoření. Můţeme také určit stránky, které se nezahrnou do výpisu. is_admin() zda je zobrazena stránka s administrací. Příklady funkcí [24] get_post_meta($post_id, $key, $single) získání meta dat k příspěvku pomocí ID a názvu proměnné. Třetím parametr parametrem si můţeme určit, zda chceme vrátit data v poli, nebo v řetězci. get_page_uri( $page_id ) získání URI adresy konkrétní stránky. is_page($page) V systému Wordpress můţeme vkládat buďto statické stránky nebo příspěvky, které mohou být dynamicky přiřazeny určitým kategoriím. Funkce is_page vrací boolean hodnotu true v případě, ţe je právě zobrazena stránka. Zajímavostí u této funkce jsou moţnosti pouţití parametru. Parametr můţe obsahovat id stránky, její titulek, nebo její jedinečný název (post_name) Zkratky pro funkce neboli Shortcode API Zkratky pro funkce v podstatě znamená něco jako zkratky pro volání k nim přiřazených metod. Pouţívají se při editaci jednotlivých příspěvků a jejich přítomnost je v podstatě nutností, protoţe z principu bezpečnosti není moţné vkládat do příspěvku vedle obyčejného textu i kód php. Zásadní nevýhodou je omezení pouţití pouze na editaci obsahu příspěvku (z editoru). Zkratky nemůţeme pouţít ve vlastním PHP kódu (například při definici šablony vzhledu), zde se musí i nadále pouţívat klasické volání metod. Pokud bychom vytvořili aplikaci generující fotogalerii, můţeme ji poté vloţit do příspěvku následujícím kódem [gallery id="123" size="medium"]. 34

35 Definice vlastní zkratky: //Neprve definujeme funkci pro zobrazení fotogalerie function ZobrazFotogalerii($atts) { //Vnitřní implementace funkce, zobrazující jako výstup fotogalerii } //Přidání zkratky do evidence add_shortcode('gallery', 'ZobrazFotogalerii'); Pokud značka není zanesena do systému, nebude zpracována a bude vytištěna jako slovo Automatické zjišťování nových verzí Systém Wordpress uţ dlouho nabízí automatické oznamování o nové verzi u nainstalovaných pluginů a samotného systému. V posledních verzích přibyla i moţnost automatické aktualizace těchto součástí systému. V dotazech se porovnává naše verze s aktuální verzí dostupnou na webu. Bohuţel neexistuje ţádná dokumentace a podle oficiálního webu 17 se dokumentace připravuje. Ze zdrojových kódů jsem však zjistil, ţe pomocí HTTP ţádosti se odešle na server api.wordpress.org data, ve kterých je obsaţena verze nainstalovaného systému. Komunikace probíhá v obou směrech metodou POST 18. Detailnější pohled na systém automatického zjištění nové verze bude uveden v následující kapitole o pluginech. Proces zjištění aktuální verze systému je stejný jako zjišťování nové verze u jednotlivých pluginů Pluginy Pouţívání pluginu v sobě zahrnuje několik činností, které jsou nutné pro správné fungování nejen samotného pluginu, ale i celého systému. Jedná se především o proces instalace, aktivace, deaktivace a odinstalování. Kvalitní zpracování uvedených procesů má za výsledek stabilitu systému při chybách, které mohou vzniknout při instalaci, pouţívání či odinstalaci pluginů Vedle metody GET je to další metoda poţadavku HTTP protokolu. Slouţí pro předávání a výměnu dat. 35

36 Instalace pluginu Instalací libovolného pluginu není myšleno nic jiného, neţ nakopírování sloţky s pluginem, popř. souboru do sloţky wp-content/plugins. Wordpress sloţku s pluginy prochází pokaţdé, kdyţ administrátor načte stránku v administrátorském rozhraní se seznamem pluginů. Nově nainstalovaný plugin se objeví mezi neaktivními. Jeho pouţití není v tuto chvíli ještě moţné a jeho načtení mezi ostatní pluginy neznamená, ţe je se současnou verzí Wordpressu kompatibilní a bude fungovat. Ověření, zda je plugin schopen pracovat se ověřuje aţ při aktivaci. Aktivace pluginu Aktivací přejde plugin do stavu pouţitelného a fungujícího. Při aktivaci dochází: Ke kontrole poţadované verze Wordpressu. K inicializaci tabulek, které plugin bude vyuţívat, v databázi. K inicializaci dalších bezpodmínečně nutných náleţitostí pro chod pluginu, např. vytvoření sloţky pro pluginem nově vytvářené soubory. Ke kontrole poţadovaných oprávnění jako jsou právo zapisovat do určitých sloţek nebo např. moţnost odesílat y, pokud je to vyţadováno. Pokud nejsou splněny povinné náleţitosti, plugin se neaktivuje. V případě nedostatečných práv pro vytváření sloţek se můţe plugin aktivovat, ale upozorní, ţe pro svou plnou funkčnost musí uţivatel vytvořit poţadované sloţky ručně. Aktivace nekompatibilního či poškozeného pluginu můţe způsobit pád a dočasnou nefunkčnost celého systému. V takovém případě lze plugin deaktivovat pouze smazáním jeho zdrojových souborů, popř. celé jeho sloţky a Wordpress opět naběhne. Vyřešení závislostí Wordpress neumoţňuje svými mechanismy deklarovat závislost jednoho pluginu na druhém. V současné verzi není ani moţné definovat pluginy nutné pro správný běh samotného webu. Z mého úsudku předpokládám, ţe v některé z budoucích verzí se tato funkcionalita objeví. V oficiální dokumentaci se uvádí pouze odkaz na blog jednoho z vývojářů [26], který problém potřebnosti konkrétních pluginů pro zobrazení určité stránky vyřešil následujícím, velmi elegantním způsobem. 36

37 Na začátek stránky se umístí následující kód [26]: <?php //seznam potřebných pluginů uložených v poli $required_plugins = array( ); 'plugin_fn1', 'plugin_fn2', 'plugin_fn3' $missing = array(); foreach ($required_plugins as $plugin) //oveření, zda požadvaný plugin existuje a je aktivní if (!function_exists($plugin) &&!class_exists($plugin)) $missing[] = $plugin; //pokud některý z požadovaných pluginů není nainstalován, ukončí se načítání stránky if (!empty($missing)) { }?> header('content-type: text/plain'); foreach ($missing as $plugin) die(); echo "Required plugin '$plugin' is missing\r\n"; Deaktivace pluginu Při deaktivaci pluginu z administrátorské části dojde k jeho přesunu mezi neaktivní. Je důleţité poznamenat, ţe nedojde ke smazání jeho dat z databáze, proto při opětovné aktivaci bude plugin pracovat se svými stejnými daty jako před svou deaktivací. Odinstalování pluginu Odinstalování pluginu se skládá z opačného úkonu neţ při instalaci. Provede se smazáním sloţky, popř. souboru s pluginem ze sloţky wp-content/plugins. Plugin následně zmizí se seznamu neaktivních pluginů. 37

38 Automatické zjišťování nové verze pluginu Pro nasazení ve firemním, nebo jako v našem případě školním prostředí by bylo vhodné při více instalacích systému a pouţívání stejných vlastních pluginů umoţnit ověřování verze pluginu i vůči jinému neţ globálnímu úloţišti. Neexistence jakékoli dokumentace mě donutila nahlédnout do zdrojových kódů, abych zjistil, jak samotný proces zjištění nové verze probíhá. Kdy? Aktualizace se provádí v intervalech 12 hodin. Pokud je načítána stránka v administraci se seznamem pluginů, dochází k dotazu kaţdých 60 minut. Jak? Pomocí HTTP ţádosti se odešle na server api.wordpress.org data ve formě POST. Odpověď je opět ve formě POST. Kde? Soubor s generováním dat k ţádosti update.php je umístěn ve sloţce wp-includes. Vlastní ţádost je umístěna v souboru http.php ve stejné sloţce. V obou souborech můţeme najít i zdrojový kód ke zjišťování aktualizací témat a samotného Wordpressu. Co? V ţádosti je uveden seznam pluginů s názvem sloţky a hlavního souboru. Dále je zasláno název pluginu, URI adresa na stránku pluginu a autora, verze, popis, titulek a další informace dostupné o pluginu. V odpovědi je naopak uvedena mj. nová verze pluginu a odkaz na její stáhnutí. 38

39 Ukázka žádosti k jednomu pluginu: [nextgen-gallery/nggallery.php] => Array ( [Name] => NextGEN Gallery [PluginURI] => [Version] => [Description] => A NextGENeration Photo gallery for the Web 2.0. [Author] => Alex Rabe [AuthorURI] => [TextDomain] => [DomainPath] => [Title] => NextGEN Gallery ) Ukázka odpovědi k jednomu pluginu: [nextgen-gallery/nggallery.php] => stdclass Object ( [id] => 592 [slug] => nextgen-gallery [new_version] => [url] => [package] => ) Při jedné provozované instalaci systému s mnoha aktivními pluginy nám tento proces můţe výrazně ulehčit práci a udrţet náš web aktualizovaný. Existují však i situace, kdy zjišťování nové verze nám můţe způsobit problémy. Představme si ukázkový modelový příklad: Škola provozuje 25 instalací systému Wordpress. Jedná se o fakultní a katedrální weby, dále o weby jednotlivých celoškolských pracovišť. Pro přihlašování uţivatelů se do všech instalací nainstaluje plugin, který ověřuje uţivatelská jména a hesla vůči vzdálenému LDAP 19 (Lightweight Directory Access Protocol) serveru. Díky tomu si není nutné pamatovat nová hesla a plugin se tak stal velmi oblíbeným. Bohuţel by plugin dostupný z globálního úloţiště musel být před svým nasazením modifikován z důvodu různých implementací místního LDAP 19 Protokol pro ukládání a přístup k datům na adresářovém serveru, kde jsou záznamy ukládány do stromové struktury. Pouţívaný zejména pro ukládání informací o uţivatelích. 39

40 serveru. Správci jednotlivých webů jsou povinni nejen z důvodu bezpečnosti udrţovat celou instalaci včetně pluginů aktualizovanou a při vydání nové verze upravený plugin aktualizovali, tzn., nahradili modifikovaný za novou, s místním LDAP serverem nefunkční verzi. Tímto byly ztraceny veškeré změny a plugin přestal fungovat. Nabízí se tři základní cesty, kterými se můţeme ubírat. Zakázání aktualizace Prvním řešením problému by mohlo být zamezení moţnosti aktualizace našeho autorizačního pluginu. Pokud bychom smazali základní informace o pluginu (například verzi), při zjišťování nové verze by nebyl způsob, jak zjistit naši aktuální verzi, a proto by se v administrátorské části nová verze k dispozici neobjevila. Pokud však rozšíříme ukázkový příklad, můţe se nám po čase stát, ţe v pluginu objevíme kritickou chybu s moţností obejít nějakým způsobem přihlašování. Jiným příkladem by mohla být změna nastavení LDAP serveru a následná nutná změna způsobu ověřování. Oba dva případy nás nutí aktualizovat plugin na ověřování uţivatelů, coţ při několika desítkách instalací můţe být problém s kontaktováním kaţdého správce webu a poprosit ho, aby si ze zaslaného odkazu stáhl novou verzi. Tento problém by však šel řešit na doposud nezmíněné, vyšší úrovni. Jednoduše by existoval jeden globální administrátor pro všechny weby a aktualizovaný a přizpůsobený plugin by nahrál na všechny současně. V našem konkrétním případě však naráţíme na vnitřní politiku a jiţ zavedená pravidla, kdy ţádný globální administrátor neexistuje a zavedení jej zpětně by bylo velmi náročné. Úprava aktualizačních procesů převážně na straně jednotlivých instalací. Cílem bude nejprve vytvořit vlastní místní úloţiště s upravenými pluginy. Tento server bude odpovídat na konkrétní dotazy z jednotlivých instalací Wordpressu. Ţádná aplikace ani návod na její implementaci neexistují, proto je nutné ji naprogramovat a nakonfigurovat takovým způsobem, aby na dotazy odpovídala stejnou formou jako server api.wordpress.org. Úprava na straně jednotlivých instalací Worpressu spočívá v nastavení dotazu pro určité pluginy pouze na místní server. Správce webu tedy uvidí aktualizaci pouze v případě, ţe na místní aktualizační server umístíme novou verzi. Pokud shrneme nabízené řešení, bude nutné zřídit sever s webovou sluţbou a napsat nový plugin, který bude pozměňovat dotazy od klientů. 40

41 Problém nastane, pokud se objeví nová verze Wordpressu, správce aktualizuje svoji instalaci, a plugin kvůli špatné kompatibilitě s novou verzí přestane fungovat. Samozřejmě, ţe autor místního autorizačního pluginu by měl okamţitě zareagovat a upravit jej, aby byl funkční i s nejnovější verzí. Existují však případy, a to i příklad s LDAP pluginem, kdy si nemůţeme dovolit ani krátkodobý výpadek jeho funkčnosti. Při výpadku by se totiţ nikdo do systému nepřihlásil. Úprava aktualizačních procesů převážně na straně místního serveru Další varianta řeší nedostatek s nekompatibilitou pluginu a systému. Nebudeme odkazovat na místní server pouze ţádosti ohledně našeho pluginu, ale dotazy ohledně celé instalace, včetně všech pluginů. Řešení nám zjednoduší úpravy na straně klientů, kdy pouze vyměníme adresu api.wordpress.org na api.mistniserver.cz. Varianta má ale za následek potřebu sloţitější implementace na straně serveru, kdy na něm musíme udrţovat nejen aktuální verzi našeho pluginu, ale i verze ostatních pouţívaných pluginů a samotného Wordpressu. Pokud budeme pouze přesměrovávat ţádosti na aktualizaci ostatních pluginů na server api.wordpress.org, dojdeme k dobrému, ale velmi náročnému řešení nejen na počáteční implementaci, ale i na pozdější údrţbu. Konečné řešení? Kaţdá z nabízených variant má svá pozitiva, ale bohuţel i negativa. Konečné řešení bych rozlišil dle počtu provozovaných instalací. V případě menšího počtu se jeví jako výhodnější první varianta, tedy zakázání aktualizací pro určité pluginy a snaha o definici globálního uţivatele, tedy správce, který bude dohlíţet nad společně pouţívanými pluginy. V případě, ţe by se počet instalací zvýšil nebo by nebylo moţné globálního správce definovat, jako další by se nabízela druhá varianta. Nejrobustnější, ale i nejnáročnější je poslední varianta, která je především náročná na implementaci serveru. Nakonec bych navrhl ještě jedno řešení, které je opět pomyslně na vyšší úrovni. Jde o změnu celého redakčního systému na jiný, který umoţňuje, aby existovala pouze jedna instalace systému, pluginy byly uloţeny fyzicky pouze jednou a data by byla uloţena pouze v jedné databázi. Myslím si, ţe v případě naší instituce byla podceněna právě fáze výběru redakčního systému a další nabízená řešení pro správu lokálních pluginů pouze hasí poţár, 41

42 který byl zaloţen jiţ zmíněným podceněním situace. Na trhu existuje řada redakčních systémů i z řad open source, vhodných pro nasazení v naší instituci daleko více Tvorba vlastních pluginů Plugin je program napsaný ve skriptovacím jazyku PHP, přidávající nebo rozšiřující základní funkcionalitu, vyuţívající Wordpress plugin API (Application Program Interface - aplikační programové rozhraní). Před napsáním vlastního pluginu je uţitečné vyuţít globálního úloţiště všech pluginů a zkusit najít jiţ hotový plugin, odpovídající našim poţadavkům a předejít tak zbytečné práci. Pokud ţádný nevyhovuje našim poţadavkům, musíme si vytvořit vlastní Název pluginu Při vytváření vlastního pluginu, pokud máme v záměru jej později hostovat v globálním úloţišti, je důleţité zvolit unikátní název. K ověření jedinečnosti můţe poslouţit hledání na nebo jednoduše nám můţe pomoci hledání ve vyhledávači google 20. Pokud bychom uvaţovali pouze o místním úloţišti, máme při výběru názvu volnější ruku Soubory pluginu Název souboru by měl být opět unikátní, protoţe uţivatelé si všechny pluginy umisťují do stejné sloţky (wp-content/plugins/) a při kolizi jmen by mohlo dojít k přepsání jiného. Pokud náš plugin obsahuje více souborů, můţeme je umístit do nové sloţky, u které platí podobné pravidlo s unikátním názvem. Z formálního hlediska, zvláště pokud bude plugin nabízen veřejně, je nutné přiloţit i readme soubor (dle konvencí Na začátku hlavního PHP souboru (jeho název je stejný jako název pluginu) by měly být také uvedeny základní informace ohledně názvu, základního popisu, verze, pouţité licence a URI samotného pluginu a autora

43 <?php /* Plugin Name: Název pluginu URI: Description: Krátký popis pluginu. Version: Verze pluginu, např.: 1.0 Author: Jméno autora pluginu. URI: např.: GPL2 */?> Ukládání dat pluginů do databáze Při vytváření pluginů dříve nebo později vznikne potřeba ukládat data do databáze. Wordpress definuje tři základní způsoby, jak si plugin můţe uchovávat data v databázi. Liší se v podstatě pouze v tom, do jaké tabulky se ukládají. Vţdy se jedná o jednu a tu samou databázi, kterou pouţívá i celý systém. Využití option mechanizmů Data ukládají do stejné tabulky jako samotné nastavení systému Wordpress. Řešení je určené především pro ukládání menšího počtu jednotlivých proměnných. Ukládání konkrétních dat se provádí přes funkci add_option. Pokud se jiţ proměnná se stejným názvem v databázi vyskytuje, je potřeba místo add_option, zavolat metodu update_option. add_option($name, $value, $deprecated, $autoload); $name Povinný parametr typu String udává, pod jakým názvem bude proměnná v databázi uloţena. $value Hodnota, která má být uloţena do databáze. Defaultně je nastavena na prázdný String. $deprecated Parametr, který jiţ není vyuţívaný, ale pro zpětnou kompatibilitu je zachován. Pokud bychom chtěli pouţít následující parametr $autoload, musíme tento uvést jako prázdný String nebo null. 43

44 $autoload Při nastavení na 'yes' budou data nahrána automaticky funkcí get_alloption. V opačném případě při pouţití 'no' je nutné pro získání dat zavolat metodu get_option($name). Využití meta dat Meta data 21 neboli Custom Fields jsou data uloţená v databázi ve stejné tabulce jako stránky a příspěvky. Vţdy přísluší ke konkrétní stránce nebo příspěvku. Vytvoření nové vlastní tabulky Je vyuţíváno v případě potřeby uloţit větší mnoţství dat. Ve své podstatě se jedná pouze o SQL příkazy, s jejichţ pomocí jsou tabulky vytvářeny. Wordpress neobsahuje ţádné vlastní mechanismy pro zaloţení tabulek v databázi a je na autorovi pluginu, jaké tabulky s jakými atributy si vytvoří. Návod se základními pravidly je uveden v dokumentaci [24] Využití pluginu na stránce Wordpress jako platforma nenabízí pro vývoj svých pluginů moţnost definice rozhraní, přes které je moţno přistupovat k vnitřní implementaci. Samozřejmě, ţe při dodrţování základních principů objektově orientovaného programování jako je maximální pouţití modifikátoru přístupu private lze částečně zajistit bezpečnost vnitřní implementace. Na vině nepřítomnosti rozhraní můţe být i nemoţnost realizace základních vlastností komponent v prostředí jazyka PHP. I přesto však máme moţnost, jak částečně rozhraní definovat, a to pomocí zkratek, neboli Shortcode API. Ke kaţdé funkci, která má být volána zvenku, přiřadíme zkratku, pomocí které pak konkrétní funkci voláme. Jak bylo řečeno v kapitole o zkratkách, jejich pouţití je pouze omezeno na editor příspěvků. Pokud bychom chtěli přidat funkci pluginu do šablony vzhledu, musíme přes klasické volání funkcí. 21 Meta data jsou v podstatě data o datech. Máme například stránku s nějakým obsahem a k tomu obsahu si chceme uloţit své poznámky, a tak pouţijeme meta data. 44

45 Umístění nastavení v administrativní části Jako poslední nás při psaní pluginu napadne, jakým způsobem zajistit, aby administrátor mohl měnit nastavení pluginu. Pokud se budeme drţet jiţ jednou zmíněného příkladu s LDAP pluginem, musíme umoţnit administrátorovi (ten, kdo instaluje pluginy) nastavit své místní LDAP servery, vůči kterým se budou uţivatelé ověřovat. Samozřejmě lze řešit editací souborů pluginu, ale Wordpress nabízí elegantnější způsob. Kaţdý aktivovaný plugin si můţe vytvořit a umístit do administrativní časti své menu, ve kterém lze nastavovat hodnoty pro jeho správné nastavení. Stránky s nastavením lze umístit do všech jiţ existujících menu (například Nástroje, Nastavení, Pluginy) nebo si lze vytvořit v nejvyšší úrovni své vlastní menu. Ukázka vloţení vlastního menu do nejvyšší úrovně //Pro zavolání naší funkce při zobrazení administrace použijeme akci 'admin menu' add_action('admin_menu', 'zobrazmenu'); function zobrazmenu() { // Přidání menu do nejvyšší úrovně add_menu_page('moje Menu', 'Moje Menu', 'manage_options', 'toplevel-menu', 'nastavenimojemenu' ); // Přidání další položky pod menu Moje Menu add_submenu_page('top-level-menu', 'Moje Podmenu', 'Moje Podmenu', 'manage_options', 'sub-page', 'nastavenimojepodmenu'); } // nastavenimojemenu() zobrazi obsah stranky pro menu Moje Menu function nastavenimojemenu() { } echo "<h2>". 'Moje Menu'. "</h2>"; // nastavenimojepodmenu()obsah stranky pro menu Moje Podmenu function nastavenimojepodmenu() { echo "<h2>". 'Moje Podmenu'. "</h2>"; } 45

46 Obrázek 6: Nově vytvořené menu Definice funkce add_menu_page() add_menu_page( $page_title, $menu_title, $capability, $menu_slug, $function, $icon_url, $position ) $page_title Název, který bude zobrazen v titulku při zobrazení stránky s nastavením. $menu_title Nápis zobrazený přímo v menu jako odkaz na stránku s nastavením. $capability Poţadovaná způsobilost pro zobrazení stránky uţivateli. Kaţdá z uţivatelských rolí má stanovenou způsobilost pouze k určitým akcím. U administrátora můţeme např. najít install_plugins, install_themes. U návštěvníka naopak jenom read. $menu_slug Unikátní jméno potřebné například pro přidání další poloţky pod menu. $function Funkce, která se zavolá pro zobrazení obsahu stránky s nastavením. $icon_url Nepovinný parametr pro nastavení vlastní ikony pro menu. 46