A kézikönyvnek ez a része arra próbál választ adni, hogy mire lehet egyáltalán a Drupalt használni, mik a főbb ismertetőjegyei, elemei, értékei

2010.02.11.

Magyar Drupal Kézikönyv

Magyar Drupal Kézikönyv Kézikönyvünk célja a Drupal tartalomkezelő rendszer bemutatása éppúgy, mint mélységeinek tárgyalása. Megközelítésünk időnként speciálisan magyar, hiszen a nyelvi támogatás és a nyelvi funkciókat jól kiegészítő modulok bemutatása is fókuszba kerül, ha magyar felhasználásról van szó. Többek között ennek is következménye, hogy a magyar kézikönyv nem másolata az eredeti angol kiadásnak. Reményeink szerint a folyamatosan épülő kézikönyv olvasóink sok kérdésére választ ad majd.

Bemutatkozik a Drupal A tartalomkezelő rendszerek piaca népes, számos lehetőség közül választhatunk, ha egy alkalmas rendszert keresünk. A választás szempontjai szerint a tartalomkezelő rendszerek pl. lehetnek fizetősek és ingyenesek/nyílt forrásúak egyszerűbbek és komplexebbek különböző szerver környezeten üzemeltethetők kezdetlegesek és jól kiforrottak magyarul elérhetők, vagy csak más nyelven tudók. általános célúak és specializáltak (pl. e-learning, e-commerce, fórum, blog stb.). A kézikönyvnek ez a része arra próbál választ adni, hogy mire lehet egyáltalán a Drupalt használni, mik a főbb ismertetőjegyei, elemei, értékei.

Mi a Drupal, mire használható? A Drupal 2001. január tizenötödikén kezdte meg nyílt működését, amikor Dries Buytaert publikálta első verzióját az interneten. A rendszer azóta nagyon sokat fejlődött, és széles körben használt tartalomkezelővé vált. Lássuk, mégis minek nevezhetjük, és ezek a kategóriák mit is jelentenek. Tartalomkezelő rendszer azaz Content Management System (CMS) Tartalmak bevitelére és rendszerezésére használható eszköz több felhasználó támogatásával legalábbis a Wikipedia definíciója szerint. Ez kicsit bővebben azt jelenti, hogy internetes publikációk, híroldalak készítésére használható eszköz. A legtöbb ma CMS-nek nevezett rendszer ennél sokkal többet tud, és a Drupal sem korlátozódik csak tartalmak kezelésére. Képes egyszerű elektronikus bolt építésére is, illetve gyakran használják közösségek kialakítására (ahol a tartalomfejlesztés másodlagos szerepet kap). Tartalomkezelő keretrendszer azaz Content Management Framework (CMF) Olyan programozók számára készült rendszert jelent, mely tartalomkezelő rendszerek építésére szolgál - a Wikipedia definíciója szerint. A Drupal kiváló CMF, hiszen általános tartalom kezelési és rendszerezési sémákat támogat széles körű megjelenés változtatási képességekkel. Ráadásul nagyon jó forrás dokumentációval rendelkezik. Így alkalmas egyedi tartalomkezelési igények kielégítésére is. Web alkalmazás fejlesztő keretrendszer azaz Web Application Framework (WAF) A Drupal egy eléggé vékony réteget biztosít a PHP nyelvi elemei felett, mely jelentősen meg tudja könnyíteni általánosabb igényű web alkalmazások fejlesztését. Ilyen funkciók az általános űrlapkezelő rendszer, a vékony adatbázis kezelő réteg, a felhasználókezelő alrendszer. Mivel webhelyünk látogatói minden bizonnyal leginkább a Drupal CMS szerepének kihasználásában drupal.hu/kezikonyv/nyomtatobarat

1/135

2010.02.11.


érdekeltek, ezért a továbbiakban a kézikönyv is erre próbál koncentrálni. Mindazonáltal nem mehetünk el amellett, hogy a rendszer a másik két szerepet is kiválóan ki tudja tölteni, és számos éles környezeti alkalmazása van ezeken a területeken is.

Az alaprendszer és kiegészítői Amikor egy Drupal alapú webhelyet alakítunk ki, több részből állítjuk össze a kész megoldást. Biztosan szükségünk lesz az alaprendszerre, az igényeinknek megfelelő kiegészítőkre, valamint egy általunk választott megjelenésre (amit magyarul sminknek nevezünk). Ezeket magunk is összeválogathatjuk, vagy választhatjuk a közösség által már összeállított csomagok egyikét kiindulásképpen.

Az alaprendszer és a kiegészítők A Drupal fejlesztők egy központi szolgáltatás csomagot használnak a fejlesztések koordinálására, mely segít a változások követésében, a hibák megvitatásában és javításában. Itt két fő területen találhatóak a Drupal rendszerhez kapcsolódó állományok: Drupal Core - a Drupal alaprendszer A Drupal alapfunkcionalitásait megvalósító motor. Önmagában rendkívül sok szolgáltatásssal bír (ezen kézikönyvet működtető modul is ebben található), mégis alapvetően az a feladata, hogy a különböző funkciókat hatékonyan fogja össze. Bárki javasolhat módosításokat, amelyeket a fejlesztő közösség véleményez, de a forráskódba ezeket csak néhány személy vezetheti át. Ez biztosítja, hogy az itt található kódok mindig korrektek és használhatóak, valamint egy koncepcióhoz illeszkednek. Az alaprendszert minden Drupal felhasználó futtatja, ezért ez a legjobban tesztelt, így a legbiztonságosabb és legstabilabb is. Drupal Contributions - a közösség munkaterülete A közösség által beküldött kiegészítő funkcionalitások, megjelenések (sminkek), felület fordítások, telepítési profilok (lásd később) és dokumentációk itt találhatóak. Röviden minden amit az alaprendszeren kívül használni fogunk, és a drupal.org-ról gyűtjük be innen származik. Jellegénél fogva nincs olyan erős irányítás alatt, mint az alaprendszer, ezért bizonyos esetekben a stabilitása, biztonságossága elmaradhat attól. Drupal alapú webhelyünk kialakításánál a következő komponensekből építkezhetünk: A Drupal alaprendszer (a címlapon letölthető) Kiegészítő modulok. Ha az alaprendszer képességei az adott webhely kialakításához nem elegendők, a kiegészítő modulok között találhatunk számunkra megfelelő elemeket. Sminkek. A webhely megjelenítését megváltoztató komponenseket sminkeknek nevezzük. Az alaprendszerben is található néhány, de számos más smink is elérhető. Egyes sminkek illesztő programok (úgynevezett smink motorok) segítségét igényelhetik a működésükhöz. Az azonban nagyon ritka, hogy ilyet telepítenünk kellene. Fordítások. Mind az alaprendszer, mind a kiegészítők több nyelvű felületet is tudnak biztosítani. Míg a modulok és sminkek fordítása azok csomagjában érkezik, az alaprendszer fordítását külön kell beszereznünk (a magyar fordítás a címlapon letölthető). A fenti komponensekből tehát igényeinknek megfelelő webhelyet tudunk kialakítani. Ha valamilyen jellemző típus-webhelyre lenne szükségünk, a telepítési profilok lehetnek segítségünkre. Ezek az alaprendszert konkrét modulokkal és/vagy sminkkel és/vagy fordításokkal kombinálják, így adva egy előre elkészített receptet egy-egy webhely típusra. Mivel ezek az egyenként is elérhető komponenseket használják, ugyanazt a kiterjeszthető környezetet biztosítják, mintha magunk állítottuk volna össze a drupal.hu/kezikonyv/nyomtatobarat

2/135

2010.02.11.


rendszerünket, tovább bővíthetőek, alakíthatóak. A Drupal magyar nyelvű telepítése az 5.0-s kiadás óta is ennek az alrendszernek a kihasználásával valósítható meg a legkönnyebben.

Melyik verziót használjam? A Drupal fejlesztése folyamatos, mind az alaprendszerben, mind a közösségi területen. Annak érdekében, hogy a felhasználók életét megkönnyítsék, rendszeresen kiadásokat jelentetnek meg a Drupal motorból, illetve a közösségi területen kezelt projektekből. Amikor például a közösség valamely tagja egy modult fejleszt, és ezt közzé szeretné tenni, el kell döntenie, hogy mely Drupal alaprendszer verzióval együttműködő (kompatibilis) változatot hoz nyilvánosságra. Mivel egy modulnak több különböző Drupal alapverzióval együttműködő változata is lehetséges (pl. 5.0 és 6.0 verziókkal kompatibilisek) ezért egy modul fejlesztése több ágon folytatódhat. Ezeken az ágakon a fejlesztők közzé tudnak tenni fejlesztői kiadásokat, melyeknél a kiadás (csomag) neve -dev útótagra végződik. Ilyen például a simplenews-6.x-1.xdev.tar.gz, mely a Drupal 6.x-szel kompatibilis simplenews modul első saját kiadásának fejlesztői verziója. Ezek a verziók tulajdonképpen teszt szerepet játszanak: a közösség kipróbálhatja, hogy az adott Drupal alaprendszerrel valóban együtt tud-e működni a modul. Ugyanígy a Drupal alaprendszernek is vannak hasonló fejlesztői kiadásai, melyek az új funkciók és változtatások kipróbálását teszik lehetővé a közösség számára. Ahogy egy modul a kiadáshoz közeledik, alfa, béta, RC kiadások jelenhetnek meg, melyek ugyan még nincsenek kész, de már azt mutatják, hogy kevesebb ismert vagy ismeretlen hiba van a kódban. Amint egy modul képességei és az együttműködési készsége kielégítőek, egy stabil kiadást jelentethet meg a fejlesztő. Ilyenkor a csomag nevében a Drupal alaprendszert (amellyel együtt tud működni a modul) és a konkrét modul kiadás sorszámát látjuk. Ilyen például a simplenews-6.x1.0.tar.gz, mely az 6.x-es sorozattal kompatibilis, és önmagában a modul 1.0-ás kiadása. Természetesen az alaprendszernek is időről-időre megjelennek újabb kiadásai. Itt az 5.0 megjelenése óta a fő verziószám az első számjegy, a második számjegy változása pedig a hibajavító kiadások közzétételét jelzi. Korábban három jegyű verziószámok voltak használatban, és az első két szám változása jelzett új funkciókat, a harmadik volt fenntartva hibajavító kiadásoknak. Általánosságban elmondható, hogy az alaprendszer fejlesztői változata stabilnak tekinthető, a kiegészítő modulok és sminkek fejlesztői kódja azonban ritkábban működik különösebb problémák nélkül. Ezért kevés programozói tapasztalattal rendelkező felhasználóknak a számozott kiadások alkalmazása javasolt. Fontos megjegyezni, hogy a fenti együttműködési képesség a Drupalban közel sem állandó dolog. Egy Drupal 5.x-hez készült modul biztosan nem fog a Drupal 6.x-szel együttműködni módosítás nélkül. A Drupal úgy teszi lehetővé saját dinamikus fejlődését, hogy nem áldoz a visszafelé kompatibilitás megőrzésére erőforrásokat. A hibajavító kiadások célja azonban a visszafelé kompatibilitás megtartása, így egy Drupal 6.0-hoz letöltött modul szinte biztos, hogy Drupal 6.1-gyel is sikeresen együtt tud majd működni, és külön nem lesz szükség a modul frissítésére az alaprendszer frissítése miatt. Amennyiben mégis valamilyen frissítési eljárás szükséges, azt mindig megtaláljuk az új változat bejelentésében.

Irányelvek, alapértékek A Drupal fejlesztői időről-időre megjelennek különböző rendezvényeken és konferenciákon, hogy képviseljék és népszerűsítsék a rendszert. Ebből a célból egy kis brosúra (PDF) is készült a rendszer alapértékeiről, mely (bár időközben néhány technikai részletben idejét múlttá vált) jól alkalmazható ezek áttekintésére. drupal.hu/kezikonyv/nyomtatobarat

3/135

2010.02.11.


Szabad szoftver Mind a Drupal alaprendszerre, mind a közösség hozzájárulásaira követelményként meghatározott a GNU GPL licenc alkalmazása. Ez azt jelenti, hogy a Drupal biztosítottan szabad forráskódú szoftver, és ez a jövőben sem változtatható meg. Ennek következménye az is, hogy a kód ingyenesen elérhető. Szabványokon alapul A Drupal fejlesztői nagyon fontosnak tartják az együttműködés széles körű megvalósítását. A rendszerrel szállított sminkek XHTML formátumot használnak, többnyire táblázatmentes CSS formázással. A magyar Drupal weboldal is ilyen megjelenést alkalmaz. A szabványosság azonban nem csak ezt jelenti. Az alaprendszer támogatja az XML-RPC üzenetküldést és fogadást, RSS csatornák feldolgozását és rugalmas előállítását, OPML összefoglaló állományt generál, támogatja az RSD és az RSS Autodiscovery szabványokat stb. Hozzáférhető (accessible) A fejlesztők nagy hangsúlyt fektetnek arra, hogy a felület könnnyen kezelhető legyen, az űrlapok egységesen jelenjenek meg, a folyamatok azonos metaforákat használjanak. A generált XHTML oldalak szemantikusan gazdagok, ami nemcsak a hozzáférhetőséget segíti, hanem keresőbaráttá is teszi a rendszert. A képernyőolvasó programok és a kereső indexelők számára is jobb, ha a tartalmak és irányító elemek részei megfelelő megjelöléssel szerepelnek a kódban. Moduláris Az alaprendszer számos modult tartalmaz, melyek egyedi beállításával teljesen testreszabott webhelyet alakíthatunk ki. Nem csak a rendszer kialakítása moduláris, hanem a tartalmak kezelése is, hiszen egy bázisként használt tartalom reprezentációra épül minden speciális tartalom tárolása a rendszeren. Ha webhelyünk megjelenését szeretnénk befolyásolni, ezt is több szinten tehetjük meg, az általunk választott sablonrendszerrel, vagy akár csak CSS stílusállományok módosításával. Ezt a három szinten megvalósított smink rendszer teszi lehetővé. Stabil, biztonságos, teherbíró A Drupal alaprendszer erősen kézbentartott forráskódja fejlesztői verzióiban is szinte mindig stabilan működik. A változásokkal párhuzamosan karbantartott frissítést lehetővé tevő mechanizmus biztosítja, hogy valamely Drupal kiadást az aktuális fejlesztői verzióra frissítsük az adataink automatikus migrálásával. A fejlesztés során nagyon nagy hangsúly kerül a biztonság szavatolására, mindenféle betörési kísérlet alapvető megakadályozására. Mindezek mellett a rendszer képes gyorsan működni, akár szokatlanul nagy terhelés alatt is probléma nélkül kiszolgálni a webhelyet. Csatolmány

Méret

drupal.en_.booklet.1.pdf 581.34 KB

Az alaprendszer képességei, lehetőségei Az irányelvekről és alapértékekről szóló részben megismerhetjük a rendszer számos alaptulajdonságát. Azokon túl érdemes megemlíteni számos olyan lehetőséget, szolgáltatást, amit a Drupal alaprendszer nyújtani képes. Számos szolgáltatás áll rendelkezésrünkre, a Drupal szerteágazó funkciójú moduljai révén széles körben felhasználható, rugalmas rendszert alkot. A következőkben néhány kiemeltebb szempont szerint járjuk körbe, mire használható, melyek azok a funkciók, melyek megvalósíthatóak ezzel a rendszerrel. Bár az alábbi összefoglaló az alaprendszer fontosabb képességeit hivatott körbejárni, időnként lehetséges kiegészítőket is megemlítünk. Ahol külön nem jelezzük, ott alaprendszerbeli funkcióról van szó. drupal.hu/kezikonyv/nyomtatobarat

4/135

2010.02.11.


Platform támogatás Apache vagy IIS, Unix, Linux, *BSD, Solaris, Windows és Mac OS X támogatás A Drupal gyakorlatilag minden olyan rendszerre elérhető, ahol a PHP 4 vagy a PHP 5 és valamely támogatott adatbázis rendszer működik. Nem csak Apache és Microsoft IIS alatt, hanem számos operációs rendszer alatt is futtatható, mint amilyen a Linux, a különböző BSD-k, a Solaris, a Windows vagy a Mac OS X platformok. Adatbázis függetlenség Bár a legtöbb Drupal alapú oldalt üzemeltető MySQL-t használ, ez nem mindenki számára kézenfekvő megoldás. A Drupal vékony adatbázis függetlenítő felülete segítségével PostgreSQL használata is lehetséges. Más adatbázisokhoz körülbelül egy tucat egyszerű függvény létrehozásával illeszthetjük oldalunkat. Webes felületű telepítő Annak érdekében, hogy a platformok eltérésének nyűgjeivel ne kelljen foglalkozunk, illetve a Drupal webhelyünket minél hamarabb üzembe tudjuk állítani, a Drupal beépített webes telepítővel illetve adatbázis frissítővel rendelkezik.

Tartalom kezelés Sokoldalú tartalom típusok A különböző tartalom publikálási igények kielégítéséhez más-más tartalom-szerkezetre és funkcionalitásra lehet szükség. Ezért a Drupal alapcsomagja számos tartalom típust beépítetten támogat: írás, fórum téma, blog bejegyzés, könyv lap, oldal, szavazás. Saját tartalom típusok Amennyiben a beépített típusok nem elegendőek, saját típusok definiálására is van lehetőség a webes felületen a Drupal beépített tartalom típus funkcionalitásával. A rugalmas, kiterjesztésre épülő típus rendszer lehetővé teszi a gyakori elemek újrahasznosítását, a saját típusok munkafolyamatokba illesztését. Kiegészítővel: amennyiben saját mezőket szeretnénk illeszteni ezekhez a típusokhoz, a Content Construction Kit kiegészítőt kell telepítenünk, vagy programoznunk kell. Beviteli formák A felhasználók számára előképzettségük és jogosultságaik függvényében más-más beviteli forma lehet megfelelő egy-egy tartalom beküldésekor. A rendszer lehetővé teszi többféle formátum támogatását, bár beépítve csupán szűrt illetve szűretlen HTML kód támogatás áll rendelkezésre, a PHP kód értékelő mellett. Kiegészítővel: BBCode, Textile stb formátumok is könnyen hozzáadhatóak. Ezekhez a formátumokhoz számos vizuális szerkesztő kiegészítő közül választhatunk. Változáskezelés A Drupal beépített változáskezelő rendszere nyilvántartja az erre megjelölt tartalmak módosulásait: megtekinthető, hogy ki, mikor változtatott és mit. A rendszer lehetőséget ad megjegyzések hozzáadására, továbbá egy korábbi verzióra történő visszaállásra. Kereshetőség A Drupal minden tartalma teljes indexelésen esik át, s így később megtalálhatóvá is válik. A felhasználók és hozzászólások szintén kereshetőek. Állandó linkek Minden a Drupal által felügyelt tartalomhoz készített link állandó, azaz úgynevezett permalinket képez, ami azt jelenti, hogy bárki bátran linkelhet rá, megbízhatóan elérhető lesz az a későbbiek során is ugyanazon a címen. Kivéve természetesen, ha a weblap szerkesztői másképp döntenek, például törölnek egy tartalmat. Közösségi könyv drupal.hu/kezikonyv/nyomtatobarat

5/135

2010.02.11.


Az egyedülálló, más hasonló rendszerekből hiányzó közösségi könyvírási modul lehetőséget ad egy teljes könyv összeállítására. Segítségével többen is tudnak dolgozni a könyv egyes lapjain. A Magyar Drupal Kézikönyvet is ezzel a módszerrel írjuk.

Tartalom rendszerezés Taxonómia A Drupal fejlett rendszerezési megoldása a taxonómia elméletére épül. Bár ez bonyolultan hangzik, valójában nagyon egyszerű és egyszersmind sokoldalú. Lehetőség van több kategória csoportot kialakítani, és egy vagy több kategóriába helyezni a tartalmakat. A taxonómia rendszer olyan rugalmas, hogy teljes egészében nagyon kevés webhely használja ki széles körű képességeit. Szabad címkézés A taxonómia rendszerre épülő, beépített szabad címkézés (free tagging) funkció lehetővé teszi, hogy rendkívül egyszerűen, felhasználóbarát felületen rendeljünk kategóriákat az egyes tartalmakhoz közvetlenül azok létrehozásakor vagy szerkesztésekor.

Blog (webnapló) írás és követés Blogger API támogatás A Blogger API támogatása lehetővé teszi, hogy a rendszer tartalmait számos erre felkészített programból lehessen kezelni. Ez mind asztali alkalmazásokat, mind webes környezeteket magába foglal, ezáltal lehetőséget adva a leginkább megfelelő adminisztrációs eszköz kiválasztásához. Az asztali alkalmazások segítségével általában gazdag szerkesztési lehetőségek is rendelkezésre állnak. Tartalom megosztás A Drupal lehetőséget kínál az oldal tartalmának RSS formátumban történő exportálásához, megosztásához, melyet más oldalak, illetve eszközök megjeleníthetnek, feldolgozhatnak. Ez lehetővé teszi bárki számára, hogy egy hírolvasó alkalmazással kényelmesen áttekintse a friss tartalmakat az oldalon. Beépített hírolvasó A bépített hírolvasó kliens segítségével a Drupal lehetővé teszi más oldalak híreinek, tartalmának olvasását, illetve beépítését az oldalba. A letöltött híreket gyorsítótárban tárolja a rendszer, így olvasáskor nem kell várni a távoli webhely válaszára. Az RSS, Atom és RDF tartalom megosztó formátumok támogatottak.

Felhasználó és jogosultság kezelés Felhasználó azonosítás A felhasználók regisztrálhatnak és azonosíthatják magukat a helyi rendszeren keresztül. Tetszőleges számú felhasználó támogatott. A Drupal 5-ben és korábbi kiadásokban megtalálható a "drupal modul", mely lehetővé teszi, hogy más Drupal alapú webhelyeken használt nevünkkel és jelszavunkkal több webhelyen is be tudjuk jelentkezni. A Drupal 6-ban ezt az OpenID modul váltotta fel, ami még egyszerűbb és biztonságosabb, ráadásul szabványos megoldás, így nem csak Drupal alapú webhelyek között tudjuk ugyanazt az azonosítót használni, immár a jelszavunk felfedése nélkül. Kiegészítővel: intranetes felhasználás esetén például LDAP alapú azonosítás is egyszerűen telepíthető. Felhasználói csoportok A webhely felhasználói csoportokba rendezhetőek. Egy-egy felhasználó több csoportba is tartozhat, ezeken keresztül pedig általános jogosultságokat kaphat. Tartalom szintű jogosultság kezelés drupal.hu/kezikonyv/nyomtatobarat

6/135

2010.02.11.


A rendszer beépített lehetőséget ad arra, hogy különböző jogosultság sémák szerint akár az egyes tartalmakra egyenként is megadhassuk annak jogosultsági megkötéseit. Kiegészítővel: Ezzel az igényünknek megfelelő kiegészítő telepítése után könnyen korlátozhatjuk a különböző tartalmak elérhetőségét illetve szerkeszthetőségét intranet környezetben is.

Közösségi alkalmazások Szálkövető hozzászólások Lehetőség van adott tartalmakhoz hozzászólás fűzésére. Ezek tárolásakor a Drupal rögzíti, hogy mely korábbi megjegyzésre érkeztek válaszul. Ez képessé teszi a rendszert szálkövető nézet biztosítására a hozzászólások kiírásakor. Vitafórumok A Drupal lehetőséget kínál több szintű fórumok létrehozására, ezzel is elősegítve oldalunk forgalmának növekedését, s nem utolsó sorban a felhasználói közösség kialakulását. Követő Mivel a Drupal minden tartalmat alapjaiban egységesen kezel, közösségünk visszatérő tagjai könnyen áttekinthetik, hogy legutóbbi látogatásuk óta milyen új, illetve változott tartalmak jelentek meg a webhelyen. A követőben és a Drupal felületén máshol is jelzésre kerülnek az adott felhasználó számára új illetve változott tartalmak, hozzászólások.

Felület megjelenítés és testreszabhatóság Smink kezelés A Drupal smink kezelő rendszere elválasztja egymástól a tartalmat és a megjelenítést, ezáltal lehetővé téve a weblap kinéztének befolyásolását. Sablonok egyszerűen HTML és (kevés) PHP fejlesztéssel készülhetnek. Nincs szükség egy új leíró nyelv megismerésére. Kiegészítővel: ha már ismerünk egy sablon nyelvet, egy kis fejlesztéssel megoldható a használata, vagy valamely kész sablonkezelő rendszert telepíthetjük. Személyre szabhatóság Az oldalakon megjelenő tartalmak formája, a blokkok, a sminkek specialitásai mind-mind testreszabhatóak az adminisztrációs felületen. Lehetővé tehetjük felhasználóink számára is, hogy saját egyedi beállításuk legyen a megjelenésre, nyelvre vagy akár a blokkokra vonatkozóan is. Szabad blokk elhelyezés A blokkok elhelyezésére használt zónák számának és helyének csak az éppen általunk használt smink szabhat határt, a rendszer tetszőleges számú blokk megjelenítő területet támogat. Többnyelvű felület A Drupal fejlesztésekor nagy hangsúlyt kap a többnyelvű felület támogatása. Kész felület fordítások importálására egyszerűen nyílik lehetőség, így gyorsan beállíthatjuk több nyelv támogatását. Kiegészítővel: A tartalmak fordítására, illetve több nyelven történő publikálására az Internationalization (i18n) vagy a Localier kiegszítő modulok használhatók. Dinamikus, AJAX-os űrlapok Az igény szerint összecsukható űrlap elemek; Drupal 6-ban a fogd-és-vidd támogatással rendelkező felületek; a fájl feltöltésnél, a szabad címkézésnél és más beépített helyeken alkalmazott felhasználóbarát AJAX megoldások hatékonnyá teszik a rendszer kezelését. Így kevesebb időt kell egy-egy feladat végrehajtására fordítanunk, mint más rendszerekkel. Barátságos webcímek Megfelelő beállítással a Drupal alaprendszer támogatja barátságos webcímek használatát. Az így létrehozott címek rövidek, könnyen megjegyezhetőek, és nem utolsó sorban elősegítik jobb pozíció elérését a keresőkben. drupal.hu/kezikonyv/nyomtatobarat

7/135

2010.02.11.


Adminisztráció Web alapú adminisztráció A Drupal minden funkciója és beállítási lehetősége webes felületről – így szinte a világon bárhonnan, ahol egy böngésző rendelkezésre áll – adminisztrálható, karbantartható. Nincs szükség külön szoftver telepítésére a számítógépen. Naplózás és jelentéskészítés Minden fontos tevékenység és rendszeresemény feljegyzésre kerül a rendszernaplóba, melyet az adminisztrátor egy későbbi alkalommal áttekinthet. A rendszer saját állapotáról is összefoglaló jelentést készít, hogy az alapvető hibákat gyorsan észrevehessük és javíthassuk. Időzített feladatok A webhely adminisztrációját rendszeresen időzített feladatok segítik, így például a kereső indexe mindig aktuális lehet. Karbantartás miatt zárva Lehetőség van a webhely nyilvános funkcionalitásának kikapcsolására, csak az adminisztrátori feladatokra korlátozni a Drupal működését. Ilyenkor a látogatók egy beépített üzenetet láthatnak, amit igény szerint testre is szabhatunk.

Teljesítmény és skálázhatóság Átmeneti tár A gyorstárazós megoldások a dinamikusan előállított oldalak kiszolgálási sebességét jelentősen javítják, ezzel növelve a teljesítményt és csökkentve a kiszolgáló terhelését. Összességében egy gyorsabb, hatékonyabb oldal készíthető segítségükkel. A gyorsítótárazás ezen kívül menet közben is állítható, hangolható az éppen aktuális terheltség függvényében. A Drupal az eddigi tapasztalatok alapján igen nagy látogatottság kiszolgálására is képes, akár egy Slashdot támadást is kibír. Visszafogók Az úgynevezett visszafogó modul segítségével extrém terhelés alatt automatikusan kikapcsolhatóak az oldal egyes funkciói, ezzel is elősegítve a hatékonyabb és gyorsabb működést, a terhelés túlélését. A visszafogó modul finomhangolható az igények szerint, s hatékony eszköze lehet az oldal skálázásának.

Terméktámogatás Kézikönyv, súgó A Drupal magyar és angol honlapján is elérhetőek Drupal kézikönyvek, melyek sok kérdésre választ adhatnak. Bár ezek pontos aktualitását nem lehet garantálni, így is felveszik a versenyt a hasonló projektek dokumentációjával. A rendszer beépített súgókat tartalmaz az elsőre nem egyértelmű feladatok oldalain. Ezek jelentősen megkönnyíthetik a különböző műveletek elvégzését. Közösségi támogatás Nyíltan működő, és nyilvánosan archivált magyar és angol nyelvű levelezőlisták illetve fórumok elérhetőek. Amennyiben ezekben a forrásokban nem található válasz kérdéseinkre, a közösség segíthet. Professzionális terméktámogatás Nemzetközi porondon, és a hazai piacon is találhatóak olyan cégek, melyek Drupal hosztingot, fejlesztést, bevezetést, oktatást vállalnak. Számos ilyen cég is közelről követi a fejlesztéseket, illetve részt vesz a különböző projektekben, segítve a szabadon elérhető modulok kialakítását is.

drupal.hu/kezikonyv/nyomtatobarat

8/135

2010.02.11.


Felhasználói alapismeretek Ez a fejezet segíteni fog a Drupal alapú weboldalak használatában. Bemutatja, hogyan hozzunk létre felhasználói azonosítót (másként fogalmazva: hogyan regisztráljunk), hogyan lépjünk be, hogyan állítsuk be személyes adatainkat, és végül hogyan hozzunk létre tartalmakat (weboldalakat). A Drupal egy tartalomkezelő rendszer. Célja, hogy egyszerűen lehessen tartalmakat (szövegeket, képeket, csatolt állományokat, stb.) felvinni, és azokat elérhetővé tenni a látogatók számára. Nem kell a technikai részletekkel foglalkoznunk, csupán a tartalmakra kell koncentrálnunk. A Drupal a tartalmakat adatbázisban tárolja, ahonnan – a felhasználó böngészőjének kérésére – a tartalmakat közzéteszi. Természetesen a Drupal lehetőséget ad arra, hogy a weboldal látogatói különböző szerepkörökben és különböző jogosultságokkal használhassák a weboldalunkat. Van, akinek tartalmakat feltölteni, másoknak szerkeszteni, a legtöbb látogatónak pedig „csupán” olvasni van lehetősége az oldalakat. (Bár ez utóbbi sem mindig így van, hiszen lehetnek zárt oldalak is, amelyeket csak bizonyos látogatók tekinthetnek meg.)

Felhasználókezelés Ahhoz, hogy minden látogató pontosan azt (nem többet és nem kevesebbet) tehesse meg a honlapon, amire az oldal tulajdonosa vagy adminisztrátora fel akarja jogosítani, bizonyos esetekben elengedhetetlen a látogató személyének beazonosítása. Ennek régóta bevált módszere, hogy a felhasználók számára azonosítót hozunk létre (más néven regisztrálunk), amihez jogosultságokat rendelünk, a felhasználó pedig a honlap későbbi használatai esetén a felhasználónevének és jelszavának megadásával azonosítja magát (bejelentkezik). Bevezetésként még érdemes megemlíteni, hogy a Drupal weboldal adminisztrátora jogosult arra, hogy a honlapon olyan feladatokat is elvégezzen, amelyek senki másnak nem engedélyezettek, például egy regisztrált felhasználó jogosultságainak pontos beállítása.

A felhasználó regisztrációja A Drupal oldalakon a tartalmak beküldése (létrehozása), szerkesztése általában csak regisztrált, és bejelentkezett látogatók számára (vagy azok közül is csak némely szűkebb csoport számára) engedélyezett. (Speciális esetekben a látogatók bejelentkezés nélkül is küldhetnek be tartalmakat: tipikusan fórum bejegyzések, illetve megjegyzések beküldése esetén ezt bárki számára meg szoktuk engedni.) A regisztráció alapvetően kétféle módon történhet: saját magunkat regisztráljuk, vagy az adminisztrátor regisztrál.

Saját magunk regisztrálása A látogatók maguk végezhetik el a regisztrációt. Ennek módja, hogy a honlap belépésre szolgáló részén megkeressük a Felhasználó létrehozása linket. drupal.hu/kezikonyv/nyomtatobarat

9/135

2010.02.11.


A linkre kattintva megjelenik a Saját adatok oldal, ahol a kívánt felhasználói név és az e-mail cím megadása szükséges. Ezen kívül további adatok megadására is lehet szükség, illetve lehetőség, az adminisztrátor által meghatározott módon. Sajnos egyre gyakrabban van szükség például a Captcha ellenőrzés beiktatására.

(Ha az ábrán látható oldalon a jelszó megadására nincs lehetőség, akkor ennek egy további biztonsági oka van, és a jelszó a megadott e-mail címre fog érkezni. Hamarosan visszatérünk erre az esetre.) A felhasználói név megválasztásánál egyre elterjedtebb megoldás a saját nevünket alkalmazni, főleg olyan oldalaknál, ahol a honlap látogatói nem csak virtuálisan (a honlap látogatóiként), hanem fizikai valójukban is találkozhatnak, ismerhetik egymást. A jelszó kiválasztásánál érdemes a következőket figyelembe venni: olyan jelszót válasszunk, amelyik nem található ki könnyen a személyünk ismeretében sem, minden honlapon más jelszót használjunk, a jelszó lehetőleg tartalmazzon számokat, nagybetűket és írásjeleket is, és legalább 6-8 karakterből álljon. Fontos megjegyezni, hogy az űrlapokon begépelt adatoknak nem lesz végleges hatásuk, amíg az űrlap alján található Beküldés, Mentés vagy hasonló (jelen esetben Felhasználó létrehozása) feliratú gombra kattintva el nem küldjük azokat a honlapot kiszolgáló webszervernek. A weboldal adminisztrátora szigorúbb lépéseket is beiktathat a fenti regisztrációs folyamatba. Ez azonban drupal.hu/kezikonyv/nyomtatobarat

10/135

2010.02.11.


az adminisztrátornak csupán lehetősége, nem minden esetben él vele. Ilyen lépések lehetnek például: A regisztráció során megadott e-mail címre automatikusan érkezhet egy levél, amelyben a leírt teendőket követve véglegesíthetjük a regisztrációt. (E lépés célja, hogy korrekt, működő e-mail címmel rendelkezzen minden regisztrált látogató.) Ebben az esetben a jelszót nem tőlünk várja a weboldal, hanem később tudjuk azt beállítani. A regisztráció adminisztrátori elfogadáshoz kötött is lehet. Ekkor az adminisztrátor elfogadásáig csak zárolt (vagyis pillanatnyilag nem használható) regisztrált felhasználóval rendelkezünk, az adminisztrátor engedélye után pedig Aktív felhasználóvá válunk. (Aktív felhasználónak tehát azt tekintjük, aki be tud jelentkezni az oldalra.)

Az adminisztrátor regisztrál Előfordulhat, hogy az adminisztrátor maga hoz létre a felhasználók számára felhasználói azonosítót. Ebben az esetben a Drupal (vagy az adminisztrátor) egy e-mailben értesíti a leendő felhasználót a regisztráció megtörténtéről. Ennek előnye, hogy a felhasználó megfelelő jogosultságait már ekkor megkaphatja. Zárt oldalakra többnyire csak így lehet bekerülni.

Be- és kijelentkezés Addig, amíg az oldalra be nem jelentkezünk a felhasználónév és jelszó megadásával, mindössze azonosítatlan (anonymous, a továbbiakban névtelen vagy vendég) felhasználóként tudjuk az oldalt használni. Ha ki akarjuk használni a regisztrált felhasználói azonosítónkkal járó plusz szolgáltatásokat, akkor mindenképpen be kell jelentkeznünk. A bejelentkezés legegyszerűbb módja, hogy az űrlapon megadjuk a felhasználónevünket és a jelszavunkat, majd a Belépés gombra kattintunk. A sikeres belépésre utal többek között, hogy az eddig látható Belépés űrlap (célja nem lévén) nem lesz látható. Látszik viszont helyette az ún. Navigációs menü, amelynek címe (felirata) a saját felhasználói nevünk. Itt található a Saját adatok és a Kilépés link, ez utóbbira kattintva ismét névtelen felhasználóvá válunk a Drupal alapú oldal számára.

A böngészőnk (beállításaitól függően) felajánlhatja, hogy a begépelt adatokat elmenti. Ezt csak akkor fogadjuk el, ha a számítógéphez fizikailag más nem tud hozzáférni. Például netkávézóban, iskolai gépteremben nem szabad elmentenünk, mert akkor illetéktelenek használhatják a honlapot a mi nevünkben és jogosultságunkkal. Ha engedélyeztük a belépési adatok elmentését, akkor a legközelebbi látogatáskor a böngészőnk fel fogja ajánlani a korábbi adatokat, így azokat nem kell újra begépelnünk. Biztonsági okokból lehetőleg mindig lépjünk ki a Kilépés link segítségével. Kivételt képezhet az az eset, ha a számítógépünkhöz illetéktelen személyek nem férhetnek hozzá. drupal.hu/kezikonyv/nyomtatobarat

11/135

2010.02.11.


Saját adatok módosítása A regisztrált felhasználók saját adataikat megváltoztathatják a Saját adatok linkre, majd a Szerkesztés fülre kattintva. Az e-mail cím és a jelszó megváltoztatása minden esetben lehetséges. Az adminisztrátor beállításaitól függ, hogy pontosan ezen kívül mit tudunk az oldalon beállítani. A következők szoktak előfordulni: Ha engedélyezve van, megváltoztathatjuk a felhasználónevünket. Ha engedélyezve van, itt feltölthetünk egy saját arcképet, ami például a beküldött tartalmaink, hozzászólásaink mellett jelenhet meg. Többnyelvű oldal esetén a felhasználói felület nyelvét megváltoztathatjuk. Ha engedélyezve van, az időzóna megadásával korrigálhatjuk a szerver és a mi számítógépünk közötti esetleges időzóna-eltérést. Ha az oldal többféle kinézettel (sminkkel) rendelkezik, beállíthatjuk a számunkra megfelelőt. Ha engedélyezve van, a hozzászólásainknál alapértelmezetten megjelenő aláírás szöveget is megadhatunk.


12/135

2010.02.11.


Tartalmak kezelése A Drupal tartalomkezelő rendszer fő célja, hogy a honlap tartalmait (oldalait) kezelje, vagyis lehetővé tegye az oldalak létrehozását, módosítását, törlését, megtekintését. (Természetesen a szolgáltatásokat csak az adott feladat ellátására jogosult felhasználók érhetik el.)

Tartalmak létrehozása Amennyiben rendelkezünk megfelelő jogosultságokkal, a navigációs menün megjelenik a Tartalom beküldése link. drupal.hu/kezikonyv/nyomtatobarat

13/135

2010.02.11.


Itt olyan tartalom típusok közül választhatunk, amelyek beküldésére jogunk van. (Az ábra esetén csak Oldal típusú tartalmat tudunk beküldeni.)

A Cím a beküldött oldal címét, míg a Törzs a tartalom érdemi részét várja.

Összefoglaló és teljes nézet A tartalmunk beküldésekor gondoljunk arra, hogy egyes esetekben (pl. címlapra küldött tartalom esetén) nem a teljes tartalom, hanem annak csak egy összefoglalója/előnézete jelenik meg. A törzs megadása felett az összefoglaló és a teljes nézet viszonyát adhatjuk meg. Az alapértelmezett esetben az összefoglaló a teljes nézetben is megjelenik, tehát mintegy előzetes funkcionál. Hogy a tartalomnak mennyi része legyen az összefoglaló, az több módon is eldőlhet. Az alapbeállítások szerint néhány száz karakternyi szöveg kerül automatikusan az összefoglalóba. Ha nem szeretnénk ezt az automatizmust dolgozni, akkor az Összefoglaló elválasztása a kurzornál gombbal ezt kikapcsolhatjuk, és mi magunk dönthetünk róla.


14/135

2010.02.11.


Beviteli forma A Törzs mező alatt pontos információkat kaphatunk arra nézve, hogy e beküldendő tartalmat hogyan kell megadnunk. Például a web és e-mail címek automatikusan linkként fognak megjelenni. Ezen túl a HTML nyelv itt felsorolt tagjait is használhatjuk. Nem kell azonban megijedni, az adatbevitelre többnyire kényelmesebb, kevesebb szaktudást igénylő eszközök is a rendelkezésünkre állnak. Mindenképpen figyelembe kell azonban venni, hogy a weboldalak szövegformázásának logikája (az eltérő megjelenítési logika miatt) eléggé eltér a hagyományos, papír alapú szövegszerkesztéstől. Előfordulhat, hogy a Beküldés nem, csak az Előnézet gomb látható. Ez arra utal, hogy az előnézet használata kötelező, csak második lépésben fogjuk megtalálni a Beküldés gombot.

Vizuális szerkesztő A következő ábrán látszik, hogy a tartalmak bevitele a vizuális szerkesztő segítségével hasonló módon oldható meg, mint ahogy azt a szövegszerkesztőnkben is megszokhattuk. Érdemes azonban figyelembe venni, hogy egy weboldal – eltérően egy nyomtatásra szánt, szövegszerkesztőben készített dokumentumhoz képest, – akár minden látogató esetén máshogy fog kinézni. Ezért érdemes csupán alapvető formázási tevékenységre szorítkozni.


15/135

2010.02.11.


Előnézet Előnézet kérése esetén megtekinthetjük, milyen lesz az oldalunk, ha véglegesen beküldjük. (Ha most kilépnénk a szerkesztési oldalról, és nem a Beküldés gombra kattintanánk, akkor az eddig bevitt tartalom elveszne.)

Az oldal Bevezető előnézete tipikusan akkor fog szerephez jutni, ha az éppen beküldés alatt álló tartalom a drupal.hu/kezikonyv/nyomtatobarat

16/135

2010.02.11.


kezdőoldalon is megjelenő hír lesz. Általában a Teljes tartalom előnézetével kell elsősorban foglalkoznunk. Itt még szükség esetén módosíthatjuk az oldal tartalmát, majd ha kész vagyunk, Beküldés. Ezután a tartalmunk kész.

További információk megadása Bizonyos esetben a címen és a törzsön kívül további információk megadására is van lehetőség. Néhány eset ezek közül: Fórum téma beküldése esetén kiválaszthatjuk, hogy melyik fórumhoz tartozzon:

Bizonyos esetekben (tipikusan hírek esetén) megadhatunk egy vagy több kulcsszót, amellyel a tartalom témáját jelöljük. A kulcsszavakat (még pontosabban kulcskifejezéseket, mivel több szavasak is lehetnek) vesszővel kell egymástól elválasztani.

Az így beküldött tartalmak esetén megjelennek a témák is:


17/135

2010.02.11.


A téma felirata linkként is működik, rákattintva a témához tartozó tartalmak listája érhető el. Egyes esetekben (tartalomtípustól és jogosultságoktól függően) a tartalom mellékleteként csatolt állományok is alkalmazhatók. (A melléklet állományokra nézve méret- és típuskorlátozás lehet érvényben.)

Az állomány helyét és nevét a Tallózás gombbal adhatjuk meg. A Csatol gomb elvégzi a tényleges feltöltést, majd Leírást adhatunk meg, ami a fájlnév helyett lesz látható.

Egyenlőre nem foglalkozunk azzal a kérdéssel, hogy az adott oldal hol (pl. milyen menüpontban) lesz elérhető a honlapunkon.

Tartalom szerkesztés, törlés Ha később visszalátogatunk az előzőleg létrehozott oldalunkra, akkor az oldal címe mellett az aktuális Megtekintés fül mellett a Szerkesztés fület is megfigyelhetjük. drupal.hu/kezikonyv/nyomtatobarat

18/135

2010.02.11.


A Szerkesztés fülön a beküldéshez hasonlóan módosítani vagy akár törölni tudjuk a tartalmunkat. Figyelem! A tartalom törlése nem visszavonható művelet! Éppen ezért javasolt, hogy inkább a tartalom rejtetté tételét (a Közzétett jelző kikapcsolását) alkalmazzuk.

Telepítés lépésről lépésre A Drupal tartalomkezelő a telepítést és a frissítést lehetővé tevő grafikus telepítő rendszerrel rendelkezik. Ennek működéséhez azonban célszerű egy megfelelő környezetet összeállítanunk, amely a Drupal számára a lehető legjobb futási feltételeket biztosítja. Érdemes figyelmesen elolvasni a telepítési lépéseket és tippeket. Egyáltalán nem mindegy, hogy a Drupal telepítését saját szerverünkön akarjuk végrehajtani, vagy egy tárhelyszolgáltatónál szeretnénk elhelyezni új Drupal oldalunkat. Előbbi esetben gyors hatást tudunk gyakorolni a rendszerre, a szükséges beállításokat hamar el tudjuk végezni. Utóbbi esetben viszont lehet olyan szerencsénk, hogy a beállítások megfelelnek a telepítéshez, és így akár könnyebb dolgunk is lehet; előfordulhat azonban, hogy a rendszergazdával kell egyeztetnünk bizonyos módosítások érdekében. A telepítéssel kapcsolatos problémák és kérdések a fórum megfelelő témakörében feltehetőek.

Milyen rendszerre telepíthető a Drupal? A Drupal tartalomkezelő rendszer mindenképpen igényel egy PHP feldolgozási képességgel felvértezett webkiszolgálót. Javasolt az Apache webszerver szoftver valamely aktuális változatának használata. Az Apache és a PHP telepítéséről Windows rendszerre a Weblabor egyik cikkében bővebben lehet olvasni. A Drupal a Microsoft Internet Information Server (IIS) használatával is tud működni, azonban ilyen kiszolgálón többmindenre kell figyelnünk, hogy biztonságos legyen a telepítésünk, ráadásul a szép webcímek használatától eleve elesünk. Ezért az IIS szerver nem a legjobb választás Drupal működtetésére. Unix/Linux rendszeren szinte biztos, hogy már eleve rendelkezésre áll egy PHP képes Apache webkiszolgáló. A Drupal igazán kényelmesen működik külön virtuális hoszton, de bármilyen könyvtárrendszerbe is beilleszthető, egy meglévő webhely alkönyvtárában is kiválóan működtethető. Az adatok tárolásához MySQL vagy PostgreSQL adatbáziskezelő rendszer használata támogatott. Ezért valamelyik adatbázis szerver jelenléte feltétlenül szükséges. Ideális esetben a Drupal adatainak tárolásához egy külön adatbázis szintű felhasználót kaphatunk (hozhatunk létre), és egy különálló adatbázist használhatunk erre. A Drupalnak az sem okoz ugyanakkor problémát, hogy egy adatbázison osztozzon más programokkal, hiszen a használt táblák neveit előtagokkal láthatjuk el, és így az azonos adatbázist használó más programok tábláival elkerülhetjük a keveredést. Ha saját magunknak kell adatbáziskezelőt telepíteni, akkor ebben a Weblabor erről szóló cikke nagy szolgálatot tehet. A cikk a PHPMyAdmin telepítését is leírja, melynek nagy hasznát fogjuk venni. Annak érdekében, hogy a webhely leendő regisztrált felhasználói megkaphassák induló jelszavukat, a szerverünkön telepített PHP-nek támogatnia kell a levélküldést. Ez már az első adminisztrátor felhasználó létrehozásakor is érdekes lehet, ezért fontos rá odafigyelni. Ha szolgáltatót választunk Drupal webhelyünk működtetésére, akkor mindenképpen ellenőrizzük, hogy a PHP-ből történő levélküldéssel nem lesz probléma. Megkerülő megoldásokat kell használnunk, ha a szolgáltatónk a levélküldést nem támogatja. drupal.hu/kezikonyv/nyomtatobarat

19/135

2010.02.11.


Fontos megemlíteni, hogy a Drupal kereső indexelője és más elemei időzített feladatok formájában, a weblap megjelenítő lekérésektől lehetőleg elkülönítve futtatandók. Ehhez a webszerverünknek cron támogatással kell rendelkeznie, vagy a poormanscron modult kell telepítenünk a Drupal rendeltetésszerű üzemeltetéséhez. Nem feltétlenül szükséges, de Apache szerver használata esetén jelentősen javíthat a teljesítményen, könnyítheti a telepítést illetve jobb kereső helyezéseket biztosíthat a nemzetközi keresőkben is, ha a webszerverünk feldolgozza a Drupal által adott .htaccess fájlt és biztosítja a mod_rewrite modult. Ezt sajnos az ingyenes szolgáltatók nem szokták engedélyezni. A továbbiakban feltételezzük, hogy egy támogatott adatbázis, egy webszerver és egy PHP értelmező rendelkezésre áll, a Drupal telepítője úgyis figyelmeztet, ha ezen eszközök verziószáma nem kielégítő.

Telepítés előkészítése saját Windowsos gépen Kezdő Drupal felhasználóként ajánlott, hogy legalább első alkalommal a saját gépünkön kialakított lokális szervert használjuk az ismerkedéshez. Mivel a (PHP, Apache, MySQL) szerver alkalmazások önálló telepítése nem mindig egyszerű feladat, próbálkozhatunk előre csomagolt, és minden szükséges alkalmazást telepítő és bekonfiguráló programokkal is. Ezek közül csak egyet nézünk meg közelebbről, a többi alkalmazása hasonló.

XAMPP Windows alatt az egyik ajánlott csomag az XAMPP. Ennek segítségével ki tudunk alakítani egy a Drupal számára megfelelő futtatókörnyezetet (szervert). A letöltött telepítőprogram lényegében a telepítéskor szokásos kérdéseket teszi fel (pl. a telepítési könyvtár). A telepítés után a Start menüből és parancssorból is vezérelhetjük az alkalmazásokat, de legegyszerűbb az XAMPP Control Panel használata. A Control Panellel az Apache és a MySQL futtatását kell kezdeményeznünk.


20/135

2010.02.11.


Telepítés után A webszerver telepítéskor megadott könyvtáron belül létrejött a htdocs nevű alkönyvtár. E könyvtár tartalmát tekintjük a webszerver dokumentum-könyvtárának, vagyis (elsősorban) e könyvtár tartalmát tudja a webszerver statikus vagy dinamikus módon kiszolgálni. Legegyszerűbb lehetőség tehát itt létrehozni pl. egy drupal nevű alkönyvtárat, és a telepítés során ebbe kicsomagolni a letöltött telepítő fájlok tartalmát. Ha begépeljük a böngészőnk cím sorába a http://localhost útvonalat, akkor az XAMPP admin felülete, a http://localhost/pma esetén a PhpMyAdmin oldala, míg a http://localhost/drupal esetén a majdani Drupal oldalunk fog elindulni. Otthoni, tanulásra szánt telepítés esetén alapértelmezetten a root nevű és jelszó nélküli felhasználót fogjuk tudni az adatbázis elérésére használni.

A fájlrendszer előkészítése Letöltés A Drupal alapvető telepítéséhez elegendő annyit tudnunk, hogy szükségünk van a Drupal alaprendszerre és a magyar fordítás csomagjára. A következő fájlokat kell letöltenünk: A Drupal alapcsomagja: http://ftp.drupal.org/files/projects/drupal-6.11.tar.gz A magyar fordítás: http://ftp.drupal.org/files/projects/hu-6.x-1.0.tar.gz Elvileg a drupal.org-ról is letölthetnénk a magyar fordítás csomagot, de a nálunk megtalálható csomag jobban használható, így a telepítési leírást is ehhez igazítottuk.


21/135

2010.02.11.


Kitömörítés Amennyiben frissen telepített webszerverrel van dolgunk, vagy szolgáltatónknál saját felhasználói mappánkban még semmi sem található, választhatjuk ezt a mappát is a Drupal telepítésére. Ha azonban meglévő honlaphoz akarjuk illeszteni a tartalomkezelőt, akkor egy alkönyvtárat is nyithatunk a Drupal állományai számára a web területünkön. (Néhány későbbi kellemetlenséget elkerülhetünk, ha nem alkönyvtárba, hanem (al)domainre telepítünk.) Figyeljünk arra, hogy a Drupal csomag egy könyvtárban tartalmazza a szállított állományokat. Erre a könyvtárra nem lesz szükségünk (vagy legalábbis nem ezen a néven), csak a tartalmára. A következőképpen tudjuk kitömöríteni a Drupal csomag tartalmát: UNIX alatt parancssorból: $ tar -zxvf drupal-6.10.tar.gz Majd másoljuk be a kapott állományokat a kiválasztott könyvtárba. Windows alatt: Szükségünk lesz egy olyan kitömörítő programra, ami képes a .tgz, .tar vagy .tar.gz állományok kezelésére. A népszerű WinZip, Total Commander és WinRAR programok mind képesek erre. Ne felejtsük el a kicsomagolt állományokat a kiválasztott weben elérhető könyvtárba másolni. Ugyanebbe a könyvtárba kell kitömörítenünk a magyar fordításban kapott fájlokat is. A magyar csomag úgy van kialakítva, hogy egyrészt a meglévő Drupal könyvtárrendszerbe helyezi saját fájljait, másrészt egy új telepítési profilt is ad a rendszerhez. Gondoskodjunk arról, hogy a magyar fordítás csomag tartalmát is a Drupal könyvtárába másoljuk. Ennek eredményeképpen egy olyan könyvtárrendszert kell kapnunk, amelyben a Drupal alapcsomagjának és a magyar nyelvű telepítést lehetővé tevő telepítési profilnak is megjelennek a könyvtárai és fájljai. A továbbiakban az itt látható (webről elérhető) tartalmú könyvtárat nevezzük a Drupal könyvtárának.

Jogosultságok beállítása Unix rendszeren a bemásolt állományok alapértelmezett jogosultsága (állományokra 644, könyvtárakra 755) biztos, hogy alapesetben megfelelő lesz. Ha mégsem, akkor a chmod paranccsal tudjuk a jogosultságokat megváltoztatni. Hozzunk létre a Drupal telepítési könyvtárában egy files nevű mappát. Ebben fogja a Drupal tárolni a feltöltött állományokat, ezért a webszerver felhasználójának joga kell legyen a könyvtárba történő állomány mentésre. Ezt elérhetjük úgy, hogy a webszerver felhasználójához rendeljük a könyvtárat (a chown parancssal), vagy 777-es jogosultságot adunk rá: chmod 777 files. Windows rendszeren is annak megoldása szükséges, hogy a Drupal lássa a mappájában lévő állományokat, a files könyvtárba pedig írni is tudjon. A telepítés során szükség lesz arra, hogy a sites/default/settings.php fájlt a telepítő írni tudja. drupal.hu/kezikonyv/nyomtatobarat

22/135

2010.02.11.


Addig nem tudjuk megkezdeni a telepítést, amíg ez a fájl nem írható, ezért a telepítés előtt a PHP számára ezt ugyancsak írhatóvá kell tennünk. Annak érdekében, hogy a telepítés után ne felejtsük el ezt a jogosultságot visszavonni, a Drupal figyelmeztetni fog bennünket a telepítés után az írhatóság megszüntetésére. Ha nem vonjuk vissza a PHP-től az írhatóságot, akkor az biztonsági kockázatot jelent a Drupal számára.

Fájlok feltöltése a szerverre Ha mindezeket a műveleteket nem közvetlenül a szerveren végezzük el, szükségünk lesz még egy FTP (vagy jobb szolgáltatók esetén SCP) programra, amivel a fájlokat fel tudjuk tölteni a szerverre. Ügyeljünk arra, hogy a jogosultságokat az FTP programunk nem feltétlenül viszi át, így a szerveren ezt külön be kell állítanunk. Ráadásul a rejtett fájlokat nem mindig mutatják ezek a programok, és a .htaccess ilyennek minősül. Ezért külön figyeljünk arra oda, hogy ezt is sikerült feltöltenünk (sajnos az ingyenes szolgáltatók nagy része ezt nem engedi, ott nem fogjuk tudni ezt a fájlt feltenni).

Webhelyünk biztonsága és a .htaccess A Drupal többek között biztonságosságával tűnik ki a széles körben használt, meggondolatlanul fejlesztett rendszerek táborából. Nem árt azonban, ha mi is odafigyelünk a biztonság szavatolására. Ennek alapvető eszköze az, hogy a Drupal csomagban szállított .htaccess jelenlétéről és végrahajtásáról gondoskodunk. Ez az állomány garantálja, hogy a PHP megfelelő biztonsági beállításokkal futtassa a Drupal csomagban található szkripteket, valamint hogy a nagyvilág számára nem publikus állományok ne legyenek elérhetőek böngészőből. Annak érdekében, hogy a .htaccess állomány parancsai helyesen feldolgozásra kerüljenek, a Drupal telepítési mappájára az Apache szerverben az AllowOverride All kitételnek kell szerepelnie. Ha ez teljesül, akkor nem tudjuk a Drupal mappában található különböző .module, .engine és hasonló egyedi kiterjesztésekkel ellátott állományokat böngészőből elérni, és a PHP beállításai is megfelelőek lesznek. Sajnos ingyenes szolgáltatóknál a .htaccess alkalmazását jellemzően nem engedélyezik, ott ennek hátrányaival és lehetséges biztonsági problémáival együtt kell élni.

Az adatbázis előkészítése Amennyiben saját adatbázis szerverünket üzemeltetjük, mindenképpen létre kell hoznunk a Drupal számára egy adatbázist és egy felhasználót, mely ebben az adatbázisban műveleteket tud végezni. Ha szolgáltatónk biztosítja számunkra az adatbázist, akkor onnan kell megtudnunk a használható adatbázis nevét, illetve a műveletek végzésére jogosult felhasználó nevét és jelszavát. A Drupal MySQL és PostgreSQL adatbáziskezelőkkel tud együtt dolgozni. Sajnos néhány kiegészítő nem működik PostreSQL-lel, a népszerűbb kiegészítők azonban mindenképpen elérhetőek mindkét adatbázis rendszeren. Figyeljünk arra, hogy a Drupal telepítéséhez (és később a modulok bekapcsolásakor valamint frissítéskor) ennek a felhasználónak táblák létrehozására (CREATE TABLE), meglévő táblák módosítására (ALTER TABLE) és táblák törlésére (DROP TABLE) is joga kell, hogy legyen. A Drupal telepítője figyelmeztet, ha valamilyen szükséges művelet nem végezhető el a megadott névvel és jelszóval.

MySQL beállítása Az alábbiakban a MySQL 4.1 vagy újabb esetén követendő (azonos gépen futó szerverre vonatkozó) lépéseket taglaljuk. Nem érdemes MySQL 4.1-nél korábbi MySQL verziót használni, mert az nem támogatja jól a Drupal által is használt UTF-8 kódolást. Parancssorból a következőképpen van lehetőségünk az utasítások megadására: drupal.hu/kezikonyv/nyomtatobarat

23/135

2010.02.11.


Indítsuk el a MySQL kliens programot (ahol 'jelszo' a root felhasználó jelszava): $ mysql -uroot -pjelszo

A megjelenõ parancssorban hozzuk létre az adatbázist: CREATE DATABASE drupal DEFAULT CHARSET utf8 DEFAULT COLLATE utf8_hungarian_ci; Ha véletlenül nincs magyar egybevetés támogatás az általunk használt MySQL rendszeren, használhatjuk az utf8_general_ci egybevetést is. Vegyük fel a Drupal felhasználót (a jelszó szükség szerinti megváltoztatásával): GRANT ALL PRIVILEGES ON drupal.* TO drupal@localhost IDENTIFIED BY 'titkosjelszo';

Ha PHP 4-gyel szeretnénk a MySQL 4.1-es vagy újabb adatbázisunkat használni, akkor feltétlenül a régebbi jelszó kódolási formát kell használnunk, mert a PHP 4 nem készült fel az újabb MySQL által alkalmazott kódolásra. Ha ezt a PHP-MySQL kombinációt használjuk, akkor adjuk ki a következő parancsot: SET PASSWORD FOR 'drupal'@'localhost' = OLD_PASSWORD('titkosjelszo');. Így már PHP 4-gyel tudunk majd csatlakozni.

PHPMyAdmin használata Ezeket a műveleteket a PHPMyAdmin webes felhasználói felületén is elvégezhetjük, amennyiben megfelelő jogosultsággal rendelkezünk adatbázisok és felhasználók létrehozására.

Ha csak egy adatbázisban dolgozhatunk egy adott felhasználóval, akkor ezt kell elfogadnunk. A Drupal számára ezzel előkészítettük az alaprendszert, elindulhat a telepítés.

A telepítő használata Miután előkészítettük a fájlrendszert és az adatbázis rendszert, már csak a webes telepítőt kell futtatnunk, amely beállítja a Drupal számára a használt adatbázist, nevet és felhasználót, illetve létrehozza az alapértelmezésben alkalmazott adatbázis szerkezetet. Ennek elindításához látogassunk el webböngészőnkkel a http://example.com/drupal/install.php címre, ahol a http://example.com/drupal/ az a hoszt illetve könyvtár webszerveren elérhető címe, ahova a fájlokat előkészítettük. Itt a magyar telepítést alkalmazva egy telepítési profil választó képernyő fogad bennünket (angol nyelven). Csak a második profilt választva van lehetőségünk a teljesen magyar nyelvű telepítést követően azonnal magyar nyelven használni a rendszert, ezért válasszuk ezt. Az első profil a Drupal rendszerrel alapkiépítésben jár, ez nem fogja a Drupal felületét a telepítés során magyarítani. A profil választást követően a profilhoz elérhető nyelvet is ki tudjuk választani. Itt a magyar mellett döntünk.


24/135

2010.02.11.


Innentől kezdve magyarul szól hozzánk a telepítő. Ha valamit elrontottunk az előkészítésben (például nem írható a telepítő számára a sites/all/default.php fájl), akkor itt fog figyelmeztetni bennünket arra, hogy addig nem folytathatjuk a telepítést, amíg ez nem megoldott. A korábban ismertetett lépéseket követve azonban azonnal az adatbázis beállító képernyőt kell kapnunk. Itt alapértelmezésben csak a felső űrlapelem csoport látható, az alsót nekünk kell lenyitnunk, ha a számunkra fontos adatokat csak ott tudjuk beállítani. Sok webszerveren elegendő, ha az aktuális gépen feltételezzük az adatbázis kiszolgálót, és nem használunk speciális portot vagy táblázat név előtagokat. Ilyenkor a haladó beállításokkal nem kell törődni, csak a használt adatbázis típust, adatbázis nevet, felhasználói nevet és jelszót kell megadni a korábban beállított vagy a szolgáltatótól kapott adatok szerint.

Továbblépve a rendszer megpróbálja ellenőrizni, hogy minden szükséges adatbázis művelet elvégezhető-e. Ha a telepítéshez elengedhetetlen műveletek valamelyikére a megadott adatbázis felhasználó nem jogosult, vagy valamilyen adatot hibásan adtunk meg, akkor erre figyelmeztet, és a hibát meg kell oldanunk. Ha azonban minden jól megy, akkor a telepítő beállítja a tábláinkat, és a magyar nyelvű felülethez szükséges szövegeket is az adatbázisba tölti. Egy olyan telepítési sikerességet mutató képernyő fogad bennünket, ami jelzi, hogy nem szabad elfelejtenünk a beállítási fájl írási jogának visszavonását.


25/135

2010.02.11.


A Webhely információk alatt adhatjuk meg a weboldal egészére vonatkozó néhány alapbeállítást. A weboldal neve nemcsak az oldal felső részén, a logó mellett jelenik meg, hanem a böngésző címsorában is. Az email cím mezőben megadott cím fog feladóként szerepelni minden olyan levélben, amelyet a rendszer (pl. regisztrációkor) küld, ezért erre a címre fog válasz is érkezni a látogatók részéről.

Az adminisztrátor regisztrációja A telepítés következő lépéseként létre kell hoznunk egy felhasználót, amely a továbbiakban minden jogosultsággal rendelkezni fog a rendszer adminisztrációját illetően. Ez lesz az első számú felhasználó. Először a kívánt felhasználói nevet és email címünket kell megadnunk. A megadott felhasználónév a belépéshez lesz szükséges, de a további látogatók is ezen a néven fognak bennünket látni. (Itt érdemes hangsúlyozni, hogy van lehetőségünk a magyar helyesírás szabályai szerint leírni a nevünket.)


26/135

2010.02.11.


Az e-mail cím nem fog az oldalon publikusan megjelenni, maga a Drupal rendszer küldhet rá fontos üzeneteket, vagy kapcsolati űrlapon keresztül feladott üzenetek lesznek erre a címre elküldve. A jelszó megadásánál egyből értékelést is kaphatunk a jelszavunk „erősségét” illetően. (Érdemes a lehető leginkább követni az olvasható információkat, hiszen egy Drupal rendszer esetén az adminisztrátor jelszava a honlap feletti teljes hatalmat jelenti.)

Webszerver beállítások


27/135

2010.02.11.


Az alapértelmezett időzónát a látogatóközönség zömének időzónája szerint érdemes beállítani. Ha a webszerverünk szolgáltatásai lehetővé teszik, érdemes a rövid webcímek használatát engedélyezni. (Ennek célja a ?q= webcím résztől való megszabadulás.) Ha nem tudjuk kiválasztani az Engedélyezett lehetőséget, a szolgálatatás megfelelő működése érdekében a webszerver konfigurálásához kell nyúlnunk. Végül a frissítési figyelmeztetéseket is érdemes bekapcsolva tartani, hogy az újabb, hibajavító verziók megjelenése esetén a hibákat egyből orvosolni is tudjuk.

A telepítés sikeresen befejeződött, most már a működő webhelyre léphetünk.


28/135

2010.02.11.


Simítások a frissen telepített rendszeren A webhely állapotának összefoglalása Amikor megkíséreljük első alkalommal megtekinteni a webhely adminisztrációs oldalát, biztosan egy piros dobozban írt figyelmeztetés fogad majd bennünket az oldal tetején. Ez figyelmeztet arra, hogy még nincs minden rendben a Drupal webhelyünk beállításával. Kattintsunk az állapot felmérését lehetővé tevő linkre!

Itt legalább egy, az időzített feladatokkal kapcsolatos hibát fogunk kapni (A cron nem futott...), ami felhívja a figyelmünket, hogy nem állítottuk még be az időzített feladatokat. De ugyanitt kapunk figyelmeztetést akkor is, ha a korábbi lépésekben a beállítás fájlt nem tettük újra írásvédetté, vagy a fájlok feltöltésére használt könyvtárat nem állítottuk be megfelelően. Ez a képernyő tulajdonképpen a Drupal környezetének megfelelőségéről ad egy áttekintő jelentést számunkra.

Időzített feladatok Egy webhely karbantartása során gyakran felmerülnek olyan feladatok, melyeket rendszeresen végre kell hajtani. A Drupal például rögzíti a rendszerben történt fontosabb eseményeket és az azokhoz kapcsolódó információkat. Ha ez az eseménynapló folyamatosan csak nőne, akkor egyrészt nehéz lenne megtalálni az utóbbi idők fontosabb eseményeit egy esetleges hiba felderítésekor, másrészt az adatbázisunk kezelése is feleslegesen lassulna. Ezért célszerű idegőrlő-időre kitörölni a régebbi naplóbejegyzéseket. Természetesen még számos ilyen időzített feladat van illetve lehet egy Drupal webhelyen, például a változott tartalmak újraindexelése a kereső számára, vagy egy bizonyos időpontban megjelenítendő tartalom közzététele. A Drupal modulok időzített feladatait a cron.php futtatja le, melynek neve a Unix/Linux rendszereken elérhető cron szolgáltatás nevére utal. Amennyiben kiszolgálónkon elérhető ez a szolgálatatás, akkor érdemes ennek segítségével beállítani, hogy adott időközönként lefusson a cron.php. Attól függően, hogy milyen szolgáltatónál helyeztük el webhelyünket, különböző módja lehet az időzített feladatok beállításának. Lehetséges, hogy emailben kell felkeresnünk a rendszergazdát, előfordulhat, hogy webes felületen tudjuk menedzselni az időzítéseket (ilyen még akár ingyenes szerveren is előfordulhat). Ha a saját szerverünket üzemeltetjük, akkor segítségünkre lehet az alapcsomag scripts könyvtárában drupal.hu/kezikonyv/nyomtatobarat

29/135

2010.02.11.

található


cron-lynx.sh

nevű állomány, ami a javasolt meghívási módot mutatja.

#!/bin/sh # $Id: cron-lynx.sh,v 1.3 2006/08/22 07:38:24 dries Exp $ /usr/bin/lynx -source http://example.com/cron.php > /dev/null 2>&1

Ebben a webcímet a webhelyünk nyilvánosan is elérhető címére kell átírni, hiszen ha nem egy nyilvános címet adunk meg, bizonyos feladatok nem fognak helyesen lefutni. Ennek az állománynak a módosítása azonban nem elegendő. Tudatnunk kell az operációs rendszerrel, hogy szeretnénk adott időközönként lefuttatni ezt a parancsot. A crontab paranccsal vegyük fel a következő bejegyzést az időzítési listánkba – értelemszerűen testre szabva a cron-lynx.sh elérési útját: 00 * * * * /home/www/drupal/scripts/cron-lynx.sh

Ezzel a bejegyzéssel a Drupal időzített feladatai óránként futnak majd le, de ettől eltérő beállítás is megoldható – bizonyos webhelyek sokkal gyakoribb futtatást igényelhetnek a feladatok függvényében. Előfordulhat, hogy nincs cron lehetőség a kiszolgálón. Ekkor sem kell kétségbe esni, hiszen elérhető egy poormanscron nevű egyszerű modul, mely a Drupal rendszerbe épülve próbálja meg megvalósítani az időzítés feladatát. Működésének lényege, hogy minden egyes oldallekérés végén ellenőrzi, hogy eltelt-e már a konfigurációs oldalán megadott időtartam. Amennyiben eltelt, akkor meghívja az összes időzített feladatot. Mivel a végrehajtás az oldal kimenetének előállítása után történik, a látogató nem érzékel majd semmit abból, hogy az időzített feladatok is ebben a kérésben hajtódtak végre. Megjegyzés: Fontos tudni, hogy a Drupal saját feladatai külön-külön belső időzítési közökkel futnak le. A hírolvasó például minden egyes RSS forrásra beállíthatóvá teszi a letöltési időközt, az említett eseménynapló pedig testre szabhatóvá teszi a bejegyzések elévülési idejét. Mivel a cron.php futtatása ezekkel az időszakokkal nem feltétlenül van szinkronban, ezért csak az garantálható, hogy az időszak elteltét követő első futásnál hajtódnak végre az oda időzített feladatok. Éppen ezért célszerű lehet egy óránál is rövidebb időközt választani, ez természetesen a gyakorlatban finomítható.

Rövid webcímek A Drupal alaptelepítésben a q paramétert használja webcímeiben arra, hogy a rendszerben azonosított elérési utat megadja. Így egy tartalom elérése a következőképpen történik: http://example.com/drupal/index.php?q=node/12

Amellett, hogy ez nem feltétlenül mutat jól, a keresők indexelőrobotjai sem szeretik a dinamikusnak látszó, paraméterekkel zsúfolt webcímeket. Minden mai webhely alapvető érdeke a keresők adatbázisában való jobb részvétel, ezért nem kérdés, hogy ha ennek eléréséért tehetünk, akkor ne szalasszuk el a lehetőséget. A Drupal is lehetővé teszi, hogy a fenti webcímet erre egyszerűsítsük: http://example.com/drupal/node/12

Webfejlesztői szemszögből nézve számos módszer van ilyen rövid webcímek készítésére. A Drupal fejlesztői az Apache mod_rewrite modul használatát támogatják. Ahhoz, hogy rövid webcímeinket működésre bírjuk, támogatást kell biztosítanunk ehhez a kiszolgáló modulhoz. Windows rendszeren az Apache httpd.conf beállítási állományában keressük meg azokat a LoadModule (és esetleg AddModule) sorokat, melyek a mod_rewrite modulra hivatkoznak. Vegyük ki ezen sorok elejéről a megjegyzést jelző kettőskeresztet és indítsuk újra a webkiszolgálót. Unix/Linux drupal.hu/kezikonyv/nyomtatobarat

30/135

2010.02.11.


esetében más eljárást kell követnünk, ez azonban rendszerfüggő, ezért itt nem részletezzük. Amennyiben alkönyvtárba telepítettük a Drupal rendszert, még egy dologra kell figyelnünk, mégpedig, hogy a .htaccess fájlunkban megfelelően adjuk meg ezt a mappát a Rewrite számára. A .htaccess fájlban a RewriteBase sora elől vegyük ki a kettőskeresztet, és értékeként adjuk meg a telepítésre használt könyvtár nevét. Mindenképpen gondoskodni kell arról, hogy az Apache a .htaccess fájl tartalmát feldolgozza. Ehhez a Drupal könyvtárára célszerű AllowOverride All jogosultságot adni az Apache beállításainál. Így a rendszer számára lehetővé válik a mod_rewrite kihasználása mellett a hatékonyabb gyorstárazás és a legjobb PHP környezet használata is. A kiszolgálót már felkészítettük, így nincs más hátra, mint meglátogatni az Adminisztráció » Webhely beállítása » Rövid webcímek oldalt, és bekapcsolni a rövid webcímek használatát. Láthatjuk, hogy ez nem olyan egyszerű, hiszen a Drupal nem engedélyezi ennek bekapcsolását, amíg meg nem győzködött róla, hogy az valóban működik. Az űrlap elem magyarázat végén található linkre kattintva próbálja ezt ellenőrizni, siker esetén pedig lehetővé teszi ennek bekapcsolását. Ha sikertelen a próba, akkor megóv bennünket attól, hogy az adatbázisban kelljen keresgélnünk a visszaállítás mikéntjét, a rendszer tovább működik, még ha kicsit csúnyább webcímek használatával is. Ezek után ha minden jól ment, akkor a q elérési paramétert a webcímeinkben nem fogjuk többet látni.

Fájlrendszer beállítása Előfordulhat, hogy a fájlrendszerhez kapcsolódó hibaüzenetet kapunk az Állapotjelentésnél. Ekkor kattintsunk a felajánlott fájlrendszer beállítások linkre, és a megoldás már meg is érkezik, amennyiben van joga könyvtárat létrehozni a webszervert futtató felhasználónak. Amennyiben nincs, „kézzel” kell azt létrehoznunk, és esetleg a jogokat beállítanunk.


31/135

2010.02.11.


Be kell állíthatjuk az ideiglenes fájlok könyvtárát is. Ez az a hely, ahova a feltöltött fájlok kerülnek az előnézet során, és szintén írhatónak kell lennie a webszerver számára. (Linux alatt erre a célra a /tmp, míg Windows alatt a C:\temp könyvtár szolgál. E könyvtár tartalmát bármikor, indok nélkül törölheti pl. a rendszergazda.) Végül választhatunk a nyilvános vagy a privát letöltési mód között. Figyelem: ezt a beállítást a rendszer működése közben (ha már csatoltunk állományt valamelyik tartalomhoz) nem célszerű megváltoztatni, mivel ennek módosítása problémákat okozhat. Privát módot akkor érdemes választani, ha bármilyen letöltendő állománynál esetleg elő fog fordulni, hogy nem mindenki számára szeretnénk elérhetővé tenni, vagy épp a letöltések számát szeretnénk megtudni. Ha egyik ok miatt sem szükséges módosítanunk, hagyhatjuk a nyilvános beállítást.

Webhely karbantartás Ha a honlapot nyilvános helyen fejlesztjük, célszerű azt offline állapotba helyezni, és csak a honlap publikálható állapotba kerülésekor visszahelyezni online állapotba. (Később, pl. a Drupal frissítése, egy modul telepítése, vagy éppen biztonsági mentés készítése esetén is érdemes ezt a lehetőséget használni.)


32/135

2010.02.11.


Mindezt a Webhely karbantartás adminisztrációs oldalon tehetjük meg. Az offline kapcsolón túl a látogatók számára megjelenítendő üzenetünket is megfogalmazhatjuk.

Az oldal offline állapotára folyamatosan figyelmeztet bennünket (az adminisztrátort) a Drupal oldalunk: minden oldal tetején olvashatjuk az „Offline módú működés” feliratot. Az offline állapotnak még „veszélye” az is, hogy kilépés után maga az adminisztrátor sem fog tudni a szokásos módon belépni, hiszen a nyitóoldalon csak az előbb megfogalmazott üzenet olvasható, nincs lehetőség a belépésre. Ezért érdemes megjegyezni, hogy ha bármilyen szituációban begépelhetjük a ? q=user szöveget a honlap URL-jének végére a böngészőnk cím sorába, máris kapunk egy belépési lehetőséget.

Webhely információk A webhely információk adminisztrációs oldal néhány beállítását már telepítéskor megtehettük (név, e-mail drupal.hu/kezikonyv/nyomtatobarat

33/135

2010.02.11.


cím), ezen azonban utólag változtathatunk, illetve néhány további jellemzőt beállíthatunk.

A következő három mező (Jelmondat, Küldetés, Lábléc üzenet) sminkfüggő, hogy megjelenik-e a publikus oldalakon. Bizonyos sminkek megjelenítik ezeket a szövegeket az oldalon. (Az alapértelmezett Garland smink mindegyiket megjeleníti.) A névtelen felhasználó megnevezése (pl. Névtelen vagy Vendég) olyan esetekben fog megjelenni,amikor a tartalom vagy megjegyzés „tulajdonosaként” a Drupal nem tud mást megjeleníteni. A node alapértelmezett címlapot csak akkor szokás megváltoztatni, ha a kezdőoldalt nem a friss hírekkel akarjuk megtölteni.


34/135

2010.02.11.


Drupal 6 telepítése (videó) Ez a videó a Drupal 6 távoli szerverre történő telepítését mutatja be lépésről lépésre. A videó a következőket tárgyalja: Drupal letöltése és kicsomagolása, fájlok felmásolása a szerverre, adatbázis létrehozása, magának a telepítésnek az elvégzése, végül az időzített feladatok és a .htaccess fájl beállítása. A videót Dianiska Balázs készítette. Ha eddig még sosem próbáltad ki a Drupalt, akkor itt a nagyszerű alkalom!

Telepítés és beállítás ingyenes szolgáltatóknál A Drupal magyar nyelvû népszerûségének növekedésével jogosan merült fel a kérdés, hogy miként telepíthetõ a különbözõ ingyenes szolgálatatók szervereire. Ezeken a kiszolgálókon általában különbözõ védelmeket építenek be, melyek korlátozzák a felhasználó mozgásterét, egyrészt a felhasználók egymástól való megvédése érdekében, másrészt a szerver egészségének megtartása végett. Ezek azonban nem minden esetben jönnek jól annak, aki Drupal rendszert szeretne telepíteni. Eddig a következõ tapasztalatokat sikerült összegyûjteni a különbözõ rendszereken.

TVN.hu Ennél a szolgáltatónál annyira kevés a PHP szkriptek számára megengedett memória használat, hogy ez egy funkcionális Drupal webhely számára nem tûnik elegendõnek.

Telepítési problémák, kérdések Ezt az szakaszt tervezzük a jövõben bõvíteni további tapasztalatokkal, amennyiben azok rendelkezésre állnak. Az ingyenes szolgáltatóknál tapasztalt telepítési problémák és kérdések a fórum hosztingról szóló témakörében tehetõek fel.

Drupal 4.7 telepítés a FreeWeb-en Az alábbi leírás Drupal 4.7.x-re vonatkozik, ne alkalmazzuk Drupal 5.x telepítésére! A FreeWeb az egyik legrégebbi ingyenes tárhely szolgáltató Magyarországon, sajnos azonban csak korlátozott formában engedi futtatni a Drupal rendszert. Az érdeklõdésre való tekintettel egy tesztrendszer beállításával megvizsgáltam az alap lehetõségeket. Lássuk hogyan telepíthetünk Drupal rendszert a Freeweben és mik a buktatók. 1. Regisztráljunk a FreeWeb (FW) felületén. Emailben kapunk egy aktiváló webcímet, ezt látogassuk meg, majd az ezt követõ email visszaigazolás után a regisztrációnál megadott név/jelszó párossal lépjünk be a webes felületen. 2. A MySQL menüpontban hozzuk létre az adatbázist, jegyezzük fel a kapott jelszót, és kattintsunk a phpMyAdmin felületre vezetõ linkre. Itt a felugró ablakban adjuk meg a felhasználói nevünket és a megjegyzett jelszót. A sikeres belépés után válasszuk ki az egyetlen adatbázisunkat a jobb oldalon, majd kattintsunk az SQL fülre a felsõ menüben. A szövegfájl feltöltése részben válasszuk ki a saját számítógépünkön kitömörített Drupal database mappájában található database.4.1.mysql nevû fájlt, és nyomjuk le a végrehajtás gombot. Ezzel létrejön az adatbázisunk, bezárhatjuk ezt az drupal.hu/kezikonyv/nyomtatobarat

35/135

2010.02.11.

3.

4.

5.

6.

7. 8.


ablakot. Az FW által adott MySQL hoszt, felhasználó név, adatbázis név és az elõbb megjegyzett jelszó adatokat alapul véve szerkesszük a sites/default/settings.php fájlt a számítógépünkön. Ugyanebben a fájlban vegyük ki a kettõskeresztet a $base_url beállítása elõl, és adjuk meg záró perjel nélkül a webhelyünk címét. A file.inc-ben található chmod() hívásokat tegyük megjegyzésbe. Az email küldés mûködéséhez a FreeWeb PHP/CGI levélküldés oldalán generáljunk magunknak azonosítót, majd a user.module fájlban a user_mail() függvény végére a saját azonosítónkkal kitöltve a return elõtt szúrjuk be a következõ sort: $header .= "\nX-FWMailID: ide-ird-az-azonositot"; Ezzel a forráskód elõkészítésével készen vagyunk. Az FW által biztosított FTP adatokat használva vegyük elõ FTP programunkat, és másoljuk fel a Drupal csomag fentiek szerint szerkesztett tartalmát. A gyökérben található szöveges fájlok és a scripts mappa felmásolása szükségtelen, ezeket a rendszer semmire nem használja. A .htaccess fájl feltöltését a FreeWeb nem engedélyezi. Látogassuk meg a FreeWeb oldalunk címét, mely egy angol nyelvû üdvözlõ lapot jelenít meg. Az elsõ pontban található linkre kattintva hozzuk létre az adminisztrátor felhasználót. Mivel ennek jelszavát csak kiírja a rendszer, de nem küldi el emailben, érdemes valami megjegyezhetõre változtatni a jelszót. Az administer » settings menüpontra kattintva a rendszer jelzi, hogy a tiltott mkdir() miatt nem tudja létrehozni a files és uploads mappákat. Az FTP programunkban hozzunk létre egy files és az alatt egy uploads nevû mappát a weblapunk gyökerében. Mindkettõre adjunk írási jogot az egyéb csoport felhasználóinak (ennek módja FTP programtól függ). Térjünk vissza a Drupal felületére és adjuk meg a files és files/uploads karaktersorozatokat a fájlok és ideiglenes feltöltések mappájaként értelemszerûen. A Drupal létre fog hozni egy .htaccess állományt a files mappában. Mivel a FreeWeb 5 másodperces futási limitet ad a szkripteknek, a fordítás egy menetben történõ importálása nem lehetséges. Használható (nem túl bonyolult) megoldásokat várunk. Az administer » modules oldalon kapcsoljuk be az upload modult. A create content menüpontban tudunk új tartalmat felvinni, és ellenõrizni, hogy a fájl feltöltés is helyesen mûködik.

A Drupal FreeWeb-en történõ telepítését és beállítását illetõen a fentieken túl az átalános tanácsokat vehetjük figyelembe. A modulok beállítása, új sminkek felvétele stb. ugyanúgy mûködik mint bármely más kiszolgálón. Érdemes megjegyezni, hogy mitõl esünk el, ha a FreeWeb-et választjuk Drupal webhelyünk futtatására. 1. Nem használhatunk rövid webcímeket 2. Mivel a .htaccess nem tölthetõ fel, a .inc, .theme, .module és hasonló speciális kiterjesztésû fájljaink nem védettek a kíváncsi szemek elõtt, ezek forráskódját tudják olvasni, meglétét tudják ellenõrizni. 3. A .htaccess feltölthetetlensége és bizonyos beállítások átállításának tiltása miatt egyes PHP beállítások sem úgy állnak rendelkezésre, ahogyan a Drupal számára ideális lenne. Szerencsére az olyan esetek, mint a magic_quotes_gpc bekapcsolt állapota speciálisan kezeltek a kódban, ezért mûködik az ideálisan elvárt beállítások hiányában is a Drupal. 4. Mivel a files és az ez alatt található uploads mappa is a weben olvasható könyvtárban található (nem is tudjuk máshova tenni), csak azonosítással elérhetõ letöltések létrehozása nem lehetséges, hiába is próbáljuk bekapcsolni ezt az opciót a beállításoknál. Amennyiben részletesebben érdeklõdünk a PHP beállításait illetõen, a FreeWeb ugyan letiltja a phpinfo() használatát, de az ini_get() segítségével egyes PHP beállítások lekérdezhetõek, így ezzel a számunkra érdekes beállítások neveit ismerve felmérhetjük a környezet korlátait. drupal.hu/kezikonyv/nyomtatobarat

36/135

2010.02.11.


Ehhez a dokumentációhoz csak az ezt bõvítõ, pontosító, javító hozzászólásokat várunk, más (FreeWebhez kapcsolódó) problémák számára hoszting fórumunk ad megfelelõ teret.

Drupal 5.1 telepítése FreeWeb-en Ma gondoltam egyet és felraktam egy 5.1-es drupal-t a régi freeweb-es tárhelyemre. Mivel láttam, hogy a kézikönyvben még csak a 4.7-es verzióhoz való leírás szerepelt, így gondoltam megosztom a tapasztalataimat. Nagyjából a következõ lépésekbõl áll a telepítés: 1. FreeWebes regisztráció 2. Bejelentkezünk az FW webes felületén és elõkészítjük az adatbázist (MySQL menüpont): ehhez phpMyAdmin áll a rendelkezésünkre. Arra vigyázzunk csak, hogy amikor a phpMyAdmin felületre akarunk bejelentkezni akkor a felhaználói név az FW-s regisztrációnál megadott név, de a jelszó az FW által generált jelszó, de ez szerepel is a megfelelõ leírásban 3. Csomagoljuk ki a saját gépünkön a letöltött drupal rendszert és a magyarítást 4. A sites/defaules/settings.php állománnyal van még egy kis dolgunk: nyissuk meg egy szövegszerkesztõvel és a # $base_url = 'http://www.example.com';

sort elõl vegyük ki a #-t és írjuk át a saját oldalunknak megfelelõen, például: $base_url = 'http://www.freeweb.hu/mycroft';

5. 6.

7. 8.

9.

10.

11. 12.

13.

Fontos:Csak ez a FreeWeb-es hivatkozás jó, tehát például hiába írjuk be http://mycroft.fw.hu formában a címet, nem fog mûködni! Fontos továbbá a www használata is, enélkül szintén nem mûködik! Másoljuk fel a drupalt egy FTP program segítségével az FW-es tárhelyre Ideiglenesen állítsuk be a sites/default/settings.php állomány jogosultságát 666-ra, azaz bárki számára írhatóvá kell tennünk. De a telepítés végeztével mindenképp állítsuk vissza az eredeti - 644 - jogosultságot!. Megjegyzés: TotalCommander használók a fenti beállítást a Fájl -> Attribútum módosítása menüpont alatt végezhetik el. Egy böngészõbe beírva a frissen regisztrált oldalunk címét, máris a telepítõ fogad bennünket. Válasszuk a Drupal localized opciót, majd a következõ oldalon választhatjuk ki a nyelvet. Sajnos hiába válasszuk a magyart, továbbra is angol nyelven folyik tovább a telepítés! (Sõt, késõbb sem sikerült rávenni a rendszert, hogy használja a magyar nyelvi fáljokat,ezzel kapcsolatban várom a tanácsokat. Az adatbázis beállításoknál a 'Database name' mezõbe az általunk létrehozott adatbázis nevét kell beírni, felhasználó név az FW-s nevünk, de a jelszó az FW által generált jelszó! Fontos még, hogy az Advanced részben a 'Database host' mezõbe a localhost helyett írjunk sql-t. Ezzel elvileg készen is vagyunk, de: Lehet hogy csak én bénáztam el valamit, de a beállítások mentése után engem újra az install képernyõ fogadott. Miután újra kiválasztottam a telepítés módját (Drupal localized) és a nyelvet (Magyar) már tényleg az 'Installation complete' /üzenet fogad minket, természetesen angolul :/, de ezzel már majdnem készen is vagyunk! Hozzuk létre az admin felhasználónkat Nézzük meg a status report-ot, láthatjuk, hogy pár feladatunk még van: állítsuk vissza a settings.php fájl jogosultságát 644-re, majd futassunk egy cron-t. Ezután újra az FTP programra lesz szükségünk, hozzuk létre a drupal gyökérkönyvtárában a files könyvtárat, illetve azon belül egy tmp könyvtárat és mindkettõre állítsunk be 777-es jogosultságot. Valószínûleg kapni fogunk pár warning-ot miszerint nem tudja futtatni a chmod parancsot,


37/135

2010.02.11.


különösebben nem baj, kézzel megcsináltunk mindent 14. Lesz még egy warnint a status reportnál, miszerint nem tudja meghatározni az Apache verziószámát, így lehet, hogy a rendszer nem fog tökéletesen mûködni... A "régi" leírásban szereplõ hiányosságok továbbra is érvényesek (pl. .htacces tiltása, rövid webcímek hiánya stb.) Hirtelenjében ennyi tapasztalatom akadt, ahogy elkezdem használni a rendszert, még lehet hogy elõjön valami, azt természetesen jelzem. Ha valami hülyeséget írtam, szóljatok! :)

Drupal telepítés az Ultraweb-en Az alábbi leírás Drupal 4.7.x-re vonatkozik, ne alkalmazzuk Drupal 5.0 telepítésére! Az Ultraweb (UW) ingyenes szolgáltató PHP és MySQL rendszert biztosít, melyeken a Drupal mûködtethetõ (bár nem ideális konfigurációban). Mivel folyamatosan nagy az érdeklõdés az UW-n való telepítést illetõen, és sok a félreértés, az imént próbaképpen végrehajtottam egy teljes Drupal 4.7.2 telepítést, melynek lépéseit és tapasztalatait az alábbiakban igyekeztem összefoglalni. A Drupal beállításához tehát tegyük a következõket: 1. Regisztráljunk az Ultwaweben, az emailben kapott aktiváló webcímet látogassuk meg, majd a kapott jelszóval lépjünk be a rendszerbe. A weblap jobb oldalán egy adminisztrációs konzolt fogunk kapni. 2. A MySQL menüpontban hozzuk létre az adatbázisunkat az ott található gombbal. A phpMyAdmin felületre mutató link segítségével látogassuk meg az adatbázis adminisztrációs felületet. Válasszuk ki az egyetlen adatbázisunkat a jobb oldalon, majd kattintsunk az SQL fülre a felsõ menüben. A szövegfájl feltöltése részben válasszuk ki a saját számítógépünkön kitömörített Drupal database mappájában található database.4.1.mysql nevû fájlt, és nyomjuk le a végrehajtás gombot. Ezzel létrejön az adatbázisunk, bezárhatjuk ezt az ablakot. 3. Az UW adatbázis lapján található MySQL hoszt, felhasználó név, jelszó, adatbázis név adatokat alapul véve szerkesszük a sites/default/settings.php fájlt a számítógépünkön. Az ugyanebben a fájlban található ini_set() hívásokat tegyük megjegyzésbe, a file.inc-ben található chmod() és realpath() hívásokat tegyük megjegyzésbe. Keressük meg a common.inc fájlban az url() függvény kódját és a $script = (strpos... sort teljes egészében cseréljük le annyira, hogy $script = 'index.php';. Ezzel a forráskód elõkészítésével készen vagyunk. 4. Mivel a webes FTP feltöltés fájlonként eléggé kényelmetlen, a hagyományos FTP-t kell alkalmaznunk. Az Ultraweb tárhely adminisztrációs felületen állítsuk a könyvtár indexet index.phpre. Jegyezzük meg a weben olvasható belépési adatokat, váltsunk át egy FTP progamra, és másoljuk fel a Drupal csomag fentiek szerint szerkesztett tartalmát. A gyökérben található szöveges fájlok és a scripts mappa felmásolása szükségtelen, ezeket a rendszer semmire nem használja. A .htaccess fájl feltöltését az Ultraweb nem engedélyezi. 5. Látogassuk meg az Ultraweb oldalunk címét, mely egy angol nyelvû üdvözlõ lapot jelenít meg. Az elsõ pontban található linkre kattintva hozzunk létre az adminisztrátor felhasználót. Mivel ennek jelszavát csak kiírja a rendszer, de nem küldi el emailben, érdemes valami megjegyezhetõre változtatni a jelszót. 6. Az administer » settings menüpontra kattintva a rendszer létrehozza a files mappát és az abban található .htaccess állományt. Hibát ad viszont a feltöltésre használt mappát illetõen, amit kézzel drupal.hu/kezikonyv/nyomtatobarat

38/135

2010.02.11.

7.

8.

9.

10.


kell létrehoznunk (a files mappán belül célszerû uploads néven), és ennek megfelelõen beállítani a Drupal által hibásnak jelölt értéket. Az administer » modules oldalon kapcsoljuk be a locale és az upload modulokat. Az administer » localisation » import menüpontban a Drupal alapcsomag fordítását töltsük fel, célpontként kiválasztva a magyar nyelvet. Ezen dokumentum készítésekor ez a lépés tökéletesen beimportálta ugyan a fordítást, de egy Ultraweb hiba oldalra vezetett. Ezesetben a saját Drupal címlapunkra visszatérve folytathatjuk a következõ lépéssel. Térjünk vissza az administer » localisation menüponthoz, és kapcsoljuk be, valamint válasszuk a magyar nyelvet alapértelmezésnek. Az angolt ki is kapcsolhatjuk, ha nem kívánjuk megadni a választást látogatóinknak. Az Ultraweb beállításoknál az idõzített feladatok között felvehetjük a cron.php rendszeres futtatását. Ez nagyon ajánlott, ha például a keresõ modul szolgáltatásait igénybe szeretnénk venni, vagy a gyorsítótár régebbi bejegyzéseit törölni szeretnénk idõrõl-idõre. Leggyakrabban naponta futtathatjuk a szkriptet, megválasztva az idõpontot, amikor végre kell hajtani. Késõbb a Drupal eseménynaplóban tekinthetjük vissza, hogy sikeres volt-e a futtatás. Próbáljuk ki a telepített rendszert, hozzunk létre tartalmat, töltsünk fel mellé fájlt. Ha mindez mûködik, akkor elértük célunkat.

A Drupal Ultraweb-en történõ telepítését és beállítását illetõen a fentieken túl az átalános tanácsokat vehetjük figyelembe. A modulok beállítása, új sminkek felvétele stb. ugyanúgy mûködik mint bármely más kiszolgálón. Érdemes megjegyezni, hogy mitõl esünk el, ha az Ultrawebet választjuk Drupal webhelyünk futtatására. 1. Nem használhatunk rövid webcímeket 2. Mivel a .htaccess nem tölthetõ fel, a .inc, .theme, .module és hasonló speciális kiterjesztésû fájljaink nem védettek a kíváncsi szemek elõtt, ezek forráskódját tudják olvasni, meglétét tudják ellenõrizni. 3. Az ini_set() tiltása és a .htaccess feltölthetetlensége miatt bizonyos PHP beállítások sem úgy állnak rendelkezésre, ahogyan a Drupal számára ideális lenne. Szerencsére az olyan esetek, mint a magic_quotes_gpc bekapcsolt állapota speciálisan kezeltek a kódban, ezért mûködik az ideálisan elvárt beállítások hiányában is a Drupal. 4. Mivel a files és az alatta található uploads mappa is a weben olvasható könyvtárban található (nem is tudjuk máshova tenni), csak azonosítással elérhetõ letöltések létrehozása nem lehetséges, hiába is próbáljuk bekapcsolni ezt az opciót a beállításoknál. Amennyiben részletesebben érdeklõdünk a PHP beállításait illetõen, az UW nem tiltja a phpinfo() használatát, így egy ezt meghívó egyszerû szkript létrehozásával áttekinthetjük a futtatókörnyezet képességeit. Ehhez a dokumentációhoz csak az ezt bõvítõ, pontosító, javító hozzászólásokat várunk, más (ultrawebes) problémák számára hoszting fórumunk ad megfelelõ teret.

Az alaprendszer moduljai, szolgáltatásai A Drupal alapvető funkcióit a modulok segítségével lehet kibővíteni. Ezen az oldalon lehet engedélyezni a már telepített modulokat. (Most egyenlőre csak az alaprendszer moduljaival foglalkozunk, a kiegészítő modulok telepítése és alkalmazása későbbi témánk lesz.) Az engedélyezést követően a modul beállításához az Adminisztráció menü megfelelő pontját kell drupal.hu/kezikonyv/nyomtatobarat

39/135

2010.02.11.


kiválasztani. Egy engedélyezett modul új felhasználói jogosultságok beállítását is igényelheti. Az alaprendszer szükséges (vagyis kikapcsolhatatlan) moduljait csak egy gyors lista erejéig vegyük szemügyre:

A lista jól mutatja, mik azok az alapszolgáltatások, amit minimálisan nyújt a Drupal tartalomkezelő rendszer.

Modulok használatba vétele A többi modul ki-be kapcsolása egyszerű művelet: az Adminisztráció/Modulok oldalon a jelölőnégyzet segítségével, majd a beállítások mentésével véglegesíthetjük. Természetesen a modulok bekapcsolás után még konfigurációt is igényelhetnek. Most pedig nézzük meg az alaprendszer "nem szükséges" moduljait. (Talán érdemes úgy gondolni ezekre a modulokra, hogy ugyan nem létszükséglet a használatuk, de többségüket igen gyakran alkalmazzuk.) A sorrend kicsit önkényes, más beállítási sorrendek is logikusak lehetnek.

Útvonal álnevek (Path modul) Az útvonal (Path) modullal a Drupal webcímeihez álnevek rendelhetőek. (Ennek az oldalnak a kezikonyv/alaprendszer/utvonal az álneve.) Ezek az álnevek javíthatják a webcímek olvashatóságát, és segíthetnek az internetes keresőknek a tartalom hatékony indexelésében. Egynél több álnév is rendelhető egy adott útvonalhoz (bár ez általában nem célravezető megoldás). Az útvonal modul a megfelelő jogosultsággal rendelkező felhasználók számára egy kiegészítő mezőt jelenít meg a tartalmak beküldési és szerkesztési űrlapján, mely segítségével a tartalom útvonalát elfedő álnév közvetlenül megadható. Emellett saját felületet nyújt a már meglévő álnevek megtekintésére és szerkesztésére.


40/135

2010.02.11.


Így az Adminisztráció/Útvonal álnevek oldalt közvetlenül ritkán használjuk, akkor is elsősorban áttekintő listaként. A későbbiekben látni fogjuk, hogy kiegészítő modul (pl. Pathauto) segítségével az útvonal álnevek egységes rendszerben és automatikusan generálhatók.

Dátum és idő beállítások A dátum és idő megjelenítésével kapcsolatos beállítások, valamint a rendszer alapértelmezett időzónája állíthatók be. A beállítási lehetőségek magukért beszélnek:

Regisztrált felhasználók számára akkor érdemes engedélyezi az időzóna testreszabását, ha előfordulhat, hogy a szerver és a látogatók más időzónába tartoznak. A hét első napjának beállítása naptár jellegű megközelítés esetén lesz fontos.

Keresés beállításai Ritka kivételtől eltekintve nem érdemes a keresés funkciót (Search modul) kikapcsolni, hiszen nagyon hasznos szolgáltatást nyújthatunk minimális költségért cserébe. drupal.hu/kezikonyv/nyomtatobarat

41/135

2010.02.11.


A kereső modul kulcsszavak kereshetőségével ruházza fel a rendszert. Egy nagy webhelyen a kereső használata gyakran az egyetlen módja egy tartalom megtalálásának. A kereső segítségével felhasználók és tartalmak egyaránt megtalálhatóak kulcsszavak alapján. A keresőmotor a webhelyen közzétett tartalmak és felhasználói adatok alapján felépített index segítségével működik. A modul beállításaival szabályozható az index feltöltésének módja. Az időzítő (cron) beállítása és rendszeres futtatása szükséges a kereső működéséhez.


42/135

2010.02.11.


Az index százaléka adja meg az időzítő egyszeri lefutásakor leindexelendő tartalmak számát. Az érték alacsonyra állításával elkerülhető, hogy az időzítő túllépje a maximális futási időt, vagy kifogyjon a rendelkezésre álló memóriából. Az alapbeállításokhoz képest talán a sorba rendezés szempontjainak súlyozását érdemes átgondolni. Pl. egy technológiai honlapnál nagyobb, míg egy botanikai honlapnál kisebb súllyal érdemes a közzététel frissességét figyelembe venni. Megjegyzés: A modul csak egész szavakat indexel, így szótöredékekre sajnos nem tudunk vele keresni.

Gyorstárazás A Wikipédia definíciója szerint „a gyorsítótár vagy cache [...] az átmeneti információtároló lemeket jelenti, melyek célja az információ-hozzáférés gyorsítása. A gyorsítás egyszerűen azon alapul, hogy a gyorsítótár gyorsabb tárolóelem, mint a hozzá kapcsolt, gyorsítandó működésű elemek, így ha ezen területek tartalma korábban már bekerült a gyorsítótárba (mert már valaki/valami hivatkozott rá korábban), az ilyen adatokat drupal.hu/kezikonyv/nyomtatobarat

43/135

2010.02.11.


nem a lassú működésű területről, hanem a gyors cache tárolóból lehet előhívni.”

A gyorstár bekapcsolása jelentős teljesítmény javulást eredményezhet. A Drupal képes az anonim felhasználók (látogatók) által kért webcímeket illető tömörített gyorstárazott oldalak tárolására és küldésére. A gyorstárazás használatával a Drupal-nak nem kell minden oldallekérésnél előállítania a weblapot, hanem azt a gyorstárból (cache-ből) tudja kiszolgálni. A gyorstárazási módot ajánlott Normál-ra állítani, aminek még nem lehetnek mellékhatásai. Minimális gyorstár élettartam Nagy forgalmú webhelyek esetén szükséges lehet a gyorstár élettartamának minimális értéket adni. A gyorstár minimális élettartama az az idő, aminek el kell telnie azelőtt, hogy a gyorstár kiürítésre majd újra feltöltésre kerülne. A hosszabb minimális gyorstár élettartam jobb teljesítményt nyújt, azonban a felhasználók hosszabb ideig nem látják majd a legfrissebb tartalmakat. Fejlesztés esetén érdemes az alapértelmezett 0 értéket meghagyni, vagy még inkább kikapcsolni a gyorstárazást. Blokk tömörítés Néha egy-egy blokk generálása erőforrás-igényesebb, mint a tartalom legenerálása. Éppen ezért általában érdemes ezt is bekapcsolni.


44/135

2010.02.11.


Sávszélesség optimalizálás A Drupal alapú honlapunk jó eséllyel több CSS és JavaScript állomány letöltését is szükségessé teszi az oldal megjelenítéséhez. De maga a generált HTML oldal se a legoptimálisabb a letöltési sebesség szempontjából. A következő lehetőségek a webhely felé irányuló kérések számának és méretének csökkentését teszik lehetővé. Ez csökkentheti a szerver terhelését, a használt sávszélességet, és az oldalak betöltődésének átlagos idejét. E beállítások engedélyezése fejlesztés közben nem javasolt.


45/135

2010.02.11.


A következő listákon láthatjuk a generált HTML kimenetet, a két mód közti különbséget. drupal.hu/kezikonyv/nyomtatobarat

46/135

2010.02.11. Magyar Drupal Kézikönyv

Jól látszik, hogy a sok CSS fájl letöltése helyett csak egyre lesz szükség. Ez pedig előnyös.

Fejlesztés alatt hagyjuk e lehetőségeket Tiltott állapotban.

Magyar felület fordítás A magyar felület fordítási munkái a http://localize.drupal.org által biztosított infrastruktúrán zajlanak. Ebből a Drupal webhelyek telepítőinek annyit érdemes tudniuk, hogy a magyar fordításokat két módon lehet beszerezni. A Drupal alaprendszer fordítása minden esetben megtalálható a címlapon. Alapvetően ezt ajánljuk mindenkinek, aki szeretné, hogy az adatbázisa a lehető leghatékonyabban legyen kihasználva, felesleges fordítások ne terheljék a rendszerét. Ez alkönyvtár helyesen tartalmazza a szükséges fájlokat, melyet egyszerűen a telepített Drupal forráskódja mellé kell másolni. Azonban ez a csomag viszonylag ritkán frissül. A legfrissebb fordítás beszerezhető közvetlenül a fordítási adatbázisból is, ennek azonban már feltétele egy felhasználói fiók megléte a http://drupal.org webhelyen. Ez sokkal naprakészebb csomagot biztosít, hiszen a fordításunk akár napról-napra is változhat. A közösség által közzétett modulok esetében is ez a kettősség van jelen. A népszerű, sokak által használt modulok esetén a magyar fordítási fájl általában megtalálható a csomagban. A fejlesztés menetéből következően ez azonban mindig az eggyel korábbi változat fordítása lehet csak, így előfordulhat, hogy nem teljes. Természetesen itt is igaz, hogy a legfrissebb fordítás beszerezhető közvetlenül a fordítási adatbázisból is, amennyiben valaki már lefordította azt.

Részvétel a fordításban A magyar fordítói csapat levelezőlistát tart fenn, melyen a fordítással kapcsolatos beszélgetések, egyeztetések zajlanak. Előfordul, hogy több lehetőség közül nem a megfelelő fordítást választjuk, vagy nem találjuk meg az alkalmas magyar fordítást egyes angol fordulatokhoz, kifejezésekhez. Szívesen fogadunk új ötleteket, javaslatokat a fordítással kapcsolatban, ehhez semmilyen speciális technikai eszközre nincs szükség, csupán a levelezőlistán kell felvetni a kérdést. Előfordulhat, hogy nem a megfelelő stílust vagy mondatszerkezeteket választjuk bizonyos fordítások során, esetleg nem egységes vagy félreérthető a drupal.hu/kezikonyv/nyomtatobarat

47/135

2010.02.11.


szóhasználatunk. Az ilyen hibákkal kapcsolatos jelentéseket is szívesen látjuk. A fordítást természetesen nem csak érdeklődő szemlélőként lehet nézni, hiszen mindig van valamilyen javítandó vagy fordítandó felület. A fordítási munkába való bekapcsolódás iránt érdeklődőknek rendelkezniük kell UTF-8 támogatással bíró szerkesztőprogrammal. Kényelmi szempontok miatt egy Gettext Portable Object szerkesztő (pl. KBabel vagy poEdit) jó választás lehet, de egy teljesen hagyományos szöveges fájlszerkesztő is megteszi, ha UTF-8 támogatással bír. Mivel a fordításokat a localize.drupal.org kiszolgálón kezeljük, a résztvevőknek felhasználói azonosítóval kell rendelkezniük itt. Egy drupal.org felhasználói regisztrációt követően átlépve a localize.drupal.org oldalra ez a felhasználói azonosító automatikusan létrejön. Ezt követően a ezen az oldalon lehet csatlakozni a csapathoz. Aki komolyabban szeretne a fordításokkal foglalkozni, az itt igényelhet CVS azonosítót. Ez az azonosító feljogosít arra, hogy bármely modul vagy smink magyar fordítását módosíthassuk (más nyelvi fordításokba is bele lehet írni, de ez nem ajánlott). A Drupal alapcsomag külön projektként jelenik meg. A magyar fordítást érintő változások figyelése összetett feladat lehet, hiszen sok projekten átívelő módosulásokról lehet szó. Ezért beállítottunk egy automatikus monitoring programot, aminek a segítségével a hírolvasónkban nyomon követhetők a magyar fordításokat érintő változások. A részvétellel kapcsolatos bármilyen kérdést, javaslatot a fordítói levelezőlistán érdemes feltenni.

Fordítási irányelvek A különböző kifejezések fordításakor időnként parázs vita alakult ki a helyes nyelvhasználatról, az egyértelműségről, a hagyományokról, és olyan technikai kérdésekről, melyek a Drupal felület fordítását egyszerűbbé tehetik. Úgy gondoltuk, hogy nyelvi döntéseinket, választásainkat érdemes lehet megosztani másokkal is, ezzel talán segítve más honosító projektek munkáját is, amellett, hogy a magyar felülettel ismerkedőknek is támpontokat adhatunk. Ezért az alábbiakban egy magyarázatokkal ellátott szójegyzéket teszünk közzé, jelölve az esetenként felmerült alternatívákat, és a végső döntésünk okát. Természetesen nem szeretnénk arra vállalkozni, hogy a magyar fordítás tudományát újra feltaláljuk, a módszereket saját magunk definiáljuk, de sok esetben találkoztunk olyan kérdésekkel, melyeket máshol nem tárgyalnak. Szerencsére sok forrás van, melyhez fordulhatunk: A magyar helyesírás szabályai természetesen és szerencsére elérhető digitális formában is. Koblinger Egmont és Tímár András készített egy általános útmutatót a szabad szoftverek magyarításához, melyet szintén érdemes böngészni általános információk iránt érdeklődőknek. A Magyar Linux Dokumentációs Projekt számára Daczi László készítette el a Fordítás HOGYAN dokumentumot. Előbbire alapozva Kéménczy Kálmán és Kelemen Gábor készített egy ennél némileg bővebb Fordítás HOGYAN-t. A Xaraya fordító csapata is közzétette ajánlásait, és néhány hasznos dokumentumra és szótárra is linkeket adott.

Fordítási stílus Mindenképpen alapkövetelmény volt, hogy vállalati környezetben is jól használható fordítás készüljön, így a tegezés használatát eleve kizártuk. Három lehetőség maradt, a magázás, a személytelen, illetve a magyar drupal.hu/kezikonyv/nyomtatobarat

48/135

2010.02.11.


könyvekben előszeretettel használt többesszám első személyű megközelítés használata. Végül ezutóbbi kettő mellett döntöttünk, mert úgy ítéltük meg, hogy ez az a megoldás, ami egyenlő távolságra van a magázástól és a tegezéstől, és mindkét igényt megfogalmazó számára elfogadható. Stílusunk tehát elsősorban személytelen, illetve ahol ez nem oldható meg jól, ott többesszám első személyben szól. Ennek érzékeltetésére: Tegező: Biztosan törölni szeretnéd a blokkot? Magázó: Biztosan törölni szeretné a blokkot? Magyar Drupal: Biztosan törölhető a blokk? Tegező: A beállítások oldalon add meg a blokk nevét! Magázó: A beállítások oldalon adja meg a blokk nevét! Magyar Drupal: A beállítások oldalon adható meg a blokk neve. A megszólítás és a megszemélyesítés elkerülése vonatkozik a felhasználóra és a kiszolgálóra, a programra egyaránt. Néhány helyen nem tudtunk jobbat találni a magázásnál – ezek főleg a felhasználó adataival foglalkozó modulokban fordulhatnak elő. Más projektek honosításainál szokásos formában meggyűlt a bajunk a névelők használatával, amikor azokat automatikusan elhelyezett tartalmak elé kell illesztenünk. Mivel megítélésünk szerint az „a(z)” típusú névelő használat nem helyes, ezt mindenképpen kerüljük. Sajnos nem minden esetben helyes magyar nyelven a névelő elhagyása, ennél jobbat rendelkezésre álló eszközeinkkel azonban nem tehettünk. Az alábbi példákban a @user helyére a Drupal az oldal előállítása közben helyez be egy értéket: Helytelen: A @user felhasználó törölve lett Helytelen: Az @user felhasználó törölve lett Helytelen: A(z) @user felhasználó törölve lett Magyar Drupal: @user felhasználó törölve lett Hasonló kérdés a többesszámok használatának problémája, ahol szintén nem tartjuk járhatónak a „felhasználó(k)” típusú fordítást. Ehelyett olyan változatot használunk, amely az adott helyzetben megfelelőbb. Általában a többesszám alkalmazása helyénvalóbb. Például: Helytelen: Bejelentkezett felhasználó(k) Magyar Drupal: Bejelentkezett felhasználók

Dátumformátum Rövid: Y. m. d. H.i azaz 2004. 10. 28. 14.21 Közepes: Y. F j. H.i azaz 2004. október 28. 14.21 Hosszú: Y. F j., l H.i azaz 2004. október 28., csütörtök 14.21 Ezek csak javaslatok, a magyar nyelv szabályait figyelembe véve más kombinációk is előfordulhatnak. Fontos szempontok: hónap és nap nevek kisbetűsek óra és perc között pontot kell használni, nem kettőspontot számmal írt év, hónap és nap után pontot és térközt kell tenni (kivéve, ha még vesszővel is leválasztjuk az új információt) „év hónap nap” ebben a sorrendben szerepel

Idézőjelek drupal.hu/kezikonyv/nyomtatobarat

49/135

2010.02.11.


Idézőjeleknek helyes használata (UTF-8): „idézet”. Kérünk mindenkit a bonyodalmak elkerülése érdekében ezeket használja! Hasonlóképpen elvárható a helyes nagykötőjel- illetve gondolatjel-használat (a magyar nyelv félkvirtmínuszt használ ezekre), valamint a kötött (nem törő) szóköz megfelelő alkalmazása is. Windows Windows alatt eképpen csalható elő: A kezdő: Alt+0132 -> „ A záró: Alt+0148 -> ” Linux és *BSD Linux alatt több járható út van, az egyik az Xmodmap alapú billentyű-hozzárendelés, mely az altgr+e kombinációra és az altgr+r kombinációra rakja a két idézőjelet: xmodmap -e 'keycode xmodmap -e 'keycode

26 = e E doublelowquotemark' 27 = r R rightdoublequotemark'

A másik mód az X Window System rendszerekhez készült magyar billentyűzetkiosztás-fájl felülbírálása. 1. Töltsd le az xkb-hu.txt fájlt. 2. Másold be a fájlt az xkb rules könyvtárába „hu” néven (felülírva a régit). Pl. így: sudo cp xkb-hu.txt /usr/share/X11/xkb/rules/hu

3. Érvényesítsd a változásokat. (Ha az X-et újraindítjuk, akkor erre nincs szükség, feltéve, hogy a magyar billentyűkiosztás van érvényben.) Pl. így: setxkbmap -layout hu -variant nodeadkeys

Építőelemek fordításai module – modul Ezesetben nem merült fel más lehetőség, a Drupal funkcionalitását kiegészítő elemeket moduloknak nevezzük. theme – smink Ekörül alakult ki a legkomolyabb eszmecsere. Felmerültek még: arculat, téma, stílus, megjelenés, sablon, maszk. A sablon és a stílus a Drupal megjelenítési rendszerének más elemeit jelölik, ezért foglalt szavak. A téma a subject szó fordításaként, illetve a fórum topic (fórum téma) fordításaként már szerepel a Drupalban. Az arculat nem fedi a Drupal által biztosított lehetőségeket, túl merev a testreszabhatósági képességekkel összehasonlítva. A maszk elrejtést szolgál, és nem a felület színesítésére utal. A megjelenés túlságosan is lapos, általános érvényű. theme engine – sminkmotor Sablon alapú sminkek készítésére használt függvénygyűjtemények. Az alapcsomagban az xtemplate (Drupal 4.7.0-tól kezdve a phptemplate) sminkmotor található. template – sablon Egy adott sminkmotor számára készült HTML előállítására használt sablon. style – stílus Egy adott sablonhoz, illetve sminkhez készült CSS, képek és egyéb fájlok gyűjteménye, melyek a smink illetve sablon által adott HTML kódhoz színes megjelenést rendelnek.

Tartalomtípusok fordításai drupal.hu/kezikonyv/nyomtatobarat

50/135

2010.02.11.


node – tartalom A node a Drupal tartalomkezelésének alapegysége, minden típus ezt egészíti ki, ruházza fel újabb lehetőségekkel. A legtöbb esetben sikerült megtartani a „tartalom” fordítást, de ahol nagy koncentrációban fordult elő, ott a „node” elkerülése nem volt lehetséges. story – írás A legegyszerűbb, és ebből következően a legsokoldalúbb típus. Nagy ötletelés előzte meg ennek a fordítási változatnak a kiválasztását. Felmerültek még: történet, közlés, közlemény, sztori. Végül a típus általánosságát leginkább kifejező „írás” változatra esett a választás. page – oldal Az „oldal” típus segítségével lehet új oldalakat felvenni a webhelyre. Ez gyakorlatilag megegyezik az írás típussal, de különálló léte lehetővé teszi, hogy saját besorolást kaphassanak az ilyen tartalmak. Jellemző, hogy az oldalakon a beküldési információ nem jelenik meg – ez a sminkben állítható. book page – könyvlap A közösségi könyv modul tartalomtípusa, a tárolt verziókhoz megjegyzések fűzését teszi lehetővé, és a könyvben elfoglalt hely beállítását biztosítja. blog post, blog entry – blogbejegyzés A blog (webnapló) modul tartalomtípusa. forum topic – fórumtéma A fórumban egy téma elindítását lehetővé tevő tartalomtípus.

Tartalmak tulajdonságainak fordítása author – szerző A tartalom beküldője. published – közzétett A webhelyen megjelenő tartalom, az arra jogosult felhasználók megtekinthetik. unpublished – rejtett A webhelyre küldött, de még közzé nem tett, vagy korábban már közzétett, de jelenleg rejtett tartalom (a közzétett ellentéte). sticky – kiemelt, az oldal tetejére A dátumtól vagy más sorrendezéstől függetlenül az oldalak tetejére emelt tartalom. Csatolmány Méret xkb-hu.txt

14.16 KB

Fordítási segédlet A localize.drupal.org webhelyen a Localization Server modul kezeli a fordításokat. Mivel nem mindenki ismeri tüzetesen ennek működését, legyen itt pár szó arról, hogyan lehet valaki hatékony a fordításokban. Először is azt kell tudni, hogy ez a modul önálló karaktersorozatokat kezel. Ebből az következik, hogy ha egy szöveg már előfordult bármelyik modulban, annak egyéb modulokban történő előfordulásait nem tekinti új szövegnek. Tehát egy karaktersorozatnak (pl. „Undo”) pontosan egy fordítása lehet, függetlenül attól, hogy mely modulokban fordul elő. (Ez a Drupal 7 megjelenésével már nem így lesz.) Tehát, így működik a Localization Server, amikor valaki beküld egy fordítási fájlt: egyesével végigolvassa a beküldött karaktersorozatokat; megnézi, hogy az angol verzió szerepel-e az adatbázisban; drupal.hu/kezikonyv/nyomtatobarat

51/135

2010.02.11.


ha nem szerepel, akkor a fordítást egyszerűen eldobja; ha szerepel, és a beküldött fordítás megegyezik az aktuális fordítással, akkor nem tesz semmit; ha szerepel, és a beküldött fordítás nem egyezik meg az aktuális fordítással, vagy nincs is még lefordítva az adott karaktersorozat, akkor javaslatként felviszi. Milyen problémák adódhatnak ebből? Ha a fordítás nem a kérdéses modul legfrissebb változata alapján készült, akkor előfordulhat, hogy a fordítás nagy része felesleges munka volt. Csak a modulok legfrissebb 5-ös, és 6-os változata szerepel a kiszolgálón, illetve az újabb kiadások folyamatosan kerülnek fel. Felesleges ajánlás érkezik, ha a fordító nem friss a fordítottság tekintetében. Egy régebbi modul csomagjában lévő fordítás kiegészítése nem a leghatékonyabb mód, mivel ekkor már esetleg kijavított szövegekre érkezik be ismét a régi (tehát a hibás) ajánlás. A már lefordított szövegekre csak indokolt esetben célszerű új ajánlást beküldeni. Például az „Undo” esetében az aktuális fordítás a „Visszavonás”. Hiába küldi be valaki, hogy szerinte „Visszavon”, „Mégsem”, stb., ezek nagy valószínűséggel el lesznek utasítva. Miért? Mert mint fentebb szó volt róla, 1 karaktersorozatnak 1 fordítása lehet jelenleg, de ezt rengeteg modul használhatja Például az „Undo” esetében a dokumentáció írásakor: notifications: 6.x-1.1 (2) translation_overview: 6.x-1.4 (2), 6.x-2.0-beta2 (4), 6.x-2.0-beta3 (2), 6.x-2.0 (2) drupal: 6.9 (4), 6.10 (4), 6.11 (4), 6.12 (4) wysiwyg: 6.x-1.1 (3) Ha el lenne fogadva az újonnan beküldött szöveg, akkor az a fenti modulok mindegyikében módosulna, és ez nem feltétlenül jelentene jót. Bár volt már rá példa, de elég ritka. Tehát, akkor hogy a leghatékonyabb a fordítás? Ha még nincs, akkor az első lépés a felhasználói profilok létrehozása a drupal.org és a localize.drupal.org webhelyeken, majd csatlakozás a magyar csapathoz, ahogy az a Részvétel a fordításban részben szerepel. A fordítási kiszolgáló export fülén exportálni kell a kérdéses modul legfrissebb (vagy az összes) változatát a „Translation” és az „All in one file” opciók használatával. Még ha a modulhoz soha senki nem küldött be semmit, már biztosan lesz benne néhány - néha nem is kevés - szöveg, amely le van fordítva. Egyrészt ezeket már nem kell lefordítani, másrészt nem kell új javaslatként beküldeni sem, ha csak nem egyértelmű elírásról van szó. A fordítói levelezési listán célszerű bejelenteni egy modul fordításának elkezdését. Ugyanis lehet, hogy valaki már fordítja, így a felesleges munka elkerülhető. Itt jön az érdemi rész, vagyis a maradék szöveg lefordítása a fordítási irányelveknek megfelelően. Célszerű minden szöveget lefordítani, hisz csak akkor éri meg foglalkozni egy modullal, ha az elkészült fordítás közzé is tehető. Az elkészült fordítást importálni kell a fordítási kiszolgáló import fülén. A fordítói levelezési listán be kell jelenteni, hogy a fordítás elkészült. Amint valamelyik adminisztrátor ideje engedi, a fordítás átnézésre, elfogadásra, és közzétételre kerül. Itt kell megjegyezni, hogy amennyiben valaki nagyon jó fordításokat javasol, és ezt nagy mennyiségben, rendszeresen követi el, akkor természetesen rövid időn belül az adminisztrátorok között találhatja magát.

Frissítés újabb verzióra drupal.hu/kezikonyv/nyomtatobarat

52/135

2010.02.11.


Ebben a részben elsõsorban a Drupal.hu frissítésének tapasztalatait szeretnénk megosztani az érdeklõdõkkel. A frissítés elõkészítése ennek a résznek az írásával egyidõben zajlik, 4.5-ös Drupal kódról 4.7-es verzióra lépünk.

Drupal frissítés - a Drupal.hu tapasztalatai (1) Mielõtt a Drupal rendszerünket frissítenénk, egy dolgot mindenképpen át kell gondolnunk. Szükségünk van-e egyáltalán az új Drupal verzióra? Ez egy fontos kérdés, és nem szabad elmenni mellette, hiszen jelentõs munkát spórolhatunk meg vele, ha a válasz nemleges lesz. Elõfordulhat, hogy webhelyünket a jelenlegi Drupal verzió elvárhatóan mûködteti, vagy olyan mértékû testreszabást hajtottunk végre, hogy nem éri meg az újabb változat beüzemelése. A Drupal.hu frissítésének elõkészítése is ezzel a kérdéssel kezdõdött. Mivel elsõdleges feladatunk egy Drupal bemutató webhelyet üzemeltetni, és a jelen írás szerkesztésekor használt sokszor foltozott 4.5-ös kiadás már igencsak idejétmúlt, a szükségesség kérdésére adott válasz esetünkben igen volt. Ezt követõen át kellett tekintenünk, hogy mit használunk ki a Drupalból, ezekbõl mi érhetõ el az új (leendõ 4.7.0-ás) Drupal kiadáshoz. Szerencsére a varázslatos dolgokat tudatosan elkerüljük, hogy lehetõleg valós képet mutassunk a Drupal alapképességeirõl, ezért nincs sok kiegészítõ modul telepítve rendszerünkben. Nem csak a modulokat kell ugyanakkor figyelembe venni, a használni kívánt sminkre is gondolnunk kell. A Drupal.hu ezen írás szerkesztésekor egy marvin_2k for phptemplate smink variánst használ, ennek erénye pedig, hogy a phptemplate absztrakciójának köszönhetõen jobban hordozható, mint a PHP-ben írt sminkek. Ez nem azt jelenti, hogy a Drupal.hu ugyanezzel a megjelenéssel lépne tovább, de ez sem volt kizárható. Ne feledjük, hogy bizony azt is számításba kell vennünk, hogy egy általunk áhított funkcionalitást esetleg töröltek a Drupalból. A 4.7-es kiadás alapcsomagjában nem lesznek elérhetõek a pontozásos moderálási funkciók a tartalmak (queue modul) és a hozzászólások esetén sem, ezek nem voltak eléggé gyakran használatosak ahhoz, hogy a továbbiakban az alapcsomagban tartsák õket. Szerencsére ezeket a funkciókat nem használtuk ki, az általunk igényelt egyszerû tartalombeviteli munkafolyamat pedig természetesen továbbra is mûködõképes, így például a felhasználók által beküldött linkek alapértelmezésben el vannak rejtve. Nézzük részletesebben a használt kiegészítõ modulokat: codefilter: a forráskódok színezésére drupalhu: saját fejlesztés, egyszerû szûrõ kiegészítéseket ad, a filebrowser és trstatus modulok között teremt hidat filebrowser: a fordításaink böngészési felülete, saját fejlesztés, de közzétettük nyílt forráskódú projektként trstatus: saját fejlesztés, a fordításaink állapotának statisztikáit elemzi, és számolja meg a drupalhu modul számára emészthetõ formába öntve azokat weblink: a klasszikus nagy behemót, ami rengeteget tud, és szinte semmit sem használunk ki belõle Ezek közül a codefilter szerencsére elérhetõ 4.7-es Drupalhoz is, ezzel akadt a legkevesebb probléma. A frissítés kapcsán a filebrowser kódjának 4.7-en futásra alkalmassá tétele volt a legérdekesebb feladat, ezt februárban el is készítettem, az erre váró más fejlesztõk örömére. A trstatus és a drupalhu modulok szerencsére igen csekély olyan kódot tartalmaztak, amelynek futása problémát okozna Drupal 4.7 alatt, drupal.hu/kezikonyv/nyomtatobarat

53/135

2010.02.11.


tehát ezek átalakítása triviálisnak bizonyult. Az egyszerûség kedvéért egyetlen drupalhu nevû modulban él tovább a kódjuk. A 4.7-es sorozatban már nem támogatott weblink modul helyettesítése volt a legtöbb munkát igénylõ feladat. A szerzõk a links modul csomagot ajánlják a cseréhez, ezzel azonban meglátásom szerint az egyik behemótot a másik behemótra cseréltem volna le, amikor egészen egyszerû link megadási és kattintás számlálási funkciókra volt szükség. Így a 35kbyte méretû weblink modult a 36kbyte méretû links + links_weblink modul kettõs helyett egy saját fejlesztésû 3kbyte méretû simplelinks modulra cseréltem, ami minden szükséges funkcióval rendelkezik. Tehát a frissítendõ Drupal rendszer rendelkezésére áll egy-egy 4.7-es verzió alatt futó codefilter, drupalhu, filebrowser és simplelinks modul. Ez nagyon fontos kiindulási pont volt annak érdekében, hogy az adatbázis frissítést és a smink kialakítását elkezdhessük, amirõl a következõ részben szeretnék írni.

Drupal frissítés - a Drupal.hu tapasztalatai (2) Az elõzõ rész hiányosságaként tomsolo rámutatott, hogy meg kell különböztetnünk kétféle frissítést is. A könnyebbik esetben biztonsági és/vagy hibajavító frissítést telepítünk (például Drupal 4.6.0-ról valamely késõbbi 4.6.x-es kiadásra váltunk). Ez könnyebb a webhely gazdája számára, hiszen adatbázis változtatást szinte biztosan nem kell végrehajtani, csak a kódot kell cserélni, sõt a kiegészítõ modulok kompatibilitása is biztosított. Emiatt ez a fajta frissítés mindenképpen javasolt. Ebben a sorozatban viszont a nagyobb verzió ugrások végrehajtásához szeretnék tippeket adni, mint például a Drupal 4.6.x-rõl 4.7.0-ra történõ frissítés, vagy esetünkben a Drupal 4.5.x-es sorozatról a legújabb 4.7.0-ra. Itt garantált, hogy a korábban használt modul kódok nem lesznek kompatibilisek, új fordításokat kell telepítenünk és az adatbázis struktúra is szinte biztosan megváltozik.

Gondoljunk az adatbázisra és a fordításokra is Az elõzõ részben megbizonyosodtunk róla, hogy az új frissítendõ kiadáshoz rendelkezésre állnak a számunkra szükséges kiegészítõ modulok kódjai. Két dologról azonban még mindenképpen meg kell gyõzõdnünk a frissítés megkezdése elõtt. A Drupal 4.7.0 a korábbiaknál is felhasználóbarátabb adatbázis frissítõ megoldással érkezik. Régebben a kiegészítõ modulokhoz tartozó adatbázis táblák frissítését egyedileg kellett elvégeznünk, a modulonkénti leírások átolvasásával. A 4.7.0-hoz kiadott modulok esetén .install fájlokban leírhatóak a telepítésnél és frissítésnél végrehajtandó utasítások, és minden modulhoz saját adatbázis séma verziót tart nyilván a rendszer, ami alapján a szükséges frissítések kiterjesztésenként külön megállapíthatóak. Ha az általunk kívánt kiegészítõ modulok esetében nem volt adatbázis változás, vagy rendelkeznek ilyen frissítést segítõ fájllal, akkor szerencsénk van. Elõfordulhat, hogy mégis egyedi leírások alapján kell a kiegészítõ táblákat frissíteni, hiszen ez a telepítõ alrendszer még friss, nem minden modul fejlesztõjének sikerült még áttérni rá. Nem elhanyagolható szempont magyar (vagy más) nyelvû webhely karbantartásánál, hogy a kívánt modulokhoz elérhetõ-e már a kívánt fordítás. Ez az alapcsomag esetében semmiképpen nem gond, a kiegészítõk már változatosabb mintát mutatnak az elérhetõ fordítások tekintetében. Ha véletlenül nincs letölthetõ fordítás a kívánt modulhoz, nem kell elkeseredni. A modul kódjának mappájából elindítva az extractor.php segítségével könnyen generálhatjuk a fordítási sablon fájlokat (.pot), melyekbõl kiindulva a modul fordítását magunk is elkészíthetjük, egy egyszerû szöveges fájlszerkesztõ használatával. Bármilyen nyelvre is fordítunk, csak arra kell feltétlenül figyelnünk, hogy UTF-8 kódolást használva mentsük el a fordítást. Ezután érdemes a közösséggel megosztani a munkát, így erõsítve az általunk használt rendszer képességeit, hozzájárulva jövõjének biztosításához. Bõvebb információ a magyar fordításról. drupal.hu/kezikonyv/nyomtatobarat

54/135

2010.02.11.


A hivatalos verzió: frissítés adatbázis mentéssel Nem érdemes feltételezni, hogy minden rögtön tökéletesen fog mûködni, ezért különösen veszélyes egy éles webhelyen frissítést végrehajtani. Könnyen lehet, hogy valami félrecsúszik, és ilyenkor mindenképpen jó, ha van egy biztonsági mentésünk a frissítés megkezdése elõtti állapotról, amire könnyen visszaállhatunk. Valójában magán a mentésen, azaz a mentés alapján létrehozott teszt webhelyen érdemes a frissítést elindítani, biztonságos távolságra az éles környezettõl. A Drupal.hu MySQL adatbázist használ, így most ezzel fogunk foglalkozni. Vegyük tehát a kedvenc adatbázis dump elõállító programunkat (phpMyAdmin webes felületen vagy mysqldump a parancssorból), és egy .sql állományba mentsük el az adatbázisunk tartalmát. A mysqldump használatával a következõképpen juthatunk eredményre: mysqldump --user=felhasznalonev --password=jelszo adatbazisneve > dumpfile.sql

Valójában eléggé nagy mentésünk lesz a cache, locales_target, locales_source és hasonló táblák miatt, amik tartalmára valószínû nem lesz szükségünk, a fordításokat úgyis újra kell importálnunk, a gyorstárat pedig a fordítás miatt úgyis ûríti majd a rendszer. Ezeket a kivételeket azonban a mysqldump számára nem egyszerû megadni, ezért a magam részérõl inkább együttélek a nagy fájl le- és feltöltésével járó nagyobb várakozással. A következõ lépés egy friss üres Drupal 4.7.0 telepítése, mely alá a gyárilag szállított MySQL adatbázis helyett a mentett adatbázisunkat töltsük fel. Ezután az index.php betöltése helyett az update.php oldalt hívjuk be. Itt kaphatunk egy hibaüzenetet, hogy nem vagyunk belépve, és így nem tudjuk elvégezni a frissítést. Ezesetben az update.php tetején található $access_check változót állítsuk FALSE értékre, így nem kell belépnünk. A frissítés után természetesen állítsuk vissza TRUE értékre, vagy töröljük az update.php fájlt teljesen. Ha minden rendben megy, a frissítést elindíthatjuk, kiválasztva az összes felajánlott frissítési lehetõség közül azokat, amikre szükségünk van. Attól függõen, hogy bekapcsolt vagy kikapcsolt JavaScript mellett futtatjuk a kódot, egy kicsit más felület fogad bennünket. Mindenképpen feltûnõ a korábbiakhoz képest barátságosabb elõrehaladást mutató sáv, mely a végére érve egy összefoglaló oldalra irányít bennünket, ahol áttekinthetjük a frissítés során végrehajtott adatbázis átalakító utasításokat, és az esetleges hibaüzenteket. Ezzel az összes frissítésre felkészített modulunk mögött álló adatbázist sikeresen az új verzióra állítottuk át, meglátogathatjuk az eseménynaplót a rögzített esetleges hibaüzeneteket áttekintendõ, vagy rögtön a címlapunkra léphetünk.

A drupal.hu változat: párhuzamos tesztelés Akik hozzánk hasonlóan saját modulokat is adtak a rendszerhez, esetleg még sminket is szeretnének változtatni, vagy már korán el szeretnék kezdeni a frissítés elõkészítését, azok nem számíthatnak azonnal megfelelõ eredményre. Könnyen lehet, hogy a teszteléshez használt rendszert folyamatosan a meglévõ rendszer mûködtetése mellett kell elõkészíteni. Ezt tettük a Drupal.hu esetében is. Mivel a folyamatos párhuzamos üzemeltetés nem kényelmes kézi eszközökkel, egy kis segésszkriptet valósítottuk meg, mely veszi a meglévõ drupal.hu adatbázist, és az azonos szerveren, de a világ szeme elõl elrejtve karbantartott tesztelésre használt virtuális hosztnak megfelelõ adatbázisba másolja azt. A PHP-beli megvalósítás lehetõvé teszi, hogy speciális módosításokat is végrehajtsunk az adatbázison, mielõtt az update.php-t futtatjuk. Nézzük részleteiben a klónozásra használt szkript kódját:
55/135

2010.02.11. Magyar Drupal Kézikönyv $conn = mysql_connect("localhost", "ujuser", "ujjelszo"); mysql_select_db("ujdrupalhu", $conn); // Ujdrupalhu tablak eldobasa $tables = mysql_list_tables("ujdrupalhu", $conn); while ($r = mysql_fetch_row($tables)) { mysql_query("DROP TABLE ujdrupalhu.$r[0]", $conn); } ?>

Az elsõ fontos pont, hogy nem a Drupal rendszer adatbázis mûveleteit használjuk, hiszen ahhoz be kellene tölteni a Drupal alaprendszert, ami viszont egy aktuális adatbázis sémát feltételez, és éppen ez az, ami még nem áll rendelkezésünkre. Így magunkra vagyunk utalva. Annyit teszünk, hogy az új adatbázishoz csatlakozva eldobjuk annak minden tábláját (egy korábbi klónozás eredményét), és felkészülünk az újabb klónozásra.

Ezekután nincs mit tenni, mint egyenként venni a drupalhu adatbázis tábláit, a CREATE TABLE utasításukat lemásolni, az ujdrupalhu adatbázisban felhasználva lefutattni, majd az adatokat átmenteni. Ez természetesen azért lehetséges, mert olvasási jogot kapott az ujuser felhasználó a korábbi drupalhu adatbázisra. Ott más jogosultságra nincs szüksége, és nem is szabad adni neki, nehogy a frissítés negatívan érintse a meglévõ rendszert. Mivel elkészült a korábbi adatbázis másolata, akár rögtön neki is állhatunk az update.php futtatásának, mi azonban kihasználva a PHP nyújtotta lehetõségeket, még a fent említett adat eldobásokról is gondoskodunk, elmozgatva a felesleges adatokat, amik csak meghosszabbítanák a frissítést.

Ugyanitt lehetõségünk van azoknak a módosításoknak a végrehajtására is, amiket a frissítés után a webes felületen amúgyis végrehajtottunk volna. Például az elõzõ részben leírtak szerint új saját fejlesztésû simplelinks.module helyettesíti a korábbi weblink modul funkcionalitását, így a weblink bejegyzését töröljük, a simplelinks bejegyzését viszont hozzáadjuk az adatbázishoz. Ehhez hasonlóan bármilyen elõkészítõ lépést megtehetünk. Mindez természetesen nem lenne szükségszerû, ha a folyamatosan alakított és frissített Drupal illetve modul drupal.hu/kezikonyv/nyomtatobarat

56/135

2010.02.11.


forráskódok miatt nem kellene rendszeresen újra futtatnunk a frissítést. Így viszont a folyamat automatizálása jelentõsen könnyítette az életünket. Maga a frissítés természetesen már az update.php betöltésével kényelmesen elvégezhetõ.

Drupal.hu specialitás: a kódolások visszavágnak Még egy momentum okozott számunkra fejfájást. A drupal.hu mögött álló adatbázis tábláinak szöveges mezõi történelmi okok miatt (eléggé helytelenül) iso-8859-2 kódolásúra vannak állítva a MySQL számára. Ez nem okoz különösebben gondot a napi mûködésben, ilyen adatbázisban is tud a MySQL UTF-8-as adatokat tárolni. A 4.7.0 frissítése azonban a szöveges mezõk típusát kifejezetten UTF-8 beállításúra próbálja állítani. Ez nem is lenne gond, ha a kapcsolat kódolását már a konverzió elõtt az elsõ pillanattól nem UTF-8-ra állítaná a rendszer. Így viszont az iso-8859-2 kódolású mezõket átvezetve ezen a kapcsolaton olyan karaktersorozatokat kap a PHP, melyeket a Drupal által elõszeretettel használt unserialize() nem tud kibontani (nem annyi karakter van ugyanis a kódolás váltás miatt a karaktersorozatban, mint amit az unserialize() elvárna). Ez nem teszi lehetõvé a frissítés lefutását, menetközben végtelen ciklusba kerül (körülbelül 70%-os frissítettségnél). A probléma megoldása egyszerûbb, mint amilyennek a gond leírása hangzott. Egyszerûen nem alkalmazunk UTF-8 alapú kapcsolatot addig, amíg nem olyan formában állnak rendelkezésre az adatok. Ehhez a database.mysql.inc fájlban a 84-86. sorban a következõ módosított változatot használjuk: =') && !function_exists('update_sql')) { mysql_query('SET NAMES "utf8"', $connection); } ?>

Az update_sql csak az update.php által betöltött oldalon létezik, így a frissítés során nem lesz aktív ez a kapcsolat kódolás beállítás, csak késõbb. Ehhez még hozzá kell vennünk egy cache tábla eldobást a frissítési oldalak végén, különben elõfordulhat, hogy olyan gyorsítótár állapot marad meg az adatbázisunkban, ami az új kódolásnak nem megfelelõ (az unserialize() által használt formátum miatt). Ezért beillesztettük még az alábbi sort a Drupal update.php kódjának végére:

Hogy erre a két módosításra szüksége van-e más magyar Drupal webhely mûködtetõknek, az azon múlik, hogy a frissítés enélkül is sikeresen lefut-e, azaz hogy milyen adatbázis struktúra volt a korábbi adatbázisban. Az mindenesetre fontos, hogy a majdani késõbbi frissítések már helyes kódolással fussanak le, tehát az elsõ kis változtatást a késõbbiekben már nem szabad a rendszerben hagyni.

Frissíteni könnyû Akár a hivatalos verziót követjük, akár a klónozásos párhuzamos tesztelést, a megfelelõ elõkészítõ lépések megtétele után a frissítés könnyedén le tud futni. Ha mégis probléma lenne a frissítéssel, akkor a drupal.org hibajelentõjében lehet részletes hibajelentéssel élni, mely javítása esetén egy remélhetõleg még jobban használható frissítési folyamathoz vezet a jövõben.

Kiegészítések beszerzése és telepítése drupal.hu/kezikonyv/nyomtatobarat

57/135

2010.02.11.


A Drupal kiegészítések (modulok, sminkek) nincsenek olyan rövid pórázon tartva, mint a Drupal magja, ezért igen sokféle tapasztalatunk lehet a kipróbálásukkal, attól függõen, hogy egy kiforrott és népszerû modult, vagy egy új, esetleg kevésbé eltrjedt modult használunk. A különbözõ Drupal kiadásokhoz megjelent modulokat és egyéb kiegészítõket a Drupal.org projektek oldaláról lehet beszerezni. Figyeljünk arra, hogy a megfelelõ Drupal alapmotorhoz a megfelelõ kiegészítõ verziót válasszuk. A számok illesztésének módjáról a magyar kézikönyv bevezetõ részében olvashatnak az érdeklõdõk. Az egyes kiegészítõk telepítési folyamata jelentõsen eltérõ lehet, elõfordulhat, hogy csak néhány fájlt kell bemásolnunk a Drupal mappájába, majd engedélyeznünk kell a modult (amely esetleg ekkor adatbázis módosításokat hajt végre). Ritkábban olyan modulokkal is lehet találkozni, melyek foltok (alapcsomag módosítások) alkalmazását is elvárják a helyes mûködéshez. A konkrét telepítési lépésekrõl a kiegészítõvel kapott README.txt illetve INSTALL.txt állományokban lehet részleteket megtudni. Minden modul információt tartalmaz arról, hogy ha nem használhatjuk önmagában, hanem valamilyen más modul bekapcsolását igényeli. Ilyenkor a Drupal nem teszi lehetõvé a modul bekapcsolását, amíg a szükséges másik modult vagy modulokat fel nem telepítjük. Ezután nem tudunk olyan modult kikapcsolni, amely meglétére más bekapcsolt modul épít. Ez jelentõsen könnyíti a modulok megfelelõ telepítését.

Fejlesztõi változatok letöltése Elõfordulhat, hogy valamilyen okból olyan modul fejlesztõi változatára van szükségünk, amelynek a weben letölthetõ csomagja sem érhetõ el. Ezesetben nem tudunk mást tenni, mint a Drupal CVS kiszolgálójáról begyûjteni az állományokat. A webes felület alkalmas lehet az fájlok felderítésére, de a letöltés egyenként nem túl kellemes. Ezért javasolt egy CVS kliens használata. Számos ilyen kliens létezik, vannak parancssori változatok, és asztali grafikus felhasználói felülettel rendelkezõ megoldások is. Az alábbiakban a Windows rendszerekre elérhetõ Tortoise CVS szoftverhez adunk tippeket, mert ez a legkényelmesebb megoldás a Drupal CVS verziójának letöltésére, és frissen tartására, hiszen közvetlenül a Windows Intézõbe épül be. A következõ lépések szükségesek a program megfelelõ beállításához: TortoiseCVS letöltése és telepítése. Ehhez elérhetõ magyar nyelvû felület is, itt az angol felületrõl mutatunk be képeket. Tetszõleges, használni kívánt munkakönyvtár kiválasztása a Windows Intézõben. A mappában indított jobbgombos menüben egy CVS Checkout menüpontnak kell szerepelnie.


58/135

2010.02.11.


Erre a következõ dialógus ablak jelenik meg, melyet megfelelõen ki kell tölteni:

A fenti ábra a Drupal motor aktuális fejlesztõi változatának beszerzésére szolgáló parancsokat mutatja. Ha a közösségi fejlesztõi területre vagyunk kíváncsiak, akkor a Repository folder értékét állítsuk a /cvs/drupal-contrib útvonalra, a Module pedig legyen a contributions. Az OK gomb lenyomására a program felveszi a kapcsolatot a CVS szerverrel. A letöltéshez használható jelszó mindkét esetben: "anonymous". A megjelenõ ablakban folyamatosan látható az aktuális letöltési állapot, s végül sikeres letöltés esetén a Success, CVS operation completed üzenetet kapjuk. A Drupal motor és a közösségi terület tartalma napról napra változik, bõvül. A saját gépünkön található másolat frissen tartása érdekében szükség esetén a munkakönyvtárban a jobbgombos menü CVS Update parancsát futtassuk le. Korrekt végrehajtás után az aktuális fejlesztõi verzió másolata lesz elérhetõ saját gépünkön is.

Különbözõ jelölésû fejlesztõi változatok Könnyen meglehet, hogy nem a legfrissebb kód érdekel bennünket, hanem például csak a 5.0-s sorozat javításait szeretnénk letölteni és mielõbb használni. A CVS változáskövetõ rendszer biztosítja, hogy a fejlesztést több ágon folytathassák, így válik lehetõvé a Drupal 5.x-s sorozat hibáinak javítása és a késõbbi 6.x-s sorozat elsõ tagjának elõkészítése is egyidõben. Az ágakat az angol terminológia branch néven emlegeti. Azt is fontos megjegyezni, hogy a külön ágat nem igénylõ, ámde kiadások szempontjából fontos pontokat is meg lehet jelölni. A 5.1-es vagy 6.2-es kiadások a nekik megfelelõ 5.x-es és 6.x-es ágon egyegy ilyen ponthoz tartoznak. A jelölésekhez úgynevezett címkéket (tag-eket) használnak. A CVS checkout mûvelet végrehajtásakor lehetõségünk van egy kiválasztott ág legfrissebb kódjának vagy drupal.hu/kezikonyv/nyomtatobarat

59/135

2010.02.11.


pontosan egy címkével megjelölt kód állapotnak a letöltésére is. Erre a Revision fülön nyílik lehetõség, ahogy ezt a következõ ábra mutatja. Az Update list... gomb szolgál a lekérhetõ ágak és címkék neveinek listázására. A Drupal közösségi fejlesztõi területén a különbözõ ágak nem érhetõek el a gyökérben, ezért az alkönyvtárak átfésülését kérõ jelölõnégyzetet is mindenképpen be kell jelölni.

A három számjegyet is tartalmazó címke nevek pontosan a csomagolt kiadásokhoz tartozó forráskódokat fogják szolgáltatni, a két jegyet tartalmazó ág nevek pedig az adott ágon található legfrissebb forráskódot.


60/135

2010.02.11.


Amennyiben egyszerre több változat saját gépen tartása is szükségessé válik, akkor még egy lehetõséget ki kell használnunk. A CVS checkout által létrehozott mappának nem kell feltétlenül a drupal illetve contributions nevet felvennie, ezek csak a CVS ajánlásai. Ha több változatot is a gépünkön tartunk, akkor ezeket a címke illetve ág neveknek megfelelõen érdemes elnevezni. Ennek beállítására a harmadik – Options nevû – fülön nyílik lehetõség. A Name of folder to create alatt válasszuk az Enter your own folder name lehetõséget, és adjunk meg egy egyedi nevet.


61/135

2010.02.11.


Modulok fejlesztése A Drupal számos modullal rendelkezik alapfunkcionalitásainak megvalósítására. Ezen kívül rendelkezésünkre áll a közösség által fejlesztett kiegészítõk garmadája, melyekkel rendkívül változatos formában egészíthetjük ki webhelyünket. Elõfordulhat ugyanakkor, hogy nem áll rendelkezésre olyan modul, amire nekünk szükségünk van, vagy a meglévõk nem pontosan azt nyújtják, és beállításokkal sem érhetjük el, amit szerertnénk. Ezen esetekben logikus lépés lehet, hogy saját modult fejlesztünk, vagy a meglévõ modulokat módosítjuk saját igényünk szerint. Annak eldöntése, hogy újabb modult érdemes fejleszteni, vagy egy meglévõt módosítani, nem mindig egyszerû kérdés. Az alapmotor vagy valamely kiegészítõ modul módosításával olyan feladatot veszünk a nyakunkba, mely csak késõbb jelentkezik. Amennyiben valamikor frissíteni szeretnénk a rendszert mûködtetõ kódokat, magunknak kell figyelnünk a változások fenntartására, a felülírások elkerülésére. Ebben nagyon sokat segíthet egy változáskövetõ rendszer (CVS, Subversion), ezeket azonban nem használják szélesebb körben. Ezért ha jelentõsen eltérõ funkcionalitásra van szükségünk, mint amit egy meglévõ modul nyújt, akkor célszerû lehet annak lemásolása, és más néven történõ továbbfejlesztése saját céljainkra. Érdemes elolvasni az Amikor változtatni kell a Drupal kódján címû sorozatunk elsõ és második részét. Amennyiben olyan kiterjesztési ötletünk, javaslatunk van egy modulhoz, mely széles körben is érdeklõdésre tarthat számot, akkor ezt célszerû a modul fejlesztõjének javasolni. Az alapmodulok, és a kiegészítõk is rendelkeznek hibajelentõ és javaslat beküldõ felülettel, ahol ötleteinket megadhatjuk. Általában jó gyakorlat, és a teljes rendszer fejlõdését elõbbreviszi, ha saját általános célú fejlesztéseinket a nyilvánosság elé tárjuk, és erre a Drupal fejlesztõi szervere lehetõséget is ad. Ezesetben természetesen kicsit körültekintõbben kell a fejlesztett modult elkészítenünk, de ez csak a minõségi kialakítást segíti, ezért kifejezetten hasznos is lehet.

Legyen saját Drupal API oldalad! Az új Drupal stabil kiadásához közeledve hasznos lehet, ha az ember újragondolja, átnézi a fejlesztéseit, hiszen a legtöbb esetben mindenképpen módosítani kell az általa kifejlesztett, egyedi funkcionalítást adó modulon, hogy használható legyen a Drupal 6 alatt is. Ilyenkor nagy segítséget jelent az api.drupal.org, ahol könnyen lehet keresni a használható függvények között, megnézni a paraméterezését, vagy a működését. Viszont nem mindenkinek áll a rendelkezésére az Internet, mint ahogy jómagam is ebben a helyzetben voltam évekig, így szeretném bemutatni az ilyenkor használható hűséges segítőtársamat: az API modult, amelyet teljesen offline működésre fogunk bírni. A megoldást Linux operációs rendszer alatt teszteltem, és ott is használom, így azokról az esetleges eltérésekről, amelyek a Microsoft Windows alatt jelentkezhetnek (pl. a fájlrendszer elérése), nem tudok nyilatkozni. Amire szükségünk lesz: Egy feltelepített Drupal rendszerre, mivel erről a kézikönyv is hosszasan ír, ezért inkább itt nem taglalnám Az API modulra, ugyan a modul nem rendelkezik még magyar fordítással, de enélkül is könnyen érthető a felülete Kell még a PHP függvények rövid leírása, amelyet itt fogunk megtalálni, mentsük le funcsummary.txt néven (a download linkre kell kattintani) drupal.hu/kezikonyv/nyomtatobarat

62/135

2010.02.11.


A minél teljesebb dokumentációhoz szükséges még néhány dokumentáció (pl. Form API), és egyéb példakódok, ezeket a következő paranccsal tudjuk kinyerni a Drupal tárolóból: cvs -z6 -d:pserver:anonymous:[email protected]:/cvs/drupal-contrib checkout -r DRUPAL-5 contributions/docs/developer

Végül pedig szükséges még a PHP dokumentáció, itt fontos, hogy a több fájlból álló változatot válasszuk, amely innen tölthető le magyar nyelven. Ha ezek megvannak, akkor minden szükséges dolgot letöltöttünk, vigyük haza, és lássunk munkához! Először is, a webszerver által használt gyökérkönyvtárban hozzunk létre egy alkönyvtárat phpdoc néven, és oda tömörítsük ki a PHP dokumentációt, majd ebben a könyvtárban hozzunk létre egy fájlt .htaccess névvel, amelynek a tartalma legyen a következő: RewriteEngine on RewriteBase /phpdoc/html RewriteCond RewriteCond RewriteCond RewriteRule

%{REQUEST_FILENAME} !-f %{REQUEST_FILENAME} !-d %{REQUEST_FILENAME} ^(.*)_(.*)$ ^(.*)_(.*)$ $1-$2

RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^([0-9A-Za-z\-]*)$ function.$1.html [L]

Ezzel elértük azt, hogy a http://localhost/phpdoc/html/is_array címen megjelenik az is_array PHP függvény leírása, ez amúgy többféle módon is megoldható, érdemes elolvasni a Weblabor kapcsolódó cikkét. Szintén ebbe a phpdoc könyvtárba másoljuk be a korábban lementett funcsummary.txt állományt. Az api modul bekapcsolása után az adminisztrációs oldal "webhely beállítása" részében megjelent egy új menüpont "API reference" néven, itt tudjuk a modul működését szabályozni. Az első megadandó dolog a "Short name", ezt majd a címek generálásakor használja a Drupal, így nem tartalmazhat szóközt, vagy olyan karaktert, amely nem megengedett az internet-címekben. A következő a "Long name", ez lesz a blokk látható neve, fontos szerepe van akkor, ha egyszerre több Drupal dokumentációját, mondjuk a stabil és a fejlesztői változatét kívánjuk elkészíteni. A "Directory name" helyen kell megadnunk az indexelni kívánt Drupal abszolút elérési útvonalát, akár egyszerre többet is, kettősponttal elválasztva. A "Maximun files to scan per cron run" helyen állíthatjuk be, hogy az időzített feladatok futása közben egy-egy alkalommal hány fájlt dolgozzon fel. Ezt érdemes az alapértelmezett 10 értéken hagyni, így nem futnak ki folyamatok az engedélyezett időből. A "Save changes" gombra kattintva elmenthetjük az itt megadott adatokat, így lehetőség nyílik másik telepítés leindexelésére is, majd ha többet is beállítottunk, a "Default branch" rádiógomb alatt lehetséges az alapértelmezettet kiválasztani. Fontos, hogy miután megjelent a "Changes saved." felirat, akkor mégegyszer nyomjuk meg ezt a gombot, mert ekkor menti el a "Default branch" tartalmát, ennek hiánya esetlegesen galibát okozhat. A "PHP Manual" résznél az első helyre írjuk be a funcsummary.txt elérési helyét: http://localhost/phpdoc/html/funcsummary.txt A második résznél pedig megadhatjuk PHP dokumentáció helyét a gépünkön, a "!function" karaktersorozattal kiegészítve (ide kerül majd a függvény neve), tehát: http://localhost/phpdoc/html/!function drupal.hu/kezikonyv/nyomtatobarat

63/135

2010.02.11.


Majd ha ezek megvannak, kattintás az "Index PHP manual pages" gombra, és egy kis várakozás. Ha végzett, és mindent helyesen állítottunk be, akkor a "Reindex" gombra kattintva megkezdődik a megadott Drupal rendszerek forrásának feldolgozása. Most nincs más dolgunk, mint szorgosan futtatni az időzített feladatokat, akár böngészőből: http://localhost/ahol_van_az_oldalunk/cron.php, akár konzolból a wget -O - -q http://localhost/ahol_van_az_oldalunk/cron.php

parancsot futtatva. Annyiszor kell ezt végrehajtani, amíg a hozzáférési naplóban az api modulhoz tartozóan a "Parsing" kezdetű üzenetek el nem fogynak. Ezek után már csak egy lépés választ el minket a sikertől: Az adminisztrációs oldal "Blokkok" részében kapcsoljuk be az "API navigation" és az "API search" blokkokat, majd a főoldalra lépve legyünk boldogok, és válljék egészségünkre a gépünkön üzemelő Drupal API dokumentációs rendszer.

Modulok helye, elnevezése és a hurkok A Drupal moduljai a modules könyvtár alatt találhatóak. Lehetõség van arra, hogy minden modul közvetlenül ebben a mappában helyezkedjen el, de több fájlból álló modulok esetén célszerû külön alkönyvtárakat létrehozni, hiszen a rendszer azokban is megtalálja a kiegészítõket. A külön alkönyvtár létrehozását egyes kiegészítõ modulok telepítési utasításai kifejezetten ajánlják. A késõbbi karbantarthatóság érdekében néhányan azt az utat követik, hogy csak az alapmodulokat tartják meg közvetlenül a modules mappában, és a kiegészítõket mindig alkönyvtárakban helyezik el. Így jobban azonosítható a modulok származási helye. Arra is lehetõség van, hogy egy-egy alkönyvtárba egyszerre több modult helyezzünk, a részmodulokból álló kiegészítések is ezt a megközelítést alkalmazzák.

Elõkövetelmények Lássuk, mi szükséges a modul fejlesztés megkezdéséhez: Természetesen nem érdemes saját modul fejlesztésébe fogni, ha nem rendelkezünk adminisztrátori jogosultságokkal egy telepített Drupal rendszeren. Ahhoz, hogy modulokat tudjunk engedélyezni, vagy egy modul beállításait módosítani tudjuk, ilyen jogosultságra szükségünk lesz. Szintén elengedhetetlen, hogy fájlrendszer elérésünk legyen a Drupal telepítéshez, hiszen új illetve módosított modul állományunkat valahogy a rendszer modules mappájába kell juttatnunk. A Drupal moduljai PHP szkriptek, melyeket a rendszer a megfelelõ idõben betölt, ezért fejlesztésükhöz PHP tudás szükséges. A rendszer fejlettségéhez képest meglepõ lehet, de a modulok (és sminkek) készítéséhez objektum-orientált programozási tapasztalat nem szükséges, a Drupal csak adathordozóként használja az objektumokat, viselkedéssel nem ruházza fel azokat. A függvények használata a fejlesztés során természetesen elõnyökkel és hátrányokkal is jár. A legfontosabb elõnyök: gyors program végrehajtás, könnyû bekapcsolódás a fejlesztésbe, a funkcionalitás egyszerû megosztása különbözõ fájlok között. A legkomolyabb hátrány a különbözõ függvényhívások között megõrizhetõ adatok lehetõségének hiánya, mely problémát azért meg lehet kerülni, és ezt a megoldást a Drupal rendszerben is többször kihasználják. Amennyiben modulunk valamilyen adatbázis kezelési mûveletet is igényel, SQL tudásra is szükségünk lehet. Ha szélesebb körben használható modult fejlesztünk, akkor oda kell figyelnünk a szabványos SQL használatára. drupal.hu/kezikonyv/nyomtatobarat

64/135

2010.02.11.


Elnevezési szabályok A modulok állhatnak több fájlból is, de mindenképpen szükséges egy a modul neve szerint elnevezett .module kiterjesztésû fájl, ugyanis ezeket ismeri fel a Drupal modulokként. Amennyiben eseteként betöltendõ kiegészítõ funkcionalitást is szeretnénk a modulba építeni, akkor azt .inc állományokba helyezhetjük. Példák: story.module, bbcode.module, bbcode-filter.inc. A Drupal telepítésekor beállított .htaccess állomány Apache szerver esetén biztosítja azt, hogy a speciális .module és .inc kiterjesztés védett legyen a webes kiszolgálás szempontjából, azaz, hogy ne tudják böngészõbõl lekérdezni a webhelyünk forráskódját. Moduljainkban fõleg az állomány kiterjesztés elõtti neve alapján elnevezett függvényeket definiálunk, mint story_help, story_page, bbcode_filter, stb. Ezért nagyon fontos, hogy az állomány nevét úgy válasszuk meg, hogy az csak PHP függvénynévben használható karaktereket tartalmazzon. Nem szabad kötõjelet vagy más speciális karaktert használni a modul fájl nevében, mert ilyenek függvénynévben nem szerepelhetnek. A Drupal 4.7-ben bevezetett speciális fájlok az .install kiterjesztésû telepítést kezelõ állományok. Ezek segítségével lehet a modulunkhoz telepítés során lefutó kódot csatolni, így létrehozva a kapcsolódó táblákat, felvéve bizonyos beállításokat.

Hurkok és más függvények Nagyon ritkán fordulhat az elõ, hogy a Drupal forráskódját módosítanunk kell, hiszen a rendszer számos ponton lehetõvé teszi a folyamataiba történõ beavatkozást az úgynevezett hurkokon (hook) keresztül. Ezek olyan speciálisan elnevezett függvények, melyek szükség esetén meghívódnak. Nekünk nem kell törõdni azzal, hogy meghívásra kerüljenek, errõl a Drupal gondoskodik. A hurkoknak nem csak a neve, hanem a paraméterezése is kötött, a hurok definiálója adja meg, hogy mi az elvárt paraméter lista. Saját hurok megvalósításainkat is ennek megfelelõen kell létrehoznunk. A hurokfüggvények a dokumentációban hook_menu, hook_block, hook_perm, stb. néven vannak definiálva. A saját hurok megvalósításunknál a nevekben a hook elõtagot a modulunk nevére kell cserélni. A fenti példákkal élve story_help és bbcode_perm egy-egy hurok megvalósítás. Néhány fontosabb hurok: hook_help($section)

A modul leírásának megadására és általában a Drupal rendszer oldalain megjelenõ súgók definiálására szolgál. Az adminisztrációs felületek segítõ leírásai ezzel adhatóak meg. hook_menu($may_cache)

A rendszermenübe történõ menüpont felvételt teszi lehetõvé, valamint a menütõl függetlenül biztosítja webcímek függvényekhez rendelhetõségét. A különbözõ oldalakon megjelenõ fülek definiálására is ezt használhatjuk. hook_block($op = 'list', $delta = 0, $edit = array())

Az oldal blokkjainak összeállításakor hívódik meg, lehetõvé téve modulunk által definiált blokk illetve blokkok létrehozását. Az ilyen blokkok teljes értékûek a rendszerben, azaz a hagyományos blokk mûveletek elvégezhetõek ratjuk. Ezek a példák csak ízelítõt adnak a hurkok lehetõségeibõl, hiszen sokkal több hurok áll rendelkezésre, melyeket felhasználhatunk, sõt saját modulunk is definiálhat hurkot, melyet más kiegészítések implementálhatnak. Mivel számos hurok lehetséges, azokat a függvényeket, melyeket nem hurok megvalósításnak szántunk, drupal.hu/kezikonyv/nyomtatobarat

65/135

2010.02.11.


körültekintõen kell elnevezni. Gyakori például a modulneve_page függvény, mely a modul HTML oldalait állítja elõ, ez azonban nem hurok, és nem is alkalmazza minden modul ezt az elnevezést az oldalát elõállító függvény definiálására. Annak érdekében, hogy elkerülhessük az esetleges név ütközéseket, célszerû a csak belsõleg használt függvények neve elé egy aláhúzást tenni, mint: _story_getcontent vagy _bbcode_filter_process. A szabályok mentén elnevezett függvényeknek még egy csoportja van, ezek pedig a smink függvények. Nem kötelezõ smink függvényt definiálnunk, ezek segítségével azonban lehetõvé tehetjük, hogy modulunk kimenetének valamely részét sminkeljék – kinézetét megváltoztassák. A smink függvények nevének elõtagja meghatározott, mégpedig minden esetben theme_modulneve_. Smink függvény név példák: theme_story_display, theme_bbcode_list.

Forrás dokumentáció Kézikönyvünkben nem vállalkozhatunk arra, hogy minden egyes hurkot dokumentáljuk, különösen, hogy felhasználásuk egy mintát követ, ezért egyik-másik hurok megismerése után újabbak elsajátítása már igen egyszerû. A Drupal jelentõsebb verzióról-verzióra változtatja a hurkok paraméterezését, elvárt mûködését vagy akár nevét is. Éppen ezért a Drupal forrása gazdagon tûzdelt dokumentációs megjegyzésekkel, melyek a phpdoc formát követik. Ennek keresztreferenciás megtekintéséhez egy külön API modult fejlesztettek ki, melyet mi is telepíthetjük magunknak, hogy közelrõl böngészhessük az elérhetõ függvényeket és hurkokat. Azoknak, akik nem szeretnék telepíteni ezt a modult, egy nyilvános felület is elérhetõ az api.drupal.org címen. A saját munkánkat is le tudjuk egyszerûsíteni, ha szükség esetén a Drupal által kezelt adatokat a rendszer lekérdezõ függvényei segítségével szeretnénk megkapni. Az adatbázis függetlenítõ, felhasználó kezelõ, ûrlap generáló, smink kezelõ stb. függvényeken túl az egyes modulok is rendelkeznek olyan függvényekkel, amelyeket újra tudunk hasznosítani, meg tudunk hívni, ha adatokra van szükségünk. A hurkokkal lehetõségünk van kiterjesztést fejleszteni, és beépülõ komponenseket készíteni, de a hurkokon felül a Drupal függvénykészletének ismerete jelentõsen megkönnyíti, hogy gyors, biztonságos és átlátható kódot készítsünk. Az említett forrás dokumentáció ebben is nagy segítségünkre lehet.

Fordítható felület készítése Saját modul fejlesztésekor hamar felmerülhet a kérdés, hogy egy gyorsan saját célra összerakott kiterjesztést készítünk, avagy szeretnénk azt szélesebb körben is publikálni, visszaadva a nyílt forrású közösségnek valamit abból, amit ajándékba kaptunk. Ha más nyelvi környezetben is használhatóvá szeretnénk tenni a modulunkat, akkor nem árt, ha felkészítjük arra, hogy több nyelven is beszéljen. Ugyanez a probléma merül fel akkor is, ha saját oldalunkon szeretnénk több nyelvet támogatni. Fordítható felület kialakítására a Drupal két egyszerû függvényt biztosít, és ezeket elegendõ ismernünk ahhoz, hogy több nyelvet támogató felületet készítsünk. A t() függvény karaktersorozatok lefordítására szolgál, míg a format_plural() egyes- és többesszámban álló alakok kiírására. Lássunk néhány rövid példát:
66/135

2010.02.11. Magyar Drupal Kézikönyv // Fájl nevét ki szeretnénk írni (de itt is hibásan) [2] $message = t('Unable to load file:') . ' ' . $filename; // Fájl nevének kiírása helyesen [3] $message = t('Unable to load file: %filename', array('%filename' => $filename)); ?>

A t() tehát egy adott karaktersorozat lefordítására szolgál. Arról a Drupal gondoskodik, hogy a megfelelõ nyelvre történjen lefordításra az adott karaktersorozat, ha az adatbázisban rendelkezésre áll hozzá tartozó fordítás. Néhány általános szabály t() fordítások írásához: HTML használatát célszerû kerülni a karaktersorozatokban – kivéve a hosszabb súgó szövegeket, ahol ez elkerülhetetlen. Dinamikusan betöltendõ tartalmakat nem karaktersorozat befûzéssel [2] kell megoldani, hiszen ez nem teszi lehetõvé a befûzendõ tartalom áthelyezését a fordításban, ami szórendi okok miatt szükséges lehet. Változóhelyettesítést használni szintén teljesen céltalan [1], hiszen akkor annyi fordítandó karaktersorozat lesz, amennyi behelyettesített érték elõáll, a fenti esetben a lehetõségek száma gyakorlatilag végtelen. Ilyen esetekben tehát a megoldás egy helykitöltõ használata [3], mely általában a százalékjellel kezdõdik, és aztán néhány karakterben leírja, hogy mi kerül arra a helyre. A t() második paraméterében megadott tömbben kell az egyes helykitöltõkhöz tartozó értékeket megadni. Így lehet a fordítás például: "%filename betöltése nem sikerült" A format_plural() akkor használatos, ha valamilyen mennyiséget szeretnénk kiírni, melynél a kísérõ szavakat másképp kell írni a mennyiségtõl függõen. Magyar nyelvben csak egy változat van az '1 meggymag', '243 meggymag', stb. megfogalmazására, mennyiségtõl függetlenül. Angol nyelvben az egyes szám és többesszám különválik, és vannak olyan nyelvek, ahol sokkal többféle formát használnak. A megfelelõ fordítások elõállítása persze az adott fordítói csapat dolga lesz, nekünk csak a format_plural() használatával kell tisztában lennünk.

Az elsõ paraméter egy egész szám, a következõ kettõ pedig az egyes és többesszámú alak. A többesszámú alakban a %count helykitöltõt használhatjuk, ami a szükséges idõben a $number értékével helyettesítõdik majd – miután a megfelelõ fordítást sikerült megtalálni. Természetesen vannak további függvények, melyek hátterében felület fordítás is áll. Ilyenek például a format_interval() és a format_size(), ezekkel viszont nem kell feltétlenül törõdnünk, hiszen a nyelvi szükségleteiket saját hatáskörben megoldják.

Sminkek készítése A Drupal sminkrendszere rendkívül rugalmas, sok utat biztosít az egyedi oldalak kialakítása felé. Lehetõségünk van új sminket (stílust) építeni meglévõ sminkre, új sminket írni egy sablonkezelõ (leggyakrabban a PHPTemplate) segítségével, vagy közvetlenül a Drupal smink függvényeivel PHP alapokon. Smink készítése csak stíluslapokkal. Lehetõség van arra, hogy egy meglévõ sminkbõl pusztán CSS és más médiaállományok (képek, Flash mozik stb.) hozzáadásával készítsünk egy másikat. Ehhez mindössze nyitnunk kell egy könyvtárat annak a sminknek a könyvtárán belül, amelyiket testre szeretnénk szabni. Oda kell tennünk a saját style.css nevû stíluslapunkat, és esetleg egyedi drupal.hu/kezikonyv/nyomtatobarat

67/135

2010.02.11.


képeinket, más média állományainkat. A smink neve a most nyitott könyvtár lesz. Smink készítése sablonokkal. A következõ szint, amikor már saját sminket készítünk valamilyen sablonkezelõ motor segítségével. Ha HTML-t tudunk szerkeszteni, és a PHP-tõl sem riadunk vissza, akkor a Drupal rendszerrel szállított PHPTemplate sablonkezelõ segítségével bonyolultabb egyedi sminket is tudunk készíteni. Smink készítése PHP függvényekkel Végül, ha jól értünk a PHP-hez, és/vagy speciálisabb igényeink vannak, akkor teljesen önálló sminket is írhatunk a Drupal sablon függvényeinek megfelelõ alkalmazásával.

Saját PHP függvény alapú smink készítése Legegyszerûbb leírni a tiszta PHP smink készítését, ráadásul a PHPTemplate megértését segíti, ha elõször ezzel kezdem. Minden smink a themes alatt a saját könyvtárában lakik, és a neve megegyezik a könyvtárnévvel, a kiterjesztése pedig theme. Tehát az themes/sajatsmink könyvtárban van a sajatsmink.theme fájl. Ezen belül, hasonlóan a modulokhoz, különbözõ hurkokat valósíthatunk meg. Ezek a hurkok a kézikönyvben theme_-al kezdõdnek, élesen elkülönülve a hook_ hurkoktól. Ez utóbbi csak egy jelölés, míg a smink hurkok ténylegesen meg is vannak valósítva a includes/theme.inc fájlban. Például van egy theme_form_element smink hurok, amit a sajatsmink_form_element fájlban sajatsmink_form_element néven valósítunk meg. Ennek a függvénynek egy stringet kell visszaadni, amit aztán kiír majd a Drupal. Minden tiszta PHP sminknek meg kell valósítania a theme_features hurkot, ez egy tömböt ad vissza. A tömb leírja, hogy ez a smink mire képes. Lehetséges elemei: logo Megadhatunk egy logót. A sminknek ellenõriznie kell a default_logo (logikai) és logon_path (string) változók értékeit. toggle_logo A logó ki-be kapcsolható. toggle_name A weboldal neve ki-be kapcsolható. toggle_search A keresés doboz ki-be kapcsolható. toggle_slogan A jelmondat ki-be kapcsolható. toggle_mission A misszós üzenet ki-be kapcsolható. toggle_primary_links Az elsõdleges hivatkozások ki-be kapcsolhatóak. toggle_secondary_links A másodlagos hivatkozások ki-be kapcsolhatóak. toggle_node_user_picture A smink meg tudja jeleníteni a felhasználók képét a tartalmai mellett. toggle_comment_user_picture A smink meg tudja jeleníteni a felhasználók képét a hozzászólásai mellett. Például: drupal.hu/kezikonyv/nyomtatobarat

68/135

2010.02.11.


Az alap disztribúcióban ilyen típusú smink a chameleon. Angolul ezen az oldalon találhatjuk meg a smink hurkok listáját.

Tippek és trükkök Ezeken az oldalakon hosszabb-rövidebb tippeket osztunk meg olvasóinkkal, amik a Drupal megismerését, az arra való fejlesztést segíthetik.

A Drupal menürendszere A Drupal menürendszerébõl a felhasználók a megjelenõ navigációs menüt és a különbözõ füleket érzékelik, programozói szempontból viszont legfontosabb feladata az, hogy Drupal elérési címekhez kezelõfüggvényeket rendeljen. A megadott címek és paraméterek alapján jelennek meg a különbözõ menü elemek a navigációs blokkban illetve a füleken.

Drupal elérési címek Alaptelepítés esetén a q webcím paraméter értékét nevezzük elérési címnek, mely rövid webcímek támogatásával a webhely gyökerünkben elérhetõ fájl elérésnek tûnik. A következõ két webcímben az elérési cím értéke node/12: http://example.com/?q=node/12 és http://example.com/node/12. A programozó a menürendszert arra használhatja, hogy ezekhez a címekhez kezelõfüggvényeket rendeljen, meghatározza az adott felhasználóra számított elérési jogosultságokat, és a megjelenítésre adható információkat megadja.

A menü hierarchia, kezelõfüggvények, jogosultságok Új kezelendõ elérési címek felvételére a menü hurokban nyílik lehetõség, ami a hook_menu() megvalósítását jelenti. Korábban már felvett címet nem írhatunk felül. A bejegyzett elérési címek összessége egy egyszerû hierarchiát követ, melyet a megadott utak határoznak meg. A menürendszer egy oldal elõállításának elején a menü hurkoktól összegyûjti ezeket a címeket, és meghatározza az utakból összeálló hierarchiát. Például, ha meghatároztuk az a, a/b, e, a/b/c/d, f/g, a/b/h, utakat, akkor a következõ struktúrát kapjuk: a a/b a/b/c/d a/b/h e f/g drupal.hu/kezikonyv/nyomtatobarat

69/135

2010.02.11.


Vegyük észre, hogy az útvonal elemeinek száma nem feltétlenül határozza meg az adott elem mélységét a megjelenõ menüben – az f/g útvonalhoz tartozó menüelem ugyanolyan mélységben van, mint az e, és az f útvonalhoz nem tartozik oldal. Egy oldalkérésre válaszolva, a menürendszer megnézi, hogy a böngészõ által kért útvonalhoz tartozik-e bejegyzett elérési cím, melynek meghívható kezelõfüggvénye van. Ha nem, akkor elkezd keresni a fában minél teljesebb találat – meghívható kezelõfüggvénnyel rendelkezõ elem – után. Például, ha a fenti fát definiáltuk, és az a/b/i útvonalat kérjük le, akkor az a/b-hoz tartozó kezelõt hajtja végre a rendszer. Az olyan elérési címekre, melyekre a Drupal eszerint az algoritmus szerint sem talál bejegyzést, egy 404-es (nem található oldal) hibaüzenet ad vissza a látogatónak. A kezelõfüggvény megkapja azokat a paramétereket, melyeket a menüelem "callback arguments" jellemzõjében felvettünk. Ezután az útvonal megmaradt részeit is elérheti. Így például az a/b útvonalhoz tartozó kezelõ másként tudja kezelni az a/b/i és az a/b/j oldalt. Az elérési címek jogosultság ellenõrzése az alapján az "access" paraméter alapján történik, melyet egyegy cím bejegyzésekor megadtunk. Ha ez a jellemzõ TRUE, akkor lehetséges a hozzáférés, ha FALSE, akkor nem lehetséges. Az elõször megtalált "access" jellemzõ dönt a cél elérhetõségrõl. A menüelemek tehát elhagyhatják ezt a jellemzõt, és ilyenkor a szülõ elem által megadott érteket fogja a Drupal használni. Az olyan elérési címekre, melyek bejegyzettek a rendszerben, de nincs jogosultság az elérésükre, 403-as (nem jogosult elérés) hibaoldalt jelenít meg a Drupal.

Fülek Az alapértelmezett felületen sok menüpont fülként jelenik meg. Ezeket a menürendszer helyi feladatokként ("local tasks") tartja nyilván, és alapértelmezésben fülekként jeleníti meg, noha más vizualizáció is lehetséges. A helyi feladatok szinte minden tekintetben ugyanúgy mûködnek, mint más menüelemek. Az a megállapodás, hogy ezeknek a neve lehetõleg egy rövid ige legyen. A fában közös szülõvel rendelkezõ helyi feladatokat feladatcsomagnak nevezzük. Minden ilyenhez szükséges egy alapértelmezett feladat megadása. Ez jelenik meg, amikor a feladatcsomag szülõelemét látogatjuk meg. Ebben az alapértelmezett feladat különleges, mert nem a saját útvonalához kapcsolódik, hanem a szülõjéhez. A saját útvonalát csak a menühierarchiában elfoglalt helyéhez használja a rendszer.

Gyakorlati példák Legegyszerûbb meglévõ példákból tanulni a menürendszer részleteit, hiszen azok – bizonyos dokumentációkkal ellentétben – mindig aktuálisak, különben nem mûködnének. Lássunk néhány példát a menürendszer használatára. Az egyik legbonyolultabb példa a node.module fájlban található. Az érdekesebb részeket itt megvizsgáljuk: 'admin/node', 'title' => t('content'), 'callback' => 'node_admin', 'access' => user_access('administer nodes')); /* Ha a felhasználó rendelkezik 'administer nodes' jogosultsággal, akkor a menüben megjelenik egy t('content'), magyarul Tartalom nevû elem. Ha drupal.hu/kezikonyv/nyomtatobarat

70/135

2010.02.11. Magyar Drupal Kézikönyv meglátogatja az admin/node útvonalat, akkor meghívódik a 'node_admin' függvény.*/ $items[] = array('path' => 'admin/node/overview', 'title' => t('list'), 'type' => MENU_DEFAULT_LOCAL_TASK, 'weight' => -10); $items[] = array('path' => 'admin/node/configure', 'title' => t('configure'), 'callback' => 'node_configure', 'access' => user_access('administer nodes'), 'type' => MENU_LOCAL_TASK); /* Az elõbb meghatározott admin/node alá így definiáltunk két helyi feladatot, a t('list'), magyarul Lista nevû elem az alapértelmezett. Nagyon fontos észrevenni, hogy a Adminisztráció menü Tartalom alpontjában a Lista fül NEM az admin/node/overview oldalra visz, hanem a szülõ admin/node oldalra. Az alapértelmezettnél még érdemes észrevenni, hogy a súlya -10, így mindig legelöl lesz. */ $items[] = array('path' => 'admin/node/configure/settings', 'title' => t('settings'), 'type' => MENU_DEFAULT_LOCAL_TASK, 'weight' => -10); $items[] = array('path' => 'admin/node/configure/defaults', 'title' => t('default workflow'), 'callback' => 'node_default_settings', 'access' => user_access('administer nodes'), 'type' => MENU_LOCAL_TASK); /* Itt csak az az érdekes, hogy az elõzõekben az admin/node/configure útvonalat helyi feladatként definiáltuk, és most ez alá további helyi feladatok kerültek. Nézzük meg az admin/node/configure útvonalat, hogy lássuk, miként jelenik ez meg. */ $items[] = array('path' => 'node', 'title' => t('content'), 'callback' => 'node_page', 'access' => user_access('access content'), 'type' => MENU_SUGGESTED_ITEM); } else { // most következnek olyan elemek, amiket nem lehet gyorsítótárazni if (arg(0) == 'node' && is_numeric(arg(1))) { // ha node/12345 az útvonal kezdete $node = node_load(array('nid' => arg(1))); if ($node->nid) { // ha létezik az adott node $items[] = array('path' => 'node/'. arg(1), 'title' => t('view'), 'callback' => 'node_page', 'access' => node_access('view', $node), 'type' => MENU_CALLBACK); /* Ez egy node/12345 nevû menüpontot regisztrál, ami nem jelenik meg a menüben, mert MENU_CALLBACK típusú. Láthatjuk, hogy nem csak a user_access használható az access értékének meghatározásához. Elsõre nem látszik, mi szükség erre, hiszen a node útvonalat már regisztráltuk, és ha node_page függvény fogadna egy paramétert, aminek lenne alapértelmezése, akkor nagyon hasonló eredményhez jutnánk. Persze az elérés különbözik, de az igazi ok a következõ két menüelemben van. */ $items[] = array('path' => 'node/'. arg(1) .'/view', 'title' => t('view'), 'type' => MENU_DEFAULT_LOCAL_TASK, 'weight' => -10); $items[] = array('path' => 'node/'. arg(1) .'/edit', 'title' => t('edit'), 'callback' => 'node_page', 'access' => node_access('update', $node), 'weight' => 1, 'type' => MENU_LOCAL_TASK); /* Ugyanis csak így tudja regisztrálni a node_module a megtekintés és a szerkesztés helyi feladatokat. */ } } drupal.hu/kezikonyv/nyomtatobarat

71/135

2010.02.11. } return $items; } ?>


Lássunk egy egyszerûbb példát. Tegyük fel, hogy a proba.module tartalma a következõ: 'proba/egy', 'title' => 'egy', 'callback' => 'proba_page', 'access' => TRUE, 'type' => MENU_DEFAULT_LOCAL_TASK ); $items[] = array( 'path' => 'proba/ketto', 'title' => 'ketto', 'callback' => 'proba_page', 'access' => TRUE, 'type' => MENU_LOCAL_TASK ); } return $items; } function proba_page() { return 'Próba'; } ?>

Hívjuk be a proba/egy útvonalat, és nézzük meg, hova vezet az "egy" feliratú fül – a fõoldalra. Emlékezzünk vissza a fent leírtakra. Az f/g-nek a gyökér volt a szülõje, ha f nem definiált. Márpedig az alapértelmezett helyi feladat a szülõ útvonalára vezet.

A hook_form_alter() a gyakorlatban A Drupal.hu frissítésével merült fel az igény arra, hogy bizonyos a fejlesztõi csapat által kevésbé lényegesnek ítélt node szerkesztõ mezõknek mégis nagyobb jelentõséget tulajdonsítsunk a felület megjelenítésekor, így a Drupal 4.7.0-val érkezett új tömbökre épülõ ûrlap építõ rendszer egyik elõnyös tulajdonságát, a hook_form_alter() ûrlap módosító hurok képességeit kellett igénybe vennem. Ráadásul ezt Õry Máté fordítói levlistára beküldött magyar dátumokat támogató megoldásával fûszereztem, így egy kis ismertetõ alapja éppen összeállt. A Drupal 4.7.0-ás kiadásának legnagyobb fejlesztõi változása a teljesen átalakított ûrlap összeállításért és ellenõrzésért felelõs rendszer, mely a korábbi Drupal verziókkal összehasonlítva valamelyest bonyolutabb, de ugyanakkor sokkal rugalmasabb programozást tesz lehetõvé. Megtehetjük például, hogy meglévõ ûrlapokba új elemeket veszünk fel, beviteli mezõk csoportjait sorrendezünk át, és hasonlók. Lássuk, hogy ezen írás születésekor mit teszünk a drupalhu.module kódjában:
72/135

2010.02.11. Magyar Drupal Kézikönyv function drupalhu_form_alter($form_id, &$form) { // Node form átírása if (preg_match("!_node_form$!", $form_id)) { // Node típusok a path és options megnyitásához $openpath = in_array($form['type']['#value'], array('story', 'book', 'page')); $openoptions = $openpath || $form['type']['#value'] == 'weblink';

// Opciók megnyitása if (isset($form['options']) && $openoptions) { $form['options']['#collapsed'] = FALSE; } // Álnév kötelezõ vagy nem látszik if (isset($form['path'])) { if ($openpath) { $form['path']['#collapsed'] = FALSE; $form['path']['#weight'] = -2; $form['path']['path']['#title'] = 'Az útvonal álneve'; $form['path']['path']['#required'] = TRUE; } else { unset($form['path']); } } } // Magyar dátum megjelenítéshez a beállítás // ûrlap átírása Õry Máté kódja alapján if ($form_id == 'system_settings_form') { $hu_formats = array( 'short' => 'Y. m. d. H.i', 'medium' => 'Y. F j. H.i', 'long' => 'Y. F j., l H.i' ); foreach ($hu_formats as $n => $f) { $form['dates']['date_format_' . $n]['#options'][$f] = format_date(time(), 'custom', $f) . ' (magyar)'; $form['dates']['date_format_' . $n]['#default_value'] = variable_get('date_format_' . $n, $f); } } } ?>

Mikor fut le a drupalhu_form_alter()? Mindig lefut egyszer, amikor egy ûrlap összeállítása során módosíthatjuk annak tartalmát, szerkezetét. Számunkra azonban nem mindegy, hogy más módosító függvényekhez képest mikor hívódik meg saját függvényünk. Mint a függvény elõtti megjegyzés is mutatja, fontos, hogy meggyõzõdjünk róla, hogy a drupalhu_form_alter() függvényünk eléggé késõn hívódik meg. A node szerkesztõ ûrlap 'path' eleme ugyanis szintén egy form_alter megvalósításon keresztül kerül az ûrlapra, és ha alfabetikus sorrendben futnának le a modulok, akkor itt még nem látnánk azt az elemet, így nem is tudnánk befolyásolni. A meghívási sorrendet az adatbázis system táblájának weight értékével szabályozhatjuk. A nagyobb súlyú modulok hurkai késõbb hívódnak meg, mint a kisebb súlyúaké.

A módosítandó ûrlap kiválasztása Két ûrlapot fogunk módosítani a rendszerben, ezeket a $form_id alapjánt tudjuk azonosítani. A második eset egyszerûbb, hiszen a system_settings_form egyértelmûen azonosítja a rendszer beállítások ûrlapját. Az elsõ esetben azonban egy story_node_form típusú ûrlap azonosítót fogunk kapni, tehát a drupal.hu/kezikonyv/nyomtatobarat

73/135

2010.02.11.


node típus is szerepel az azonosítóban. Ezért én egy mintaillesztõ kifejezést választottam a megfelelõ végzõdés megállapítására. A path_form_alter() egy másik megoldást is mutat ugyanerre a kérdésre.

Node szerkesztõ felület testreszabása Tekintsük az elsõ ûrlap módosítást, ahol tehát a node szerkesztõ ûrlap tulajdonságait változtatjuk meg. Az, hogy adott esetben milyen tömb struktúrán tudunk módosításokat végezni részben a node_form_array(), részben pedig a path_form_alter() függvénybõl tudjuk kideríteni. Elõször is ha a szerkesztõség által jóváhagyandó tartalommal van dolgunk, és már jelen van az adminisztrátorok számára ûrlapba tett 'options' mezõcsoport, amelyben a közzétételre, kiemelésre és más általános lehetõségekre vonatkozó beállítások találhatóak, akkor ezt kinyitjuk. Másodszor pedig a webcím álnév beállító csoportját emeljük ki az ûrlap elejére, a taxonómia beállítás utánra azoknál a tartalmaknál, melyekhez álnév szokott tartozni. Ráadásul az elemcsoportban kötelezõvé tesszük az álnév megadására szolgáló elem kitöltését. Ezzel nem kerülhet álnév nélküli szerkesztett tartalom a rendszerbe. Azért kell címet adnunk az elemnek, mert ezt használja fel a Drupal a hibaüzenet kiírásakor, és emellett jelenhet meg a piros csillag, ami a kötelezõ kitöltést jelzi. Végül amely típusoknál nem használunk álneveket (weblink és forum a drupal.hu esetében), ott ennek a beállítási lehetõségét el is tüntetjük.

Magyar weblapra magyar dátumokat Õry Máté küldte be nemrég a fordítói levelezõlistára megoldását, mely szintén a form_alter hurkot használja arra, hogy lehetõvé tegye helyes magyar dátum formátumok kiválasztását a rendszer beállításainál. Ennek egy jelentõsen rövidített, ám funkcionalitásában többet adó megoldását adtam hozzá a drupalhu.module kódjához. Tehát ha a system_settings_form ûrlappal van dolgunk, akkor ennek dátumokra vonatkozó lehetõségeit szeretnénk kibõvíteni a magyar formátum választhatóságával. A módosítható elemek a system_view_general() függvényben azonosíthatóak. A megoldás elérése érdekében felvesszük a három lehetséges dátum részletezettségnek (short, medium, long) megfelelõ magyar formátumokat egy tömbbe. A system_view_general kódjából tudjuk, hogy $form['dates']['date_format_short'] és hasonló nevû ûrlap mezõk teszik lehetõvé a dátum kiválasztását. Ezek választási lehetõségeihez felvesszük a magyar formátumokat, sõt oda is írjuk a minták végére, hogy ezek a helyes magyar dátum formátumok, ugyanis sokan nem tudják például, hogy a magyar idõ kijelzésben az óra és perc számait pont választja el egymástól. Végül pedig beállítjuk ezeket a formátumokat alapértelmezésnek, tehát ha még nem állítottak be semmit, akkor a rendszer ezt ajánlja fel. Fontos megjegyezni, hogy ettõl a változtatástól függetlenül a dátumok alapértelmezése nem a magyar formátum lesz a rendszerben, hiszen a máshol használt variable_get() hívásoknak más alapértelmezése van. Ezért vagy az adminisztrációs felületen kell beállítanunk a most már rendelkezésre álló magyar dátum formátumot, vagy az adatbázisban kell átszerkesztenünk. A fenti kódnak köszönhetõen a felületen egyszerûbb dolgunk lesz.

Zárszó A fenti két példa remélhetõleg megmutatta, hogy a Drupal 4.7-es sorozat új ûrlap összeállítási rendszere megkönnyíti az életünket, hiszen saját fejlesztéseinket az alap modulok módosítása helyett elkülönített függvényekbe helyezhetjük, megkönnyítve a késõbbi hibakeresést és frissítést is.


74/135

2010.02.11.


Amikor változtatni kell a Drupal kódján (1) Májusban egy Drupal without modifications címû szál kapott erõre a Drupal fejlesztõi levelezõlistán, mely arról is szólt, hogy szükséges-e módosításokat végrehajtanunk a Drupal alap kódján ahhoz, hogy a kívánt webhelyet megkapjuk. Ez természetesen azzal a komoly igazsággal zárult, hogy "attól függ". A Drupal.hu kialakításakor például szigorú vezérelv volt, hogy alap telepítést használjunk, csak modulokkal kiegészítve a rendszert. Így ahelyett, hogy varázslatokat mûvelnénk, a maga valóságában tudjuk bemutatni a Drupal rendszert. A módosítások elkerülése sok esetben mûködik, de nem minden esetben tartható. A jelenleg Drupal 4.6 alapú Weblabor.hu esetében például nem tudtunk megoldani néhány dolgot anélkül, hogy a Drupal alapmotor forráskódon változtattunk volna. Minden esetben igyekeztünk átgondolni, hogy szükségünk van-e egy-egy változtatásra, és idõrõl-idõre visszatérünk ezekre a kérdésekre. Éppen egy ilyen nemrég megvalósult "visszatérés" ihlette ezt a kis tippet. Dokumentáljuk a változásokat Ha mégis módosítanunk kell valamit, minden esetben érdemes a változtatásokat a kódban dokumentálni. Mi erre a célra a +WL: megjegyzés elõtagot választottuk, mely jól kereshetõ a kódban. A több soros változtatásoknál hosszabban írjuk le, hogy miért nyúltunk a kódba, de mindig egy sorba tesszük a megjegyzést, mert így késõbb programozottan is egyszerûen kigyûjthetõ. Egy valós példa a Weblabor kódból:

A kód közvetlen módosítása A kód módosításának egyik útja, hogy közvetlenül a meglévõ forrást szerkesztjük. Ezt fõleg kisebb változtatások esetén alkalmazzuk, amikor csak 1-5 sort kell módosítani, vagy hozzáadni. Néhány érdekes változtatás, amit meg kellett tennünk: A contact.module kódjában a szerkesztõség CC-zésének lehetõsége. Pár sor változtatást igényelt. Változtatható karakter kódolás az RSS csatornához. A node modul módosítását igényelte. Hozzászólás ûrlap megjelenítése csak azokon az oldalakon, ahol még nincs hozzászólás (különben a szálazás érdekében a válasz linkekre irányítjuk a figyelmet). Néhány karakteres módosítást kellett tennünk. Érdekes, hogy ezek és még számos változtatásunk sokszor az ûrlapokat érintik, amik a Drupal 4.7-estõl kezdve bevezetett sokkal rugalmasabb tömb alapú megoldással már sokkal kevésbé igénylik majd a kód módosítását. Számos kifejezetten Weblabor specifikus függvényt kiszerveztünk egy wllib.inc nevû fájlba, melyet a sites/default/settings.php fájlból töltünk be, így elkerülve, hogy emiatt módosítani kelljen a Drupal kódját. Így a módosításainkat kis méretûen tudjuk tartani, legalábbis, amikor további kódot kell hívni. Meglévõ viselkedés helyettesítése A fenti rövid kódpélda esetében is érdemes elgondolkodni, hogy egyáltalán bárhol is szükségünk van-e az drupal.hu/kezikonyv/nyomtatobarat

75/135

2010.02.11. xml_icon


megjelenítésére. Ha nincs, akkor természetesen a theme_xml_icon()-nak megfelelõ saját smink függvényünket kell elkészíteni, üres visszatérési értékkel. Ez a Weblabor környezetében az azigazi_xml_icon() nevû függvény lenne. Esetünkben viszont úgy gondoltuk, hogy nem akarjuk teljesen eltávolítani ezt a rendszerbõl (bár valószínû ez a döntés is megérett a felülvizsgálatra).

Vannak azonban olyan helyzetek, amiket nem lehet egyszerû kód módosítással kezelni, és a smink függvényekhez hasonló felülíró mechanizmust sem kapunk, hanem jobban járunk, ha egy függvényt máshol definiálunk. Így alakult, hogy a drupal_get_path_map(), drupal_get_path_alias(), drupal_get_normal_path(), és a drupal_rebuild_path_map() függvényeket a kódban egyszerûen megjegyzésbe tettük, a +WL: magyarázattal ellátva, és a wllib.inc-ben valósítjuk meg a mûködésüket. Sajnos eléggé összetett álnév számítási rendszert fejlesztettünk ki, ragaszkodva a lehetõleg magyar webcímek használatához. Ez nagyon komoly teljesítmény problémákat okozott a 4.6-os álnév rendszerbe épüléssel, ezért a tesztjeink arra mutattak, hogy jobban tesszük, ha saját céljainkra optimalizált megvalósítást teszünk a kódba. Ráadásul emiatt több kisebb változtatást is el kellett végeznünk más modulokban is. A változtatásokat kezelni kell Az embernek könnyen "eljár a keze", akár meggondolatlanul is képes változtatásokat vinni a rendszerbe, ha szükségét látja. Sajnos ez gondot okozhat a késõbbi frissítéskor, amin a speciális megjegyzések sem segítenek, ha egyszerûen csak felülmásoljuk a kódot. A következõ részben azt szeretném leírni, hogy a fenti változtatások megtartása mellett hogyan tudjuk mégis folyamatosan frissíteni a Weblabor mögött mûködõ Drupal rendszert.

Amikor változtatni kell a Drupal kódján (2) Érdekes módon éppen a változtatásokról szóló tipp-kettõs elõzõ részének megjelenése napján vált elérhetõvé a Lullabot Podcast tizenhatodik része, melyben Jeff Robins készít interjút Dries Buytaert-tel, a Drupal alapítójával. Ebben hangzik el a következõ párbeszéd: Jeff Robins: Don't hack Drupal, if you are hacking the code, you are doing something wrong. Dries Buytaert: Either you are doing something wrong, or core needs to be extended. Jeff Robins: [...] but then some security update comes out, or a new version of Drupal comes out, you can't upgrade, because your hacks will break everything. Most arra a kérdésre próbálom megadni a választ, hogy mit tehetünk, ha mindenképpen saját módosításokat kell alkalmaznunk, de ezeket a frissítésekkel is meg szeretnénk tartani. A megoldás természetesen nem olyan egyszerû, mint egy klasszikus Drupal frissítés, de aki módosít a kódon, annak ezt vállalnia kell.

Melyik Drupal verziót használjuk? Ha a legújabb hibajavításokkal szeretnénk élni, akkor könnyen lehet, hogy elvesztjük a biztos tudatunkat arról, hogy mégis melyik Drupal verziót használjuk. A Weblabor esetében például jelenleg úgy foghatjuk meg a használt verziót, hogy a Drupal 4.6-os ágon valamilyen dátummal bezárólag aktuálisak a fájljaink. A szükség esetén megjelenõ 4.6.x-es kiadások követése mellett a folyamatos hibajavításokat is érdemesnek tartjuk alkalmazni, így valószínû, hogy amit használunk, annak nincs is hivatalos verziószáma. Még ha lenne is, akkor sem lehet megállapítani a fájlok alapján, hogy pontosan melyik verzióval állunk szemben (hacsak nem vezetjük következetesen egy jegyzetben, hogy melyik verzióra frissítettünk legutóbb). drupal.hu/kezikonyv/nyomtatobarat

76/135

2010.02.11.


Így kell egy eszköz, ami megmondja, hogy milyen dátumból kell kiindulni. Végig kell nézni minden fájlt, amiben a fejlesztõi (CVS) verziónak megfelelõ információ található, beleértve a Drupal rendszerbeli legutóbbi módosítás dátumát is. Ezt magunk is megtehetjük, de az alábbi saját fejlesztésû szkript automatizálja a feladatot: strtotime($latest)) { $latest = $date[0]; } } } else { $cvsids[$filename] = 'n/a'; } } print "LATEST;$latest\n"; foreach($cvsids as $name => $id) { print substr($name, 2) . ";$id\n"; } // Recursively go over possible Drupal files function find_drupal_files($root = '.') { $folders = glob($root . '/*', GLOB_ONLYDIR); $files = glob($root . '/*.{php,inc,txt,module,theme,engine,mysql,pgsql,install}', GLOB_BRACE); if (file_exists($root . '/.htaccess')) { $files[] = $root . '/.htaccess'; } foreach($folders as $folder) { if (!in_array($folder, array('.', '..'))) { $files = array_merge($files, find_drupal_files($folder)); } } return $files; } ?>

Ezt a Drupal gyökerébe téve, és onnan lefuttatva megkapjuk CSV formában a fájlok verzió azonosítóit, és legutóbbi fejlesztõi módosítási dátumait. A szkript megkísérli a legutóbbi dátumot kiválasztani. Ebben azonban nem szabad vakon bízni. Ha kiegészítõ modulokat is telepítettünk, érdemes azoktól eltekinteni a legutóbbi dátum megállapításakor. Hiszen valószínû az alaprendszert és a kiegészítõket külön frissítjük, illetve lehet, hogy egy kiegészítõ jóval késõbbi dátummal rendelkezik, mint amikor az alaprendszert legutóbb frissítettük. Ez indokolja a CSV formátumot, amit így tudunk importálni kedvenc táblázatkezelõnkbe, és szûrhetjük az elemeket, sorrendezhetünk, és könnyedén kiválaszthatjuk a legutóbbi frissítés dátumát. Így kiderítettük, hogy mikori a Drupal rendszerünk. drupal.hu/kezikonyv/nyomtatobarat

77/135

2010.02.11.


Változáskövetés Követnünk kell a változtatásainkat. Erre a legkézenfekvõbb eszköz egy saját célra telepített Subversion, CVS vagy más változáskezelõ rendszer. Ha eléggé szerencsések vagyunk, hogy egy ilyet az eszköztárunkban tudhatunk, akkor már félig megoldottuk a problémát. Ezzel persze csak a saját módosításainkat követhetjük, illetve a frissítések fájlokra tett hatását ellenõrizhetjük. Feltételezem viszont, hogy olvasóimnak nincs verziókezelõ rendszer a tarsolyában, és szerencsére a változáskövetés esetünkben enélkül is megvalósítható. A Drupal.org CVS szervere ugyanis segítségünkre van mindenben. A megállapított dátumnak megfelelõ kódot kell elõször is letöltenünk a szerverrõl. Attól függõen, hogy milyen CVS klienst használunk, ez más-más módon történik. Én parancssori klienst alkalmaztam. Tegyük fel, hogy a megállapított dátumunk 2005. december 13. és a Drupal 4.6-os kódra van szükségünk. Az alábbi parancs segítségével kaphatjuk meg. $ cvs -z6 -d:pserver:anonymous:[email protected]:/cvs/drupal co -r DRUPAL-4-6 -D "2005-12-13" drupal

Ezzel kaptunk egy tiszta módosítatlan Drupal forráskódot. Most nincs más dolgunk, mint megállapítani a saját Drupal kódunk, és a tiszta Drupal kód eltéréseit, hogy a változtatásainkat egyértelmûen azonosíthassuk. Erre a célra én a Meld nevû programot használtam, de nagyon hasonlóan használható a WinMerge is Windows rendszert alkalmazóknak. Most hogy tételesen látjuk a változtatásainkat, érdemes egy pillanatra végiggondolni mindegyiknek a létjogosultságát, és amennyiben megtartásuk mellett döntünk, dokumentáljuk mindegyiket az elõzõ részben bemutatott konvenciók szerint. Ez még nagyon meghálálja magát a késõbbi kódfrissítéseknél.

Frissítsünk A változtatásaink azonosítása számos elõnnyel jár, de leginkább azért van rá szükség, hogy megkezdhessük a kódfrissítést. Készítsünk egy másolatot az elõbbi tiszta Drupal verzióról az összes extra CVS könyvtárral együtt. Ennek a másolatnak a fájljait írjuk felül a saját módosított fájljainkkal. Ezek után futtassuk le a CVS frissítõ parancsát továbbra is a 4.6-os ágon maradva, de kérve a legaktuálisabb fájlokat: $ cvs update -r DRUPAL-4-6

A megjelenõ üzenetek között a C jelû fájlokra kell különösen figyelmet fordítanunk, mert ezekben a saját módosításainkat és a Drupal forráskód módosításait a CVS nem tudta összefésülni, és mindkét verziót berakta a fájlba speciális jelzésekkel. Nyissuk meg ezeket a fájlokat bármilyen szerkesztõ programban és eseti jelleggel magunk döntsük el, hogy mi lesz a helyes új kód. Ha minden ilyen konfliktust megoldottuk, futtassunk le még egy ilyen update parancsot, és figyeljük meg, hogy csak M jelû fájlunk maradt-e. Ezek az általunk módosított fájlok, amik a frissítéssel összefésülve megtartották a változtatásainkat.

Még nem vagyunk készen Mivel a kódfrissítés és összefésülés elkészült, egyszerûen felülírhatnánk a webhelyünk forráskódját az új kóddal. Én azonban azt javaslom, hogy ne siessük el, hanem vegyük elõ a fent használt különbség vizsgáló programunkat, és ezúttal a frissült kód és a webhelyünk forráskódja között tekintsük át a változtatásokat. Így látni fogjuk, hogy milyen módosítások kerültek a Drupal rendszerbe. Ezek egyrészt adott esetben sminkünk vagy kiegészítõ modulunk mûködésének javítását is szükségessé tehetik. Másrészt pedig ha valami elromlik a friss kód gyakorlatba ültetése után, akkor több tippünk lesz, hogy mégis mi mehetett drupal.hu/kezikonyv/nyomtatobarat

78/135

2010.02.11.


tönkre, mi változott egyáltalán.

Biztonsági mentés Végül pedig, mielõtt az új kódot hadrendbe állítanánk, ne felejtsünk el biztonsági mentést készíteni a webhelyünk forráskódjáról és az adatbázisról. Ha valamit elszúrtunk volna, akkor arra még mindig visszatérhetünk.

Calendar modul, listázás az esemény időpontja alapján Sokan használják a Date és a Calendar modulokat, hogy Views segítségével listázhassák a beküldött naptárbejegyzéseket. A Calendar modul bekapcsolása után a Views listában megjelenik a „calendar” nézet. Engedélyezés után alapértelmezetten a „weboldalneve.hu/calendar” útvonalon érhető el. Meglepő módon mintegy archívum működik, és a tartalmak létrehozásának/utolsó módosításának dátuma szerint rendezi, jeleníti meg azokat. Ha jobban belegondolunk ez jogos is, hiszen a modul nem tudhatja, hogy mi milyen nevet fogunk adni a Date típusú mezőnknek.

Az eseménynaptár kialakításának a helyes módja Akkor nézzük az elejétől. 1. 2. 3. 4. 5.

6. 7.

8.

Hozzunk létre egy új mezőt a kívánt tartalom típusunkban, mondjuk „Date” névvel. Vigyünk fel pár új tartalmat (node-ot), kitöltött dátummal mezővel. Kapcsoljuk be a Calendar modult. Engedélyezzük a Views-ban a „calendar” nézetet, készítsünk egy másolatot róla és azt nyissuk meg. Mindenhol a „Default” nézetet kell szerkeszteni! A „Default” nézet „Mezők” részében adjuk hozzá (+) a „Tartalom: Dátum - (field_date)” mezőt. Megjegyzés: amennyiben a tartalom típus date mezőjénél engedélyeztük a „To Date” funkciót (befejezés dátumát), akkor a Views listájában ezek a mezők külön-külön jelennek meg: „Dátum (field_date) - From date” és „Tartalom: Dátum (field_date) - To date”. Normál esetben az elsőt kell választani. Az „Arguments” részben kattintsunk a „Dátum: Date (node) Tartalom: Updated date” linkre, és szerkesztés módban válasszuk a „Törlés” gombot. A „Default” nézet „Arguments” részében adjuk hozzá újként (+) a „Dátum: Date (node)” mezőt. Beállítások: „Action to take if argument is not present: Provide default argument” „Default argument type: Current date” A „Date field(s):” részben válasszuk ki a „Tartalom: Dátum - (field_date)” sort, és kattintsunk a „Frissítés” gombra. A „Default” nézet „Mentése”.

Most már (elvileg) ha a „weboldalneve.hu/calendar” nézetben nem a node utolsó módosításának ideje alapján, hanem a „Date” mezőben megadott dátum alapján rendezi sorba a tartalmakat. drupal.hu/kezikonyv/nyomtatobarat

79/135

2010.02.11.


Amúgy kicsit bugos pont ez a rész, fontos a sorrend betartása. Erről a hibáról bővebben az alábbi linken olvashatunk: http://drupal.org/node/350279#comment-1223870 Ha „The calendar_nav style requires a Date argument.” hibaüzenetet kapunk, akkor rossz sorrendben csináltuk... ;) Kezdjük újból! Én szépen bele is futottam, amikor próbálgattam a nézetet átalakítani, hogy elkészülhessen ez a leírás. A Tippek és trükkök számára a cikk alapjául a Calendar modul fórum téma szolgált. Palócz „Paal” Pál

Views export Segítségként kiexportáltam a nézetet. Csak abban az esetben működik, ha a CCK/Date mezőt - a fenti leírásnak megfelelően - Date-nek nevezzük el. $view = new view; $view->name = 'calendar'; $view->description = 'A multi-dimensional calendar view with back/next navigation.'; $view->tag = 'Calendar'; $view->view_php = ''; $view->base_table = 'node'; $view->is_cacheable = FALSE; $view->api_version = 2; $view->disabled = FALSE; /* Edit this to true to make a default view disabled initially */ $handler = $view->new_display('default', 'Defaults', 'default'); $handler->override_option('fields', array( 'title' => array( 'label' => '', 'link_to_node' => 1, 'exclude' => 0, 'id' => 'title', 'field' => 'title', 'table' => 'node', 'relationship' => 'none', ), 'field_date_value' => array( 'label' => 'Date', 'alter' => array( 'alter_text' => 0, 'text' => '', 'make_link' => 0, 'path' => '', 'link_class' => '', 'alt' => '', 'prefix' => '', 'suffix' => '', 'help' => '', 'trim' => 0, 'max_length' => '', 'word_boundary' => 1, 'ellipsis' => 1, 'strip_tags' => 0, 'html' => 0, ), 'link_to_node' => 0, drupal.hu/kezikonyv/nyomtatobarat

80/135

2010.02.11. Magyar Drupal Kézikönyv 'label_type' => 'widget', 'format' => 'default', 'multiple' => array( 'multiple_number' => '', 'multiple_from' => '', 'multiple_to' => '', 'group' => TRUE, ), 'repeat' => array( 'show_repeat_rule' => '', ), 'fromto' => array( 'fromto' => 'both', ), 'exclude' => 0, 'id' => 'field_date_value', 'table' => 'node_data_field_date', 'field' => 'field_date_value', 'relationship' => 'none', ), )); $handler->override_option('arguments', array( 'date_argument' => array( 'default_action' => 'default', 'style_plugin' => 'default_summary', 'style_options' => array(), 'wildcard' => 'all', 'wildcard_substitution' => 'Minden', 'title' => '', 'breadcrumb' => '', 'default_argument_type' => 'date', 'default_argument' => '', 'validate_type' => 'none', 'validate_fail' => 'not found', 'date_fields' => array( 'node_data_field_date.field_date_value' => 'node_data_field_date.field_date_value', ), 'year_range' => '-3:+3', 'date_method' => 'OR', 'granularity' => 'month', 'id' => 'date_argument', 'table' => 'node', 'field' => 'date_argument', 'validate_user_argument_type' => 'uid', 'validate_user_roles' => array( '2' => 0, ), 'relationship' => 'none', 'default_options_div_prefix' => '', 'default_argument_user' => 0, 'default_argument_fixed' => '', 'default_argument_php' => '', 'validate_argument_node_type' => array( 'merci_reservation' => 0, 'merci_reservation_template' => 0, 'book' => 0, 'page' => 0, 'picture' => 0, 'story' => 0, ), 'validate_argument_node_access' => 0, 'validate_argument_nid_type' => 'nid', drupal.hu/kezikonyv/nyomtatobarat

81/135

2010.02.11. Magyar Drupal Kézikönyv 'validate_argument_vocabulary' => array(), 'validate_argument_type' => 'tid', 'validate_argument_transform' => 0, 'validate_user_restrict_roles' => 0, 'validate_argument_php' => '', ), )); $handler->override_option('filters', array( 'status' => array( 'operator' => '=', 'value' => 1, 'group' => '0', 'exposed' => FALSE, 'expose' => array( 'operator' => FALSE, 'label' => '', ), 'id' => 'status', 'table' => 'node', 'field' => 'status', 'relationship' => 'none', ), )); $handler->override_option('access', array( 'type' => 'none', 'role' => array(), 'perm' => '', )); $handler->override_option('cache', array( 'type' => 'none', )); $handler->override_option('title', 'Calendar'); $handler->override_option('header_empty', 1); $handler->override_option('items_per_page', 0); $handler->override_option('use_more', 0); $handler->override_option('style_plugin', 'calendar_nav'); $handler = $view->new_display('calendar', 'Calendar page', 'calendar_1'); $handler->override_option('path', 'calendar'); $handler->override_option('menu', array( 'type' => 'none', 'title' => '', 'description' => '', 'weight' => 0, 'name' => 'navigation', )); $handler->override_option('tab_options', array( 'type' => 'none', 'title' => '', 'description' => '', 'weight' => 0, )); $handler->override_option('calendar_colors', array( '0' => array(), )); $handler->override_option('calendar_colors_vocabulary', array()); $handler->override_option('calendar_colors_taxonomy', array()); $handler->override_option('calendar_popup', 0); $handler->override_option('calendar_date_link', ''); $handler = $view->new_display('calendar_block', 'Calendar block', 'calendar_block_1'); $handler->override_option('block_description', 'Calendar'); $handler->override_option('block_caching', -1); $handler = $view->new_display('calendar_period', 'Year view', drupal.hu/kezikonyv/nyomtatobarat

82/135

2010.02.11. Magyar Drupal Kézikönyv 'calendar_period_1'); $handler->override_option('style_plugin', 'calendar_style'); $handler->override_option('style_options', array( 'display_type' => 'year', 'name_size' => 1, 'max_items' => 0, )); $handler->override_option('attachment_position', 'after'); $handler->override_option('inherit_arguments', TRUE); $handler->override_option('inherit_exposed_filters', TRUE); $handler->override_option('displays', array( 'calendar_1' => 'calendar_1', 'default' => 0, 'calendar_block_1' => 0, )); $handler->override_option('calendar_type', 'year'); $handler = $view->new_display('calendar_period', 'Month view', 'calendar_period_2'); $handler->override_option('style_plugin', 'calendar_style'); $handler->override_option('style_options', array( 'display_type' => 'month', 'name_size' => '99', 'with_weekno' => '1', 'date_fields' => NULL, 'max_items' => 0, )); $handler->override_option('attachment_position', 'after'); $handler->override_option('inherit_arguments', TRUE); $handler->override_option('inherit_exposed_filters', TRUE); $handler->override_option('displays', array( 'calendar_1' => 'calendar_1', 'default' => 0, 'calendar_block_1' => 0, )); $handler->override_option('calendar_type', 'month'); $handler = $view->new_display('calendar_period', 'Day view', 'calendar_period_3'); $handler->override_option('style_plugin', 'calendar_style'); $handler->override_option('style_options', array( 'name_size' => '99', 'with_weekno' => 0, 'max_items' => 0, 'max_items_behavior' => 'more', 'groupby_times' => 'hour', 'groupby_times_custom' => '', 'groupby_field' => '', )); $handler->override_option('attachment_position', 'after'); $handler->override_option('inherit_arguments', TRUE); $handler->override_option('inherit_exposed_filters', TRUE); $handler->override_option('displays', array( 'calendar_1' => 'calendar_1', 'default' => 0, 'calendar_block_1' => 0, )); $handler->override_option('calendar_type', 'day'); $handler = $view->new_display('calendar_period', 'Week view', 'calendar_period_4'); $handler->override_option('style_plugin', 'calendar_style'); $handler->override_option('style_options', array( 'name_size' => '99', 'with_weekno' => 0, 'max_items' => 0, drupal.hu/kezikonyv/nyomtatobarat

83/135

2010.02.11. Magyar Drupal Kézikönyv 'max_items_behavior' => 'more', 'groupby_times' => 'hour', 'groupby_times_custom' => '', 'groupby_field' => '', )); $handler->override_option('attachment_position', 'after'); $handler->override_option('inherit_arguments', TRUE); $handler->override_option('inherit_exposed_filters', TRUE); $handler->override_option('displays', array( 'calendar_1' => 'calendar_1', 'default' => 0, 'calendar_block_1' => 0, )); $handler->override_option('calendar_type', 'week'); $handler = $view->new_display('calendar_period', 'Block view', 'calendar_period_5'); $handler->override_option('style_plugin', 'calendar_style'); $handler->override_option('style_options', array( 'display_type' => 'month', 'name_size' => '1', )); $handler->override_option('attachment_position', 'after'); $handler->override_option('inherit_arguments', TRUE); $handler->override_option('inherit_exposed_filters', TRUE); $handler->override_option('displays', array( 'calendar_1' => 0, 'default' => 0, 'calendar_block_1' => 'calendar_block_1', )); $handler->override_option('calendar_type', 'month'); $handler = $view->new_display('block', 'Upcoming', 'block_1'); $handler->override_option('fields', array( 'title' => array( 'label' => '', 'link_to_node' => 1, 'exclude' => 0, 'id' => 'title', 'field' => 'title', 'table' => 'node', 'relationship' => 'none', 'format' => 'default', ), 'changed' => array( 'label' => '', 'link_to_node' => 0, 'exclude' => 0, 'id' => 'changed', 'field' => 'changed', 'table' => 'node', 'relationship' => 'none', 'date_format' => 'small', 'format' => 'default', ), )); $handler->override_option('arguments', array()); $handler->override_option('filters', array( 'status' => array( 'operator' => '=', 'value' => 1, 'group' => '0', 'exposed' => FALSE, 'expose' => array( 'operator' => FALSE, drupal.hu/kezikonyv/nyomtatobarat

84/135

2010.02.11.


'label' => '', ), 'id' => 'status', 'table' => 'node', 'field' => 'status', 'relationship' => 'none', ), 'date_filter' => array( 'operator' => '>=', 'value' => array( 'value' => NULL, 'min' => NULL, 'max' => NULL, 'default_date' => 'now', 'default_to_date' => '', ), 'group' => '0', 'exposed' => FALSE, 'expose' => array( 'operator' => FALSE, 'label' => '', ), 'date_fields' => array( 'node.changed' => 'node.changed', ), 'granularity' => 'day', 'form_type' => 'date_select', 'default_date' => 'now', 'default_to_date' => '', 'id' => 'date_filter', 'table' => 'node', 'field' => 'date_filter', 'override' => array( 'button' => 'Use default', ), 'relationship' => 'none', ), )); $handler->override_option('title', 'Upcoming'); $handler->override_option('items_per_page', 5); $handler->override_option('use_more', 1); $handler->override_option('style_plugin', 'list'); $handler->override_option('style_options', array( 'grouping' => '', 'type' => 'ul', )); $handler->override_option('block_description', 'Upcoming'); $handler->override_option('block_caching', -1);

Egyedi "Karbantartás alatt" oldal készítése Ha Drupal honlapunkon karbantartási munkákat végzünk, az admin/settings/site-maintenance oldalon célszerû a webhelyet offline üzemmódba kapcsolni. Ekkor csak a webhely adminisztrátora fér hozzá a honlap tartalmához, a többi látogató az alábbi feliratot látja:


85/135

2010.02.11.


Az oldal szövegét szintén az admin/settings/site-maintenance oldalon tudjuk módosítani – például ha szeretnénk jelezni, hogy mikor indul újra a honlap, itt megtehetjük. Lehetõség van HTML kód bevitelére is:
A nyitás tervezett idõpontja:

2007. június 24. hétfõ, reggel 9 óra

Ha szeretnénk teljesen egyénivé tenni az oldalt, könnyedén lecserélhetjük a Drupal logót és a „Karbantartás miatt zárva” fõcímet is a theme_maintenance_page() függvény felülírásával. Az egyik lehetõség, hogy egyszerûen bemásoljuk a függvényt a template.php fájlba, átnevezzük phptemplate_maintenance_page()-re, és elvégezzük a kívánt módosításokat. Kicsit bonyolultabb, de végsõ soron kényelmesebb megoldás, ha külön sablont készítünk a karbantartási oldal számára. Ehhez hozzunk létre egy page-maintenance.tpl.php nevû fájlt a sminkmappában, és hívjuk meg a template.php segítségével: $content, 'messages' => $messages, 'partial' => $partial)); } ?>

Ezek után készítsük el a page-maintenance.tpl.php sablont. Belinkelhetjük a webhely favikonját és a karbantartási oldalhoz készített külön CSS fájlt is. Az admin/settings/site-maintenance oldalon megadott üzenetünket a $content változó segítségével tudjuk kiíratni. Webhely karbantartás | Honlap.hu <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <style type="text/css" media="all">@import "/maintenance.css"; drupal.hu/kezikonyv/nyomtatobarat

86/135

2010.02.11.


Sajnáljuk, honlapunk pillanatnyilag nem elérhetõ

A végeredmény:

Feladat alapú jogosultság kezelés a jogosultság hurokkal A Drupal 4.5.0-ás kiadásával kezdõdõen többféle jogosultság séma jelenléte lehetséges a rendszerben, melyek együttes hatásán múlik az, hogy egyes oldalakat illetve tartalmakat ki érhet el, ki szerkeszthet és ki törölhet. Ebben a leírásban a feladat alapú jogosultságkezeléshez történõ fejlesztéssel foglalkozunk.

Bevezetõ A Drupalban minden felhasználó valamilyen csoportba tartozik. Látogatóknak nevezzük azokat, akik nem regisztráltak a rendszeren, vagy nem léptek be. Ezek az érdeklõdõk az alapértelmezésben rendelkezésre álló anonymous user csoportba tartoznak automatikusan. Azon felhasználók, akik beléptek a rendszerbe, regisztrációjukkor az authenticated user csoportba kerültek besorolásra. Ezen a két alapcsoporton kívül természetesen lehetõség van bármennyi csoport létrehozására, az alaprendszerben pedig a felhasználók egyenkénti szerkesztésével tudjuk csoportba tartozásukat megadni. A Drupal moduljai különbözõ jogosultságokat definiálnak, melyeket megadhatunk az egyes csoportoknak. Az adminisztráció » felhasználók » beállítás » jogosultságok oldalon találjuk azt a mátrixot, melyben a különbözõ csoportoknak megadhatjuk az egyes jogokat. Egy felhasználó több csoportba is tartozhat, és ilyenkor a jogosultságai összeadódnak, tehát ha egy csoportban megadtunk neki valamilyen jogot, akkor azt megkapja akkor is, ha más csoportnak – melyeknek tagja – nincs ilyen joga. Az elsõként regisztrált felhasználónak mindenhez joga van, csoportba tartozásától függetlenül. A feladat alapú jogosultság rendszer azt teszi lehetõvé, hogy egyes feladatokhoz (például írások drupal.hu/kezikonyv/nyomtatobarat

87/135

2010.02.11.


létrehozása) jogot adjunk egy csoportnak. Ezzel a csoport tagjai a webhelyen létrehozhatnak írás típusú tartalmakat. A legfontosabb alapjogokat a node modul definiálja: tartalmak elérése és tartalmak adminisztrációja. Az elõbbi lehetõvé teszi, hogy a webhely tartalmait az adott csoportba tartozó felhasználók olvassák (ha más, például tartalom-szintû jogosultság ezt felül nem bírálja), az utóbbi pedig a tartalmak metaadatainak szerkesztését is lehetõvé teszi, azaz tartalmak közzétételére, eltüntetésére is jogot ad.

Támogatott jogosultságok ellenõrzése Saját modul fejlesztésekor könnyen elõfordulhat, hogy egy meglévõ jogosultság ellenõrzése tökéletesen megfelel számunkra. Ilyenkor a user_access() függvény és a kívánt jogosultság eredeti angol nevének ismerete elegendõ. A user_access() az aktuális felhasználó (vagy a második paraméterében megadott felhasználó) jogosultságait ellenõrzi. Ezt a függvényt nagyon sok helyen megtaláljuk a Drupalban, többek között a menük elõállításakor.

A jogosultság hurok Mégis honnan tudhatjuk meg, hogy mi a számunkra érdekes jogosultság neve, illetve, a Drupal miként tudja listázni a beállítható jogosultságokat az adminisztrációs felületen? A válasz igen egyszerû: a jogosultság hurokban megadhatjuk a modulunk által definiált jogosultságokat. Ez a hurok egyszerûen egy jogosultság név listával tér vissza. Ezeket ajánlja majd fel a Drupal az adminisztrációs felületen, és ezeket használhatjuk nyugodtan user_access() hívásokban is. Nem kell definiálnunk a jogosultság hurkot, ha megelégszünk a rendelkezésre álló jogosultság készlettel, és nincs szükségünk újabbra. Ilyenkor a meglévõ modulok jogosultság hurkaiból tudjuk kideríteni a definiált jogosultságok eredeti neveit – melyeket az adminisztrációs felület lefordítva jelenít meg a karbantartók életének megkönnyítése érdekében.

A jogosultságok elnevezésére bevett szokás az administer és access elõtagok használata az adminisztrációs illetve elérési jogok megadására, ám ezek nem korlátozó szabályok, csak az áttekinthetõség érdekében bevezetett irányelvek. Ha a fenti jogosultság hurkot definiáltuk, modulunkban nyugodtan használhatjuk a user_access("collect cherry seeds") jogosultság ellenõrzést, ha arra vagyunk kíváncsiak, hogy az adminisztrátor jogot adott-e az aktuális felhasználónak a meggymagok gyûjtésére.

Fordítások készítése egyszerûen A cikk elavult kérlek olvasd inkább a Magyar felület fordításáról szóló kézikönyv lapot vagy nézd meg a tanarurkerem.hu oldalán található videót. drupal.hu/kezikonyv/nyomtatobarat

88/135

2010.02.11.


Elõfordulhat, hogy letöltünk egy modult, amihez sehol nem találunk a számunkra szükséges nyelven fordítást. Ilyenkor tanácstalanok lehetünk, fel is adhatjuk a modul használatát, vagy az adott nyelv fordítói csapatánál verhetjük az asztalt, hogy márpedig le kellene azt a modult fordítani. Valószínûleg egyik út sem a kívánt eredményre fog vezetni, ezért jó tudni, hogy a magunk kezébe is vehetjük az ügyet. Nagyon ritka, hogy olyan modullal találkozunk, amit nem készítettek fel a fordíthatóságra. Az azonban már sokkal gyakoribb, hogy könnyen szerkeszthetõ .pot (Gettext Portable Object Template) sablon fájlt nem kapunk a modulhoz, vagy amit a csomagban letöltöttük, már nem aktuális. Ilyenkor lesz segítségünkre az extractor.php nevû szkript, . Ezt használják a Drupal fordítók is arra, hogy az alaprendszer és a kiegészítõ modulok, sminkek fordítási sablonjait elõállítsák. Mivel ez a szkript webbarát, nincs más dolgunk, mint a kívánt kiterjesztés vagy modul mappájába tenni, és a böngészõnkbõl a webszerveren keresztül lefuttatni. Ezzel az adott mappában keletkezik legalább egy .pot fájl, vagy ha nincs joga a szkriptnek új fájlokat létrehozni, akkor hibaüzenetet ad. A .pot fájlok már egyszerû UTF-8 kódolású szöveges fájlok, amik csak a fordítandó karaktersorozatokat tartalmazzák. Ezeket akár egy UTF-8-képes szöveges fájl szerkesztõvel is lefordíthatjuk, vagy bevethetünk egy a poEdit képességeivel rendelkezõ speciális programot. A kész fordítást az administer » locales » import (adminisztráció » nyelvek » import) fülön tölthetjük fel, pont úgy, mint ahogy az alaprendszer fordítását is importáltuk. Ne felejtsük el a kész fordítást az adott nyelv fordítói csapatával is megosztani! Érdemes a közösség által végzett munka kiaknázása után hozzájárulni a közösség gyarapodásához, ha már magunk számára úgyis elkészítettük a fordítást. A magyar fordítói csapat a levelezõlistáján keresztül érhetõ el.

Kapcsolat ûrlap és levél módosítása a Drupalban Korábban már írtam a hook_form_alter() elõnyeirõl és mûködésérõl. Ennek segítségével – némi programozással – elérhetjük, hogy a Drupal módosítása nélkül a rendszer ûrlapjai kedvünkre változzanak meg. De mi van akkor, ha az ûrlapok változtatása nem elegendõ? Az utóbbi hetekben a Weblabor.hu 4.6.x-es rendszerrõl 5.x-es Drupal rendszerre frissítésén is munkálkodom szabadidõmben, és éppen ma értem el a Weblabor szerkesztõit is megcímzõ kapcsolati ûrlap funkcióhoz. Lássuk mi az igényelt funkció, és milyen kényelmes megtenni a módosításainkat Drupal 5.1-gyel! A kérdéses szolgáltatás csak az adminisztrátorok számára érhetõ el a Weblaboron, és azt teszi lehetõvé, hogy amikor egy levelet küldünk (jellemzõen valamilyen moderációs lépésrõl) egy felhasználó kapcsolat ûrlapjáról az adott tagnak, akkor azt egyben cc-zzük is a Weblabor szerkesztõinek. Fontos, hogy egy cc fejléc elemet veszünk fel a levélbe, és a Drupal beépített 'másolatot kérek' funkciójával ellentétben nem új levelet küldünk. A cc fejléc használata ugyanis lehetõvé teszi, hogy a szerkesztõk is azonnal reagáljanak, hozzátegyék saját véleményünket a levélhez úgy, hogy azt a szerkesztõk és a felhasználónk is megkapja. Ráadásul szálkövetõ marad a levelezés. A fejlesztõi alapproblémám egy a korábbi Drupal 4.6-os rendszerkód módosításával megvalósított szolgáltatás átültetése ezúttal már oly módon, hogy ne kelljen Drupal kódot módosítanom. Szerencsére a két ehhez szükséges eszköz a Drupal 5.0-val megérkezett, tudok megjelenített ûrlapot és elküldött levelet is módosítani. A demonstráció kedvéért nevezzük a modulunkat wlcontact-nak, a domain pedig legyen example.com (így aki innen másolja a kódot, az nem rögtön nekünk címzi a leveleit). Elõször is az ûrlapot kell megváltoztatnom. Itt azonosítani kell, hogy a felhasználói kapcsolat ûrlapról van drupal.hu/kezikonyv/nyomtatobarat

89/135

2010.02.11.


szó, és adminisztrátorral van dolgunk. Ha ez teljesül, akkor felveszünk egy új 'toeditors' elemet az ûrlapba, ami jelölõnégyzet típusú. Magyarázatot is adunk, hiszen a mûködés eltérõ a beépített másolat funkciótól (és az összekeverés elkerülése érdekében arra a beépített elemre is adunk magyarázatot). Meg kell még oldanunk, hogy az új elemünk a submit gomb fölött jelenjen meg. Mivel ebben az ûrlapban nincsenek megadott súlyozások, a submit gombnak nagyobb súlyt adunk meg, mint a saját jelölõnégyzetünknek. Ezzel kész is az ûrlap külalakja. Még egy dologra kell figyelnünk, mégpedig, hogy értesüljünk az ûrlap elküldésérõl és feldolgozzuk a másolat kérést. Ennek érdekében az ûrlap elküldése után lefutó függvények elejére regisztrálunk egy saját eseménykezelõt, ami így befolyásolni tudja majd a további mûködést. Fontos, hogy az elejére regisztráljunk, hiszen az alapértelmezett eseménykezelõ küldi a levelet, és nekünk azelõtt kell közbelépnünk a folyamatba. 'Másolat az Example.com szerkesztõknek', '#type' => 'checkbox', '#description' => 'Másolat küldése a szerkesztõségi email címre is.', '#weight' => 9, ); $form['copy']['#description'] = 'Másolat küldése a személyes email címre.'; $form['submit']['#weight'] = 10; $form['#submit'] = array('wlcontact_mail_user_submit' => array()) + $form['#submit']; } } ?>

Felmerülhet a kérdés, hogy miként ismertem fel az ûrlap azonosítóját és elemeit. Ilyen részletek érdekében nem szeretem a forráskódot böngészni, ezért egyszerûen a var_dump($form_id) és var_dump($form) használatával derítettem fel a struktúrát, illetve, hogy mit hol kell módosítanom, milyen nevû kulcsok vannak a tömbben. Ez éppen elegendõ volt a céljaimra. Nos, lássuk mit tudunk tenni, ha az ûrlapot elküldik. Mivel a követelményünk az volt, hogy nem második levelet küldünk, hanem a contact modul által egyébként is elküldött levelet módosítjuk, nem tudunk azonnal levelet küldeni. Meg kell viszont jegyeznünk, hogy a szerkesztõségnek is el kell küldeni a levelet, mert erre még késõbb szükségünk lesz. A submit függvények két paramétert kapnak, az ûrlap azonosítóját és a beküldött értékeket. Most biztosak vagyunk az ûrlap azonosítóját illetõen, hiszen csak egy ûrlaphoz kötöttük ezt az eseménykezelõt, ezért annak értékével nem foglalkozunk, csak azzal, hogy be legyen állítva. Amennyiben pedig az ûrlap értékek között a szerkesztõknek való elküldést kérték, ezt egy statikus értékben megjegyezzük. Ha úgy hívjuk meg ezt a függvényt, hogy nem adunk meg semmilyen ûrlap azonosítót, akkor fogjuk visszakapni a megjegyzett értéket.

Végül szükségünk van arra, hogy a megjegyzett értéknek megfelelõen elhelyezzünk egy cc fejlécet a drupal.hu/kezikonyv/nyomtatobarat

90/135

2010.02.11.


kiküldött levelekben. Erre a célra tavaly nyár óta a hook_mail_alter() használható. Ezt kell tehát már csak megvalósítanunk. Itt a levél részletes adatait kapjuk meg külön-külön paraméterekben. Most számunkra az az érdekes, hogy melyik levéllel van dolgunk. Szerencsére a contact modul fejlesztõi okosan megkülönböztették a normál kapcsolat levelet a (beépített képességgel elõállított) másolat levéltõl, így csak a normál kapcsolat levélre tudunk koncentrálni. Itt ellenõrizni kell, hogy a korábban megjegyzett ûrlap mezõ érték mi volt. Ha kérték a cc fejléc beállítását, akkor a fejlécek tömbjéhez adjuk ezt hozzá.

Voilá! Készen is vagyunk a kapcsolat ûrlap funkcionalitásának kiterjesztésével, anélkül, hogy bármit módosítani kellett volna az alaprendszeren.

Melyik nevedet mutassam? A készülõ Drupal alapú magyar Ubuntu közösségi webhely készítése során valósítottam meg azt, ami már a Weblabor kapcsán is többször felmerült bennem. Mostanában ?divattá? vált az interneten a teljes név használata semmitmondó nicknevek mögé zárkózás helyett. Ez a jelenség a Weblabornál, mint szakmai médiumnál megfigyelhetõ, a warezoldalakon ? érthetõ okokból ? kevésbé. Ez viszont felvet egy technikai problémát: magyarok vagyunk, és ?gonosz? módon nem csak ASCII neveink vannak. Erre a problémára adhat megoldást a felhasználónév, a nick és a teljes név különválasztása. A konkrét megoldásom az volt, hogy a felhasználó személyes beállításainál megadhatja teljes- és becenevét illetve azt, hogy melyik jelenjen meg beküldött tartalmai, hozzászólásai beküldõjeként. A megvalósításhoz három változtatást kell eszközölni. Az elsõ a ?profile? modul engedélyezése. A második a megfelelõ profiladatok felvétele, amit az adminisztrációs rendszerbõl (admin/settings/profile) a legegyszerûbb elvégezni: Típus

Mezõnév

Láthatóság Megjegyzés

egysoros szövegmezõ

profile_nickname

publikus

Becenév; opcionális

egysoros szövegmezõ

profile_fullname

publikus

Teljes név; opcionális

választólista

profile_whichname személyes

Alapértelmezett név; Lehetõségek: Felhasználói név, Teljes név, Becenév

Végül a harmadik lépés PHPTemplate sablonrendszer használata esetén a smink gyökerében egy template.php fájlt létrehozása (ha nem létezik még). Ebbe a következõt írjuk:
91/135

2010.02.11. Magyar Drupal Kézikönyv * * @param $object * The user object to format, usually returned from user_load(). * @return * A string containing an HTML link to the user's page if the passed object * suggests that this is a site user. Otherwise, only the username is returned. */ function phptemplate_username($object) {

if ($object->uid && $object->name) { // Shorten the name when it is too long or it will break many tables. if (drupal_strlen($object->name) > 20) { $name = drupal_substr($object->name, 0, 18) .'?'; } else { $name = $object->name; } if (user_access('access user profiles')) { //sajnos be kell töltenünk a felhasználói profilt profile_load_profile($object); $output = ""; //a lényeg if ($object->profile_whichname=="Teljes név") { $_title = t('View user profile.') . ' Felhasználói név: ' . $name; $output .= l($object->profile_fullname, 'user/'. $object->uid, array('title' => $_title)); } elseif ($object->profile_whichname=="Becenév") { $_title = t('View user profile.') . ' Felhasználói név: ' . $name; $output .= l($object->profile_nickname, 'user/'. $object->uid, array('title' => $_title)); } else { //az eredeti $output .= l($name, 'user/'. $object->uid, array('title' => t("View user profile."))); } } else { $output = check_plain($name); } } else if ($object->name) { // Sometimes modules display content composed by people who are // not registered members of the site (e.g. mailing list or news // aggregator modules). This clause enables modules to display // the true author of the content. if ($object->homepage) { $output = l($object->name, $object->homepage); $output .= " homepage}\" rel=\"nofollow\" title=\"Személyes weblapja\">" . theme_image('themes/ubuntuhu/gfx/url.png', 'Honlapja') . ''; } else { $output = check_plain($object->name); } $output .= ' ('. t('not verified') .')'; } else { $output = variable_get('anonymous', 'Anonymous'); } drupal.hu/kezikonyv/nyomtatobarat

92/135

2010.02.11. return $output; } ?>


Ez a Drupal 4.7.2 theme_username függvényének megfelelõ kiegészítése. A megjegyzésekben látszik, hogy mi nem az eredeti függvény része.

Publishboard: a drupal.hu szerkesztőségi segítője A Drupal.hu indulásakor a webhely egyik funkciója az új tartalmak beérkezése esetén az adminisztrátorok értesítése (notify) volt. Ezt egyrészt a megnövekedett link beküldés szám, másrészt pedig az akkor használt modul hátrahagyottsága (a frissítés elmaradása miatt) nem használtuk tovább. Így viszont, és a kis szerkesztőség kevés idejének is betudhatóan nem követtük a beérkező tartalmakat, sokszor külön emailben értesültünk, hogy valamilyen cikket vagy hírt most már át kellene nézni, és meg kellene jelentetni. Amikor a drupal.hu szerkesztőségét bővítettük (mely ma már a legtöbb kiemelten aktív drupal.hu tagot magában foglalva hét tagot számlál), ez a gond még erősebben jelentkezett. Úgy döntöttünk, hogy email értesítés helyett folyamatosan szem előtt lévő összefoglalót alakítunk ki. Ennek a fejlesztését én vállaltam, s a néhány hónapja használt Publishboard modulunk meglátásom szerint beváltotta a hozzá fűzött reményeket. A feladat tehát a beküldött tartalmak összefoglalása volt, hogy értesülhessünk a beküldött új tartalmakról, és minél hamarabb cselekedhessünk ezeket illetően. Természetesen belefoghattunk volna valamilyen általános modullal összevarázsolni a saját eszközünket, de az eredményként született jól kommentezve is csupán 115 soros modul karcsúbb és célratörőbb lett.

A publishboard blokk megjelenése

Először is természetesen szükségünk volt egy .info fájlra a modulhoz: name = Publishboard description = Beküldött tartalmak kezelését segíti package = "Drupal.hu" core = 6.x

Itt látszik, hogy a drupal.hu számára kifejlesztett moduljainkat egy csomagban fogjuk össze. A számunkra lényeges információ az, hogy mennyi még megjelenésre váró tartalom van, illetve ezek közül mennyi új és régi. Drupal terminológiával most újnak tekintünk minden tartalmat, amit az aktuálisan belépett felhasználó még nem látott vagy amióta látta, azóta változtattak rajta. Ennek érdekében a következő összesítő kódot alakítottuk ki:
93/135

2010.02.11. Magyar Drupal Kézikönyv listájára. $result = db_query('SELECT nid, type, changed FROM {node} WHERE status = 0'); while ($node = db_fetch_object($result)) { $list[$node->nid] = $node; if (!in_array($node->type, $types)) { $types[] = $node->type; } } // Ha van bármilyen nem közzétett tartalom. if (count($types)) { // Nézzük, hogy az éppen látogató felhasználó melyeket látta már ezekből legutóbbi // módosításuk óta (melyek így tényleg újak a számára). Az IN() tartalma biztos számokból áll // a fenti kód alapján, ezért azt biztonságos az SQL-ben közvetlenül használni. $part = join(", ", array_keys($list)); $result = db_query("SELECT nid, timestamp FROM {history} WHERE uid = %d AND nid IN ($part)", $user->uid); while($history = db_fetch_object($result)) { if ($list[$history->nid]->changed > $history->timestamp) { // Van róla adatunk, és régebben látta, mint amikor legutóbb változott. $changed[$list[$history->nid]->type]++; } else { // Volt róla adat, de a változás régebbi, mint a látogatás. $unchanged[$list[$history->nid]->type]++; } // Kezeltük a history tábla alapján. unset($list[$history->nid]); } } // Ezeket nem találtuk meg a history táblában, azaz soha nem látta a user, // vagy nagyon régen látta, és már a history táblában nincs benne a bejegyzés. // Csak a limitet tudjuk alapul venni az ellenőrzéshez. foreach ($list as $node) { if ($list[$node->nid]->changed > NODE_NEW_LIMIT) { $changed[$node->type]++; } else { $unchanged[$node->type]++; } } // A típusok listájával és a számolások eredményével térünk vissza. return array($types, $changed, $unchanged); } ?>

Ezekről az adatokról egy emberileg olvasható blokkban szeretnénk információkat megjeleníteni: array('info' => 'Beküldött tartalmak', 'weight' => -100, 'enabled' => 1, 'region' => 'right')); } elseif ($op == 'view' && user_access("access administration pages")) { // Csak adminisztrátoroknak mutatjuk meg ezt a blokkot. drupal.hu/kezikonyv/nyomtatobarat

94/135

2010.02.11. Magyar Drupal Kézikönyv $items = array(); // Emberek számára olvasható nevek praktikusabbak, mint a gépi nevek. $names = node_get_types('names'); // Alapadatok lekérdezése. list($types, $changed, $unchanged) = publishboard_unread_counters(); foreach ($types as $type) { $title = ''; // Elvileg valamelyik be van állítva, de azért menjünk biztosra. if (isset($unchanged[$type]) || isset($changed[$type])) { if (isset($unchanged[$type])) { $title .= $unchanged[$type] .' régi'. (isset($changed[$type]) ? ', ' : ' '); } if (isset($changed[$type])) { $title .= $changed[$type] .' új '; } $items[] = l($title . $names[$type], 'publishboard/'. $type); } } if (count($items)) { // Vannak megjelenítendő linkek. return array( 'subject' => 'Beküldött tartalmak', 'content' => theme('item_list', $items), ); } } } ?>

A blokk funkciója természetesen nem csak az információ átadása, hanem a szerkesztőség segítése is, tehát olyan linkeket kellett kialakítani, amik az adminisztrációs felület megfelelő oldalára vezetnek. A tartalmak kezelőfelülete azonban nem linkelhető a webcímbe helyezett olyan kritériumokkal, mint, hogy adott típusú, nem publikált tartalmakra van szükségünk. Ezért kellett bevezetni az előző kódban látható publishboard címen a köztes oldalunkat, ami a megfelelő beállításokkal átirányít a tartalmak adminisztrációs oldalára. 'publishboard', 'title' => 'Beküldött tartalmak', 'callback' => 'publishboard_page', 'access' => user_access("access administration pages"), 'type' => MENU_CALLBACK, ); } return $items; } ?>

Itt egy menüben meg nem jelenő, a publishboard_page()-et hívó webcím kezelőt állítottunk be. Az pedig egyszerűen:
95/135

2010.02.11. Magyar Drupal Kézikönyv // A tartalom lista szűrése meg nem jelent $type típusú elemekre, a node.module kódja alapján. $_SESSION['node_overview_filter'] = array( array('status', 'status-0'), array('type', $type), ); // Átirányítás a céloldalra. drupal_goto('admin/content/node'); } ?>

Ennyivel meg is oldottuk a funkcionalitást. Rendelkezésünkre áll egy blokk, ami kijelzi a meg nem jelent tartalmakat, és a linkekre kattintva az adminisztrációs felületre vezet. Bekapcsolhatjuk a blokkot akár minden felhasználó számára, hiszen maga a blokk akadályozza meg, hogy nem adminisztrátorok részére is láthatóvá válljon. Számunkra még egy fontos elem volt: emeljük ki a blokkot a többi közül, megkönnyítve a szemünk számára a blokk azonosítását. Ezt a következő egyszerű CSS szabályok sminkünkbe helyezésével értük el: /* Publishboard */ #sidebar #block-publishboard-0 { background-color: #ffc; padding: 0.8em; } #sidebar #block-publishboard-0 .item-list ul { margin: 0; } #sidebar #block-publishboard-0 a { color: #036; font-weight: bold; }

Ezzel egy figyelemfelkeltő sárga háttérrel megjelenő blokkot kaptunk, mely a fent látott módon fest.

Szálakba rendezett új hozzászólások követhetõvé tétele Alapvetõ és állandó probléma nagyobb forgalmú oldalakon, hogy a sok hozzászólás között igen nehéz a különbözõ szálakba érkezett új hozzászólások követése. A Drupal alapértelmezés szerint az általunk még nem olvasott hozzászólásokat (és tartalmakat) ?új? jelzéssel látja el. Ezt javítottam föl azzal, hogy arra kattintva a következõ új hozzászólásra ugorjon. A megoldás két egyszerû lépésbõl áll PHPTemplate sminkmotor használata esetén. Az elsõ a template.php kiegészítése. Ez a fájl az adott smink gyökerében helyezhetõ el, például /sites/all/themes/azensminkem/template.php. Feladata a gyárilag használható .tpl.php fájloknál kevésbé általános finomhangolások végrehajtása, esetünkben a comment.tpl.php-nak küldött változók felülírása. Ez a _phptemplate_variables($hook, $vars) függvénnyel történhet a következõ módon:
96/135

2010.02.11.

Magyar Drupal Kézikönyv $vars['numnew'] = ++$numnew;

} break; } return $vars; } ?>

Mivel ez a függvény meghívódik minden sablon kiértékelésekor, a hozzászólások megjelenítése elõtt meg tudjuk vizsgálni, hogy éppen egy új hozzászólást dolgozunk-e fel. Ha új hozzászólásról van szó, akkor a függvényhívások között megjegyzett értékû (static) $numnew változóban számoljuk, hogy hányadik új hozzászólást találtuk. Az aktuális hozzászólásra vonatkozó $numnew változót megkapja a sablonunk. A második lépés a hozzászólásoknál a megjelenés testreszabása, a link elhelyezése. Ez a comment.tpl.php, hozzászólások megjelenését szabályozó fájllal oldható meg. Ha nem létezik, létre kell hozni. Drupal 5 használata esetén az alapértelmezése a következõ.
new) : ?> <span class="new">

A megjegyzésekkel jelölt részt kell módosítani a következõre. new) { if ($numnew == 1) { print ''; } print '<span class="new">' . $new . ''; } ?>

Ezzel ha új hozzászólást látunk, és az elsõ új hozzászólásról van szó, akkor a new horgornyt rakjuk le. Különben egy new5 típusú horgonyt, ahol 5 az új hozzászólások közötti sorszám. A következõ új hozzászólásra linkeljük a feliratot. drupal.hu/kezikonyv/nyomtatobarat

97/135

2010.02.11.


Tartalomszervezési megoldások I. - Taxonomy és Book modul Az egyik leggyakoribb feladat honlapkészítés során, hogy a webhelyre feltöltött nagy mennyiségû tartalmat (írásokat, oldalakat, képeket – Drupal szakzsargonban: a node-okat) valahogyan rendszerezzük. Erre a Drupal alapcsomag két modult is kínál: a Taxonomy (kategorizáló) modullal a tartalmakat kategóriákba sorolhatjuk, a Book (könyv) modullal pedig "szülõ-gyermek" kapcsolatot, azaz hierarchikus viszonyt alakíthatunk ki közöttük. Egyszerûbb webhelyeken ez általában elegendõ a tartalmak rendszerezéséhez; azonban ahogy honlapunk egyre összetettebbé válik, elõfordulhat, hogy beleütközünk az alapcsomag korlátaiba. Ilyenkor kiegészítõ modulok telepítésével növelhetjük a Drupal képességeit. Az alábbi kétrészes cikkben elõször a tartalomszervezés problémáját ismertetjük, majd többféle, egyre növekvõ komplexitású megoldást mutatunk be kezdõ és haladó Drupal webmesterek számára.

A feladat Vegyünk egy egyszerû példát: szeretnénk egy sportegyesületnek webhelyet készíteni. Az egyesület keretein belül 2 csapat is mûködik, egyenként 15-20 taggal. Honlapunkon az egyesület adatai mellett szeretnénk önálló oldalt nyitni mindkét csapatnak, valamint egyenként az összes játékosnak. Természetesen a játékosok oldalain fel kell tüntetnünk, hogy melyik csapatban játszanak.

Elsõ megoldás: Taxonomy modul Ha Taxonomy modullal oldjuk meg a feladatot, akkor hozzunk létre egy "Csapatok" nevû szótárat, és ehhez adjunk 2 kategóriát: Piros csapat, Kék csapat. Ezek után hozzuk létre a játékosok oldalait, és a tartalombeküldõ oldalon a Kategóriák rovatban jelöljük be, hogy az adott játékos melyik csapathoz tartozik. A végeredmény valahogy így fog kinézni: Piros csapat (taxonomy/term/1) Játékos-1 (node/1) Játékos-2 (node/2) Játékos-3 (node/3) stb. Kék csapat (taxonomy/term/2) Játékos-4 (node/4) Játékos-5 (node/5) stb. Ha most felkeressük webhelyünkön a www.honlapneve.hu/taxonomy/term/1 oldalt, akkor ott egy listát találunk, amelyben a linkek a Piros csapat tagjainak egyéni oldalaira mutatnak (www.honlapneve.hu/node/1, stb.); az egyéni oldalakon pedig ott látjuk a cím alatt a kategória linket, amely megmutatja, hogy az adott játékos melyik csapatnak a tagja, és amelyen keresztül visszatérhetünk a csapat oldalára. A menübe felvehetjük a Piros csapat és Kék csapat oldalaira mutató linkeket – ezzel el is készítettünk egy egyszerû webhelyet. Ezután azonban szeretnénk továbblépni: logikusnak tûnik, hogy a csapatok oldalának tetején, a játékosok listája felett ott legyen a csapatvezetõ neve és elérhetõsége, az edzõ neve, a csapat története, közös fotója, stb. A Taxonomy modul erre nem ad lehetõséget. A modul által létrehozott kategóriák csak egyszerû dobozok, amelyekbe betehetjük az egyes tartalmakat (a játékosok egyéni oldalait) – de a dobozon csak a kategórianév (Piros csapat, Kék csapat) szerepel, és nem írhatunk rá további információkat. drupal.hu/kezikonyv/nyomtatobarat

98/135

2010.02.11.


Második megoldás: Book modul Próbálkozzunk most a Book modullal. Ennek bekapcsolása után a node oldalakon a Megtekintés és a Szerkesztés mellett megjelenik egy újabb fül: a Vázlat. Hozzunk létre egy "Csapatok" nevû oldalt, a Vázlat fülön nyilvánítsuk könyv címlapnak (azaz olyan oldalnak, amely legfelsõ szintû); majd hozzuk létre a csapatok oldalait, és ezeket rendeljük a könyv címlap mint "szülõ" oldal alá. Mivel most a csapatok oldalai egyszerû Drupal könyvlapok, bármilyen információt rájuk írhatunk, így végre helyet kaphat a csapat elérhetõsége, története, stb. Következõ lépésben hozzuk létre a játékosok egyéni lapjait, és soroljuk be õket a csapat-oldalak alá. Struktúránk most így néz ki: Csapatok Piros csapat (node/1) Játékos-1 (node/2) Játékos-2 (node/3) Játékos-3 (node/4) stb. Kék csapat (node/5) Játékos-4 (node/6) Játékos-5 (node/7) stb. Ez a megoldás már megfelel az elképzeléseinknek – és egyszerûbb, pár oldalas webhelyeken ennél többre nincs is szükségünk. Mi azonban szeretnénk további listázó oldalakat készíteni, például a játékosok neme (fiú-lány) szerint. Piros csapat Piros lányok Piros fiúk Kék csapat Kék lányok Kék fiúk Ha Taxonomy modullal dolgozunk, a feladat egyszerû. Létrehozunk egy Nemek szótárat, abban két kifejezést (Fiúk, Lányok), majd a játékosokat besoroljuk valamelyik kategóriába. Ha szeretnénk a Piros lányokat listázni, csak kombinálnunk kell a kategóriák azonosítóit az oldalra mutató link végén, és a Drupal magától tudja, hogy mely játékos-oldalakat kell felvennie a listára. Csapatok szótár Piros csapat kategória (taxonomy/term/1) Kék csapat kategória (taxonomy/term/2) Nemek szótár Fiúk kategória (taxonomy/term/3) Lányok kategória (taxonomy/term/4) A Piros lányok listáját a következõ címen találjuk: www.honlapneve.hu/taxonomy/term/1,3. A Kék fiúkat pedig itt: www.honlapneve.hu/taxonomy/term/2,4. A megoldás kifogástalanul mûködne – ha nem vetettük volna el a kategóriák használatát akkor, amikor kiderült, hogy nem tudjuk a csapatok elérhetõségét a csapat-oldal tetejére kiírni. A Book modullal készített Piros csapat és Kék csapat viszont nem kategória, hanem közönséges oldal, ezért ezeket nem tudjuk a drupal.hu/kezikonyv/nyomtatobarat

99/135

2010.02.11.


Fiúk-Lányok kategóriákkal kombinálni.

Harmadik megoldás: mindent bele! Kézenfekvõnek tûnik, hogy a két rendezési módszert kombináljuk, azaz a játékosok oldalait tegyük be kategóriákba (Piros csapat, Kék csapat, Fiúk, Lányok), és egyúttal soroljuk be õket a Piros csapat és Kék csapat c. könyvlapok alá. Ezzel megoldódott a kombinált listázás problémája. Ugyanakkor most egy zavaró jelenséget tapasztalhatunk: ha látogatónk felkeresi a Piros csapat könyvlapját (elérhetõségekkel, csapattörténettel, stb.), majd onnan elnavigál Játékos-1 személyes oldalára, ott találja Játékos-1 neve mellett a Piros csapat kategóriára mutató linket. Ha tehát az oldal elolvasása után a látogató szeretne a Piros csapat többi tagjával is megismerkedni, akkor rá fog kattintani erre a linkre, ez viszont nem a Piros csapat könyvlapra mutat (ahol az elõbb járt, és ahová szeretne visszalépni), hanem a Piros csapat nevû kategória listázó oldalára (amely a látogató számára is nyilvánvaló módon nem azonos a korábban megtekintett csapat-oldallal). A problémát rövid úton megoldhatjuk, ha eltüntetjük a könyvlapokról a kategória-linkeket. Keressük meg a sminkünk könyvtárában a node.tpl.php nevû fájlt, és készítsünk róla ugyanebbe a könyvtárba egy másolatot node-book.tpl.php néven. Ezzel lényegében arra utasítottuk a Drupalt, hogy könyvlapok esetén a megjelenítéshez ne a node.tpl.php fájlt használja, hanem a most létrehozott node-book.tpl.php-t. Ezután nyissuk meg a fájlt egy kódszerkesztõ programmal (Windows alatt pl. Notepad++), és töröljük a taxonómiára vonatkozó részt. Garland smink esetén a törlendõ kódrészlet a következõ:

Ha most felkeressük bármelyik játékos oldalát, nem látjuk a zavaró kategória-linkeket. Ezzel azonban annak lehetõsége is megszûnt, hogy látogatóink maguktól felfedezzék a kombinált kategóriák oldalait (Piros lányok, Kék fiúk) – így ezekre külön fel kell hívnunk a figyelmet. Ehhez kapcsoljuk be az alapcsomagban kapott Path modult, amelynek segítségével egyszerûen megjegyezhetõ útvonal álneveket rendelhetünk oldalainkhoz. A Piros csapat oldalához a szerkesztõ ûrlapon adjuk meg a piros útvonal álnevet (az oldal ezután a www.honlapneve.hu/piros címen is elérhetõ lesz), a Kék csapat oldalához pedig a kek-et; majd vegyük fel a két oldalra mutató linket az elsõdleges menübe. A játékosok oldalainak szintén adjunk egyedi útvonalneveket, ahol az útvonal elsõ tagja mindig a csapat neve legyen: piros/kisspal, kek/nagypeter. Ezután készítsünk egy menüt, amelynek elemei a Piros lányok, ill. Piros fiúk oldalára mutatnak; majd a blokk beállítások között határozzuk meg, hogy ez a menü csak a piros és a piros/* útvonalon található oldalakon jelenjen meg. Ugyanezt ismételjük meg a Kék lányok, Kék fiúk esetén. Most tehát ha látogatónk elnavigál bármelyik csapat, vagy játékos oldalára, akkor feltûnik a lapon egy újabb menü, amelyen keresztül eljuthat a Piros lányok, Piros fiúk, ill. Kék lányok, Kék fiúk oldalakra.

Tartalomszervezési megoldások II. - Views és CCK modul Negyedik megoldás: Views Tételezzük fel, hogy egyesületünk honlapján a csapatnevek mellet nem 2 hanem 4 további kategóriát szeretnénk bevezetni: Fiúk, Lányok, Hazai játékosok, Vendégjátékosok. Ez a – rendkívülinek nem drupal.hu/kezikonyv/nyomtatobarat

100/135

2010.02.11.


nevezhetõ – helyzet azt eredményezi, hogy webhelyünk szerkezete, és ezzel párhuzamosan a menürendszer kényelmetlenné és a kategóriák közötti átfedésektõl függõen nehezen áttekinthetõvé vált: Piros csapat Piros fiúk Piros vendégjátékosok Piros vendégjátékos fiúk Fiúk Hazai játékos fiúk ...stb. Ha például azt szeretnénk, hogy a hazai játékosoknak és a vendégjátékosoknak a csapatok mintájára külön oldaluk legyen (ne csak egy-egy lista), akkor ezeknek külön könyvet kell nyitnunk; és mivel egy oldalt (könyvlapot) csak egy könyvbe tudunk beilleszteni, a játékosok oldalait kétszer kell felvinnünk a honlapra. Hasonló problémát okoz az a korlátozás, hogy egy node-hoz csak egy útvonal álnevet rendelhetünk, ezért pl. egy Piros csapatban játszó vendégjátékos fiú oldalán vagy a Piros fiúk, vagy a Vendégjátékosok segédmenüpontot fogjuk tudni megjeleníteni (hacsak nem használunk többszörösen összetett útvonal álneveket, amivel éppen az álnév lényegét – egyszerûen megjegyezhetõ internetcím – veszítjük el). Ezen a ponton már a Drupal alapcsomag korlátait feszegetjük, és éppen ideje kiegészítõk után néznünk: ismerkedjünk meg a Views modullal. A Views a Drupal rendszer által készített listák felülírására, valamint új listák létrehozására használható. A felülírás azt jelenti, hogy egy adott webcímen, pl. a www.valami.hu/taxonomy/term/1 alatt nem a szokásos kategória-listát látjuk, hanem egy általunk megadott szempontok szerint módosított felsorolást. Lássuk, milyen módosításokat tesz lehetõvé a Views: Lista megjelenítése nem csak önálló oldalon, hanem blokkban is Hozzáférés korlátozása felhasználói csoportok szerint Oldalaknak, blokkoknak egyéni cím Oldalaknak, blokkoknak egyéni fejléc és lábléc Listázott elemek megjelenítési módjának meghatározása (teljes node, bevezetõ, táblázat, felsorolás) Listában szereplõ node-ok számának meghatározása Listában szereplõ mezõk meghatározása (pl. cím, beküldési idõ, szerzõ neve, stb.) Lista szûkítése kategóriák, tartalomtípusok, közzétételi beállítások szerint Lista rendezése növekvõ vagy csökkenõ sorrendbe ... stb. A fenti felsorolás nem teljes, de talán érzékelteti a modul sokoldalúságát. Számunkra most a legérdekesebb az a lehetõség, hogy a listázó oldalakhoz egyéni fejlécet készíthetünk. Eredeti problémánk az volt, hogy nem tudtuk a kategória listázó oldalak tetejére beszúrni a csapatok elérhetõségét és egyéb információit – ezt a feladatot szépen megoldhatjuk a listázó oldal felülírásával. Készítsük el tehát a kategóriákat és vigyük fel a játékosok oldalait: Piros csapat (taxonomy/term/1) Játékos-1 (node/1) Játékos-2 (node/2) Játékos-3 (node/3) stb. Kék csapat (taxonomy/term/2) Játékos-4 (node/4) Játékos-5 (node/5) drupal.hu/kezikonyv/nyomtatobarat

101/135

2010.02.11.


stb. Ezután az admin/build/views/add oldalon készítsük el a nézeteket, amelyekkel felülírjuk a taxonomy/term/x oldalakat: Name (név): piroscsapat Access (hozzáférés): mivel mindenki számára elérhetõvé kívánjuk tenni az oldalt, ne jelöljük be egyik csoportot sem Description (leírás): Piros csapat oldala (ezt a szöveget csak az adminisztrátor látja) Page (oldal) Provide page view (oldal készítése): kipipálva URL (webcím): taxonomy/term/1 View type (nézet típusa): Teaser List (bevezetõk) Title (az oldal látható címe): Piros csapat Use Pager (lapozó használata): kipipálva Breadcrumb trail should not include "Home" (A morzsa ne tartalmazza a 'Nyitólap' linket): hagyjuk üresen Nodes per Page (node-ok száma): 10 Header (fejléc): ide illeszthetjük be a Piros csapatra vonatkozó információkat; ha HTML vagy PHP kódot használunk, ne felejtsük el átállítani a beviteli módot Filters (szûrõk): Node: Published -> Equals: Yes (csak a közzétett oldalak szerepeljenek a listán) Taxonomy: Terms for Csapatok -> Is One Of: Piros csapat (csak a 'Piros csapat' kategóriába sorolt cikkek szerepeljenek a listán); Option: 10 (ha szeretnénk, hogy a 'Piros csapat' kategória alá besorolt esetleges alkategóriák tartalmát is listázza) Sort Criteria (sorrendezési szabályok): Node: Sticky -> Order: Descending ('kiemelt' cikkek az oldal tetejére, csökkenõ idõrendi sorrendben) Node: Created Time -> Order: Descending (többi cikk csökkenõ idõrendi sorrendben) Látogassunk el a www.valami.hu/taxonomy/term/1 oldalra: a korábbi egyszerû listázó oldal helyett most a fejléccel kiegészített, teljes értékû Piros csapat oldalt látjuk. Természetesen használhatunk egyszerûen megjegyezhetõ webcímeket is; ehhez navigáljunk az 'Útvonal álnevek' menüpont alá, és adjuk meg, hogy a taxonomy/term/1 mellett legyen oldalunk a piros címen is elérhetõ. A 'Menük' oldalon állítsunk be egy piros címre mutató menüpontot is – ezzel el is készültünk a Piros csapat oldalával. Ismételjük meg a nézet készítés, útvonal álnév megadás, menüpont készítés lépéseket valamennyi kategóriánkra. Ha ezek után felkeressük bármelyik játékos oldalát, ott találjuk a kategória linkeket (Piros csapat, Fiúk, Vendégjátékosok); és ha bármelyik linkre rákattintunk, a Views által készített, fejlécekkel/láblécekkel feljavított nézet-oldalakra lépünk. Ezeket az oldalakat igen jól lehet sminkelni, tehát egyéni megjelenést is tudunk nekik adni; emellett a fejléc/lábléc szövegbe egyszerûen beilleszthetünk kombinált taxonómialinkeket (pl. a Fiúk oldalon a hazai és vendégjátékos fiúk listájára mutató linkek), ill. Insert View modullal bármilyen más nézetet – így kordában tudjuk tartani a csak bizonyos oldalakon megjelenítendõ másodlagos menük burjánzását. Webhelyünk ezzel áttekinthetõ szerkezetet és következetes navigációs struktúrát kapott. Megjegyzés: A Views nézetkészítõ ûrlapján lehetõség van URL-ként útvonal álnevek megadására, valamint menüpont készítésre is. Ezeket a szolgáltatásokat akkor célszerû használni, ha teljesen új, a rendszerben nem szereplõ listát készítünk (pl. ha a "Piros csapat" kategóriában szereplõ "kép" típusú tartalmakat drupal.hu/kezikonyv/nyomtatobarat

102/135

2010.02.11.


szeretnénk kigyûjteni egy külön képgaléria számára). Ha egy meglévõ listát szeretnénk felülírni, akkor elõször készítsük el a nézetet a rendszer által meghatározott URL (pl. taxonomy/term/x) megadásával, majd külön lépésben definiáljuk az útvonal álnevet és a menüpontot. Ezzel elkerülhetõ, hogy webhelyünkön egymás mellett éljen a hagyományos oldal és annak felülírt verziója, ami esetleg megzavarhatja a barangoló látogatókat.

Ötödik megoldás: CCK + Views A Views modullal már egészen összetett webhelyeket is építhetünk anélkül, hogy egyetlen sor PHP-kódot kellene írnunk; mégis elképzelhetõ néhány olyan eset, amikor még ez a megoldás sem elégíti ki az igényeinket. A Views kezelõfelülete meglehetõsen bonyolult, márpedig minden egyes alkalommal, amikor új nézetet készítünk (pl. új kategóriával bõvül a webhely), vagy meglévõt módosítunk (megváltozott a csapat telefonszáma), akkor kénytelenek vagyunk ezen a barátságtalan ûrlapon dolgozni. Húsz-harminc nézetnél többet ilyen módon kezelni még akkor is kényelmetlen, ha a webhely karbantartását hozzáértõ webmester végzi – laikusoktól pedig egyáltalán nem várható el, hogy kiigazodjanak a Views bokros opciói között. Szintén tovább kell lépnünk akkor, ha szeretnénk kétszintes honlapunkat (játékosok, csapatok) háromvagy többszintessé bõvíteni. Képzeljük el azt az esetet, amikor több tucat csapatunk van, és szeretnénk a csapatok részvételével versenyeket szervezni. Létrehozhatunk egy Versenyek kategóriát, de ehhez nem tudjuk hozzárendelni a csapatokat, mert azok nem node-ok, hanem kategóriák, ill. a kategóriák módosításával létrehozott nézetek. Ennek a problémának a megoldására született a Category kiegészítõ modul – az ezzel a modullal létrehozott kategóriák tehát egyúttal node-ok is, amelyek tetszõleges információkat (elérhetõségek, verseny helyszíne, idõpontja, stb.) tartalmazhatnak, és amelyeket a szokásos módon kategorizálhatunk és listázhatunk. A Category felülete azonban legalább olyan bonyolult, mint a Views modulé, és csupán egyetlen szolgáltatást kínál. Cikkünk megírásának idõpontjában általában jobb megoldás a Content Construction Kit (rövidítve CCK) modul használata. A Drupal alapcsomaggal létrehozott tartalomtípusok csak két mezõt tartalmaznak: a címet és a törzset. A CCK modul legfontosabb szolgáltatása, hogy lehetõvé teszi a tartalomtípusok bõvítését további mezõkkel. Ha jól strukturálható adatokkal dolgozunk, akkor a CCK segítségével a tartalmak beküldését és megjelenítését nagymértékben szabályozni tudjuk. Példánknál maradva hozzunk létre 3 tartalomtípust a szükséges mezõkkel: Játékos Name: Játékos Type: jatekos Title field label: A játékos neve Body field label: A játékos életrajza Text field: A játékos telefonszáma Node reference: Csapat Csapat Name: Csapat Type: csapat Title field label: A csapat neve Body field label: A csapat története Text field: Az edzõ neve Text field: Az edzõ telefonszáma Node reference: Játékos Verseny Name: Verseny drupal.hu/kezikonyv/nyomtatobarat

103/135

2010.02.11.


Type: verseny Title field label: A verseny neve Body field label: A verseny leírása Text field: Helyszín Date field: Idõpont Node reference: Csapat A tartalomtípusok létrehozása után a "Tartalom beküldése" menüpont alatt megjelenik a 3 típus – az ezekhez tartozó beküldõ ûrlap kitöltése pedig a laikus felhasználó számára sem okoz gondot. Tartalomszervezés szempontjából figyelemre méltó a "Node reference" mezõ, amely megoldást jelent kategorizálási problémáinkra: ennek segítségével a versenyzõket a csapatokhoz, a csapatokat pedig a versenyekhez tudjuk rendelni. A gyakorlatban ez azt jelenti, hogy például egy új játékos létrehozása két lépésbõl áll: elõször is létre kell hoznunk a "játékos" típusú tartalmat, amelynek során kiválasztjuk a node reference listából, hogy az új ember melyik csapatban játszik; majd az adott csapat node reference listájára fel kell vennünk az új játékost. A munkafolyamatot tovább egyszerûsíthetjük, ha a csapatok tagjait nem node reference útján határozzuk meg, hanem Views modullal készítünk egy csapattagokat listázó nézetet, majd ezt beágyazzuk a Csapat tartalomtípusba. URL: csapat Filters: Node Published -> Equals: Yes Node: Type -> Is One Of: Játékos Arguments: Argument type -> Node reference: Játékos (field_csapat) Default -> Summary, unsorted Ezzel lényegében megmondtuk a Views-nak, hogy készítsen listát azokból a játékos node-okból, amelyek rendelkeznek field_csapat nevû CCK-s mezõvel. Ha a nézet nem kap argumentumot az URL végén (pl. a www.honlapneve.hu/csapat címen), akkor készít egy összesített listát, zárójelben a csapat játékosainak számával: Piros csapat (20) Kék csapat (18) Ha a nézet az URL végén argumentumot kap (pl. www.honlapneve.hu/csapat/12), akkor kilistázza az adott csapatra – esetünkben a node/12 azonosítójú, csapat típusú tartalomra – node reference útján hivatkozó node-okat, azaz a csapat játékosait. Ezt a nézetet Viewfield modullal tudjuk beágyazni a csapat node-okba: 1. Egészítsük ki a Csapat CCK-s tartalomtípusunkat egy Viewfield mezõvel. 2. Argumentumként adjuk át az aktuális node azonosítóját: %nid. 3. Ha ezek után felkeressük bármelyik Csapat típusú node-ot, ott látjuk az adott node-ra node reference útján hivatkozó játékosok listáját. A CCK és a Views a legdinamikusabban fejlesztett kiegészítõ modulok közé tartoznak, egyes funkcióik hamarosan az alapcsomagban is megjelennek. Számíthatunk rá, hogy a jövõben a hasonló rendszerezõ oldalak készítése tovább fog egyszerûsödni. Elég jó angol nyelvû dokumentáció található róluk a Drupal.org kézikönyvében: Views: Customized node lists Content Construction Kit Handbook CCK kiegészítõk listája (folyamatosan bõvül, érdemes figyelemmel kísérni) drupal.hu/kezikonyv/nyomtatobarat

104/135

2010.02.11.


További újdonságot jelenthet a Book modul tervezett átalakítása, amely kimondottan a hierarchikus honlapok készítését fogja megkönnyíteni. Remélhetõleg a fenti példákból is nyilvánvalóvá vált, hogy szinte bármilyen tartalomszervezési problémával kerülünk szembe, találni fogunk a Drupal kínálatában olyan megoldást, amellyel PHP kód írása nélkül, esetleg pár soros kódrészlet beillesztésével a feladat megoldható. Azonban a Drupal csak a kódolás terhét tudja levenni a vállunkról – gondolkodni nem tud helyettünk. A számunkra optimális megoldást csak akkor tudjuk kiválasztani, ha a webhely építését megelõzõen elemezzük, modellezzük a feladatot, és még a tartalmak tömeges felvitele elõtt alaposan tesztelünk. Csatolmány

Méret

cck_viewfield.png 13.35 KB

Többnyelvű oldal fejlesztése Drupal 6.x alatt A több helyről érkező pozitív információ nyomán elhatároztam, hogy kipróbálom a Drupal alapú tartalomkezelés gyakorlati megvalósítását. Teljes mértékben kezdőként érkeztem a feladathoz, ezért rengeteg olvasással és videó nézéssel töltöttem a kezdeti időszakot, köszönet érte a szerzőknek. Ennek eredményeként úgy éreztem, hogy az elméleti alapokat megszereztem (természetesen ez a gyakorlat során kiderült, hogy nem igaz), nekiállhatok a tényleges fejlesztésnek. Ha az ember többnyelvű fejlesztésbe kezd akkor a Drupal több lehetőséget is felkínál erre. Lehetőségünk van a keretrendszer és tartalom vagy csak a tartalom többnyelvű megjelenítésére. Ez utóbbi az egyszerűbb megoldás: 1. A 6-os verzióban található locale modult (Adminisztráció -> Webhely építés -> Modulok) be kell kapcsolni. 2. Ha a drupal alaprendszert is szeretnénk több nyelven, akkor a kívánt nyelve(ke)t letölteni a Drupal webhelyéről, és kicsomagolás után bemásolni a Drupal gyökérkönyvtárba a könyvtárakat és fájlokat. 3. Az Adminisztráció -> Webhely beállítása -> Nyelvek oldalon a nyelv hozzáadása linkre kattintva a kívánt nyelv kiválasztása és mentés. 4. A tartalom típusoknál a megfelelő tartalomra ( Adminisztráció -> Tartalom kezelés -> Tartalom típusok ) engedélyezni kell az "Általános beállítások" alatt a "Több nyelv támogatása:" választógombok közül a "Engedélyezett, fordítás támogatással" opciót. Ezután a megadott tartalom típusoknál tartalom beküldésekor kiegészül a beviteli forma egy "Nyelv" választólistával, ahol megadhatjuk a tartalomhoz választott nyelvet. A tartalom mentése után feltűnik egy újabb opció a tartalomnál "Fordítás". Erre kattintva egy listát kapunk, ahol a tartalom fordításai vannak felsorolva. A különböző nyelvekre kattintva tudjuk a fordítást elvégezni. Amennyiben a fordítást megcsináltuk, akkor a tartalom alatt megjelennek a nyelvek, amin a fordítás elérhető, ezekre kattintva az adott nyelvre fordított szöveg jelenik meg. Ezzel a tartalmak többnyelvű megjelenítését el is végeztük. Hátradőlhetünk, illetve hátradőlhetnénk, ha egy többnyelvű felülettől csak ennyit várnánk el. Egy igazi többnyelvű oldal azonban több kihívást rejt magában, amikor a címeket, menüket és tartalmakat is úgy akarjuk elkészíteni, hogy az adott nyelvet beszélő felhasználók otthon érezzék magukat az oldalunkon. Ez már keményebb dió, de a Drupalos fejlesztők erre is kidolgozták a megoldásokat. Ez az írás azért született, drupal.hu/kezikonyv/nyomtatobarat

105/135

2010.02.11.


hogy könnyebben tudjanak eligazodni a hozzám hasonló kezdők ennek a megvalósításában.

Mire lesz szükségünk? A fentebb írt 1-3 pontokban vázoltak végrehajtására. Az alaprendszeren túl szükségünk lesz az Internationalization modulra, jó ha megjegyezzük, hogy ez az i18n modul, mindenhol így hivatkoznak rá. Miután telepítettük a webszerverre, be kell kapcsolnunk a modulok között is: Adminisztráció -> Webhely építés -> Modulok a Multilanguage szekcióban kapcsoljunk be mindent amit csak lehetséges, majd mentsük a beállításokat. A nyelvválasztó menüt meg kell jeleníteni, ez fontos szerepet tölt be már a fejlesztés során is. Az Adminisztráció -> Webhely építés -> Blokkok oldalon a Nyelv választó blokkot pozicionáljuk az általunk preferált helyre. Mentés. Ezután menjünk a Adminisztráció -> Webhely beállítása -> Multilingual system oldalra és állítsuk a "Content selection mode: " választómezőt a Mixed current language (if available) or default language (if not) and language neutral opcióra. Ezzel nagy lépést tettünk előre, de korántsem eleget. Ha eddig nem szerettünk belepiszkálni az alapbeállításokba, most erőt kell venni magunkon és határozott mozdulatokkal be kell másolnunk a következő blokkot /** * Multilingual settings * * This is a collection of variables that can be set up for each language when i18n is enabled. * These are the basic ones for Drupal core, but you can add your own here. */ $conf['i18n_variables'] = array( // Site name, slogan, mission, etc.. 'site_name', 'site_slogan', 'site_mission', 'site_footer', 'anonymous', // Different front page for each language 'site_frontpage', // Primary and secondary links 'menu_primary_links_source', 'menu_secondary_links_source', // Contact form information 'contact_form_information', );

a telepített drupal rendszerünk sites/default/settings.php fájl végére. Ezzel elérjük, hogy a telepített nyelveken is meg tudjuk adni a webhely adatait. Ehhez menjünk az Adminisztráció -> Webhely beállítása -> Webhely információk oldalra és figyeljük meg a beviteli mezők alatti feliratot, miszerint a "Név:" mezőnél például a következő szöveg látszik: "A webhely neve. This is a multilingual variable". Furfangos ennek a kezelése, mert mindig a kiválasztott nyelven kell megadni a szövegeket az ilyen információval bíró mezőknél, majd mentés. Így létrejönnek jelen esetben a webhely információi az összes nyelven, amit kiválasztunk és megadjuk az adatokat, majd elmentjük. Ha ezek után nyelvet váltunk, már ezek az adatok az adott nyelven jelennek meg az oldalunkon. Hurrá! Nem is volt drupal.hu/kezikonyv/nyomtatobarat

106/135

2010.02.11.


olyan nehéz. Akkor most hozzunk létre menüpontokat. Adminisztráció -> Webhely építés -> Menük és válasszuk az Elsődleges linkek menüt. Adjunk hozzá egy menüpontot. Keressünk olyan mezőt ahol látjuk a "This is a multilingual variable" feliratot. Igen kedves olvasó, nem találunk ilyen mezőt, az elsődleges és másodlagos linkek kezelése egy kicsit másként működik. Ha létrehoztuk ezt a menüpontot akkor töröljük, így semmit nem tudunk kezdeni vele. De akkor hogy lesz nekünk többnyelvű oldalunk? Semmi izgalom, a megoldás a következő: Adminisztráció -> Webhely építés -> Menük a Menü hozzáadása oldalon adjunk hozzá annyi menüpontot ahány nyelvet felvettünk a Nyelv hozzáadása oldalon. Például egy Magyar, Angol oldalnál vegyünk fel egy menüt "Magyar" és egy menüt "Angol" néven (bármilyen szöveg megadható ). Ha ezek megvannak, akkor az Adminisztráció -> Webhely építés -> Menük oldalon válasszuk a Beállítások pontot. És lássunk csodát! Az "Elsődleges hivatkozások forrása: " választómezőnél láthatjuk a "This is a multilingual variable." feliratot. Innentől könnyű dolgunk van: az éppen kiválasztott nyelv megfelelő menüpontját válasszuk ki (pl. Magyar) és mentsük a beállítást, majd ismét a Beállítások menü, váltsunk másik nyelvre és válasszuk forrásnak a másik hozzáadott menüt (Angol), mentés. Innentől nincs más dolgunk, mint létrehozni a Magyar, Angol, stb. menük alatt a menüpontokat. Ezek fognak megjelenni a kiválasztott nyelvnél. Most elértük, hogy az oldal több nyelven is tud kommunikálni velünk, már csak a tartalmaknál kell ugyanezt elérni. A fent vázolt megoldás helyett, már sokkal elegánsabb megoldást is választhatunk. Nem kell minden tartalom alatt megjelenniük a nyelveknek, már a nyelv választó menüben választott nyelven "automatikusan" is megjelenhetnek. Én a taxonómiát választottam a megoldás kidolgozására. Ezért erről tudok most írni, bizonyára van több megoldás is. Menjünk az Adminisztráció -> Tartalom kezelés -> Taxonómia oldalra és adjunk egy szótárt hozzá a Szótár hozzáadása menüvel. A "Translation mode" választómezőben válasszuk a "Localize terms. Terms are common for all languages, but their name and description may be localized." opciót. Nyelvnek azt a nyelvet amilyen nyelven a "Szótár nevét" megadjuk. Innentől a szokásos eljárás, tartalom típus ahol használni szeretnénk valamint a választás módja a tartalomnál majd. Mentés. A szótárhoz most adjunk kifejezéseket a "kifejezések listája" linkre kattintva. Lehetőleg a szótárral azonos nyelven hozzuk létre a kifejezések nevét. Ezt majd később fogjuk fordítani, és bár nem próbáltam másként, logikailag az a gyanúm, hogy a szótárnál megadott nyelv lesz a fordítás alapja. Ha az összes kifejezést megadtuk akkor kezdhetjük lefordítani az Adminisztráció -> Webhely építés -> Felület fordítása oldalon. A "Keresés" linkre kattintva egy elég komplex oldalra jutunk, itt jelen esetben érdemes a "Keresés csak a következőkben: " választólistából a "Taxonómia" pontot választani, majd a "Keresés"-re kattintani. Ha mindent jól csináltunk akkor itt megjelennek a taxonómiáknál megadott szövegeink amiket elkezdhetünk lefordítgatni a szerkesztés linkre kattintva. Én az angolt választottam default nyelvnek, nem tudom, hogy mi történik, ha más nyelven hozzuk létre a szótárakat a kifejezésekkel. Remélem, hogy minden fontos lépést leírtam, ezáltal használható lesz olyan embereknek akik hozzám hasonlóan most ismerkednek a Drupal-lal, illetve a többnyelvű felületekkel Drupal alatt. Dudás József drupal.hu/kezikonyv/nyomtatobarat

107/135

2010.02.11.


Útvonal kiegészítése az aktuális oldal címével Feladatul kaptam, hogy az útvonalban (breadcrumb) jelenjen meg az aktuálisan megjelenített tartalom címe is. Úgy gondoltam, hogy a smink módosításával érdemes megoldani a problémát, hiszen az útvonalak összeállítása különbözõ helyeken történik a Drupalban. Megkerestem a következõt a page.tpl.php-ben (phptemplate esetén)

Majd lecseréltem a következõre: ',' ? '.$title.'

A kézikönyvnek ez a része arra próbál választ adni, hogy mire lehet egyáltalán a Drupalt használni, mik a főbb ismertetőjegyei, elemei, értékei

Recommend Documents

Sajnáljuk, honlapunk pillanatnyilag nem elérhetõ