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 é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.

Elkészült és letölthető a Drupal 7 alapismeretek könyv

Elkészült a Drupal 6 alapismeretek könyv jelentősen átdolgozott, és a Drupal 7-eshez illesztett verziója 370 oldal terjedelemben.

Szakmai Lektor: Palócz István.

A kiadvány létrejöttét az FSF.hu Alapítvány a Szabad Szoftver Pályázat 2011 keretében támogatta.

További információ és letöltés

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 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.x-dev.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.x-1.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

2004 nyarán a Drupal rendszer fejlesztői lehetőséget kaptak, hogy a Karlsruhében minden évben megrendezett LinuxTag konferencián képviseljék a rendszert, és ennek alkalmából egy kis brossúra (PDF) is készült a rendszer alapértékeiről, mely jól alkalmazható ezek áttekintésére.

Drupal brossúra

Ez alapján a Drupal legfontosabb ismertetőjegyei, melyhez ragaszkodik:

Szabványokon alapul
A Drupal fejlesztői nagyon fontosnak tartják az interoperabilitás megvalósítását. A rendszerrel szállított megjelenések 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.
Elé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 az elé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 megjelenés (smink) rendszer teszi lehetővé
Stabil
A Drupal motor erősen kézbentartott forráskódja fejlesztői verzióiban is szinte mindig stabilan működik, a Drupal honlapját is általában egy aktuális fejlesztői verzió hajtja meg. A változásokkal párhuzamosan karbantartott frissítést lehetővé tevő mechanizmus lehetővé teszi, hogy valamely Drupal kiadást az aktuális fejlesztői verzióra frissítsük az adataink automatikus migrálásával.
Szabad szoftver
Mind a Drupal motorra, 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ő.
CsatolmányMéret
PDF ikon drupal.en_.booklet.1.pdf581.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ó.

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
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
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.

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 Viselkedési Irányelvek - DVI

Az eredeti dokumentum az alábbi oldalon található: DCOC http://drupal.org/dcoc

Bevezető

Ahogy nő a közösség, úgy lesz egyre fontosabb az idevezető út során összegyűlt tapasztalat megőrzése és továbbadása, azért, hogy a Drupal továbbra is egy befogadó, kihívásokkal teli, de tisztességes hely maradjon. A Drupal Viselkedési Irányelvek az együttműködéssel kapcsolatos ideáljainkat foglalják össze. Kicsit olyan, mint a program kódolási irányelvek, csak ez emberekre vonatkoztatva. Segít abban, hogy a jelenlegi értékeinket megoszthassuk a közösség egészével.

Ubuntus barátaink kiváló példával jártak elöl. CMS-nek a Drupalt választották, mi pedig átvesszük az általuk használt Iránymutatót.

Ez a szöveg alapvetően megegyezik az Ubuntu közösség által használttal (a projekt neve más természetesen, illetve a konfliktuskezelésről szóló bekezdést töröltük, miután ilyen a Drupal közösségben nincs).

Az erről az írásról szóló közösségi megbeszélések a Drupal.org Policies csoportjában folynak.

Legyél körültekintő

Munkánkat mások is használni fogják, cserébe mi is függünk mások munkájától. Bármely döntésünk hatással lesz a felhasználókra és kollégákra - így számolnunk kell a döntésünk következményeivel. A Drupal rendszernek több millió felhasználója és több ezer közreműködő fejlesztője van. Ha elsőre nem is egyértelmű, de a saját hozzájárulásunk hatással lesz mások munkájára a Drupalban. Például kódot, infrastruktúrát, az irányelveket, dokumentációt és fordítást megváltoztatva mások munkáját nehezíthetjük meg, esetleg tehetjük tönkre.

Viselkedj tisztelettudóan

A Drupal közösség és tagjai tisztelettel bánnak egymással. Mindannyian hozzájárulhatunk valami értékessel a Drupalhoz. Nem mindig értünk egyet, de egyet nem értésünk soha nem lehet ok az esetleges illetlen viselkedésre. Időnként mindannyian érezhetjük kellemetlenül, esetleg megbántva magunkat, nem hagyhatjuk azonban, hogy ez személyes támadásokat váltson ki belőlünk. Fontos észben tartanunk, hogy egy olyan közösség, melynek tagjai kényelmetlenül vagy fenyegetve érzik magukat, nem lehet igazán eredményes. Elvárjuk, hogy a közösség tagjai tisztelettel bánjanak egymással és a külső szemlélőkkel egyaránt.

Legyél együttműködő

A közös munka kulcsfontosságú a Drupal és minden nagyobb szabad szoftveres közösség életében. Ez az együttműködés azt jelenti, hogy a Drupal közösség tagjai csapatokba szerveződve dolgoznak egymással, mely csapatok persze egymással is együttműködnek. Ezen tagok és csapatok összedolgoznak a Drupalon kívül más nyílt forrású közösségekkel is. Ez az együttműködés megóv a feleslegesen elvégzett munkától, miközben javítja a munka minőségét is. Fontos, hogy a Drupal projekten belül és azon kívül is nyitottak legyünk az együttműködésre. Ahol csak lehet, törekednünk kell, hogy szorosan együttműködjünk más nyílt forrású projektekkel és a szabad szoftveres világ képviselőivel, hogy egyeztessünk a fejlesztői, támogatói, dokumentációs és egyéb munkák irányításáról. A munkát átláthatóan kell végeznünk, minél több érdeklődő minél korábbi bevonásával. Ha úgy döntünk, hogy másoktól eltérő irányba indulunk, időben tudassuk velük, dokumentáljuk a munkánkat és rendszeresen számoljunk be az elért eredményekről.

Ha nincs egyetértés, akkor másokkal is konzultálunk

Amint azt választjuk, hogy alkalmazunk egy átfogó vagy hivatalos konfliktus kezelési eljárást, ezt a szekciót befejezzük. Addig is a cím mindent elmond.

Ha bizonytalanok vagyunk, segítséget kérünk.

Senki sem tud mindent és senkitől nem várjuk el a Drupal közösségben, hogy tökéletes legyen. A kérdésekkel sok problémát el tudunk kerülni az idők folyamán, ezért szívesen látjuk a kérdéseket. Akitől kérdeznek, készségesnek és segítőkésznek kell lennie. Ugyanakkor, ha kérdéseket teszünk fel, ügyeljünk rá, hogy ezt a megfelelő helyen tegyük.

Megfontoltan szállj ki

A tagok minden projektben jönnek-mennek, a Drupal sem kivétel. Kérünk mindenkit, aki elhagyja, részben vagy teljesen továbblép a projektjétől, lehetőleg úgy tegye, hogy távozása a legkisebb mértékben zavarja meg a projekt menetét. Ez azt jelenti, hogy a továbblépőknek közölniük illik a többiekkel, hogy elhagyják a projektet és a megfelelő lépéseket meg kell tenniük annak érdekében, hogy mások a helyükbe léphessenek és ott folytathassák, ahol ők abbahagyták.

(A fordításért köszönet: aboros, alippai, den, snufkin, zserno.)

Hogyan kezdjek hozzá!

Szeretném a nagyérdemű segítségét kérni.
Kezdő Drupal felhasználó szeretnék lenni, de sajna a telepítésen kívül igazából nem jutottam tovább. Fogalmam sincs, hogy merre kell elindulnom.
Első lépésként letöltöttem egy theme-t és sikerült is installálnom, de....
És itt a gond, nem tudom, hogy kell menüt szerkeszteni, és egyáltalán a tartalmat kezelni. Ehhez megpróbáltam végignézni a drupallal foglakozó témákat elolvasni a neten, de hát egyértelmű segítséget nem találtam.
Pedig ha van a telepítésről egy lépésről-lépésre útmutató itt az oldalon, akkor az elindulást miért nem segíti senki? Át böngésztem az oldalt és igazából, számomra is érthető formában nem találtam leírást. Lehet hogy van, de én nem találtam. :(
Tudom nem mindenkinek kell a segítség, de az olyanok mint én, esetleg nagyon hálásak lennének érte.
Olyan szájbarágós, alsótagozatos szintű kézenfogós, vezetgetős magyarázat kéne, ami azzal kezdi, hogy klikkelj az XY linkre, hogy megnyíljon az admin felület, stb... stb...
Tud valaki ilyen jellegű leírást valahol, vagy esetleg leírná valaki ide?
Reménykedve várom az útmutatást. :(

Drupal verzió: 

Saját címlap készítése

Ebben a cikkben az admin modul kódjából kiindulva, kis változtatásokkal eljutunk egy olyan új modulig, amely webhelyünk címlapját is kiszolgálhatja. Azért esett a választás a címlapra, mert itt gyakorta teljesen egyedi oldalszerkezettel találkozhatunk. Ha már értünk egy kicsit a PHP programozáshoz, akkor ez egyáltalán nem nehéz, csak egyszer neki kell vágnunk.

Kiindulásunk az admin modul, melynek forrása a következő:

/*01*/ function admin_help($section) {
/*02*/ switch ($section) {
/*03*/ case 'admin/modules#description':
/*04*/ return t('Handles the administration pages.');
/*05*/ case 'admin':
/*06*/ return t('Welcome to the administration section. Below are the most recent system events.');
/*07*/ }
/*08*/ }
/*09*/ function admin_menu($may_cache) {
/*10*/ $items = array();
/*11*/ if ($may_cache) {
/*12*/ $items[] = array(
/*13*/ 'path' => 'admin',
/*14*/ 'title' => t('administer'),
/*15*/ 'access' => user_access('access administration pages'),
/*16*/ 'callback' => 'admin_main_page',
/*17*/ 'weight' => 9);
/*18*/ }
/*19*/ return $items;
/*20*/ }
/*21*/ function admin_main_page() {
/*22*/ watchdog_overview('actions');
/*23*/ }
?>

Mivel ez a modul is csak egy oldalt definiál, emellett meglehetősen rövid, ezért ezt fogjuk végignézni sorrol-sorra, hogy lássuk, hogy épül fel egy ilyen modul. Saját modulunk építését bátran kezdhetjük úgy, hogy lemásoljuk az admin.module fájt cimlap.module néven, és kezdetnek lecseréljük az admin_ karaktersorozatokat cimlap_ -ra. Lássuk miből áll az admin modul, és ebből nekünk mire van szükségünk.

Az első függvény a 1-8. sorokban az admin_help, ez a hook_help kampó megvalósítása. Mit jelent egyáltalán az, hogy hook_help? Egyszerűen annyit, hogy az admin.module modul help (súgó) függvényét admin_help néven hívja a rendszer. Szabadon dönthetünk arról, hogy a számos kampó közül melyiket valósítjuk meg, és melyiket nem.

Mint látjuk, a hook_help hívásakor egy paramétert kapunk, a $section értéket. Ennek tartalma egy Drupal útvonal, majd egy esetleges kettőskereszt és egy leíró. Legfontosabb az admin/modules/#description értéket kezelnünk, hiszen ez a modulok listájában megjelenő szöveg. Adjuk meg saját modulunkhoz ezt a harmadik sorban a 'Handles the administration pages.' helyére. Ha nem írunk be semmit, vagy akár az egész _help kampót kihagyjuk, akkor sincs probléma, modulunk egyszerűen nem fog súgókat nyújtani. Ettől ugyan még használható lesz, de nem érdemes ezen a pár szón spórolni.

Bár az admin modul az 5-7. sorokban az admin útvonal meghívásakor is megjelenít egy segítő szöveget, amit a táblázat felett láthatunk, nekünk ilyenre nem lesz szükségünk, ezeket a sorokat törölhetjük.

A 9-20. sorokban az admin_menu függvény következik, mely a hook_menu megvalósítása. Vigyázat, a név kissé becsapós: ennek a segítségével nem csak a navigációs blokkban látható menübe szúrhatunk be menüpontokat. Ugyanitt tudunk füleket definiálni, sőt a menüben meg nem jelenő elérési utakhoz is itt tudunk hozzárendelni kezelőfüggvényeket. Paramétere a $may_cache. Ez igen friss a Drupalban, a http://drupal.org/node/8179 tanúsága szerint 2004. szeptember 13-án vezették be, és a legjobb dokumentáció hozzá – legalábbis szerintem – jelenleg ezen az oldalon található megjegyzés: ha a menüpontunk nem függ az útvonaltól, akkor bátran betehetjük az if ($may_cache) {...} blokkba. Ha azonban függ az oldaltól, mint például a tartalom szerkesztése fül, akkor ennek az else ágába tegyük.

Egy kétdimenziós tömbbel kell visszatérnünk, ezt építi fel a modul a következő három sorban. Ha használtuk már az adminisztrációs felületet, akkor csupa ismerős dologgal találkozhatunk. Láthatjuk a 13. sorban, hogy ez a modul az admin Drupal útvonalban érdekelt. A saját modulunkban ennek értéke legyen cimlap. A menüben egy administer feliratú bejegyzés jön létre a 14. sor hatására, nekünk itt a címlap felel meg. Az adminisztrációs az oldalt csak az access administration pages elérési jog birtokában nézhetjük meg (15. sor), nekünk jobban megfelel a szintén beépített access content jog használata. A callback adja meg a 16. sorban, hogy mely függvényt hívja majd meg a Drupal az oldal előállításához. Legyen ez cimlap_page, a Drupal hagyományoknak megfelelően. A 17. sorban a weight szokásos módon a bejegyzés súlyát mondja meg, mely szerint a menüben sorrendezhető. Ha ezt nem adjuk meg, akkor ábécé rendben kerülnek sorba a menüpontok.

A cimlap_page függvényben állítsunk össze egy $output karakterláncot, ami az oldal tartalma és függvényünk utolsó utasításaként írassuk ezt ki egy print theme('page', $output); hívással. Ennek hatására megjelenik az előállított HTML kód az aktuális sminkben. Mostanra a következő kódhoz jutottunk:

function cimlap_help($section) {
switch ($section) {
case 'admin/modules#description':
return 'A címlap tartalmát állítja elő';
}
}
function cimlap_menu($may_cache) {
$items = array();
if ($may_cache) {
$items[] = array(
'path' => 'cimlap',
'title' => 'címlap',
'access' => user_access('access content'),
'callback' => 'cimlap_page',
'weight' => 0);
}
return $items;
}
function cimlap_page() {
$output = 'Ez a címlap tartalma';
print theme('page', $output);
}
?>

Próbáljuk ki a http://drupal.site/cimlap oldalunkat. Ha ez jó, akkor állítsuk át az admin/settings alatt a címlapra behívott elérést node-ról cimlap értékre. Egy igazán élvezhető főoldlahoz persze tartalom is dukál, de ezt már PHP tudásunk birtokában könnyen el tudjuk készíteni. Tippekhez érdemes megnézni a node_page kódját, mely az alapértelmezett főoldalt generálja.

A főoldal egyediségéhez tartozhat még, hogy bizonyos blokkok csak ott jelennek meg, vagy éppen csak ott nem jelennek meg. Ezt az admin/block oldal Elérési út oszlopában szabályozhatjuk, mintaillesztő kifejezések segítségével. Ha például azt szeretnénk, hogy egy blokk csak a főoldalon jelenjen meg, akkor annak az elérési útja legyen |^$|. Ha viszont szeretnénk meggátolni, hogy egy blokk megjelenjen a főoldalon, akkor ugyanide pl. a |^.| ajánlható.

Prezentációtechnika

Hogyan készítsük el az előadásunk fóliáit, és hogyan adjuk elő annak tartalmát?

Évek óta tagja vagyok a Drupal Konferenciákat/Hétvégéket szervezők csapatának. Ezeken az összejöveteleken előadók segítségére készült ez az összefoglaló mely az elmúlt évek alatt megtanultakon alapul. Úgy gondolom, hogy hasznos lehet minden olyan embernek, aki előadást/bemutatót tart számítógép segítségével. Nem a szakmai tartalomról szól, hanem csak a fóliák szerkesztésére, és az elkészült bemutató előadásának módjára tér ki.

Mindenek felett: ne a „buta” számítógép adjon elő! Azt Neked kell megtenned! A számítógép csak egy eszköz, egy segítség, ami bemutatja azokat a dolgokat, amit nem tudsz elmondani: képeket, grafikonokat, videókat. Amikor beszélsz, nyugodtan kapcsold le a kivetítőt.

A fóliák felépítése

  • Nem kell „welcome”, bemutatkozás, stb. oldal. A dokumentum tartalmazhatja ezeket, de az első VETÍTENDŐ fólia az már a tényleges tartalommal kezdődjön (lapozd oda vetítés előtt)! Ha később közzéteszed a dokumentumot, vagy továbbküldöd valakinek, abban az esetben viszont hasznos lehet a bemutatkozó rész.
  • Nem kell „Vége/kérdések/köszönöm” fólia. Ezt elmondod szóban. A „blank screen”/vége után szóban kérdezd meg, hogy van-e kérdés.
  • Alapvetően MINDEN, AMIT SZÓBAN AKARSZ ELMONDANI, azt NE ÍRD LE. Ha mégis leírod, akkor hagyj időd a (közönségnek) elolvasni. De ne legyen FELOLVASÁS! Olvasni mindenki tud…
  • Szöveget minimálisan kell használni. Azokat is inkább felsorolás jelleggel, címszavakban, és azt fejtsd ki nekik majd szóban.
  • Amit nem tudsz elmondani, azokat tedd inkább a fóliákba: képek, grafikonok, videók, ábrák, stb. DE EMELD KI rajtuk, amit mutatni akarsz. Nyíllal megjelölve, bekeretezve, stb. Ne csak egy hatalmas képernyőkép legyen benne.
  • Ha holnap lesz az előadásod, és még nem vagy kész a fóliákkal, akkor nem sok értelme van tovább olvasnod…

Az előadás módja

Te legyél a központban végig – vagyis középen! Ha kell (és van rá lehetőséged), rendezd át úgy a környezetet, hogy ennek megfeleljen.

  • Technikailag minden legyen rendben a vetítéssel, hangosítással. Ha nincs, kérj 5 perc technikai szünetet, és próbáljátok megoldani a problémát. Remélhetőleg ez nem fog előfordulni!
  • Állj szembe a közönséggel, enyhe – váll szélességű – terpeszállásban. Kezed ne fűzd össze sem elöl sem hátul. Használd azokat előadás közben, „gesztikulálj” velük. Legrosszabb esetben elöl tedd egymásba a két tenyeredet, tenyérrel felfelé.
  • Használj mindenképpen „Presentation/Előadói nézet” módot a gépeden. Ez két kijelzős megjelenítés, a kivetítőn megy az előadás, nálad meg a kontroll rész. Ott tudod magadnak ellenőrizni az eltelt időt, az olyan kommenteket, amiket nem tettél a fóliára, de segít az előadásban.
  • Használd a „mute/blank screen” gombot bátran a projektoron (távirányítón) az alábbi esetekben:
    • kezdés előtt, amíg bemutatkozol (Az előadás már legyen előkészítve az első vetítendő fóliával. Ha van „bemutatkozás” azt lapozd el!)
    • ha egy témát hosszabban ki akarsz elemezni/beszélni róla, akkor is, mert ha be van kapcsolva a kép, akkor azt bámulják, és nem RÁD, a mondanivalódra figyelnek. Ha elmondtad, amit akartál, kapcsold vissza.
  • NE FORDÍTS HÁTAT a közönségnek! Ez a LEGFONTOSABB! Ne a falról „olvasd” a dolgokat, hanem fejből add elő (az előtted lévő gépből puskázz, ha szükséges)! Ez csak gyakorlással fog menni.
  • Ha hangzavar, stb. támad (ergo nem figyelnek rád) akkor maradj csendben addig, amíg „észre nem veszik magukat”. Komolyabb „felfordulás” esetén kérd a moderátor segítségét (ha van).
  • Ha „rövidzárlat” lenne, és nem jut eszedbe semmi, nincs gond. Maradj csendben, szedd össze a gondolataidat, és amikor minden OK, folytasd. Senki nem fog „félbeszakítani”. Ha ez 2 perc, akkor 2 perc. Ne kezdj el „köhécselni”, torkot köszörülni, arcokat vágni, mert ez mind-mind a lámpaláz, idegesség jele. Ne „vakargasd” magad!
  • Ne billegj jobbra-balra, ne sétálj (nem vagy te Steve Jobs)!
  • Használj lézer mutatót, ha olyan van, amit külön meg akarsz mutatni.
  • Ne nézd a cipődet, és ne bámuld a kijelzőt! Nézz az emberek szemébe, de folyamatosan pásztázva a közönséget. Ne időzz el a tekintetekben. 6 másodperc „bámulás” után már zavaró a dolog.
  • Kerüld az „ööő”-zést (angolban az „aam”-t). Ha nem megy, akkor gyakorold ennek elhagyását. Legegyszerűbb, ha megkéred a kollégákat, hogy napi beszélgetés közben csapjanak az asztalra egy hatalmasat, amikor ilyet csinálsz. 2 hét alatt teljesen le lehet szokni róla.
  • Ügyelj a beszéd tempójára. Lehetőleg folyamatos legyen, de ne rohand el, mert a végén már levegőt sem fogsz kapni.
  • Készülj az előadásra gyakorlással, és úgy módosítsd azt, hogy a tervezett előadási időbe beleférj. Semmiképpen ne csússz ki az időből! Rövidebb lehet, maximum lesz egy extra kávészünet.
  • Jelölj meg olyan pontokat az előadásodban, ahol feltűnés nélkül ki tudsz szállni. Ha mégis megcsúsznál az idővel, akkor ezeken a helyeken könnyen rövidre tudod zárni az előadást és senkinek nem marad hiányérzete. A kimaradt részeket legfeljebb elolvassák a közzétett prezentáción, vagy leírod valahol.

Nem lehet elégszer ismételni. Gyakorolj! TÖBBSZÖR is! Mindenképpen „közönség” előtt (szomszédok, család, barátok). Segít, ha a fenti dolgokat elmondod nekik, és ők ezt figyelik, jegyzetelnek. Egy üres lapot osszanak félbe függőlegesen, baloldalra írják a pozitív, jobb oldalra a negatív észrevételeket. A végén elemezzétek ki, és ennek figyelembe vételével próbáld újra!

Fontos! A kevesebb mindig több! Nem kell litánia, bekezdésnyi szöveg, csak a lényeg! Ha demózol, akkor azt is gyakorold, nehogy rossz képernyőt tegyél ki a vetítőre. Kapcsold ki a netet ha nem kell, ha igen (online demo), akkor meg tilts le minden értesítőt (pl. Growl), hogy ne zavarjon. Ha két kijelzős módot használsz (laptop+projektor kiterjesztett móddal), akkor elvileg nem gond, mert az értesítések hozzád jönnek, és nem a projektoros képre másznak ki. Nagyon rosszul jön ki, amikor egy „Szia, Édesem” üzenet érkezik, és 1-200 ember olvassa veled együtt.

Remélem tudtam újat mondani. Ha nem, akkor meg már csak gyakorolni kell!

Köszönetnyilvánítás

  • Dr. Demmler Walter
  • Calum Dunderdale
  • Darab Tibor

Palócz Pál

Drupal 7 telepítés

Régen írtam már valami hasznosat és úgy gondoltam, hogy el kéne kezdeni a D7 leírásokat is. Bár elég gyorsan avulnak az infók, talán a telepítési leírások jobban állják a sarat az idő viharában. A D7 magyar nyelvű telepítését kívánom olyanokkal megosztani akik most kezdenek ezzel foglalkozni és nehézségekbe ütköznek valamilyen oknál fogva.

Rengeteg módon hozzáfoghatunk a telepítésnek, én most két verziót fogok bemutatni. A korszerűt és a hagyományos eljárást. A hagyományost csak azért, hogy ha valaki belefutna ilyen módon a honosítási problémába az se essen túlságosan kétségbe.

Tehát a korszerű módszer:
Először is mondjunk köszönetet Hojtsy Gábornak és csapatának akik kidolgozták a módszert.

Aztán menjünk el a http://drupal.org/project/l10n_install weboldalra ahonnan letölthetjük a legfrissebb verziót a telepíteni kívánt drupalunkhoz.

Ezt csomagoljuk ki a hagyományos módon a webszerverünk megfelelő könyvtárába, így létrejön egy majdnem hagyományos drupal könyvtárszerkezet. Ami nem hagyományos benne az az egyszerű halandókat úgysem érdekli, akit mégis érdekel az nézzen be a profiles könyvtárba.

A telepítés szempontjából minket az jobban érdekel, hogy a sites/default/default.settings.php fájlt másoljuk át - NE ÁTNEVEZZÜK! - a sites/default/settings.php fájlba. Ha ez megvan akkor hozzuk létre a sites/default/files könyvtárt és adjunk a könyvtárnak olyan jogosultságot, hogy mindenki tudjon belépni és tudja írni/olvasni. Ha eddig megvagyunk már fél siker.

Írjuk be a címsorba: http://domain_nev.hu/install.php ahol a domain_nev.hu a saját domain nevünk és üssünk entert.

Megjelenik a képernyő ahol kiválaszthatjuk, hogy milyen telepítési módot szeretnénk használni. Ha eddig követtük az utasításokat akkor a Localized Drupal választás a célszerű, hisz azért töltöttük le ezt a profilt.

Miután ezt kiválasztottuk megjelennek a nyelvek, amelyeken a telepítést elvégezhetjük. Én most a magyar nyelvű telepítésről írok, ezért válasszuk a Hungarian (Magyar) rádió gombot és folytassuk a telepítést.

Amikor végez a telepítéssel, kiírja a modulok nevét amikhez letöltötte és betöltötte a nyelvi fordítás fájljait.

A magyar nyelv kiválasztása után már magyarul kommunikál, de ha most továbblépünk akkor láthatjuk, hogy a weboldal is magyarul jelenik meg a böngészőben.

A hagyományos módszer:
Ez sokban hasonlít a modernhez, például a nyelvi fájlok kezeléséhez ugyanazt az l10n_update modult fogjuk használni, csak kicsit másképp. Ez a leírás azoknak szól akik nem ismervén a localization profilt, a D7-et a http://drupal.org/project/drupal oldalról töltötték le és telepítették, illetve azoknak akik adrenalin függők, sok idejük van és nem okoz gondot néhány plusz kattintás.

Tehát az előbb írt webcímről letöltöttük a csomagot, kibontottuk a webszerverre és létrehoztuk a settings.php fájlt és sites/default/files könyvtárt minden joggal. Írjuk be a címsorba: http://domain_nev.hu/install.php ahol a domain_nev.hu a saját domain nevünk és üssünk entert.

Megjelenik a képernyő ahol kiválaszthatjuk, hogy milyen telepítési módot szeretnénk használni. Láthatjuk, hogy az előzővel ellentétben itt NINCS Loalized Drupal opció.

Válasszuk hát a standard módot és kövessük a telepítés folyamatát.

Az angol nyelven kívül itt nem ajánlja fel a többi nyelvet ezzel később kell foglalkoznunk.

Amikor elkészül a telepítés,

akkor töltsük le (http://drupal.org/project/l10n_update) és kapcsoljuk be az l10n_update modult.

Ezután menjünk az admin/config/regional/language/add oldalra és adjuk hozzá a Magyar nyelvet.

Amikor ez megvan akkor a admin/config/regional/language oldalon állítsuk alapértelmezettre a Magyart, mentés után tulajdonképpen kész is vagyunk.

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.

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ő.

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.

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 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á.

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.

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.

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.

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.

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 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:

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.

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.

Drupal 8, 9, 10 telepítése composerrel

Az itt kialakult beszélgetés inspirálta ezt az írást.

Sokaknak gondot okoz kialakítani a local környezetüket úgy, hogy annak szerkeztete megegyezzen az osztott hoszting környezetben lévővel.
Erre a legegyszerűbb megoldás a docker4drupal által biztosított megoldás amit olyanra lehet alakítani amilyen a szerveren van.
Nem fogom oprendszer specifikusan írni, mert a dockert mindegyiken ugyanúgy kell használni. A lényeg, hogy a docker és a docker-compose fel legyen telepítve és el legyen indítva.

Példaként vegyük azt az esetet amikor a hoston az alábbi könyvtárba kerül a drupal:

/var/www/mysite/web

Ebből mi tulajdonképp annyit tudunk, hogy a drupal minden alkotórésze a web mappában van az index.php -vel együtt, semmilyen komponens nem kerül a szülő mappába.

Töltsük le a docker4drupal könyvtárat vagy klónozzuk le git alkalmazással innen:
Docker4Drupal
ha megvan tömörítsük ki ha szükséges.

A projekt létrehozásának a lépései:

  • Hozzunk létre a projektünknek egy d10teszt könyvtárt.
  • Másoljuk be a docker4drupal könyvtárból a docker-compose.yml és .env fájlokat a d10teszt könyvtárba.
  • A másolt .env fájlban állítsuk be a PROJECT_NAME és PROJECT_BASE_URL változókat (a PROJECT_BASE_URL be állított domainen fog az oldal betöltődni)
  • Ha szükséges állítsuk be a php verziót a szerveren használt verzióra.

Lépjünk be a d10teszt könyvtárba és adjuk ki a következő parancsot:

docker-compose up -d

Ez egy csomó mindent letölt és ha minden rendben akkor elindítja a szükséges konténereket. Ha hiba nélkül lefutott akkor beléphetünk a php konténerbe:

docker-compose exec php bash

Most bekerültünk egy virtuális környezetbe ahol használhatjuk a composert a projektünk karbantartására.
Hozzuk létre a projektet:

composer create-project drupal/recommended-project web

Ez a parancs létrehozza a drupal projektet a web mappába.
Sajnos ez a struktúra nem lesz kompatibilis a szerveren lévő struktúrával ezért lépjünk be a web mappába:

cd web

és töröljük a web és vendor könyvtárakat:

rm -rf web vendor

Ezután a composer.json fájlt kell módosítani, hogy ne a web mappába akarjon telepíteni hanem egy szintre telepítse a drupal könyvtárakat és a vendor könyvtárt, mint a szerveren.
Tehát módosítsuk a következőket a composer.json fájlban:

  1. "drupal-scaffold": {
  2. "locations": {
  3. "web-root": "./"
  4. }
  5. },

és az „installer-paths” alatt minden web/ legyen eltávolítva. Itt egy minta csak át kell nevezni json-ra Minta composer file
Ha ez megvan akkor újrainstallálni a drupalt:

composer install -o

Most már a drupal és a vendor egy könyvtárba került.
Szükségünk lesz egy jól működő drush-ra is:

composer require drush/drush

Ha ez is megvan akkor már létrehozhatjuk a drupalunkat:

vendor/bin/drush si --db-url=mysql://drupal:drupal@mariadb/drupal

vagy letölthetjük ftp-n a szerverről és bemásolhatjuk az adatbázissal együtt, így már nem okozhat gondot a szerver szerkezet. Ebben az esetben a composer.json „require” részt ki kell egészíteni a használt modulokkal.

Ha a PROJECT_BASE_URL=testd10.localhost akkor a drupal oldal a http://testd10.localhost:8000 címen lesz elérhető.

Ha nem akar valaki dockert használni, mert van WAMP vagy LAMP a localhostra telepítve akkor is ugyanez a menete onantól, hogy beléptünk a php konténerbe. A site install parancsban módosítani kell az adatbázis adatokat a tényleges adatbázisnévre, felhasználónévre és jelszóra valamint a mariadb helyett localhost kell

vendor/bin/drush si --db-url=mysql://db_user:db_password@localhost/db_name

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 fordítást mindig a localize.drupal.org weboldalról érdemes letölteni, mert ott található meg a legaktuálisabb fordítási állapot.

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-7.1.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. 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égrehajtá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.

Telepítés saját gépre

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.

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

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.

CsatolmányMéret
Kép ikon xampp1.PNG78.1 KB

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:

  • 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.

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.

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.)

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

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.

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 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 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.

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.)

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 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.

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:

UltraWeb

Két alapproblémával kell megküzdeni a telepítéshez. Először is az UltraWeb valamiért egy belső átirányítást használ arra, hogy az index.php fájlnevet nem tartalmazó kéréseket az index.php-re irányítsa, ezért a webcímben átadott paramétereket nem kapja meg. Így a telepítés után bármilyen linkre kattintva továbbra is a honlapot kapjuk. Annak érdekében, hogy az index.php bekerüljön a linkekbe, a következőt keressük meg a common.inc fájlban az url() függvényben:

Cseréljük le a következőre:

Azaz minden esetben legyen benne az index.php a kérés címében.

Ettől kezdve a linkekre kattintva be tudjuk regisztrálni első felhasználónkat és elkezdhetjük beállítani a rendszert. Sajnos a második hiba, amivel találkozni fogunk, az valóban a Drupal hibája. A fordítási állomány feltöltésekor open_basedir hibát kapunk, mert a Drupal a PHP feltöltési könyvtárában próbálja megnyitni a fájlt, amit az UltraWeb beállítása nem enged meg. Amíg ezt a Drupalban nem javítják ki, addig a következőt ajánljuk. Vegyük fel a Magyar nyelvet az add language oldal lenyíló menüjéből, majd kapcsoljuk be (enabled) és állítsuk be azt alapértelmezettnek (default). Ezután töltsük fel a hu.po állományt, és a következő szkriptet az UltraWebes FTP gyökérkönyvtárunkba, és a szkriptet a böngészőből meghívva telepítsük a magyar fordítást:

include_once 'includes/common.inc';
include_once 'includes/locale.inc';
if (file_exists('hu.po')) {
// Drupal 4.5.0 esetén
// $file = 'hu.po';
// Drupal 4.5.1 vagy újabb verzió esetén
$file = (object) array('filepath' => 'hu.po');
_locale_import_po($file, 'hu', 'overwrite');
header('Location: index.php');
exit();
}
echo 'A hu.po nem található!';
?>

Ha minden jól megy, akkor automatikusan visszakerülünk a Drupal rendszerünk kezdőlapjára, ahol a beköszönő oldal már magyarul fog minket üdvözölni. Sajnos a menü továbbra is angol, mert a rendszer nem észlelte az új fordítás feltöltését, és a menü gyorsítótárat nem törölte. A modulok listáján a beállítások mentésével elérhetjük, hogy a menü gyorsítótár törlődjön, és a menüt is magyarul kapjuk meg. A továbbiakban a kiegészítő modulok fordításait hasonlóképpen tudjuk feltölteni, a modul csomagjában kapott hu.po importálásával.

Azt mindenképpen tartsuk észben, hogy mivel a .htaccess állományt nem engedi feltölteni az UltraWeb, a különböző speciális kiterjesztésű (.theme, .module, stb) állományaink nem védettek, azok a webről olvashatóak lesznek.

A cron.php időzített futtatását az Ultraweb adminisztrációs oldalán állíthatjuk be. A szolgáltató 3 időzítést engedélyez, így naponta 3x lehetséges az adatbázis leindexelése.

Rövid webcímek használatára nincs lehetőségünk.

FreeWeb

A FreeWeb rendszerével kapcsolatban sajnos az a tapasztalatunk, hogy olyan mértékben korlátozzák a PHP beállításait, hogy ez nem teszi lehetővé a Drupal életképes futását. A fájl feltöltési méret limit 10k-ra van állítva, azaz a több mint 400k méretű fordítási állomány nem tölthető fel. Ez azt is jelenti, hogy később egy képet vagy PDF állományt sem tudunk majd valamely tartalmunkhoz fűzni, tehát a kilátások nem túl jók. Mégis megpróbálhatjuk a fenti módszert a hu.po feltöltésére és külön szkripttel történő importálására. Akkor azt fogjuk tapasztalni, hogy a FreeWeb rendszeren maximum öt másodpercig futhatnak a PHP szkriptek, ami a fordítás importáláshoz nem elegendő. Ezt a futási limitet programból nem tudjuk állítani.

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.

Ezt az oldalt tervezzük a jövőben bővíteni további tapasztalatokkal, amennyiben azok rendelkezésre állnak. A telepítési problémákat továbbra is a fórumban szerencsés megvitatni, itt az eredmények summás megfogalmazása kaphat helyet.

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 ablakot.
  3. 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-FW-MailID: ide-ird-az-azonositot"; Ezzel a forráskód előkészítésével készen vagyunk.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.

Ehhez a dokumentációhoz csak az ezt bővítő, pontosító, javító hozzászólásokat várunk, más (FreeWeb-hez 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';
    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!
  5. Másoljuk fel a drupalt egy FTP program segítségével az FW-es tárhelyre
  6. 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.
  7. Egy böngészőbe beírva a frissen regisztrált oldalunk címét, máris a telepítő fogad bennünket.
  8. 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.
  9. 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.
  10. 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!
  11. Hozzuk létre az admin felhasználónkat
  12. 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.
  13. Valószínűleg kapni fogunk pár warning-ot miszerint nem tudja futtatni a chmod parancsot, 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.php-re. 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 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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 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.

Í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.

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.

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 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.

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.

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

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.

A felület fordítása magyarra

Bevezető

A magyar Drupal Kézikönyv jelen fejezetében arról lesz szó, hogyan használható ez a tartalomkezelő rendszer magyar nyelven, valamint hogyan lehet hozzájárulni a magyar fordítás teljesebbé tételéhez.

Ez a fejezet azonban nem (vagy csak érintőlegesen) szól a többnyelvű webhelyek létrehozásáról, üzemeltetéséről és más nyelvek Drupal-hoz illesztéséről.

 

Kiknek szól? #

Hogy senkinek se kelljen többet olvasnia, mint amennyire valójában szüksége van/érdekli, ezért e fejezet írásakor 3 külön célcsoportot különböztettünk meg:

  1. Webhely-üzemeltetők: egy Drupal-alapú webhely adminisztrátoraként legfőképpen az érdekli, hogyan tudja a magyar nyelvet telepíteni, beállítani és használni a webhelyén.
  2. Programozók, fejlesztők: saját vagy contrib modulhoz, esetleg a Drupal core-hoz programkód írásával járulnak hozzá, ezért főként az érdekli őket, hogyan lesznek a felhasználói felületen megjelenő szövegeik fordíthatóak.
  3. Fordítók: a fejezet legnagyobb része pedig azoknak szól, akik szeretnének nyelvtudásukkal hozzájárulni a Drupal Magyarországon való mind szélesebb körű terjedéséhez.

 

Webhely-üzemeltetőknek #

Egy webhely magyar nyelven való üzemeltetését is nagyban meghatározza a Drupal főverziója. A 8-as, 7-es, és 6-os alaprendszerekben (core) ugyanis eltérő szinten integrálódott a többnyelvűség támogatása.

Legkönnyebb dolgunk természetesen a vadonatúj 8-as főverzióval van, hiszen új webhely telepítésekor a legelső lépés a kívánt nyelv kiválasztása, innentől kezdve pedig az angol nyelv akár teljesen el is hagyható, mivel a korábbi főverziók szép hagyományát folytatva ennek kiadási napjára elkészült a 100%-os magyar fordítás. A 8-as alaprendszerbe pedig bekerült a korábban csak közösségi (azaz „contrib”) modulként elérhető Localization Update modul is, amely immár automatikusan figyeli a lokalizációs kiszolgálón frissen elérhető fordításokat.

A régebbi 7-es verzió telepítéskor hasonló könnyebbséget jelenthet a Localized Drupal telepítési profil. Ez ugyanis már előre tartalmazza az előbb említett l10n_update modult, ami a 7-es rendszernek még nem része alapértelmezetten. Innentől ugyanúgy automatikusan jelzi, ha az alapcsomag, vagy bármely közösségi modul, smink fordítása frissült, majd pár kattintással telepíthetőek is ezek a fordítási frissítések.

 

Programozóknak, fejlesztőknek #

Bár ez a Kézikönyv-fejezet kifejezetten a Drupal magyar nyelvre fordításáról hivatott szólni, de a fejlesztők számára hasznos lehet megemlíteni két szorosan összefüggő, de jól elkülöníthető területet.

  Többnyelvűsítés Honosítás
Angol név és rövidítés internationalization, i18n localization, l10n
Célja Egy program felkészítése különböző kultúrák eltérő nyelvi igényeinek való megfelelésre. Egy felhasználói felület átültetése a program készítőinek anyanyelvétől eltérő másik nyelvre.
Művelői általában Fejlesztők, programozók Fordítók, nyelvészek
Példák Nem-latin ábécék (pl. székely rovásírás) tárolásának megoldása, Írásirányok (jobbról-balra, fentről-lefelé) Mértékegységek átváltása (pl. angolszász → metrikus, F° → C°, stb.), Hasonlatok, példák lecserélése
Rossz példák hard-coded többes szám E-mail sablonokban “[firstname] [lastname],” megszólítás a magyar szokás helyett.
Munkacsoport a Drupal.org-on Internationalization csoport Translations csoport
Fórum a Drupal.hu-n Többnyelvűsítés topik Honositás topik

A Wikipédia idevágó szócikke számos példát sorol fel a nemzetköziesítés szükségességére. Szintén fejlesztők figyelmébe ajánljuk még a programkódba írt angol karaktersorozatok megfogalmazásához a Drupal Stíluskalauzt angol nyelven.

 

Fordítóknak #

A Kézikönyv-fejezet többi része innentől kizárólag számukra íródott:

Az MDE Honosítási Munkacsoportról

A Drupal tartalomkezelő-rendszer 15 éves történelmének egészen kezdeteitől aktív a magyar felhasználói és fejlesztői közösség. Szórakoztató nosztalgiaként e cikkben röviden áttekintjük a Drupal hazánkba való megérkezésének, valamint az anyanyelvünkre való megtanításának történetét.

Önkéntes fordítóink munkásságának köszönhetően azóta hagyománnyá alakult, hogy az alaprendszereket (core) mindig 100%-osan lefordítjuk, sokszor az első stabil verzió hivatalos kiadásának napjáig. Sok más nyelvtől eltérően mi azonban a core-on kívül számos közösségi modulhoz is teljeskörű magyar fordítást készítettünk el. 45 db Drupal 8-ashoz készült modul, valamint a 20 legtöbbször letöltött és telepített D7-es contrib modul teljes egészében magyar nyelven használható.

Nemzetközi összehasonlításban tehát kiemelkedő a magyar lokalizáció, ami különösen annak fényében ad okot a büszkeségre, hogy nagyobb népességű nemzetekhez (pl. német, spanyol, orosz, stb.) képest arányaiban kevesebb közreműködő érte el mindezt. A localize.drupal.org fordítási platformon a Magyar Honosítási Csapatnak jelenleg 764 tagja van, ebből 199 fordító küldött már be legalább egy fordítást. A csapatnak 9 adminisztrátora van, jelenlegi vezetője pedig Balu Ertl. A Magyar Drupal Egyesület 2014-es megalakulása óta a fordítócsapat e hazai szervezet égisze alatt, annak egyik munkacsoportjaként működik.

 

Elérhetőségeink #

Örömmel fogadunk bármilyen kapcsolatfelvételt számos elérhetőségünk egyikén:

  1. Drupal.hu fórum
    A magyar fordítói csapat fórumot tart fenn a Drupal.hu portálon, melyen a fordítással kapcsolatos beszélgetések, egyeztetések zajlanak. Szintén itt tesszük közzé azokat a híreinket, amelyek nem csupán fordítóknak, de szélesebb közönség figyelmére is érdemesek (pl. ha elkészül egy modul teljes fordítása).
  2. Üzenőfal
    A közös munka nagyrészt a localize.drupal.org platformon szerveződik, amelyen a magyar csapatnak is van egy saját üzenőfala (Team Board menüpont). Ezen nagyrészt már szűkebb közönségnek, a fordítással foglalkozó tagjainknak szóló információkat közlünk (pl. hibajavítási listák).
  3. IRC és Slack
    Mivel még nem született végleges döntés a hazai közösség által egyöntetűen elfogadott csevegőprogramról, ezért az azonnali üzenetküldés terén egyelőre a kettősség van jelen. A magyar fordítóknak külön csatornája van Slack-en (#l10n-hu-forditas), IRC-n pedig a közös magyar csatornán (#drupal.hu) folyik a kommunikáció.
  4. Személyes kapcsolatfelvételi űrlapok
    Mint a Drupal-alapú webhelyeken általában, úgy a drupal.hu és drupal.org felületein is használhatóak a személyes kapcsolatfelvételi űrlapok. Ezek előnye, hogy a címzett e-mail címének ismerete nélkül is beszélgetést kezdeményezhetünk vele, bár a viszontválasz érkezése nem mindig garantált (pl. ha elavult a beállításai között megadott e-mail címe).
  5. Igényfelmérő űrlap új Drupalosoknak
    Hogy a munkát a leghatékonyabban és célratörőbben végezzük, ezért folyamatosan kiváncsiak vagyunk azok véleményére, akik a Drupallal az elmúlt években ismerkedtek meg. Azért éppen az ő véleményük fontos, mert a nemzetközi tapasztalatok azt mutatják, hogy az anyanyelvre lefordított kezelőfelület jobban segíti a tanulási folyamatot. Ezt az elméletet szeretnénk megerősíteni vagy cáfolni a tőlük kapott válaszokkal.
  6. Személyesen
    Mindezek csupán virtuális üzenetek maradnának, ám a közösségi életünk egyik legjobb részét képezik a gyakori rendezvények. A DUG-ok, Sprintek, Camp-ek és Konfok mind kiváló alkalmak a baráti találkozásokra és az eszmecserék élőben való folytatására.

Sok évvel korábban a kommunikáció még levelezőlistán zajlott, és bár néha hasznos lenne visszaolvasni elődeink akkori eszmecseréjét, ennek az archívuma sajnos ma már nem elérhető.

 

Történeti áttekintés #

A nyilvánvalóan sokakat érdeklő „Melyik volt az első magyar Drupal-alapú webhely?” kérdést ma már nehéz pontosan megválaszolni ennyi év távlatából. Annyi azonban bizonyos, hogy mint webes szoftvert, az ezt munkaeszközükként használó hazai programozók szakmai csoportja hozta el Magyarországra és építette fel a 4.3.0-ás verziójával közösségi oldalaikat, mint például a Debian.hu, a Weblabor és a Hungarian Unix Portal, azaz HUP. A magyar fordítás ekkor még nem volt összehangolva, később, a 4.4.0-ás kiadás megjelenésekor még csak a Weblabor által használt modulok voltak magyarul elérhetők. Az ezt követő 4.5.0-hoz azért nem lehetett kész a teljes magyar fordítás, mert még nem voltak véglegesek a sztringek. Az első, bizonyíthatóan 100%-osan magyar nyelven elérhető főverzió tehát a 4.6.0 volt. Az éppen 2006. karácsonyán bejelentett 5.0-rc1 érdekessége pedig az volt, hogy már az első lépéstől fogva lokalizálva lehetett telepíteni Hojtsy Gábor autolocale moduljának köszönhetően.

 

A központi felület története #

Ezekben a kezdeti időkben a közösség által közzétett modulok esetében még a kettősség volt jelen. A népszerű, sokak által használt moduloknál a fordítási fájl általában megtalálható volt a csomagban. A fejlesztés menetéből következően ez azonban mindig csak az eggyel korábbi változat fordítása lehetett, így előfordulhatott, hogy nem volt teljes.

Nagy előrelépés volt tehát a 2009. szeptemberében a localize.drupal.org platform elindítása, mely innentől egyetlen központi helyre gyűjtötte valamennyi nyelv addig szervezetlenül közzétett fordításait. Ekkor, az l.d.o-ra költözésünk idején a Drupal alaprendszer (core) 5 és 6 voltak a támogatott főverziók, így ezeknek 5.19-es és 6.13-as kiadásai jelenleg a legkorábbiak, melyek 100%-os magyar fordítása innen elérhető. Utódaik, a 2011-es 7.0 és a 2015-ös 8.0 pedig már „bennszülöttként” az l.d.o-ra érkeztek, így ezeknek már nem csak a végleges kiadásuk, hanem az azt megelőző alfa- és béta-verzióik is itt követhetőek nyomon.

Bekapcsolódás a fordításba

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ó szöveg. Ezen az oldalon szedtük össze azokat a reményeink szerint hasznos tudnivalókat azoknak, akik szeretnének közreműködni a Drupal felületének magyarra fordításában.

 

Mi hasznom van belőle, ha fordítok? #

  • Hozzájárulási lehetőség a Drupalhoz más szakmai területekről
    Tény, hogy a milliós nemzetközi Drupal-közösség többsége programozó-fejlesztő, ám egy nagy része számos további szakterület felől érkezik. Ők ugyanúgy szeretnének beleadni valamit a közösbe, de programozás helyett más módokon tudják támogatni a projekt törekvéseit. A dokumentáció-írás, újonc-mentorálás, rendezvényszervezés mellett ilyen például a honosítás is.
  • Nyelvgyakorlás a valós életben
    Sok nyelvtanuló keresi a lehetőséget, hogy frissen szerzett tudását tankönyvi példamondatokon túl is kipróbálhassa. Az angol forrásszövegek értelmezése, boncolgatása, majd másik nyelvre való átültetése kiváló módja az írott idegennyelv-értési és fogalmazási készségek fejlesztésének. Az esetleg hibás beküldéseknek sincs tétje, hiszen a rutinos adminisztrátorok még időben jelzik, sőt, néhányan indoklással kísért javaslatot is tesznek a hiba javítására.
  • Segít jobban megérteni a Drupal modulok belső működését
    Az „Egy modult teljesre” irányelvünk szerint dolgozó fordító szeme előtt csak tematikusan egymáshoz kapcsolódó szövegek jelennek meg, ami nagyban segíti a köztük lévő összefüggések felismerését. Ezáltal egy modul készre fordításának végén a fordító már alapos képet kaphat az adott program működéséről, funkcionalitásáról, beállítási lehetőségeiről – majdnem mintha már használta is volna.
  • Egy nyitott, befogadó baráti társaság vár
    A Drupal nemzetközi közösségének alapvető hitvallása a nyitottság és befogadás, ami nem csak üres szólam, de jól érzékelhető a gyakorlatban is. Nincs ez másképp a hazai résztvevőkkel sem: bár az évtizedes múltú tagjaink közötti barátságok elsőre talán a bennfenntesség téves látszatát kelthetik, valójában minden érdeklődőt ugyanúgy segítünk bekapcsolódni mind a kötetlen hangulatú társasági életünkbe, mind pedig a közös munkába.

 

Szükséges feltételek #

  1. Alapfokú angol nyelvismeret
    A Drupal egy nemzetközi mozgalom, amelynek nemcsak elsődleges érintkezési nyelve az angol, de a honosítás kizárólagos forrásnyelve is egyben. Az alaprendszer (másképpen „core”) és valamennyi, több tízezer közösségi (azaz „contrib”) modul sztringjeit csak angolról lehet más nyelvekre, így magyarra is fordítani. Ehhez azonban nem szükséges kiemelkedően magas nyelvismeret: az adminisztrátorok bármikor örömmel segítenek a kezdő angol-beszélőknek is sikerélményt nyújtó fordítási feladat megtalálásában.
  2. Felsőfokú magyar nyelvismeret
    Nem kimondott elvárás a magyar anyanyelvűség, ám ahogy Irányelveinknél írtuk, mindig törekszünk a legmagasabb szintű nyelvhelyességi színvonalon, műszakilag pedig a lehető legpontosabban fogalmazni.
  3. Drupal.org felhasználói fiók
    Mivel a magyar felület fordítási munkái a localize.drupal.org által biztosított infrastruktúrán zajlanak, ezért a résztvevőknek felhasználói azonosítóval kell rendelkezniük a Drupal.org-on. A felhasználói regisztrációt követően átlépve a localize.drupal.org aloldalra ez a felhasználói azonosító automatikusan létrejön.
  4. Csatlakozás a Magyar Honosítási Csapathoz
    Hogy ne csak a már létező fordításokat lehessen böngészni, hanem új fordítási javaslatokat is be lehessen küldeni, csatlakozni kell az adott nyelv csapatához. A magyar csapat oldalán ezt a jobb oldalsáv felső dobozában lévő nagy zöld „Join” gombbal lehet megtenni. Nálunk a tagság azonnal létrejön, néhány más nyelvvel ellentétben nincs szükség adminisztrátori elfogadásra.

A részvétellel kapcsolatban bármikor szívesen segítünk Elérhetőségeink valamelyikén.

 

Javasolt eszközök #

Míg az előző lépések elvégzése kötelező a közös munkához való csatlakozáshoz, addig az alábbiakban felsorolunk pár, eddig hasznosnak bizonyult eszközt és forrást, amit jó szívvel ajánlunk újonnan csatlakozó tagjaink figyelmébe is.

 

Szövegszerkesztő #

Bár a már említett localize.drupal.org felületen is nagyszerűen lehet dolgozni, néha előfordulhat, hogy például internetkapcsolat nékül, azaz offline szeretnénk fordítani. A később ismertetett .po fájlokat könnyedén módosíthatjuk egy egyszerű, sima szövegszerkesztő programmal, amelyek szinte valamennyi korszerű operációs rendszeren előtelepítve megtalálhatók: Windows-on a Jegyzettömb (Notepad), Mac OS X-en a TextEdit, stb. Fontos, hogy támogassa a Unicode (ejtsd „junikód”) karakterkészlet UTF-8 karakterkódolását, amivel teljes mértékben kiküszöbölhetők ékezetes karaktereink megjelenítési problémái.

A Microsoft Word, LibreOffice Writer és más dokumentum-szerkesztők azért nem javasoltak, mert a szövegfájlokba felesleges információt ágyazhatnak kéretlenül, ami megzavarja a fordítási fájl beimportálásakor az értelmezőt. Az automatikus helyesírás-ellenőrzésről azonban így sem kell lemondanunk, néhány fejlettebb plain text editor (pl. Notepad++, TextWrangler, Sublime Text stb.) is képes ezt gépelés közben végezni, ami sok esetben javíthatja a beküldött fordítások nyelvhelyességi színvonalát.

 

Fordítástámogató szerkesztő #

Kényelmi-gyakorlati szempontok miatt sokan szeretik e .po fájlokat egy specializáltabb szerkesztőben írni, ami további funkciókkal segíti a fordítási munkát. A két legelterjedtebb ilyen program a Lokalize és a poEdit.

 

Szószedet ─ Drupalé #

Az évek alatt kialakult, már elfogadottá vált szavakat, kifejezéseket, mondatokat a honosítási csapat egy angol–magyar Szójegyzékben gyűjtötte össze, amely wiki alapú, így bárki szerkesztheti. Esetenként további indoklás is olvasható a döntésünk alátámasztására.

 

Szószedet ─ Más szoftverekéi #

A Drupalt soha nem önmagában látja majd a felhasználó, hanem más szoftverekbe ágyazva (pl. operációs rendszer, böngésző, stb.), ezért fontos, hogy egy adott nyelven koherens felhasználói élményt (User experience, UX) nyújtson a magyarra lefordított felület. Képzeljük csak el, milyen zavaró lehet egy kevésbé hozzáértő személy számára, ha például a Windows honlapnak, a Chrome pedig weboldalnak nevezi azt, amit a Drupal webhelynek. Az ilyen helyzetek elkerülése érdekében igyekszünk szóhasználatunkban alkalmazkodni más magyar fordítói közösségek kifejezéseihez:

Linuxmegszűnt Mozilla (Transvision) Mozilla (Pontoon) Microsoft ProZ (általános IT)

 

Böngésző-kiegészítők #

Sok esetben azonban hasznos lehet a már beküldött fordításokban is rákeresni egy adott kifejezésre a biztosan egységes szóhasználat érdekében. Ehhez készített aries egy keresőplugint, amellyel az OpenSearch módot támogató böngészőkben (Mozilla Firefox 43-mal és Google Chrome 47-tel tesztelve, elvileg Internet Explorer 7-el és 8-cal is működik) a hagyományos keresőknél megszokott módon lehet a localize.drupal.org magyar fordításai között keresni.

Tipp: az egyes beépülőkhöz kulcsszavakat is lehet rendelni, így a böngésző címsorába beírva például az „ldo machine-readable name” kifejezést, a keresés egyből a találati listára vihet.

Az Opera is támogatja a saját keresőmotorok megadását, egyelőre azonban nem ismeri az OpenSearch módot. A böngésző Haladó beállításainál, a Keresőmotor létrehozása résznél a

http://localize.drupal.org/translate/languages/hu/translate?project=&status=2&release=all&search=%s&context=all&limit=10
címet kell megadni a használatához. További segítség az Opera keresőkről szóló fejezetében található.

 

Egy szabadon használható Drupal-telepítés #

A Drupal fordítása során gyakran előforduló nehézség a szövegkörnyezet (kontextus) hiánya, amitől sokszor függne, hogy egy sztring melyik jelentését használjuk több kínálkozó közül. Az ilyen esetekben nagy segítség, ha a fordító ki tudja keresni az adott sztringet egy telepített Drupal felhasználói felületén vagy forráskódjából. Mivel egyes szövegek csak körültekintést igénylő műveletek (pl. tartalmak törlése, felhasználók kitiltása, webhelyszintű konfiguráció megváltoztatása, stb.) után jelennek meg, ezért tanácsos, ha az adott Drupal telepítésen belül a fordító szabadon mozoghat, véletlen károkozás veszélye nélkül. Egy modul korábbi főverzióhoz tartozó kiadásának fordításakor pedig kifejezetten régi Drupal-telepítésre lehet szükség. A Kézikönyv telepítéséről szóló fejezetében olvasható lehetőségek közül e célra kiválóan megfelel akár a Simplytest.me szolgáltatásnál elérhető ideiglenes, valamint persze a régóta jól bevált helyi gépen (azaz „localhost”-on) való telepítés.

 

Kié lesz a beküldött fordításaim szerzői joga? #

Teljesen jogosan merülhet fel a kérdés minden közreműködő részéről, hogy miután fordítási javaslatát beküldte, s az adminisztrátori elfogadást követően fordítássá vált, kinek a nevéhez fog fűződni annak szerzői joga? Mivel a közösségi fordítások a Drupal.org aloldalán, a localize.drupal.org-on vannak közzétéve, ezért arra is ugyanaz a jogi kitétel vonatkozik: minden innen elérhető fordítás a GNU General Public licenc (GPL) második kiadása (v2) szerint használható fel. A licenc eredeti angol nyelven a GNU webhelyén, míg egy nem-hivatalos magyar fordítás Dr. Dudás Eszter szoftverjogász jóvoltából a webhelyén érhető el.

Fordítási irányelveink

Ahhoz, hogy a több mint kétszáz, egymástól mind földrajzilag távol, mind pedig időben eltolva dolgozó fordító munkájának gyümölcse mégis egységes és következetes képet nyújtson a Drupal-alapú webhelyek látogatói számára, fontos, hogy összehangoljuk, mit mire és hogyan fordítunk magyarul. Ebben a fejezetben ezeket a szempontokat foglaljuk össze.

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.

 

Nyelvhelyesség #

Meggyőződésünk, hogy nem csak szépirodalmi, de műszaki szövegek is lehetnek magas nyelvi igényességgel megfogalmazva, ezáltal kellemes olvasási élményt nyújthatnak a befogadónak. Éppen ezért a magyar nyelv jelenkori szabályait és megszokásait mindig igyekszünk szem előtt tartani.

Nyelvhelyességi kérdésekben természetesen „A magyar helyesírás szabályai” kötet ma már digitális formában is elérhető kiadását tekintjük mérvadónak. Az MTA SZTAKI az e könyvben megfogalmazott szabályokon alapuló automatikus online tanácsadó eszközt készített, ám informatikai szakszövegek fordításához ez nem mindig nyújt kielégítő segítséget.

 

Módszertan #

A szabadszoftverek (mint amilyen a Drupal is) magyarországi népszerűsítéséért dolgozó FSF.hu alapítvány részéről Koblinger Egmont és Tímár András egy általános útmutatót, míg Daczi László egy Fordítás HOGYAN leírást készített a Magyar Linux Dokumentációs Projekt számára. Ez utóbbinak egy némileg bővebb kiadását tette közzé Kéménczy Kálmán és Kelemen Gábor a HUP-on. Bár ezen dokumentumok évtizedes múltra tekintenek vissza, a bennük lefektetett alapszabályok és javasolt jótanácsok mind a mai napig helytállóak, a korábbi Drupal-fordítók is nagyrészt az általuk kitaposott ösvényeken haladtak, ezért jelen Kézikönyv-fejezet is nagyban támaszkodik e munkákra. Bár kötelező olvasmányként nem írhatjuk elő őket, de jó szívvel ajánljuk mindenkinek, akit behatóbban érdekelnek a szabadszoftverek magyarra való átültetésének irányelvei.

Teljességre törekvés

Sokan szeretünk könnyen eredményt elérni, ezért nem meglepő, hogy a minél rövidebb sztringeket fordítjuk le a legszívesebben. A modulok azonban vegyesen tartalmaznak hosszú, több bekezdéses súgóleírásokat és rövid, egyszavas gombfeliratokat is. Aki viszont telepíti a modult, értelemszerűen szeretné, ha az egészében magyarul jelenne meg, nem csak itt-ott véletlenszerűen.

Éppen ezért az elmúlt években bevezettük az „Egy modult teljesre” irányelvünket, amire ezúton kérünk minden közreműködőt. Nem nehéz, csupán rá kell szűrni az l.d.o felületén a kívánt modul nevére. Nem gond, ha nem fűlik a fogunk a hosszú szövegekhez, csak jelezzük egy adminisztrátornak, hogy: „Figyi, a Pathauto 8.x-1.0-hoz megcsináltam, amit tudtam, de hátra vannak még a hosszúak, tudj róla”. Innentől már át tudja venni a stafétát valaki más.

Csak egy főverziót

Mint sok más közösségi projektben, a Drupal honosításában is önkéntesek vesznek részt. Éppen ezért különösen fontos, hogy kevés szabadidőnket a lehető legcélratörőbben hasznosítsuk. Ennek egyik módja, hogy az l.d.o felületén mindig rászűrünk egy adott modulra és annak legutolsó kiadásának verziószámára. Így biztosítható, hogy a belefektetett munka a lehető leghosszabb időtávlatban fog hasznot hajtani másoknak.

Hasonló vonatkozik az évek alatt felgyűlt javaslatok elfogadására is: a „Csak a támogatott főverzióit” elv szellemében az adminisztrátorok már csak a D9-es alaprendszerekre is elérhető sztringek javaslatait nézik át, mivel a D8-as és azelőttiek napjai sajnos már meg vannak számlálva…

 

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 könyvekben előszeretettel használt többesszám első személyű megközelítés használata. Végül ez utó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. Pár példa ennek érzékeltetésére:

Tegező: Biztosan törölni szeretnéd a blokkot?

Magázó: Biztosan törölni szeretné a blokkot?

T/1: Biztosan törölni szeretnénk a blokkot?

Magyar Drupal: Biztosan törölhető a blokk?

A megszemélyesítés elkerülése vonatkozik a felhasználóra és a kiszolgálóra, a programra egyaránt, ezért a megszólítást (tegezés/magázás) és a személyes toldalékokat is kerüljük. 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, ezért 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 változó 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

A Drupal alapértelmezett három különböző hosszúságú dátumformátumát így honosítjuk:
Megnevezés Megadás PHP-ban Eredményezett kimenet
Rövid Y. m. d. H.i 2016. 10. 28. 14.21
Közepes Y. F j. H.i 2016. október 28. 14.21
Hosszú Y. F j., l H.i 2016. október 28., csütörtök 14.21

A Drupal nyelvezetére az érzelmi semlegesség is jellemző, amire az alábbi példa szolgál:

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.

Másképpen megfogalmazva: Drupalt használni egy lehetőség, ezért soha nem utasítjuk a felhasználót egy művelet elvégzésére.

A közösségi (azaz „contrib”) modulok nevét nem fordítjuk, helyette az angol eredeti nevet írjuk dőlten (<em> elemmel):

Helytelen: Az Entitás API modul kibővíthető a Hivatkozó Link engedélyezésével.

Magyar Drupal: Az Entity API kibővíthető a Reference Link engedélyezésével.

E szabály alól kivétel, ha a sztring önmagában csak a modulnév (azaz nincs nyelvtani szerkezetbe foglalva), vagy feltételezhetően olyan környezetben jelenik majd meg, ahol a HTML-formázás nem megengedett (például menüpont lesz).

 

Gyakran kijavított hibák #

  • Modulok nevét soha nem fordítjuk le. Ennek oka, hogy nagyobb bonyodalmat okozna, mintsem segítené a tájékozódást.
  • A változók, függvények és adatbázistáblák neve <code> formázással érthetőbbé tehető.
  • A változók nevének elgépelése helytelen megjelenítést eredményezhet. (A változók neve kisbetű-nagybetű érzékeny.)
  • A nemzetközi védjegyoltalom alá tartozó márkanevek pontos írásmódja (pl. JavaScript, jQuery, MySQL, stb.) fontos, mert tulajdonosaik érzékenyek lehetnek rá.
  • A menüpontok és engedélyek megnevezését be kell helyettesíteni a (valószínűleg) már lefordítottal. Keress rá a sztringre l.d.o-n!
  • Az „amennyiben” kötőszóként való használata sajnos nagyon elterjedt, de ettől még helytelen.

 

Tipográfia #

Az interneten már általános szabványnak tekinthető, így a Drupal által is használt Unicode karakterkészlet UTF-8-as karakterkódolása szerencsére számos kiegészítő írásjel biztonságos megjelenítését is lehetővé teszi. Ezek ésszerű használata a kész szöveg esztétikáját, jobb érthetőségét, a nyomdászati hagyományok előtti tisztelgést is szolgálják. Gyakran kijavított további hibák:

  • A magyar nyelv „alsó-felső” idézőjeleket használ.
  • A [VALAMI] mozaikszó, ezért csupa nagybetűvel írandó.
  • A felhozott példák „magyar idézőjelek” között érthetőbbé tehetők.
  • Sokszor jobb az angol eredeti mondatzáró írásjelénél maradni.
  • Az indokolatlan rövidítéseket (de nem a mozaikszavakat!) ki szoktuk írni teljesen.

 

Közösen döntünk #

Előfordul, hogy több lehetőség közül nem mindig a megfelelő fordítást választjuk, vagy nem találjuk meg az alkalmas magyar fordítást egyes angol fordulatokhoz, kifejezésekhez. Lehet, 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 szóhasználatunk. Az ilyen hibákkal kapcsolatos jelentéseket is szívesen látjuk. Mindig szívesen fogadunk azonban új ötleteket, javaslatokat a fordítással kapcsolatban számos Elérhetőségünk bármelyikén.

Gyakran ismételt kérdések a fordításhoz

Ezen az oldalon gyűjtöttük össze azokat a sokakat érdeklő kérdéseket, amelyeket már többször feltettek a magyar Drupallal kapcsolatban.

 

 

Mit jelentenek ezek a rövidítések: i18n, l10n?

A számokat tartalmazó rövidítések numeronímiák (lásd a Wikipédia szócikkét angolul), a számok bennük pedig azt jelentik, hogy első és utolsó betűjük között hány másik betű áll még. Jelentésük az angol internationalization (értsd: nemzetköziesítés) és localization (értsd: honosítás) kifejezéseket takarják, melyekről bővebben e Kézikönyv-fejezet Bevezetőjében olvashatsz.

 

Miért mondotok mindig honosítást fordítás helyett?

Azért, mert a két fogalom nem egyenértékű, ezért nem is illik egymás szinonímájaként használni őket. Míg a fordítás szűkebb értelemben véve csak a forrásszöveg szavainak, mondatainak célnyelvre való átültetését jelenti, addig a honosítás ennél tágabban igyekszik az eredeti jelentést átadni. Beletartozhat a mértékegységek (pl. °Celsius és Fahrenheit, angolszász és metrikus, stb.) átszámítása, pénznemek körülbelüli átváltása, a felhozott példák, hasonlatok helyiekre cserélése, ezekkel ugyanis nagyban megkönnyíthető a befogadó számára az eredeti üzenet értelmezése, noha valóban nem betűhűen azt olvassa, amit az eredeti szerző írt.

 

Szeretnék én is Drupalt fordítani. Mit tegyek?

Örömmel halljuk a jó hírt! :) Először is lépj bátran kapcsolatba velünk számos elérhetőségünk bármelyikén, szívesen hallanánk rólad. Azt követően pedig ajánljuk figyelmedbe a Bekapcsolódás oldalt. A többi pedig jön majd magától, meglátod.

 

Mikor válhatok adminisztrátorrá?

Erre nincsenek kőbe vésett szabályaink, de az eddigi gyakorlatunk alapján általában az 1000 elfogadott fordítás után szoktuk felkérni társunkat, érdekelné-e esetleg a többiek munkájának felügyelete. Ám mint sok más munkaközösségben, a magasabb jogosultság nem nagyobb hatalmat, hanem komolyabb felelősséget jelent elsősorban.

 

Egy ügyfelemnek magyarul kell egy contrib modul. Mikor lesz kész a fordítása?

A Drupal van, akinek szórakoztató hobbi és van, akinek kenyérkereső megélhetés ─ és ez így is van jól. Kis alkalmazkodással azonban mindenki elégedett lehet: a fordítóknak fontos, hogy munkájuk gyümölcsét minél többen hasznosíthassák, ezért örömmel fogadunk bármikor konkrét kérést egy adott közösségi modul teljes magyarra fordítására. Ugyanakkor szíves megértésed kérjük, hogy nem tudunk rá fix határidőt vállalni, mivel itt is mindenki a ráérő szabadidejét hasznosítja a köz javára. Bátran keress meg egy Adminisztrátort a kéréseddel, biztos meg fogtok tudni állapodni.

 

Nem tetszenek bizonyos kifejezések, amiket használtok. Át tudom írni magamnak?

Igen. A Drupal 8 fejlett többnyelvűsítési képességei lehetővé teszik, hogy a webhelyek üzemeltetői bármely szöveget saját szájuk íze szerint fordítsák le, ebbéli döntésüket pedig az l10n_update modul is tiszteletben tartja: az így testreszabott kifejezéseket ezután már nem írja felül az elérhető fordítások következő frissítésekor.

 

Ki az a Multiple contributors nevű ember? És miért van neki ilyen sok fordítása?

Az l.d.o dicsőségtábláját a kezdetek kezdete óta ez a bizonyos név vezeti, ez azonban nem egy élő, valódi személyt takar, hanem annak idején e virtuális becenévhez lettek rendelve azok a fordítások, amelyeknek eredeti szerzői nem voltak ismertek.

Frissítés újabb verzióra

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, 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.

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:

// Kapcsolat felepitese
$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.

// Drupalhu klonozas
$tables = mysql_list_tables("drupalhu", $conn);
while ($r = mysql_fetch_row($tables)) {
$c = mysql_fetch_row(mysql_query("SHOW CREATE TABLE drupalhu.$r[0]", $conn));
mysql_query(preg_replace("!CREATE TABLE `([^`]+)`!", "CREATE TABLE ujdrupalhu.\\1", $c[1]), $conn);
mysql_query("INSERT INTO ujdrupalhu.$r[0] SELECT * FROM drupalhu.$r[0]", $conn);
}
?>

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.

// Felesleges dolgok az adatbazisban
mysql_query("DELETE FROM ujdrupalhu.cache", $conn);
mysql_query("DELETE FROM ujdrupalhu.locales_source", $conn);
mysql_query("DELETE FROM ujdrupalhu.locales_target", $conn);
// Korabban hasznalt, de mar nem alkalmazott modulok torlese
mysql_query("DELETE FROM ujdrupalhu.system WHERE name in ('weblink', 'trstatus')", $conn);
// A simplelinks a weblink helyettesitoje
mysql_query("INSERT INTO ujdrupalhu.system (filename, name, type, status)
VALUES ('modules/simplelinks/simplelinks.module', 'simplelinks', 'module', 1)", $conn);
?>

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 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:

if (version_compare(mysql_get_server_info(), '4.1.0', '>=') && !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:

db_query("DELETE FROM {cache}");
?>

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.

Drupal 8 kézikönyv lefordítása

Az alábbiakban egy remélhetőleg hasznos összefoglalót kívánunk nyújtani mindazoknak, akik szívesen becsatlakoznának a Drupal 8 Kézikönyv magyarra való lefordításának közös munkálataiba. Ezen az oldalon egy rövid ismertetést nyújtunk a projektről, de két további aloldalon találhatóak még részletek: 1. AsciiDoc szintaxis és 2. Hasznos linkek.
 


Frissítés: a Kézikönyv fordítása elkészült. Az ezen az oldalon alább leírtak már csak történelmi, archiválási célokat szolgálnak.


Bekapcsolódás a közös munkába

  1. Jelentkezz be a FreeTM.com-on. Ha korábban már használtad, akkor ugorj a következő pontra.
     

  2. Ha még nincs FreeTM-fiókod, akkor regisztrálj. Ezután pár kezdeti beállítás elvégzésével elő kell készítened a felületet a munkához. A legelső bejelentkezéskor az alábbi nyitóképernyő fogad:
    Képernyőkép a célnyelv nyelvkódjának beállításáról
    Kezdd el gépelni a „HU” szót, majd a legördülő listából válaszd a sima HU-t, ne a HU-HU-t. A párbeszédablak leokézása után az (egyelőre még üres) fájllistádat látod.
     

  3. Az előző képernyő alsóbb bekezdései arról tájékoztattak, hogy automatikusan be lesz kapcsolva az IATE szószedet és a gépi fordítás (Machine Translation, azaz MT). Nekünk azonban ezekre most nem lesz szükségünk, ezért az egyszerűség kedvéért kikapcsoljuk őket. Ehhez a WordFast Anywhere menü > Setup ikon > General fül > Setup Machine Translation opció > MyMemory fül > Use MyMemory jelölőnégyzetből vegyük ki a pipát. Képernyőkép a Machine Translation (MT) letiltásáról
     

  4. A buta gépi fordítás (MT) után most következik az intelligens fordítási memória (TM) beállítása. Bár e két rövidítés hasonló, ám nagy minőségi különbség van köztük! Vedd fel velünk a kapcsolatot az MDE Honosítási Munkacsoport elérhetőségeinek bármelyikén, hogy egy adminisztrátor (valószínűleg balagan) megoszthassa veled FreeTM-en a közös d8mem (ez a Drupal 8 teljes UI-ának lefordított sztringjei) és a d8ug (ez pedig a Kézikönyv többiek által már beküldött) fordítási memóriáinkat.
     

  5. A fordítási memóriák kezeléséhez nem lehet üres a fájllistánk, ezért először létre kell hoznunk valamit átmenetileg. Erre a célra nekünk most tökéletesen megfelel a fájlfeltöltési párbeszédpanelen előre kitöltött http://www.freetm.com/doc/ipad_sample.doc fájl. Az Upload and Open gombra kattintva azonnal meg is nyílik a fájl szerkesztésre.
    Képernyőkép egy átmeneti fájl létrehozásáról
     

  6. Ekkor aktívvá válik a TMs & Glossaries fül > Setup gomb opció, amivel megnyitható a konfigurációs párbeszédpanel, melyen két oszlopot látunk: a bal oldalin a fordítási memóriák (röviden TM-ek), míg a jobb oldalin a szójegyzékek vannak felsorolva.
    Képernyőkép az IATE szójegyzék letiltásáról és eltávolításáról
    Az IATE az Európai Unió hivatalos nyelvei közötti fordítást segíti, de nem az informatikai zsargon a szakterülete, ezért ezt a szótárat most nyugodtan törölhetjük.
     

  7. Végezetül pedig ha hozzáférést kaptunk a fentebb említett d8mem és d8ug fordítási memóriákhoz, akkor az alábbiak szerint állítsuk be őket.
    Képernyőkép a D8 Kézikönyv projekt által használt TM-ek és szószedetek beállításáról
    Ha végeztünk a TM-ek és szójegyzékek beállításával, akkor az átmeneti fájlt akár törölhetjük is, többé már nincs rá szükség.
     

  8. Ha már készen áll a FreeTM-felületed, kezdődhet a fordítás!
     

  9. Jelentkezz be a Drupal.org-on. Ha még nincs felhasználói fiókod, regisztrálj.
     

  10. Válassz magadnak egy témakört erről a listáról, amit le szeretnél fordítani.
     

  11. Vedd magadhoz a kiválasztott issue-t, hogy a neveden legyen. Erről bővebben az angol nyelvű Section 1.1.5, Detailed instructions: Claiming and dropping tasks fejezetben olvashatsz.
     

  12. A Drupal.org-ról másold vágólapra a kiválasztott témaköröd forrásfájlának útvonalát.
    Képernyőkép a forrásfájl útvonalának kimásolásáról
     

  13. A FreeTM-en a File > Upload > From URL útvonalon illeszd be a forrásfájl előbb kimásolt útvonalát, majd az Upload and Open gombra kattintva azonnal meg is nyílik a fájl szerkesztésre.
    Képernyőkép a forrásfájl útvonalának bemásolásáról
     

  14. Kezdd el lefordítani a fájlt a Start/Next gomb léptetésével. Amikor egyezést talál a fordítási memóriából (a képen zölddel jelölve), akkor automatikusan behelyettesíti, és ugorhatsz tovább. Képernyőkép a FreeTM felületének használatáról fordítás közben
    A képen pirossal jelölt AsciiDoc-kódokat hagyd ki, nyugodtan ugord át.
     

  15. Ha elkészültél, töltsd le a magyar fájlt a gépedre.
     

  16. Nyiss egy új Google Docs szöveges dokumentumot és másold be a teljes magyar fordításodat. Állítsd az elérhetőségét bárki a link birtokában kommentelhet-re.
     

  17. Menj vissza a témaköröd issue-jára a d.org-on és egy új hozzászólásban oszd meg a Google Docs-linket, valamint állítsd át az issue állapotát Active-ról Needs Review-ra.
     

  18. Értesítsd a többieket a Slack #d8ug-devstaging csatornáján, hogy nézzék át és véleményezzék a fordításodat a megadott Google Docs-linken.
     

Ez a cikk az angol nyelvű Fordítási Kézikönyv 1.1.3 Quick Start Guide - Translating Tasks fejezetének és balagan Using freetm.com to translate the user guide for drupal 8 blogbejegyzésének fordítása alapján készült.

Az AsciiDoc forrásfájlokról

 

 

 


Frissítés: a Kézikönyv fordítása elkészült. Az ezen az oldalon alább leírtak már csak történelmi, archiválási célokat szolgálnak.


Hogyan néz ki egy átlagos forrásfájl?

A könnyebb áttekintés kedvéért képzeletben tagoljuk 3 részre:

Fejléc

  1. Fájlazonosító (ID), ami muszáj, hogy a legelső sora legyen a fájlnak, különben az összeszerelő szkript nem találja meg:
    [[pelda-fajlazonosito]]

  2. Ezt követi a fájl címe, ami
    === Fogalom: Ennek a példafájlnak ez a címe

Fő tartalom

Lezárás

  1. Közreműködő személyek felsorolása
    Először egy cím:
    *Közreműködők*

  2. Majd pedig az adott témakör angol eredeti szerzői és szerkesztőinek neve a D.org profiljukra linkelve:
    Írta és szerkesztette: https://www.drupal.org/u/peldaszemely[Személy Neve]

További gyakran előforduló szerkezetek

Bár a fordítási memória használata sok terhet levesz a vállunkról és segít egységesebb külalakot biztosítani a száznál is több forrásfájl között, ám mindenre az sem képes. Ezért az alábbiakban gyűjtöttem össze olyan gyakran visszatérő szerkezeteket, amelyeket az angol eredeti változat szerzői is rendszeresen használtak, így nekünk is érdemes egységesen kezelnünk őket:

  1. Hivatkozás közösségi dokumentációra

    A témakörök végefelé gyakran van utalás olyan szócikkekre, ahol az Olvasó bővebb, részletesebb, általánosabb ismereteket szerezhet az adott témáról.



    * https://www.drupal.org/documentation/backup[_Drupal.org_ community documentation page "Backing up a site"]

    Ezt mi leggyakrabban így szoktuk fordítani:



    * https://www.drupal.org/documentation/backup[Backing up a site] (azaz „Webhelyünk lementése”) című közösségi dokumentáció a Drupal.org-on angol nyelven.

     

  2. Közösségi dokumentáció szerzői joga

    Azoknál a témaköröknél, ahol a szerzők a D.org leírásait emelték át a D8 kézikönyvbe, ott mindig kötelezően fel van tüntetve mindez. Így néz ki az eredeti például:



    Adapted by https://www.drupal.org/u/batigolix[Boris Doesborg] from https://www.drupal.org/node/1577752["View modes"], copyright 2000-2016 by the individual contributors to the https://www.drupal.org/documentation[Drupal Community Documentation].

    Ezt mi így tudnánk nagyjából lefordítani:

    E témakör szövegét https://www.drupal.org/u/diana.lakatos[Diána Lakatos] a Drupal közösségi https://www.drupal.org/documentation[dokumentációjának] https://www.drupal.org/getting-started/admin/reports[Reports] (azaz „Jelentések”) című szócikkéből vette át, melynek szerzői joga 2000-2016 között annak egyéni közreműködőié.

     

  3. Fordító személy (és cégének) feltüntetése

    Végül pedig a témakör magyar fordítójának neve a D.org profiljára linkelve:



    Fordította: https://www.drupal.org/u/peldaszemely[Személy Neve]

    A projekt etikettje megengedi igény esetén a közreműködő személy szervezetének feltüntetését is, opcionálisan a cég D.org-os profiloldalára linkelve:

    Fordította: https://www.drupal.org/u/peldaszemely[Személy Neve]
    (https://www.drupal.org/brainsum[Brainsum]).


     

  4. Menüútvonalaknál használt szimbólum

    Sima kacsacsőrt („>”) használ az angol, de az megtévesztő lehet a kisebb-nagyobb jelentése miatt, ezért javasolt inkább a („»”).



    e

Hasznos linkek gyűjteménye

 

 

 


Frissítés: a Kézikönyv fordítása elkészült. Az ezen az oldalon alább leírtak már csak történelmi, archiválási célokat szolgálnak.


  1. Szójegyzék: a Drupal magyar nyelvű felületének évek óta és jelenleg is gondozott, karbantartott kifejezéseinek gyűjteménye.

  2. Spreadsheet: az angol doksiíró csapat vezérlőpult-szerű táblázatának magyar klónja.

  3. Issue queue: a könyebbség kedvéért belinkelek különböző gyakran használt szűréseket:

  4. Vizuális helyzetjelentés: a D.org issue queue alapján egy többé-kevésbé aktuális áttekintése a száz témakör pillanatnyi állapotának.

  5. UI-sztringek: itt lehet rákeresni, hogy egy-egy menüpontot, gombfeliratot, stb. mire fordítottunk magyarul.

  6. Közzétett kézikönyv: azok a fejezetek, amiket már lefordítottunk, itt már láthatóak. (A nyelvválasztó menüből más fordítási csapatok munkájára is rá lehet tekinteni.)

  7. Formázási irányelvek: a fordítóknak igazából nem sok dolguk van vele, ha betartják a forrásfájlok szintaktikáját. Inkább a kommitolóknak fontos fejből tudniuk, hogy repóba küldés előtt átellenőrizzék a fordításokat.

  8. MTA-segítség: nyelvhelyességi kérdésekben a legfőbb iránymutató forrás, interaktív, egyszerűen használható, könnyen érthető.

  9. Szótárak: Linguee és SZTAKI

Fordításhoz közvetlenül nem szükséges, csak érdekességképpen:

Kiegészítések beszerzése és telepítése

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

A beszerzés megkezdése előtt célszerű elolvasni a különböző verziókról és komponensekről szóló leírást a kézikönyvben, hogy tisztában legyünk a letöltendő csomaggal.

A Drupal motor és a közösségi projektek is kétféleképpen szerezhetőek be: webes felületen és CVS kliens segítségével. Mindkettő alkalmas fejlesztői változatok és számozott kiadások beszerzésére, mégis a webes felületet jellemzően a számozott kiadások iránt érdeklődők használják, CVS klienst pedig a fejlesztői változat iránt érdeklődők vesznek igénybe.

Legegyszerűbb a Drupal letöltés oldaláról indulni, mely lehetőséget ad a különböző számozott verziók és a CVS (fejlesztői) változat beszerzésére is. Itt a változat kiválasztása után a különböző projektek közül választhatunk. Elsőként a Drupal motort találjuk, majd a kiegészítő modulokat, sminkeket és fordításokat, melyek az adott verzióhoz elérhetőek. A legtöbb projektet természetesen a CVS fül mögött találjuk, ám ezek nem feltétlenül stabil kódok, ezért első nekifutásra egy számozott verzió kipróbálása javasolt. A Drupal telepítésének megkezdéséhez csak a Drupal nevű projekt egy verziójának letöltése elegendő.

Előfordulhat, hogy valamilyen okból a fejlesztői változatra van szükségünk. Ekkor lehetséges, hogy az általunk igényelt projektnek (még) nincs weben keresztül letölthető csomagja. 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 utasításokat, 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.
  • 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. Erre a következő dialógus ablak jelenik meg, melyet megfelelően ki kell tölteni:
    A Tortoise CVS Checkout beállítása a Drupal motor elérhetőségére
  • 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.

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újtá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 rendszer 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.

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.

20 Napi Drupal API - 1. nap: Új mezőtípus létrehozása CCK-val

Jelen írás egy fordított kivonat, melyet zserno készített. Az eredeti itt található:
http://www.trellon.com/content/blog/cck-creating-new-field-types

A CCK a legfontosabb rövidítés, amit ismernünk kell ha a Drupal tartalomkezeléséről beszélünk. Az eredeti rövidítés a Content Construction Kit szavakból áll össze, ami egy olyan keretrendszer, melynek segítségével egy webhely felhasználói különféle információkat küldhetnek be.

A többi Drupal kiegészítőhöz hasonlóan a CCK igazi szépsége sem csupán az általa kínált funkcionalitásban rejlik, hanem sokkal inkább a többi modul számára kínált kibővíthetőségében. A CCK API lehetővé teszi más modulok számára, hogy saját mezőtípusokat definiáljanak, melyek aztán tökéletesen illeszkednek a Drupal platformba.

A CCK sikerét jól jellemzi, hogy nagy részét már a Drupal 7-es alapcsomag is tartalmazza
A legismertebb CCK-ra épülő modulok a Filefield, Imagefield, Emfield, Link és Email, de összesen közel 300 CCK-val cimkézett Drupal 6 modul található a http://drupal.org-on. Függetlenül a felhasználási területtől, ezek mindegyike a CCK API-ját használva képes saját mezőtípusait definiálni, melyek azután bármelyik tartalomtípusban felhasználhatók.

Egy egyszerű példaként Matthias Hutterer Email modulját fogjuk megvizsgálni. Ez a modul a CCK API-t használva egy saját mezőtípust deklarál, amivel megfelelően formázott e-mail címeket tárolhatunk saját tartalomtípusainkban. Meg fogjuk vizsgálni a kulcsfontosságú függvényeket, amik az egyedi mezőtípus definiálásához szükségesek, és ahol szükséges, rövid magyarázattal szolgálunk a konfigurációs lehetőségekről.
Kezdjük a hozzávalókkal (a legfőbb hook-ok és eljárások, amiket használhatunk):

  • Telepítés:
    • content_notify
  • Mező beállítások (field settings):
    • hook_field_info
    • hook_field_settings
    • hook_field
  • Felületi elemtípus beállítások (widget settings):
    • hook_widget_info
    • hook_widget_settings
    • hook_widget
    • hook_elements
  • Sminkelés (theming):
    • hook_theme + theme_MY_ELEMENT
    • custom formatters

A lista hosszú, vágjunk is bele.

Telepítés

Első lépésként tudatnunk kell a CCK-val, hogy modulunk mikor áll használatra készen:

function email_install() {
  drupal_load('module', 'content');
  content_notify('install', 'email');
}

A *.install file-ban közölhetjük vele, amikor modulunk telepítése, engedélyezése, kikapcsolása vagy eltávolítása zajlik. Ezt a megfelelő hook-ban (pl. hook_install, hook_enable, stb), a megfelelő paraméterrel (install, enable, stb.) meghívott content_notify CCK eljárással tehetjük meg.

Mező beállítások

Az email.module file-ban látható, ahogy a mező formát ölt.

function email_field_info() {
  return array(
    'email' => array(
      'label' => 'Email',
//...

A fenti kóddal regisztráltuk a mezőnket, az "email" belső azonosítóval és egy "Email" címkével.
function email_field_settings($op, $field) {
  switch ($op) {
    case 'database columns':
      $columns['email'] = array('type' => 'varchar', 'length' => 255, 'not null' => FALSE, 'sortable' => TRUE);
      return $columns;
  }
}

Itt az Email modul arra kéri a CCK-t, hogy kezelje ő a szükséges adatbázissal kapcsolatos teendőit. Egy külön oszlopot kér az őt használó tartalomtípusok tábláiban. Az oszlop elnevezése a majdan létrehozott mezők nevétől függően mindig "field_MEZŐNÉV_email" alakú lesz, beállításait pedig a $columns['email'] tömbben megadott jellemzők határozzák meg. Az $op változó a "database columns" értéken kívül még a "form" szöveget is tartalmazhatja, amivel egyedi űrlap készíthető a további szükséges beállításoknak (ld. a CCK Text modulját).
Végül nézzük hogyan tudjuk validálni a mezőnk tartalmát.
function email_field($op, &$node, $field, &$items, $teaser, $page) {
  switch ($op) {
    case 'validate':
      if (is_array($items)) {
        foreach ($items as $delta => $item) {
          if ($item['email'] != '' && !valid_email_address(trim($item['email']))) {
            form_set_error($field['field_name'],t('"%mail" is not a valid email address',array('%mail' => $item['email'])));
          }
        }
     }
     break;
//...

Ha a mezőnek van értéke, akkor a fenti kód a Drupal valid_email_address eljárásával ellenőrzi, hogy az valódi e-mail cím-e.

Felületi elemtípus beállítások

Miután felvázoltuk a mezőtípusunk logikai összetevőit, jöhet a felületi elemtípus (ún. widget) űrlapjának definiálása, hogy a végleges HTML űrlapelem megkaphassa a megfelelő attribútumokat. A hook_field* függvényekhez hasonlóan a hook_widget* függvényeknek is van _info és _settings változata.

function email_widget_info() {
  return array(
    'email_textfield' => array(
      'label' => t('Text field'),
      'field types' => array('email'),
      'multiple values' => CONTENT_HANDLE_CORE,
      'callbacks' => array(
        'default value' => CONTENT_CALLBACK_DEFAULT,
      ),
    ),
  );
}
//…
function email_widget_settings($op, $widget) {
  switch ($op) {
    case 'form':
      $size = (isset($widget['size']) && is_numeric($widget['size'])) ? $widget['size'] : 60;
      $form['size'] = array(
        '#type' => 'textfield',
        '#title' => t('Size of textfield'),
        '#default_value' => $size,
        '#element_validate' => array('_email_widget_settings_size_validate'),
        '#required' => TRUE,
      );
      return $form;
 
    case 'save':
      return array('size');
  }
}

Vegyük észre hogy a hook_widget_info a hook_field_info-val hasonló struktúrát használ (name és label kulcsok), azonban kiegészíti a felhasználható mezőtípusok listájával ('field types' => array('email')).
A hook_field_settings-hez hasonlóan, a hook_widget_settings-ben is lehetőség van finomítani a beállítások űrlapján (kettőjük végeredményét látjuk az "admin/content/node-type/[TARTALOMTÍPUS NEVE]/fields/[MEZŐNÉV]" útvonalon).
Az Email modul (akárcsak a Text modul) ezt arra használja, hogy a "size" mezőnek (mely a bevihető szöveg maximális hosszát határozza meg) biztosan legyen értéke.
Ahhoz, hogy az űrlapelemünk megjelenjen az űrlapon, a hook_widget-et kell használnunk:
function email_widget(&$form, &$form_state, $field, $items, $delta = 0) {
  $element = array(
    '#type' => $field['widget']['type'],
    '#default_value' => isset($items[$delta]) ? $items[$delta] : '',
  );
  return $element;
}

Tehát amikor a CCK hozzáadja a mezőnket az űrlaphoz, tudatjuk vele, hogy állítsa be a megfelelő widget típust (ez esetünkben az "email_textfield") és az alapértelmezett értéket, ha az létezik. Ha a modulunk több widget típust is használna, akkor itt a widget típus szerinti feltételes elágazással tudnánk a megfelelő attribútumokat beállítani. A legtöbb esetben azonban a fenti függvény elegendő (bővebben: nodereference.module).
Miután minden szükséges információt tudattunk a CCK-val, még a Drupal Form API-jának is el kell magyarázni, hogy miként bánjon a mezőnkkel. Ezt a hook_elements függvénnyel tehetjük meg:
function email_elements() {
  return array(
    'email_textfield' => array(
      '#input' => TRUE,
      '#columns' => array('email'),
      '#delta' => 0,
      '#process' => array('email_textfield_process'),
    ),
  );
}

Vegyük észre, hogy itt az "email" azonosító helyett az "email_textfield"-et használjuk, mert a Fom API az új widget-re kíváncsi, amit még a hook_widget_info-ban a mezőnkhöz kapcsoltunk. Továbbá azt is megmondjuk, hogy hol találja az új űrlapelem feldolgozásakor használandó kódot: '#process' => array('email_textfield_process').
Az eddig tárgyalt függvények mind az új mezőnk létrehozásával foglalkoztak: definiálták annak beállításait és létrehozták a szükséges widget-et. Egyikük sem foglalkozott azonban azzal, hogy a Drupal hogyan is fogja a widget-ünket szabályos HTML űrlapelemként megjeleníteni egy node szerkesztő form-on. Ennek leírása a (hook_elements-ben már említett) "#process" attribútumban megadott callback függvénnyel tehető meg:
function email_textfield_process($element, $edit, $form_state, $form) {
  $field = $form['#field_info'][$element['#field_name']];
  $field_key = $element['#columns'][0];
  $delta = $element['#delta'];
  $element[$field_key] = array(
    '#type' => 'textfield',
    '#title' => $element['#title'],
    '#description' => content_filter_xss($field['widget']['description']),
    '#required' => $element['#required'],
    '#maxlength' => 255,
    '#size' => !empty($field['widget']['size']) ? $field['widget']['size'] : 60,
    '#attributes' => array('class' => 'text', 'dir' => 'ltr'),
    '#default_value' => isset($element['#value'][$field_key]) ? $element['#value'][$field_key] : NULL,
  );
  return $element;
}

A Form API-t ismerőknek ez a kódrészlet már első ránézésre sokat elárul. A mezőnk egy szöveges beviteli mező (textfield) lesz, melyhez felhasználtuk a korábban definiált mező- és widget beállításokat ('widget' kulcs a fenti kódban), valamint a CCK-tól kapott információkat (ilyen pl. az $element['#title'], ami a "Mezők kezelése" oldalon egy új mezőcímke beküldésekor kerül beállításra).
Most hogy a CCK már tud az új mezőtípusunkról és a FAPI is tudja, hogy miként jelenítse meg azt a node szerkesztő űrlapon, nincs más hátra, mint az összegyűjtött adatok sminkelése.

Sminkelés

A hook_elements meghívásakor a Drupal feltételezi, hogy léteznek a deklarált elemekhez azok sminkfüggvényei is. Így pl. az Email modul esetében mivel az egyetlen deklarált elemünk az "email_textfield" volt, ezért létre kell hoznunk egy "theme_ email_textfield" nevű sminkfüggvényt. Habár a Drupal automatikusan összekapcsolja az űrlapelemet a hozzá tartozó sminkfüggvénnyel, szükség van a szokásos hook_theme függvény megírására is, hogy tudja: ez egy sminkelhető függvény.

function email_theme() {
  return array(
    'email_textfield' => array(
      'arguments' => array('element' => NULL),
    ),
// More theme functions declared here…
  );
}
 
function theme_email_textfield($element) {
  return $element['#children'];
}

A theme_email_textfield eljárás nem csinál semmi különöset, mindössze a Drupal Form API-ja által generált HTML értéket adja vissza (ahogy az az 'includes/form.inc'-ben látható). Érdemes tudni, hogy lehetne ennél komolyabb sminkfüggvényt is írni az element['field_name'] és $element['delta'] értékek felhasználásával (ezek az űrlapelem nevét és pozícióját tárolják).
Utolsó simításként készíthetünk a felhasználók által kezelhető ún. egyedi mező formázókat is, melyek az adott tartalomtípus "Megjelenítési beállítások" oldalán érhetők el (admin/content/node-type/[TARTALOMTÍPUS NEVE]/display).
Példa: az Email modul a hook_field_formatter_info segítségével definiálja saját mező formázóit, majd a hook_theme-ben deklarálja az azokat előállító callback függvényeket, végül megvalósítja az így deklarált theme_EGYEDI_FORMÁZÓ függvényeit, melyekben összeállítja a végső HTML kimeneteket.
---
A cikk hossza ellenére még csak a felszínét súroltuk a CCK lehetőségeinek. Az említett függvényekről bővebben a CCK csomagban található kiegészítő modulokban olvashatunk (pl. text, nodereference), melyek gazdag dokumentációt tartalmaznak.

Drupal kódolási stílus

Behúzások és sortörések

Egy behúzás két szóköz méretű, példa:


if (empty($valami)) {
echo "Teljesen be vagyok húzva."
}

A sorok végen ne legyen szóköz, utolsó karakter után legyen új sor. Minden fájl végén legyen egy üres sor: ez azért van, hogyha patchet készítesz, akkor ne kerüljön bele a "\ No newline at end of file" figyelmeztetés, illetve a patch maga olvashatóbb legyen.

Operátorok

Minden bináris operátort (két érték közé helyezendő operátorok), mint például a +, -, =, !=, ==, > stb. egy-egy szóközzel közre kell fogni, hogy olvashatóbb legyen.

Példa: $foo = $bar; (Rosszul írva: $foo=$bar;)

Az egy értékre ható operátorok (mint például az inkrementáló operátor, ++) közvetlenül a változó mellé írandók (pl: $foo++, vagy ++$foo).

Típuskonverzió

Mindig rakj egy szóközt a típus és a változó közé: (int) $mynumber.

Vezérlési szerkezetek (if, for, while, switch, stb.)

Hogy ne legyenek függvényhívásokkal összekeverhetőek az ilyen kódcsoportok, a nyitó parancs (if, else, stb.) után egy szóköz kötelező.

Kapcsos zárójelek használata minden esetben javasolt, még akkor is, ha a kód maga értelmes lenne nélkülük (egy soros mag). Ettől javul az olvashatóság, és valamelyest csökkenti annak esélyét, hogy a kódmag bővítése során logikai hibák kerüljenek be.


if (condition1 || condition2) {
action1;
}
elseif (condition3 && condition4) {
action2;
}
else {
defaultaction;
}

Függvényhívások és függvénydefiníciók

Függvények hívásakor a függvény neve és az argumentumok nyitó zárójele közé nem szabad szóközt tenni, illetve – mint minden felsorolás jellegű kódrészletben – a vessző és a következő paraméter közé kell a szóköz. Az utolsó paraméter után közvetlenül jön a zárójel és a kódsor végét jelző pontosvessző.


$var = foo($bar, $baz, $quux);

Ahogy látszik, az egyenlőségjel két oldalán van egy-egy szóköz, ahogy a függvény visszatérési értékét hozzárendeljük a változóhoz. Egymás után több érték változóhoz rendelése esetén több szóközt is beszúrhatunk a kód jobb olvashatósága érdekében:


$short = foo($bar);
$long_variable = foo($baz);

Azok az argumentumok, amelyeknek van alapértelmezett értékük, az argumentum-lista végére kell, hogy kerüljenek. Törekedj értelmes visszatérési érték meghatározására, ha lehetséges.

Tömbök

Tömbelemek egymástól a szokásos felsorolás stílusban (egy vessző, utána szóköz) írandóak. Amennyiben kulcs hozzárendelést alkalmazunk (=>), akkor az operátor elé és mögé is írandó szóköz:

$some_array = array('hello', 'world', 'foo' => 'bar');

Ha egy ilyen tömb-sor hosszabb lenne 80 karakternél (ami elég gyakran előfordul, például űrlap, illetve menü definícióknál), akkor a tömbelemek soronként írandóak, egy behúzással (azaz két szóközzel):


$form['title'] = array(
'#type' => 'textfield',
'#title' => t('Title'),
'#size' => 60,
'#maxlength' => 128,
'#description' => t('The title of your node.'),
);

Érdemes megfigyelni, hogy az utolsó sor végén is van egy vessző. Ez nem elírás, ez a jelölésmód segít későbbi feldolgozási hibák elkerülésében, ha bővitjuk a listát.

Idézetek

A kettős, vagy szimpla idézőjelek használatáról nincsen kőbe vésett szabály a Drupalban. Ahol lehetséges, próbálj törekedni az adott modul írásmódjával egybeesően írni: tiszteld a többi programozó egyeni stílusát.
Ugyanakkor érdemes fejben tartani, hogy a szimpla idézőjeleket gyorsabban értelmezi a PHP, mert nem próbál változókat keresni a sorban (például: "

$header

"

). Ezenkívül fordítandó szöveg esetén is ajánlott kettős idézőjelet használni, ha maga a szöveg tartalmazna szimpla idézőjelet (ekkor ugyanis egy az idézőjel elé egy visszaperjel írandó, amit a .pot készítő nem biztos, hogy meg tud oldani).

Sztring összefűzés

Mindig rakj szóközt a pont és az összefűzendő változók, értékek közé, ez nagyban javítja az olvashatóságot.

$string = 'Foo' . $bar;
$string = $bar . 'foo';
$string = bar() . 'foo';
$string = 'foo' . 'bar';
?>

Egyszerű változók esetén szabad dupla idézőjelet használni, és a változót közvetlenül az idézeten belül kiírni:

$string = "Foo $bar";
?>

Ha az összefűzés a saját operátora által ('.=') történik, akkor (mint ahogy korábban írtuk az operátorok esetén) mindkét oldalról egy szóközzel kell közrevenni:

$string .= 'Foo';
$string .= $bar;
$string .= baz();
?>

Megjegyzések

Sorbeli forrás dokumentáció a Doxygen formázási szabályokat követi.
Ajánlott nem dokumentáció jellegű megjegyzésekkel bővíteni a kódot. Nagy általánosságban az olyan programrészletek, amik megírása után az ember legszívesebben zacskót húzna a fejére és elmenekülne dél-Indiába, azonnal dokumentálandóak, mielőtt elfelejti a szerző, hogy mit és hogyan és miért úgy csinált.

Nem dokumentálás jellegű megjegyzéseknek is nyelvtanilag helyes, teljes mondatoknak kell lenniük (nagy betűvel kezdődően, mondat végén pont, mondatok egy szóközzel elválasztva). Csupa nagybetűt csak akkor használunk, ha állandókra (például TRUE) hivatkozunk. Megjegyzések külön sorba írandóak, közvetlenül a vonatkozó kódrészlet elé, például:


// Unselect all other contact categories.
db_query('UPDATE {contact} SET selected = 0');

Ha egy lista elemeihez fűznénk magyarázatot, akkor írhatunk ugyanabba a sorba, sőt be is húzhatjuk, hogy olvashatóbbak legyenek a megjegyzések.
Mind a C-ben használt megjegyzés stílus (/* */) és a C++ féle (//) elfogadott, Perl, illetve shell típusú # megjegyzések kerülendőek.

Kód include-olása

Ahol feltétel nélkül kell egy PHP kódot tartalmazó fájlt meghívni, ott használj require_once()-t. Ahol ez feltételhez van kötve, ott include_once() használatos. Ez a két utasítás közös fájllistát kezel, vagyis ugyanaz a fájl nem lesz kétszer meghívva.

Miután az include_once() es a require_once() nem függvény, hanem nyelvi elem (statement), ezért nem kell a fájlnév köré zárójelet tenni.

Ha ugyanabból a könyvtárból, vagy alkönyvtárból hívunk fájlt, az elérési utat kezdjük "."-vel: include_once ./includes/mymodule_formatting.inc. Drupal 7.x alatt használjuk a DRUPAL_ROOT állandót: require_once DRUPAL_ROOT . '/' . variable_get('cache_inc', 'includes/cache.inc');

PHP kód jelölők

Mindig a tageket használd PHP kód írásakor, a rövidebb ?> helyett. Ez nem csak Drupal standard miatt van így, hanem a kód hordozhatósága miatt is nagyon fontos, eltérő szerver konfigurációk esetenként tilthatják a rövidebb jelölést.

Pontosvesszők

A PHP nyelv szintaxisa megköveteli a sor végi pontosvesszőt, viszont megengedi annak elhagyását kód blokkok esetén. A Drupal kódolási stílusa viszont még ott is megköveteli:
Helyes:
Helytelen:

Forrás: http://drupal.org/coding-standards
Ez a fordítás közösségi munka eredménye, ha bármi hibát találsz, vagy szebben meg tudnád fogalmazni, akkor segíts javítani.

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)
  • 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:anonymous@cvs.drupal.org:/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ő:

<IfModule mod_rewrite.c>
    RewriteEngine on
 
    RewriteBase /phpdoc/html
 
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_FILENAME} ^(.*)_(.*)$
    RewriteRule ^(.*)_(.*)$ $1-$2
 
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule ^([0-9A-Za-z\-]*)$ function.$1.html [L]
</IfModule>

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

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.

Frissítve (2010.06.08):
Drupal 6 hoz a következő CVS paranccsal lehet kinyerni a dokumentációt:
cvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal-contrib checkout -r DRUPAL-6--1 contributions/docs/developer

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.

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, 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:

// Felület fordítást nem támogatjuk
$message = 'Nem sikerült betölteni a fájlt.';
// Felület fordítást támogatjuk
$message = t('Unable to load file.');
// Fájl nevét ki szeretnénk írni (de itt hibásan) [1]
$message = t("Unable to load file: $filename");
// 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.

// Megfelelő fordítás előállítása
$seeds = format_plural($number, '1 cherry seed', '%count cherry seeds');
?>

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.

Drupal tartalomkezelő magyarországi közössége

Miért válasszam a Drupalt?

Használjon Drupalt a személyes blogtól a vállalati alkalmazásfejlesztésig! Több ezer modulból és megjelenésből válogathat a saját igényei megvalósításához.

A Drupal szabadon felhasználható, megbízható rendszer, melyet több százezren fejlesztenek. Kapcsolódjon hozzánk!

Hogyan induljak el?

Nézze meg a jó példákat, olvassa el a GYIK-ot, böngéssze át a kézikönyvet és a fogalomtárat!

Kapcsolódjon a közösséghez, fogalmazza meg kérdését, és keresse meg rá a választ, vagy írja meg a fórumban!

Hogyan kapcsolódjak?

A Drupal egyik legnagyobb ereje a körülötte lévő közösségben rejlik. E közösség nyitott mindenki számára.

Számos ponton kapcsolódhat. Segíthet a hibák felderítésében, jelzésében, fordításokat készíthet és javíthat, segítséget adhat és kaphat a fórumon.

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 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:

function chameleon_features() {
return array(
'logo',
'toggle_name',
'toggle_slogan',
'toggle_primary_links',
'toggle_secondary_links');
}
?>

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

Egyszerű alsmink készítése

Alsminket készíteni a Drupalban elég egyszerű. Általában azért, illletve akkor van rá szükség ha a drupal.org-ról, vagy máshonnan letöltött sminkbe szeretnénk belenyúlni, mert nem tetszik a link színe, vagy a menü mögötti háttérkép stb. Persze megtehetjük hogy belenyúlunk a letöltött sminkbe, de akkor emlékezned kell mit módosítottál, és ha frissül a smink, ezeket a módosításokat újra és újra alkalmaznod kell. Elég macerás ugye?

Erre nyújt segítséget az a lehetőség az úgynevezett alsmink (angolul sub-theme) ahol magadnak készítesz egy sminket, ami gyerek szülő kapcsolatban lesz. Vegyünk egy konkrét példát:

Tegyük fel hogy tetszik nekünk a Danland smink, de az már nem tetszik hogy a menüpont színe fehér, jobban szeretnénk ha ez piros lenne, hover állapotra (azaz ha ráviszed az kurzort) pedig sárga.

Készíts egy mappát a sites/all/themes mappába, legyen a neve mondjuk 'danlandclone'. Ami feltétlen szükséges egy alsmink készítéséhez az egy .info fájl, amiben leírod a smink adatait, illetve esetünkben, mivel csak a menüpont színét szeretnénk megváltoztatni, kell egy css fájl is.

Info fájl elemei:

name = Danland clone

A name érték kötelező mező, bármilyen nevet adhatsz a saját sminkednek

core = 7.x

A core érték kötelező érték, itt tudod megadni mely drupal verzióhoz szertenél alsminket készíteni. Mi esetünkben most ez nem fontos, de később ennek jelnetőssége lesz.

base theme = danland

A 'danland' érték itt a smink gépi(!sic) neve, megeggyezik a szülő smink info fájljának nevével(danland).
Itt megadtuk hogy a saját sminkünknek hogy minek lesz a gyereke, azaz a danland és a danlandclone sminkek között szülő -> gyerek kapcsolat lesz.

description = Ez a smink a Danland gyermeke.

A description érték bár nem kötelező, elég hasznos lehet, ha magadnak akarsz üzenni, mi is ez a smink.

version = 1.0

A version mező nem kötelező mező.

engine = phptemplate

Az engine Drupal 7-ben ez a mező már nem szükséges.

stylesheets[all][] = danlandclone.css

A stylesheets értékben tudod megadni az alsminkedhez/smindkedhez használt saját css fájlokat. A danlandclone sminkben igaz nincs benne sok minden, de itt azt definiálhatsz amit szeretnél.
Update: Hozzáadhatsz ezzel a módszerrel további saját css fájlt is, de figyelj arra hogy ha ugyanazt a nevet adod neki mint ami a szülő sminkben is szerepel, a gyereké lesz érvényben.
Példa: nem tetszik neked a danlandclone.css név, legyen inkább style.css, akkor a "Danland clone" smink style.css -e lesz érvényben, és nem veszi figyelembe a szülő ugyanezzel a névvel létező, és az oldalnak stílust adó fájlt.

danlandclone.info tartalma:

name = Danland clone
description = Ez a smink a Danland gyermeke.
 
version = 1.0
core = "7.x"
engine = phptemplate
 
base theme = danland
 
stylesheets[all][] = danlandclone.css
scripts[] = myscript.js
 
; továbbá összes danland régió, lásd a csatolt zipben lévő info fájlt

danlandclone.css tartalma:

#nav li a {
  color:red;
}
#nav li a:hover {
  color:yellow;
}

Nincs más dolgunk mint lementeni az info fájlt a sites/all/themes/danlandclone mappába. Az info fáj nevének meg kell egyeznie a mappa nevével amiben szerepel, azaz most danlandclone.info fájl lesz belőle, karakter kódolása pedig UTF-8.

Ezt kell látnod majd a sminkek közt ha jól csináltad:

További angol nyelvű olvasivaló az info fájlról: http://drupal.org/node/171205

CsatolmányMéret
Csomag ikon danlandclone.zip704 byte

Alsmink módosítások

Most hogy már tudjuk hogy kell alsminket készíteni, akár módosíthatjuk a készített alsminkünket kicsit, hogy a mi szájunk íze szerint működjön/nézzen ki.

Első feladatunk legyen hogy a menüt szeretnénk áthelyezni a slideshow alá, második feladatként pedig a slideshow-t minden oldalon szerepeltetni szeretnénk!

Első feladatként a látványos mutatvány ugye csak a főoldalon lesz elsőre látható, hogy jelenleg az aloldalakon nincs slideshow a sminkünkben.

  1. másoljuk át a szülő smink page.tpl.php fájlját a saját sminkünk mappájába. Nem fontos, de én szeretem a tpl tájlokat mappában tárolni, így nálam ez így néz ki: danland > templates > page.tpl.php. Akkor is látja a page.tpl.php fájlt a drupal ha csak a smink gyökerébe helyezed, csupán a jobb átláthatóság kedvéért „mappázom be”.
    1. Danland esetén a slideshow elemeit is át kell helyeznünk a saját sminkünkbe, így másold át az images > slideshow mappát az alsmink images > slideshow mappádba.
  2. üríts ki a registry-t, amit vagy drush segítségével (drush cc all), vagy admin felületen az admin/config/development/performance útvonalon tehetsz meg.
  3. Találjuk meg, mit akarunk áttenni: keressünk id-t vagy class-t, nézzük melyiket:
    1. Chrome (jobb klikk elem megtekintése) vagy Firefox és Firebug segítségével (Elem vizsgálata Firebuggal) nézz rá a HTML kimenetre, kattints jobb klikkel a menüre, és tekintsd meg a forrást. Láthatod, hogy a li elem szülője egy div#nav, aminek szülője egy div#menu:
    2. Alsmink HTML kimenete vizsgálat alatt

  4. Most keresd meg a page.tpl.php fájlban a div#menu elemet (kis tipp: nekem az 52. sorban van).
  5. Így hogy tudjuk hol van a kérdéses elem, bátran játszhatunk vele, mondjuk másold ki az 52.-től a 69.-ik sorig, vágd ki, és mádold a 78.sorba (közvetlenül a <?php if($page['preface_first'] || $page['preface_middle'] || $page['preface_last']) : ?> sor fölé).
  6. Mentés.

Eredmény: a menü a slideshow alá került, midnenki döntse el maga: ez így szép-e. :)

Második feladat (ha még emlékszünk): a slidehow minden oldalon jelenjen meg, ne csak a főoldalon.

  1. A page.tpl.php fájlban keresd meg az slideshow-t. A page.tpl.php fájlban találsz egy div#slideshow-wrapper elemet, itt kezdődik a slideshow, vagy nem?
    1. Nem teljesen, mert éppen felette egy sorral akad egy ilyen elem is:  if($is_front): , itt azt vizsgálja hogy a főoldalon vagy-e, ha igen, kiírja a div#slideshow-wrapper elemet, ha nem, nem ír ki semmit.
  2. Ha belegondolsz, már nem kell mást tenned mint ezt a vizsgálatot eltávolítani, azaz töröld ki a  if($is_front): elemet, és ne felejtsd el a  endif; elemet is törölni a div#menu elem fölül.
  3. Mentés.

Összegzés: fenti két kis feladattal azt próbáltam hangsúlyozni, hogy ha már egy alsminked van, bármit bátran módosíthatsz benne.

CsatolmányMéret
Csomag ikon Módosított Danland smink104.51 KB

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.

48 nélkülözhetetlen Drupal fejlesztői tipp a Lullabot-tól

Az alábbi tippeket Justin Emond gyűjtötte egy négynapos Lullabot tréningen, melynek fő témái a sminkelés, form API, menu API, modulfejlesztés és jQuery voltak.

  1. Mindig nyomtassuk ki a $body_classes változót a body elem class attribútumaként a sminkünkben. Ezzel számos hasznos osztály válik elérhetővé CSS-ből, pl. "front", "not-front", "logged-in", stb.
  2. Az /admin/build/block oldal az egyetlen olyan admin oldal, ami nem használja az adminisztrációs sminket.
  3. A két leggyakrabban kifelejtett sminkváltozó a page.tpl.php-ben a $closure és a $tabs.
  4. Alapvető sminkelési módszer, hogy a módosítani kívánt sablon file-t előbb átmásoljuk a sminkünkbe az őt definiáló modul könvytárából, majd a másolatot szerkesztjük, pl. node.tpl.php.
  5. A fordítható szövegekben használjunk paramétereket (ún. placeholder tokeneket), mert a fordításban lehet, hogy más lesz a szórend. Pl. 


     $variables['submitted'] = t('On @date', array('@date'=>format_date($variables['created'],'custom','F jS')));
  6. Főverziók közötti frissítéskor legjobb, ha újraírjuk az összes smink függvényt, amiket korábban felülírtunk, így biztosan nem hagyunk ki fontos kódváltoztatást.
  7. Ha nem szeretnénk használni a teljes $content változót a node.tpl.php file-okban, akkor nyugodtan hagyjuk ki. Helyette nyomtassuk ki a szükséges mezőket egyenként.
  8. Teljesítmény: nézeteknél használjuk a "Mezők" sor stílust a "Tartalom" helyett, mivel utóbbi egy-egy node_load() hívást végez a nézet minden egyes sorára, ami egyenként több mint 50 lekérdezés is lehet. A "Mezők" stílus ezzel szemben csak a valóban szükséges adatokat gyűjti össze.
  9. A dpm() függvény a – CakePHP rendkívül hasznos pr() függvényéhez hasonlóan – komplex adatok rendezett megjelenítésére való, mely főként a hibakeresésben nyújt hasznos segítséget.
  10. Saját moduljainkat tegyük egy külön csomagba, így a modul listában jól elkülönülnek majd, továbbá ezzel a későbbi fejlesztők munkáját is megkönnyítjük.
  11. Használjuk a coder modul-t a Drupal 6 és 7 közötti API változások kiderítéséhez.
  12. Hasznos szokás, ha a "$user" változónevet az aktuálisan (tehát a kód futtatásának pillanatában) az oldalra bejelentkezett felhasználó jelölésére használjuk. Az egyéb okból betöltött felhasználót tartalmazó objektum jelölésére használjuk az "$account" változónevet.
  13. Teljesítmény: A teljes variable tábla előre betöltésre kerül minden oldallekéréskor, ezért ügyeljünk rá, hogy mekkora adatot tárolunk benne.
  14. Teljesítmény: A variable_get() hívása nem kerül semmibe (nem nyúl az adatbázishoz), hiszen minden Drupal változó már a memóriában van.
  15. Ne használjuk a t() függvényt a menük "title" és "description" elemein, mert azokat a Drupal cache-ből olvassa be, így a gyorstár felépítésekori nyelv lesz úgyis a mérvadó.
  16. Használjuk a MENU_LOCAL_TASK konstanst a hook_menu()-ben az ún. fülek (tabok)
    létrehozásához, ahogy az a /node vagy /user oldalon is látható.
  17. Teljesítmény: a terjedelmes menü callback függvényeinket tegyük külön .inc file-okba a menü tömb "file" kulcsának használatával. Így hatékonyabb lesz a memóriakezelés, mivel a Drupal a .module file-okat minden oldalletöltéskor memóriába tölti, viszont a .inc file-okat csak amikor szükséges.
  18. A hook_menu()-ben létrehozott útvonalakban a %user és %node jelölők (ún. magic handler-ek) használata esetén a Drupal automatikusan meghívja a node_load() ill. user_load() eljárásait a jelölők helyén álló aktuális ID-vel. Pl. $items['node/%node/edit'] menü útvonal esetén nem kell külön betölteni a $node objektumot a callback függvényünkben.
  19. Az előzőhöz hasonlóan lehetőség van saját magic handlerek használatára is. Pl. %yourown jelölő esetén a Drupal automatikusan meghívja a yourown_load() eljárásunkat mielőtt a hozzá tartozó menü callback-et meghívná. Fontos, hogy ezek a függvények a .module file-ban legyenek.
  20. Saját modulunkban bármikor használhatjuk a 

     $GLOBALS['conf']['cache'] = FALSE;
    utasítást, hogy kikapcsoljuk a Drupal gyorsítótárát az adott oldalon. (Megjegyzés: ha az oldal már a gyorstárban van, akkor ürítsük azt, különben nem fogjuk látni az utasítás hatását.)
  21. Könnyen kideríthetjük egy webhelyről, hogy Drupal alapú-e. Nézzük meg a page expire date-et a szerver által visszaküldött HTTP header-ben. Ha ez 1978. november 19. (a Drupal készítőjének, Dries Buytaert-nak a születésnapja), akkor nagy valószínűséggel az.
  22. Route-olás Drupalban: custom_url_rewrite_inbound() és custom_url_rewrite_outbound().
  23. A megfelelő dátum mezőtípus kiválasztása CCK-ban: 

    - Date (iso date): történelmi és nem teljes dátumok tárolására alkalmas (pl. csak év és hónap).

    - Datestamp (Unix epoch): a Drupal alaprendszer által használt formátummal megegyező dátum formátum.

    - Datetime (ajánlott): natív formában tárolja a dátumot az adatabázisban, tehát így lehetőség van az adatbázis szintjén dolgozni a dátumokkal, ami gyors.
  24. Osszuk fel a sites/all/modules könvytárunkat contrib és custom alkönyvtárakra. A contrib-ba tegyük a drupal.org-ról letöltött kiegészítő modulokat, míg a custom-ba a sajátjainkat.
  25. Ha egy kiegészítő modul kódján változtatnunk kell, akkor ezt mentsük ki egy patch file-ba, így lehetőség lesz a kódváltozások verziókövetésére, valamint a javítás beküldésére. Ezeket a patch-eket egy külön könyvtárba gyűjtsük. Később, ha frissíteni kell a módosított modulokat, ellenőrizzük, hogy továbbra is szükség van-e a módosításainkra. Amennyiben egy patch bekerült a modul hivatalos kiadásába, törölhetjük. Különben egyszerűen alkalmazzuk a patch-et.
  26. Saját moduljainkban a hook_menu() legyen mindig az első függvény, mert hasznos útmutatóként szolgál arról, hogy az adott modul mit csinál és hol érhető el ez.
  27. A form tömbök kulcsai azért kezdődnek kettőskereszttel (#), hogy lehessen akár újabb formokat is definiálni a tömbben.
  28. A Drupal minden form state-hez hozzáad egy "clicked_button" attribútumot, hogy lehetővé tegye a kép típusú űrlap beküldő gombok használatát Internet Explorer-ben is, ugyanis az nem használja a beküldő gomb name attribútumát a beküldő gombokon, ahogy azt a többi böngésző teszi.
  29. Űrlap beküldésekor beágyazott mezőkön a következő módon lehet hibát jelezni: "parent][child". Példa: "home][street", ahol street a mező, home pedig az őt tartalmazó űrlap.
  30. Az előzővel megegyező feladatot lát el a form_error() függvény, azonban tisztább és érthetőbb módon működik, mint a form_set_error(). 


     form_set_error('home][street','You must enter the street address.');
    form_error($form['home']['city'], 'You must enter the street address.');
  31. Ha a $form_state['storage'] tömbelembe bármit is teszünk, akkor a Drupal figyelmen kívül hagy minden korábban definiált átirányítást (ld. $form_state['redirect']), és újraépíti az űrlapot beküldés után. Hogy ezt elkerüljük, töröljük a $form_state['storage'] elemét (ld. php unset() függvény).
  32. Bármilyen HTML-t használhatunk modulunk smink függvényeiben, mert a Drupal sminkek képesek ezt később felülírni.
  33. Űrlap építéskor a Drupal automatikusan lerendereli a $form tömb maradék elemeit, amiket mi nem rendereltünk le korábban. Tehát elegendő csak azokkal foglalkozni, amiket mi magunk szeretnék lekezelni (ld. drupal_render() eljárás).
  34. Ha menet közben külső adatbázisra szeretnénk váltani, használjuk a db_set_active() függvényt a váltáshoz. Ekkor a settings.php-ban megadott kapcsolatok közül választhatunk.
  35. A Table Wizard modul segítségével bármilyen adatbázis táblából készíthetünk saját nézetet, sőt több táblánál megadhatjuk a kulcsokat is, amik alapján össze is kapcsolhatjuk őket (ld. még Migrate modul).
  36. Ha egy űrlapelemnek beállítunk egy értéket (a "#value" kulccsal), akkor a beküldés után mindig az lesz az értéke, független attól amit a felhasználó esetleg beállított az űrlapon.
  37. A "value" típusú űrlap elemek ("#type => "value") nem jutnak el a felhasználóig. Ezek értékét az űrlap adatok között tárolja a Drupal, ahol modulunk függvényéiből érhetjük el őket.
  38. Az inline módon beszúrt JavaScript betöltéséig a böngészők nem töltenek semmi mást, tehát blokkoljuk az oldalletöltést arra az időre. Vigyázzunk ezzel.
  39. A VisualjQuery.com oldalon egy hasznos, vizuális jQuery API-t találunk.
  40. Firebug tipp: A konzol alján található ">>>" szimbólum után saját JavaScript kódot futtathatunk bármely betöltött weboldalon. (Megjegyzés: Drupal oldalakon akár jQuery kódot is, hiszen a jQuery a Drupal része.)
  41. HTML tipp: néhány böngésző kidobja a href attribútum nélküli A tag-eket.
  42. jQuery tipp: class keresése sokkal gyorsabb, ha megadjuk a HTML elem típusát is, mert ekkor a jQuery a böngészők beépített getElementysByTagName() eljárását használja. Pl. 
 

    - Gyors: $('.content');
    - Gyorsabb: $('div.content');
    (Megjegyzés: hasonlóan, ID alapú kiválasztás esetén ne használjunk tag-et, mert akkor nem használja a böngészők beépített getElementNameById() eljárását, helyette végig járja az összes lehetséges tag-et, a megadott ID után kutatva.) 

  43. jQuery tipp: A szelektor függvényekben használt $(this) gyorsabb, mintha újra meghívnánk az aktuális szelektort.
  44. Nézeteink kezelésére egy hasznos módszer, ha kiexportáljuk őket egy saját modulba. Az így kapott php kód verziókezelhető, és védett az oldal felhasználóitól, ugyanis így akár ki is kapcsolhatjuk a Views UI modult. További előnye, hogy bármikor visszatérhetünk a nézetünk egy korábbi verziójára, ha szükséges.
  45. Nagy patch-ek kezelése: készítsünk egy modult, amiben a hook_update() hurkot használva végezzük el a szükséges beállításokat. Ezután frissítsuk a patch-elni kívánt modul kódját, futtassuk az update.php-t, végül alkalmazzuk a patch-et.
  46. Mikor figyeljünk a felhasználótól származó inputtal: általánosságban kijelenthető, hogy a sablon rétegben levő adatok biztonságosak, minden e fölötti szinten már nem. Használjuk a check_plain() eljárást, ha nincs HTML az adatban, és check_markup()-ot, ha pedig van (utóbbi a webhely alapértelmezett beviteli szűrőjét használja).
  47. A Drush make modullal lehetőségünk van modulok, sminkek, telepítési profilok és külső függvény könyvtárak egy listáját előre rögzíteni egy ún. drush make file-ba, majd ezt a file-t egy drush parancsként lefuttatva egy üres Drupal odalt kapunk pillanatok alatt, a megadott kiegészítőkkel. Előnye, hogy nem kell újra és újra ismételgetni az unalmas feladatokat minden egyes új projekt kezdetén.
  48. Használjuk a cache_get() és cache_set() eljárásokat ahol csak lehet, hiszen a gyorstárból jövő adatok jóval kevesebb adatbázis terhelést okoznak.


Jelen írás egy fordított kivonat, melyet zserno készített. Az eredeti itt található:
http://www.missingfeatures.com/2010/02/16/48-essential-drupal-developmen...

Köszönet drifternek, hogy megmutatta az eredeti cikket twitteren: http://twitter.com/drifter/status/13919347596!

Ha bármi hasznos tipped van amit nem találsz a fenti listában, kérlek írd meg hozzászólásban.

A Drupal menürendszere

A hook_menu() kampó megvalósításai elérési címeket jegyeznek be, megadva azok kezelőfüggvényeit, jogosultság értékeit, és megjelenítési adataikat.

Paraméterek

$may_cache Logikai érték, mely azt jelzi, hogy a visszaadott elemeink a gyorsítótárba kerülnek-e. A menü gyorsítótára felhasználófüggő, tehát az elemeket szinte mindig gyorsítótárazhatjuk, kivéve ha a felhasználó aktuális helyzetétől függnek. A node_menu() megvalósításában láthatunk példát olyan elemre, amit nem szabad gyorsítótárba tenni.

Visszatérési érték

Elérési címek tömbje. Minden elem egy asszociatív tömb, ami a következő kulcs-érték párokat tartalmazhatja:

  • "path": kötelező. Az az elérési cím, melyhez a további jellemzők tartoznak.
  • "title": kötelező. Az elérési címhez tartozó felirat. Ez jelenik meg a menüben illetve a fülön, valamint az ezen a címen előállított oldalnak is ez lesz az alapértelmezett címfelirata.
  • "callback": A címhez rendelt kezelőfüggvény. Ha nem addjuk meg, a szülő menüelem kezelőfüggvénye kerül majd meghívásra.
  • "callback arguments": Tömb, melyben a kezelőfüggvénynek átadandó paraméterek vannak.
  • "access": Logikai érték. A felhasználó erre a címre vonatkozó elérési jogosultságát adja meg. Általában a user_access() meghívásának segítségével dől el. Ha ez és a "callback" is hiányzik, akkor a szülő által meghatározott jogosultság érvényes.
  • "weight": Egész szám. A megjelenő menüelemek helyzetét dönti el, a nehezebbek lesüllyednek. Az alapértelmezés 0. Ha nem vagyunk biztosak magunkban, akkor ezt ne addjuk meg. Az alapértelmezett alfabetikus sorrend sokszor megfelelő.
  • "type": Jelzőkből álló bitmaszk. A menüelem tulajdonságait írja le. Sokféle bitmaszkhoz van rövidítésnek konstans definiálva a menu.inc fájlban:
    • MENU_NORMAL_ITEM: Közönséges menüelem, ami megjelenik a navigációs menüben. Az adminisztrátor mozgathatja vagy elrejtheti a menü modullal.
    • MENU_ITEM_GROUPING: Az elemcsoportokat olyan oldalak használják, mint a tartalom beküldése, amelyek egyszerűen aloldalakat sorolnak fel.
    • MENU_CALLBACK: Olyan elérési címet hoz létre, mely nem jelenik meg a menüben, de meghívásakor teljes értékű elérési címként viselkedik.
    • MENU_DYNAMIC_ITEM: A dinamikus menüelemek gyakorta változnak, és nem szabad eltárolni őket a testreszabást lehetővé tevő menü modul számára.
    • MENU_SUGGESTED_ITEM: Az ilyen menüpontok alapértelmezésben nem jelennek meg, de a menü modullal láthatóvá tehetőek.
    • MENU_LOCAL_TASK: A helyi feladatok fülként jelennek meg alapértelmezésben.
    • MENU_DEFAULT_LOCAL_TASK: Minden helyi feladatcsoporthoz kötelezően tartozik egy alapértelmezett feladat. Különlegessége, hogy nem az aktuális, hanem a szülő útvonalára vezet.

    Ha nem adjuk meg a típust, akkor a rendszer a MENU_NORMAL_ITEM érteket feltételezi.

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:

// A drupalhu modul weight értéke nagyra
// van állítva az adatbázsiban, ezért ez
// hívódik meg legutoljára a form_alter()-ek közül
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 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.

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:

// +WL: máshol jelenítjük meg az XML ikont
// $output .= theme('xml_icon', url('taxonomy/term/$tid/0/feed'));
?>

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 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).

Í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:

// Grab all files with possible CVS Id data
$files = find_drupal_files();

$cvsids = array();
$latest = '';

// Go over the files and collect CVS Id data
foreach ($files as $filename) {
$content = join('', file($filename));
if (preg_match('!\\$Id: ([^\\$]+) Exp \\$!', $content, $found)) {
$cvsids[$filename] = $found[1];
if (preg_match('!\\d{4}/\\d{2}/\\d{2} \\d{2}:\\d{2}:\\d{2}!', $found[1], $date)) {
if (strtotime($date[0]) > 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.

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 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. Hozzunk létre egy új mezőt a kívánt tartalom típusunkban, mondjuk „Date” névvel.
  2. Vigyünk fel pár új tartalmat (node-ot), kitöltött dátummal mezővel.
  3. Kapcsoljuk be a Calendar modult.
  4. 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! Az eredeti „calendar” nézetet kapcsoljuk ki/tiltsuk le, mert így könnyen összetéveszthető lesz majd az új blokk a régivel (ami ugye nem azt fogja mutatni, amit mi szeretnénk).
  5. 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.
  6. 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.
  7. 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.
  8. 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.

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,
    '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',
    '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', '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,
  '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,
      '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);

UPDATE: Lezártam a hozzászólások lehetőségét. Akinek kérdése van a témával kapcsolatban, az új fórum téma nyitásával teheti meg (hivatkozza be a leírás címét).

Köszönöm!

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:

Karbantartás miatt zárva

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

Nyitás: 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:


function phptemplate_maintenance_page($content, $messages = TRUE, $partial = FALSE) {
return _phptemplate_callback('page-maintenance', array('content' => $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


Sajnáljuk, honlapunk pillanatnyilag nem elérhető




A végeredmény:

Egyedi karbantartásjelző oldal

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 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 'tartalom elérése' jogosultság ellenőrzése
if (user_access('access content')) {
// ...
}
?>

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.

function meggymag_perm() {
return array("administer cherry seed", "collect cherry seeds");
}
?>

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.

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 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.

function wlcontact_form_alter($form_id, &$form) {
  if($form_id == 'contact_mail_user' && user_access('access administration pages')) {
    $form['toeditors'] = array(
      '#title' => '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.

function wlcontact_mail_user_submit($form_id = NULL, $form_values = array()) {
  static $toeditors = FALSE;
  if (isset($form_id)) {
    $toeditors = (bool) $form_values['toeditors'];
  }
  else {
    return $toeditors;
  }
}

Végül szükségünk van arra, hogy a megjegyzett értéknek megfelelően elhelyezzünk egy cc fejlécet a 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á.

function wlcontact_mail_alter(&$mailkey, &$to, &$subject, &$body, &$from, &$headers) {
  if ($mailkey == 'contact-user-mail' && wlcontact_mail_user_submit()) {
    $headers['Cc'] = '[email protected]';
  }
}

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.

Media modullal feltöltött kép beszúrása a CKEditor szerkesztőmezőjébe

Feladat:
Media modullal feltöltött képeket szeretnénk beszúrni CKEditorral szerkesztett tartalomba, egyéni képstílus használatával.

Felhasznált modulok:

Megjegyzés:
A Wysiwyg modul és a CKEditor feltelepítését nem tartalmazza a leírás. A Media modul fejlesztői változata több olyan módosítást is tartalmaz, amelyik visszafelé nem kompatibilis, többek közt a Media entitás helyett a File entitással kell elvégezni az itt vázolt műveleteket.

Lehetséges megoldás:

  1. Az admin/config/media/image-styles oldalra ellátogatva adjunk hozzá egy új képstílust, majd állítsuk be hozzá a kívánt effektusokat (pl. elforgatás, átméretezés).
  2. Ezután az admin/config/media/file-styles oldalon adjunk hozzá egy új fájlstílust, a képeknél beállítva neki az előzőleg létrehozott képstílust:
  3. Az admin/structure/ds/view_modes/manage címen készítsünk egy új nézetmódot, melyet csatoljunk a Media entitáshoz:
  4. Kapcsoljuk be az admin/config/media/types/manage/image/display oldalon, hogy a képeknél az újonnan készített nézetmódhoz egyéni megjelenítési beállításokat szeretnénk használni:
  5. Mentés után válasszuk ki az új nézetmódhoz csatolandó fájlstílust:
  6. Az admin/config/content/wysiwyg oldalon szerkesszük a használt profilt, a „Nyomógombok és bővítmények” szekcióban kapcsoljuk be a „Media browser”-t.
  7. Az admin/config/content/formats oldalon a Wysiwyg editorhoz (CKEditor) használt szövegformátum beállításainál engedélyezzük a „Converts Media tags to Markup” szűrőt.
  8. Tartalom beküldésekor a CKEditorban kaptunk egy új nyomógombot:
  9. A gombra kattintva tölthetünk fel új képet vagy választhatunk a már feltöltöttek közül, majd kiválaszthatjuk a kívánt nézetmódot:
  10. Ezután a képpel már a hagyományos módon dolgozhatunk, jobb gombbal kattintva rajta a „Kép tulajdonságai” menüpontban beállíthatjuk az igazítását és egyéb tulajdonságokat.

Természetesen, ha megelégszünk az automatikusan létrejövő képstílusok számával és elnevezésével, akkor a fenti műveletek helyett elég a már meglévő képstílusokat módosítani.

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:

/**
* Format a username.
*
* @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');
}
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.

Mire jó a ctools + panels + views trió

A 2012 Drupalaton és egy fórum kérdés ösztönözte ezt az írást.

A konkrét probléma: hogyan listázzunk ki felhasználókat bizonyos taxonómia kategóriába tartozás szerint ctools, panels és views segítségével Drupal 7 alatt.

Értelemszerűen telepítsük ezeket a modulokat a szokásos módon:
Views
Ctools
Panels

Kapcsoljuk be a Chaos tools, Page manager, Views content panes, Panels, Views, Views UI modulokat.

Ha ezzel megvagyunk akkor kezdjük a munkát. Hozzunk létre egy szótárt (admin/structure/taxonomy/add) "Felhasználó kategória" névvel és legyen a programok által használt neve "user_cat", ez lesz majd a felhasználói profilban felvéve mezőként. Készítsünk néhány kategóriát (admin/structure/taxonomy/user_cat/add) tetszés szerint.

Ezután a felhasználói beállításoknál (admin/config/people/accounts/fields) vegyük fel a mezőt a felhasználóhoz:
Mezőtípus: kifejezés hivatkozás
Név: Kategória
Programok által használt név: field_category
Szótár: Felhasználó kategória

Miután ez is elkészült hozzunk létre néhány teszt felhasználót különböző kategóriákkal, vagy módosítsuk a meglévőket. Így az előkészületekkel meg is volnánk.

Hozzuk létre az oldalunkat ami listázni fogja a megadott kategóriába tartozó felhasználókat. Ehhez a Ctools Page managerét fogjuk használni: admin/structure/pages

Page manager
Adjunk hozzá egy új oldalt ahol a megadott kategóriába tartozó felhasználókat ki fogjuk listázni.
Adjunk nevet az oldalnak és legyen az elérési út: user-list/%taxonomy_term
Így listázható lesz például a teszt1 kategória: user-list/teszt1

Új oldal
Mást itt nem kell beállítanunk, kattintsunk a Folytatás gombra.

Argumentum beállítás
Az előkészített argumentumunkat kell most beállítani, kattintsunk a Változtat gombra.

Argumentum típus kiválasztása
Válasszuk a "Taxonómia kifejezés: ID"-t és kattintsunk a Folytatás gombra.

Az argumentum beállítása
Ha term id-t szeretnénk a linkben használni akkor a Kifejezésazonosítót válasszuk, ha a kifejezés nevét szeretnénk használni akkor értelemszerűen a Kifejezés nevét válasszuk.
Ha csak a létező kifejezésekre akarjuk, hogy megjelenjen az oldal akkor a Limit to these vocabularies kiválasztóknál válasszuk a Felhasználó kategóriát. Ha mindent beállítottunk akkor kattintsunk a Befejezés gombra.

Az argumentum beállítás kész
Beállítottuk az argumentumot mehetünk tovább a Folytatás gombra kattintva.

Panel elrendezés
Ezen az oldalon állíthatjuk be a panel elrendezést. Jelenleg csak listázni akarunk, ezért az egy oszlop is megteszi, de ha komplexebb megjelenést szeretnénk akkor itt lubickolhatunk a lehetőségek között. Ha megvan a megfelelő akkor Folytatás.
A következő oldalak az induláshoz már nem feltétlen szükségesek ezért változtatás nélkül kattinthatunk a Folytatás, majd Befejezés gombokra.
Ha mindent jól csináltunk akkor most az összegző beállító oldalra kerültünk, kattintsunk a Mentés gombra.

Az oldalunk ezzel majdnem kész is van, már csak egy olyan lekérdezést kell gyártanunk ami előállítja a felhasználó listánkat, hogy beilleszthessük az oldalba.

Ehhez készítsünk egy nézetet: admin/structure/views/add

Nézet hozzáadása
Adjunk nevet a nézetnek és válasszuk a felhasználókat, oldalt és blokkot nem készítünk. Ha megvagyunk a beállításokkal akkor tovább a Folytatás és szerkesztés gombra kattintva.

Két dolgot feltétlenül meg kell tennünk:
1. Argumentumot kell létrehozni a Felhasználó kategóriának
2. Környezetet kell kreálni ami átadja az argumentumot a nézetnek

Szövegkörnyezeti szűrő hozzáadás
Kattintsunk a Haladó beállításoknál a SZÖVEGKÖRNYEZETI SZŰRŐK Hozzáadás linkre.

Mező kiválasztás
Válasszuk ki a Kategória mezőt, amit a felhasználóhoz hozzáadtunk.

Nézet elrejtése, ha nincs eredmény
Válasszuk a Nézet elrejtését, ha nincs argumentum, majd kattintsunk az Alkalmazás gombra.

Adjuk hozzá a környezetet.

Környezet hozzáadása
Ezután szerkesszük az argumentum bemenetet.

Argumentum bemenet szerkesztése
Nekünk a panel által biztosított környezetből fog kelleni a kifejezés azonosító, mert a kifejezés nevét átkonvertálta már azonosítóra.

Argumentum bemenet beállítása
Ha megvagyunk, akkor kattintsunk az Alkalmazás gombra.
A megjelenési nevet állítsuk beazonosíthatóra, például "Felhasználó listázása kategória szerint", és a nézetet mentsük el.

Ha mindent jól csináltunk akkor már csak egy dolgunk maradt, a listánkat az oldalhoz adni. Menjünk az oldal szerkesztéséhez (admin/structure/pages megfelelő oldal szerkesztés link) és válasszuk a tartalom fület.

Tartalom hozzáadása
Kattintsunk a fogaskerékre és válasszuk a Tartalom hozzáadáadása linket.

Nézet kiválasztása
Itt válasszuk a Nézetek fület, azon belül az imént létrehozott nézetünket.

Képernyő kiválasztása
Ezen belül pedig a jól beazonosítható képernyőt, majd Folytatás.

Környezet átadás beállítása
Már csak a mezőnket kell beállítani, hogy a megfelelő környezetet adja át a nézetnek, válasszuk a Kifejezésazonosító-t, és a Befejezés gombot.
Mentsük az oldalt a Frissítés és mentés gombra kattintva.

Írjuk be a címsorba domain.név/user-list/kifejezésnév és ha mindent jól csináltunk akkor megkapjuk az óhajtott felhasználó listát.

Az eredeti taxonómia oldal felüldefiniálása

Amennyiben az eredeti taxonomy/term/%taxonomy_term útvonalat akarjuk használni akkor engedélyezzük a rendszer term_view oldalt és csináljuk végig az előző részben leírtakból mindent csak nem új oldalt hozunk létre, hanem szerkesztjük a rendszer term_view oldalt. Ilyenkor útvonalat, argumentumot már nem kell beállítani!

Rendszer term_view szerkesztése
Kattintsunk a Szerkesztés linkre.

Változat létrehozása
Kattintsunk az Új változat hozzáadása linkre.

Változat beállítása
Adjunk nevet a változatnak és pipáljuk be a Választási szabályok checkbox-ot, majd a Változat létrehozása linkre kattintsunk.

Választási szabályok beállítása
Itt a legördülőből a Taxonómia szótár-t válasszuk és a Hozzáadás linkre kattintunk.

Választási szabályok beállítása2
Kiválasztjuk a Felhasználó kategória szótárt és Mentés.

Ha most a Folytatás gombra kattintunk, akkor elérkezünk a panel elrendezése oldalhoz ahonnan folytathatjuk a beállításokat.

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 publishboard blokk megjelenése

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.

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:

/**
* A nem olvasott tartalmak számának összesítése.
*/
function publishboard_unread_counters() {
global $user;
// Üres tömbökkel indulunk.
$unchanged = $changed = $list = $types = array();
// Az összes most nem közzétett node néhány adatára van szükség és a típusaik 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:

/**
* hook_block() megvalósítás.
*/
function publishboard_block($op = 'list', $delta = 0, $edit = array()) {
if ($op == 'list') {
// Egy blokkot biztosítunk a rendszer számára.
return array(0 => 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.
$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.

/**
* hook_menu() megvalósítás.
*/
function publishboard_menu($may_cache) {
$items = array();
// Cached menu items
if (!$may_cache) {
$items[] = array(
'path' => '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:

function publishboard_page($type) {
// 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:

function _phptemplate_variables($hook, $vars) {
  switch ($hook) {
    case 'comment':
        static $numnew;
        $numnew=$numnew?$numnew:0;
        if ($vars['new']) {
          $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ő.

<div class="comment<?php print ($comment->new) ? ' comment-new' : ''; print ($comment->status == COMMENT_NOT_PUBLISHED) ? ' comment-unpublished' : ''; ?> clear-block">
  <?php print $picture ?>
 
<!-- módosítandó rész eleje -->
<?php if ($comment->new) : ?>
  <a id="new"></a>
  <span class="new"><?php print $new ?></span>
<?php endif; ?>
<!-- vége -->
 
  <h3><?php print $title ?></h3>
 
  <div class="submitted">
    <?php print $submitted ?>
  </div>
 
  <div class="content">
    <?php print $content ?>
  </div>
 
  <?php print $links ?>
</div>

A megjegyzésekkel jelölt részt kell módosítani a következőre.

if ($comment->new) {
  if ($numnew == 1) {
    print '<a id="new"></a>';
  }
  print '<span class="new"><a name="new' . $numnew . '" '.
   'title="következő olvasatlan hozzászólás" href="#new' . ($numnew+1) . '">' . $new . '</a></span>';
}

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.

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.

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,4.

A Kék fiúkat pedig itt: www.honlapneve.hu/taxonomy/term/2,3.

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 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 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)
    • 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ómia-linkeket (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 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árom- vagy 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
      • 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:

    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ányMéret
    Kép ikon cck_viewfield.png13.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, 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 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

    egyedi regisztrációs űrlap létrehozása

    Feladat! Olyan regisztrációs felület létrehozása, mely túlmutat a Profil űrlapi mezők nyújtotta lehetőségeken. (pl. CCK mezők használata)

    Megoldás!

    Telepítendő modulok:
    - Content Profile
    - CCK
    - Conditional Fields

    Beállítás:
    CCK:
    A modul telepítésénél engedélyezzük a használni kívánt felületi elemeket. (Fieldgroup, Option Widgets)
    Content profile: A modult betöltve létrejön egy Profil tartalom típus. Vele egy tartalmat van lehetőségünk létrehozni. (ezt fogjuk majd felhasználni a regisztrációkor)
    Az Adminisztráció/Tartalomkezelés/Tartalomtípusok oldalon beállíthatjuk az újonnan létrejött típusunkat.
    A Szerkesztés alatt az általános tartalomtípus beállításokat találhatjuk. Új csoportként megjelenik a Tartalomprofil, ahol az "Ennek a tartalomtípusnak a használata, mint felhasználói tartalomprofil" opciót találjuk. Ezt engedélyezzük!
    A tartalom típus szerkesztő ablakának felső területen megjelennek extra hivatkozások, ezek sorban:
    Tartalomprofil: Itt lehet beállítani a profilinformációra vonatkozó opciókat. Fontos megemlíteni a Felhasználó regisztráció csoportban található Használat regisztráció során opciót. Ezt bejelölve engedélyezhetjük a tartalom típus, mint regisztrációs űrlapként történő használatát.
    Ha felhasználói döntéstől függő beviteli mezőket szeretnénk, akkor a mező hozzáadásakor (amennyiben select típusú mezőt hozunk létre) megjelenő beállító oldalon a Conditional fields settings csoportban tudjuk beállítani, hogy mitől függjön az adott elem megjelenése.
    Fontos, hogy csak azonos csoportba rendezett választó mezőktől lehet függővé tenni az adott beviteli mezőt.
    Létrehozzuk a kívánt regisztrációs tartalomtípusunkat és elérhető, mint egyedi regisztrációs
    űrlap.

    Remélem hasznos volt, hogy összefoglaltam a teendőket.

    Melyik modulhoz, modulokhoz kapcsolódik a téma?: 
    Drupal verzió: 

    Ú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)

     print $breadcrumb;

    Majd lecseréltem a következőre:

     
            mb_regex_encoding('utf-8');        
            print mb_ereg_replace('</div>',' ? '.$title.'</div>',$breadcrumb); 

    Persze lehetett volna "egyszerűbben" is:

     print $breadcrumb.' ? '.$title;

    Ekkor viszont a $title nem kerül bele a megfelelő <div> elembe így nem lesz hasonlóan formázva mint az útvonal többi eleme.

    Fontos felhívni a figyelmet, hogy mindig a multibyte string függvényeket használjuk, hisz a Drupal UTF-8 kódolással tárolja a szövegeket, és magyarok lévén nagy valószínűséggel találkozunk olyan esettel, amikor a hagyományos szövegkezelő függvények nem működnek megfelelően.

    Üdvözlőszöveg

    Andrássy Tamás kérdezte, hogyan lehetne hasonló képernyőt előállítani, mint ami a Drupal telepítésekor fogad minket. Mivel Tamásnak nagy köszönettel tartozunk, hiszen az ő lelkesedése hívta életre a Drupal.hu -t, ezért elkészítettem neki az alábbi modult, amit közre is adok, hátha más is szeretne hasonló nyitóoldalt:

    function cimoldal_menu($may_cache) {
    $items = array();
    if ($may_cache) {
    $items[] = array('title' => '', 'path' => 'cimoldal', 'callback' => 'cimoldal_page', 'type' => MENU_CALLBACK, 'access' => TRUE);
    }
    return $items;
    }
    function cimoldal_page($nid) {
    $result = db_query('SELECT body, format FROM {node} WHERE nid = %d', $nid);
    if ($node = db_fetch_object($result)) {
    print theme('page', theme('node', check_output($node->body, $node->format), FALSE, TRUE));
    }
    else {
    drupal_not_found();
    }
    }
    ?>

    Ez definiál egy cimoldal nevű Drupal útvonalat, ami után egy tartalom azonosító kell. Tehát, ha a node/1234 -ban van a tartalom, akkor cimoldal/1234 -en fogjuk találni a tartalom szövegét és a blokkokat (ne feledjük, hogy megadható, hogy melyik blokk hol jelenjen meg és hol nem).

    Grafikus felső menü

    A Drupal egyik apróbb problémája, hogy a felület nem nyújt lehetőséget szép, grafikus felső menüt összeállítani. Ezen könnyen segíthetünk egy megfelelő smink használatával. Vegyük a Marvin 2K sminket alapul, én annak a PHPtemplate-es változatából szoktam kiindulni.

    Az ötlet a List Apartról származik. A lényege az, hogy CSS-el készítünk kliens oldali térképet, mégpedig úgy, hogy linkeket megfelelő méretre "felfújunk" és a helyükre tolunk. Ilyenkor a linkek szövege csak zavaró, ezért azokat eltüntetjük. Háttérnek pedig betesszünk egy képet, ami a menüt alkotó ikonok egymás mellé rakásából keletkezett.

    A layout.css-ben a következő maradt meg a #main-nav -ra vonatkozó szabályokból:


    #main-nav {
    position: absolute;
    left: 180px;
    top: 53px;
    margin: 0;
    padding: 0;
    height: 69px;
    width: 435px;
    }

    A style.css-ben pedig ez:


    #main-nav {
    background: url(menu.jpg) no-repeat top left;
    }
    #main-nav li {
    list-style-type: none;
    float: left;
    display: inline;
    position: relative;
    width: 86px;
    }
    #main-nav li a {
    width: 86px;
    height: 69px;
    display: block;
    text-decoration: none;
    }
    #main-nav a span {
    visibility: hidden;
    }

    A phptemplate.engine-ben keressünk $links[$type][]-re, és azt a sort cseréljük a következőre:

    $links[$type][] = l(''. $value['text'][$i] .'', $value['link'][$i], $attributes);
    ?>

    Ezzel készen is vagyunk. Természetesen nem biztos, hogy pont 5*86 széles lesz a menüképünk, változassunk a fenti CSS-en értelemszerűen. De mi van akkor ha netán nem egyforma szélesek a menüikonok? Vagy szeretnénk a hivatkozott List Apart cikkhez hasonló módon rollovereket is? Ekkor a fenti sor helyett a következő kettőt írjuk a phptemplate.engine-be:

    $attributes['id'] = 'main-nav-link-'. $i;
    $links[$type]['main-nav-list-'. $i] = l(''. $value['text'][$i] .'', $value['link'][$i], $attributes);
    ?>

    És még a page.tpl.php-ben kell egy apró módosítás, keressünk ul id="main-nav"-re, és cseréljük a következőre:

    Így elértük, hogy minden egyes listaelemre és linkre egyedi azonosítóval hivatkozhatunk a CSS-ben: main-nav-list-0, main-nav-list-1 stb. illetve main-nav-link-0, main-nav-link-1 stb.

    Banner modul telepítése

    Az egyik barátom éppen most élesztette fel a banner modult Drupal 4.5.x alatt. Segítséget kért, mert hiába kapcsolta be a modult és állitott abban be bármit, a reklámcsíkok sehogy se akartak megjelenni. A hiba ott volt, hogy a xtemplate.patch fájlban leírtak szerint kellett volna módosítania három fájlt. Mivel a módosítások leírása nem volt igazán felhasználóbarát, úgy gondoltam, megpróbálom emberi nyelven leírni a lépéseket. Ezek a változtatások csak azoknak működnek, aki xtemplate alapú sminket használnak. Az alap rendszerben ilyen a bluemarine és a pushbutton.

    A themes/engines/xtemplate/xtemplate.engine fájlba a 139. sor környékén kell beszúrni a +-al megjelölt sorokat:


    $xtemplate->template->parse('header.site_name');
    }
    + if (function_exists('banner_display')) {
    + $xtemplate->template->assign('banner', banner_display());
    + $xtemplate->template->parse('header.banner');
    + }
    +
    if (theme_get_setting('toggle_slogan')) {
    $xtemplate->template->assign('site_slogan', variable_get('site_slogan', ''));
    $xtemplate->template->parse('header.site_slogan');

    A themes/bluemarine/xtemplate.xtmpl fájlba a 29. sor környékén kell beszúrni a +-al megjelölt sorokat.

    +

    +
    +

    +

    +

    +
    +

    {secondary_links}
    {primary_links}

    A themes/pushbutton/xtemplate.xtmpl fájlba a 33. sor környékén kell beszúrni a +-al megjelölt sorokat:

    +

    +
    +

    +

    +

    +
    +

    +

    {primary_links}

    Amint megvannak a változtatások, egyből működnie kell mindennek. Ám ismerősömnek nem felelt meg a reklámcsík helye. Ahelyett, hogy (telefonon keresztül) nekiálltunk volna a smink közös szerkesztésének, egy új blokkot készitettünk, a következő tartalommal:



    Ezzel elértük azt, hogy a reklámcsíkot bármelyik blokk pozícióra kirakhatjuk az oldalra. Természetesen ahhoz, hogy az eredeti helyéről eltűnjön a banner, vissza kellett állítani a három fájlt az eredeti állapotára.

    Egy kódbázisra több Drupal - nagy változások

    Eddig is volt erre lehetőség de most már a fejlesztői verzióban sokkal széles körűbbek a lehetőségek: nemcsak saját adattáblákat és/vagy adatbázist használhatunk, hanem saját modulokat és sminkeket is. Rögvest le is fordítottuk az INSTALL.txt vonatkozó részét.

    Az alapértelmezett beállításokat a feltelepített Drupal rendszer sites/default/settings.php fájlja tartalmazza. A további webhelyek beállításait alkönyvtárakba kell elhelyezzük. Minden webhely alkönyvtárának tartalmaznia kell egy settings.php fájlt, ezt legegyszerűbben az alapértelmezett settings.php lemásolásával és értelemszerű módosításával állíthatjuk elő. Az alkönyvtár nevét a webhely URL-jéből állítja elő a rendszer.

    A valahol.hu, a valami.valami.hu és a valami.valahol.hu/bolt3 külön-külön webhelyek lehetnek. Ehhez a következő alkönyvtárakra és fájlokra van szükség:

    • sites/valahol.hu/settings.php
    • sites/valami.valahol.hu/settings.php
    • sites/valami.valahol.hu.bolt3/settings.php

    A Drupal a http://valami.valahol.hu/bolt3 beállításait a következő helyeken keresi a megadott sorrendben, és az első találatot fogja használni:

    • sites/www.valami.valahol.hu.bolt3/settings.php
    • sites/valami.valahol.hu.bolt3/settings.php
    • sites/valahol.hu.bolt3/settings.php
    • sites/www.valami.valahol.hu/settings.php
    • sites/valami.valahol.hu/settings.php
    • sites/valahol.hu/settings.php
    • sites/default/settings.php

    Minden webhelynek lehetnek saját moduljai és sminkjei azon felül, amelyeket a normál modules és themes könyvtárakban találhatunk. Ehhez egyszerűen az adott webhelyhez tartozó könyvtárban kell modules és themes alkönyvtárakat létrehoznunk. Például ha a valami.valahol.hu használ egy saját sminket és egy saját modult, akkor a következő alkönyvtárakra és fájlokra lehet szükségünk:

    • sites/valami.valahol.hu/
    • sites/valami.valahol.hu/settings.php
    • sites/valami.valahol.hu/themes/sajat_theme/
    • sites/valami.valahol.hu/modules/sajat_module/

    További információkat a kézikönyvben találhatunk (majd).

    Alaprendszer frissítése drush segítségével

    Köszönet Den-nek az alábbi leírásért:

    Ezen frissítési leírás biztosan működik frissítési kiadások között, pl: 6.13 -> 6.14.

    Mindent ugyanúgy kell csinálni, ahogy a drupal telepítő készlet upgrade.txt-jében meg van határozva.

    Néhány telepítési pontban nagy segítséget nyűjt a drush:

    5.  Disable all custom and contributed modules.

    Ki kellene kapcsolni minden modult, amely nem az alap rendszer része. Erre tökéletesen alkalmas a drush. Először is kilistázzuk a bekapcsolt modulokat:

    $ drush statusmodules

    Minden parancsot a drupal telepítés főkönyvtárában kell kiadni.

    A statusmodules --pipe kapcsolóját használva egy olyan modul név listához jutunk, amely felhasználható a modulok be és kikapcsolásához is. Mindkét parancs üres karakterrel tagolt modul név listát vár. A --pipe pont ilyen listát ad:

    $ drush statusmodules --pipe
     
    admin_menu admin_menu_toolbar automenu block comment content content_copy custom_breadcrumbs date date_api date_popup date_timezone dblog excerpt extlink fieldgroup filefield filter globalredirect googleanalytics help image_fupload image_fupload_imagefield imageapi imageapi_gd imagecache imagecache_ui imagefield imce imce_wysiwyg jquery_ui locale menu menu_breadcrumb node nodereference nodewords noindex_external_links number optionwidgets page_title path path_redirect pathauto robotstxt seochecklist site_verify spamspan system taxonomy taxonomy_breadcrumb text token translation update upload user userreference wysiwyg

    Egy a baj ezzel a listával: olyan modulok is benne vannak, amelyek az alap rendszer részei (pl. node, system). Ezeket egy mozdulattal ki lehet szedni a listából. Ha nem így teszünk, akkor annak csúnya vége lehet. Próbáltam...

    $ drush statusmodules --pipe | sed 's! block ! !; s! filter ! !; s! node ! !; s! system ! !; s! user ! !; s! update ! !; s! menu ! !; s! path ! !; s! locale ! !;'

    A sed parancs egy unixos stream szerkesztő szövegek szűréséhez és átformálásához. Az s parancs a szöveg csere parancs. A határoló jelek között lévő szövegeket cseréli ki. Az s! block ! ! azt jelenti, hogy ahol a block szöveg szerepel üres karakterekkel határolva, azt cserélje le egy üres karakterre. Ha az üres karakterek nélkül adnánk ki a parancsot, akkor más block nevet tartalmazó modul nevét elrontaná a módszer.

    A fenti verzióban benne maradt még néhány, nem rendszer modult: menu, path, locale, update. Ha nincs update modul, akkor nem fog lefutni az adatbázis update.

    A fenti parancssor futtatása után már csak azokat a modulokat kapjuk a listában, amelyeket ténylegesen ki kell kapcsolni:

    admin_menu admin_menu_toolbar automenu comment content content_copy custom_breadcrumbs date date_api date_popup date_timezone dblog excerpt extlink fieldgroup filefield globalredirect googleanalytics help image_fupload image_fupload_imagefield imageapi imageapi_gd imagecache imagecache_ui imagefield imce imce_wysiwyg jquery_ui menu_breadcrumb nodereference nodewords noindex_external_links number optionwidgets page_title path_redirect pathauto robotstxt seochecklist site_verify spamspan taxonomy taxonomy_breadcrumb text token translation upload userreference wysiwyg

    Erre szükség lesz később is. Ha nem tudjuk elmenteni, akkor irányítsuk át egy állományba:

    $ drush statusmodules --pipe | sed 's! block ! !; s! filter ! !; s! node ! !; s! system ! !; s! user ! !; s! update ! !; s! menu ! !; s! path ! !; s! locale ! !;' > active_modules.lst

    Ezután az active_modules.lst állományt listázva megkaphatjuk azon modulok listáját, amit az alap rendszer frissítése előtt ki kell kapcsolni, majd a frissítés után meg be.

    A modulok kikapcsolása:

    $ drush disable admin_menu admin_menu_toolbar automenu comment content content_copy custom_breadcrumbs date date_api date_popup date_timezone dblog excerpt extlink fieldgroup filefield globalredirect googleanalytics help image_fupload image_fupload_imagefield imageapi imageapi_gd imagecache imagecache_ui imagefield imce imce_wysiwyg jquery_ui menu_breadcrumb nodereference nodewords noindex_external_links number optionwidgets page_title path_redirect pathauto robotstxt seochecklist site_verify spamspan taxonomy taxonomy_breadcrumb text token translation upload userreference wysiwyg

    Ezután végezzük el a rendszer frissítés többi pontját, egészen a 12.-es pontig:

    12. Re-enable custom and contributed modules and re-run update.php to update custom and contributed database tables.

    Itt megint hívjuk segítségül a drush-t és az elmentett modul listát:

    $ drush enable admin_menu admin_menu_toolbar automenu comment content content_copy custom_breadcrumbs date date_api date_popup date_timezone dblog excerpt extlink fieldgroup filefield globalredirect googleanalytics help image_fupload image_fupload_imagefield imageapi imageapi_gd imagecache imagecache_ui imagefield imce imce_wysiwyg jquery_ui menu_breadcrumb nodereference nodewords noindex_external_links number optionwidgets page_title path_redirect pathauto robotstxt seochecklist site_verify spamspan taxonomy taxonomy_breadcrumb text token translation upload userreference wysiwyg

    Ha minden jól megy, akkor azon modulok lesznek engedélyezve, amelyek frissítés előtt is voltak. Nem kell megjegyezni, nem kell felírni papírra semmit, a munka fárasztó részét a drush végezte.

    Folytassuk tovább a rendszer frissítést a 13. pontnál.

    Menü csak belépett felhasználóknak

    A Drupal.org-on már nem egyszer felütötte a fejét ez a kérdés, és most a magyar support listán is. Ebből az oldalból kihüvelyezhetjük, hogy a megoldás egy saját blokk létrehozása, aminek a tartalma:

    global $user;
    if ($user->uid) {
    if ($menu = theme_menu_tree()) {
    $menu = '

    ';
    return $menu;
    }
    }
    else {
    return;
    }
    ?>

    Ennél általánosabb megoldáshoz már saját modult kell írnunk. Ez elég, ha csak a hook_menu kampót valósítja meg, ennek segítségével az egyes menüpontokhoz megadhatunk tetszőleges jogosultságokat is.

    Egy kódbázisra több Drupal

    Gondoltam megosztom minden érdeklődővel tapasztalataimat a témában!

    Eleve egy olyan CMS rendszert kerestem ami képes arra, hogy egy telepítéssel és több adatbázissal futtatható legyen több portál egy tárterületen, úgy, hogy ha az egyik oldalon regisztrálta magát valaki akkor ez a regisztráció érvényes legyen minden eddigi és jövőbeli részlegre (nevezzük így egy drupal egy konfigurációját saját tartalmával).

    Szóval miután sikerült telepítenem a drupal-t a gyökérkönyvtárba, valamint az adatbázisba feltöltenem a database.mysql file-t, elérkezett a többi oldalnak a felvitele.

    Ehez az alábbi lépéseket kellet elvégezni:
    (végigmegyünk egy új oldal telepítésén, hogy egyszerű legyen a dolog)

    Szeretnék egy www.domain.hu/alfa oldalt feltelepíteni aminek legyen:

    • saját sminkje
    • saját tartalma (adatbázis táblák)
    • saját beálításai

    Hogy ezt elérjed, kell egy új cím ugyebár. Ezt egy szimbólikus link segítségével kaphatod meg.

    Gyökér URL: www.domain.hu
    Új URL: www.domain.hu/alfa

    Arról, hogy hogyan csinálhattsz ilyet UNIX alatt itt olvasshatsz bővebben.

    Ha nincs UNIX shell hozzáférésed a szolgáltatódnál olvassd el ezt!

    Ezek után szükséged lesz egy új configurációs állományra, ami leírja az új oldalat által használt:

    • adatbázist
    • adatbázis prefixumot
    • bázis URL-t
    • valamint a megosztott adatbázistáblák nevét

    Másold le és nevezzd át az /includes/conf.php -t. Vigyázat! Az új név legyen: www.domain.hu.alfa.php.

    Az elnevezés miértjéről itt olvasshatsz bővebben.

    Ebbe az új config fileba írd át/add hozzá az alábbi sorokat

    $db_prefix = array(
           "default" => "alfa",
           "users" => "",
           "sessions" => "",
           "role" => "",
           "authmap" => ""
           "sequences" => ""
           );

    default = a nem megosztani kívánt táblák prefixuma
    a többi a megosztani kívánt táblák prefixuma. Azaz ha az első durpal-t prefixum nélkül telepítettuk fel a mysql szerverre, akkor itt is NULL-t kell megadni a közös táblák prefixumára.
    $base_url = "http://www.endomainem.hu/alfa";

    Ezek után ha a www.domain.hu/alfa oldalra ellátogatsz akkor már működnie kell az új oldladnak. Egyből be kell tudond lépni az oldalra az első telepítésnél használt admin felhasználónévvel/jelszóval, mivel a users táblát megosztva használod.

    Ezek után mehet a testreszabás, smik kiválasztás stb.

    Mindenkinek sok szerencsét.

    Drupal fejlesztői bookmarklet

    A Drupal fejlesztői dokumetációja most már az api.module segítségével készül és a http://drupaldocs.org/ címen érhető el. Találunk itt egy pompás bookmarkletet is, melyet Walkah készített. A bookmarklet a felugró dialógus dobozba beírt Drupal függvény leírását keresi elő.

    Első lépések

    Ebben a rövid cikkben a Drupal telepítése utáni első néhány lépésben próbálok segíteni, mind a felhasználóknak, mind a programozóknak. Feltételezem, hogy sikerült a Drupal telepítése, s a kérdés már csak az: szép ez a valami, de hogy lesz ebből nekem végleges oldalam? Sikeres telepítés után a következő képernyő fogad minket:

    A bal felső sarokban a Druplicont láthatjuk. Az eredete a holland "druppel" (csepp). Ennek angol formája lett végül a "Drupal", annak kapcsán, hogy így megegyezik a kiejtése a holland eredetivel. A "Druplicon", azaz a Drupal logója egy cseppre épül. A szemei ravaszul egy végtelen jelet formálnak, ezzel finoman a Drupal képességeinek határaira akartak utalni állítólag a készítők...

    A Druplicon mellett most még nem sok minden van a fejlécben és az egyszerűség kedvéért ezeket most nem is tárgyaljuk.

    Alatta láthatjuk az első blokkunkat, a bejelentkezés (angolul login) blokkot. A blokkok egyszerű szövegdobozok, amik a bal vagy a jobb oldalon jelenhetnek meg. A blokkokat ki- és bekapcsolhatjuk, de lehetőséget adhatunk a felhasználóknak is erre. Egy blokkot beállíthatunk úgy is, hogy csak bizonyos oldalon jelenjen meg -- ez már a haladóbb fejezetbe tartozik azonban, reguláris kifejezések szükségesek hozzá. Blokkot kétféleképpen adhatunk meg: vagy programot írunk, vagy pedig egyszerűen begépelhetjük a tartalmát, mint ahogy az Ajánlott oldalak nevű blokkunkat mi is megvalósítottuk.

    Az adminisztráció (settings) oldalon egy nagyon érdekes bejegyzésre hívnám a figyelmet, ennek kapcsán jutunk el végre valahova. Talán már hallottuk, hogy a Drupalban minden, amit felviszünk egy node, melyet tartalomnak fordítottunk. Minden tartalomnak van egy összefoglalója, ez alapértelmezésben az első 600 karaktere. Ha behívjuk például a http://weblabor.hu/node címet, akkor láthatjuk a legutolsó tíz node összefoglalóját. Mivel a Drupal alapértelmezés szerint ezt az oldalt hívja be, ezért alapértelmezés szerint ezt a tízes összefoglalót fogjuk látni a legtöbb helyen.

    Természetesen egy -- nagyon rövid -- idő után több mint tíz node lesz. Valószínűleg szeretnénk valami szervezettséget is, s nem csak egymásra hányt oldalakat. Erre van a taxonómia (angolul taxonomy) modul, mely telepítés után be van kapcsolva. A feladata egy kategóriarendszer kialakítása. Ez a Drupal egyik legnagyobb erőssége: szótárakat alakíthatunk ki, minden szótárban kategóriákat, s a kategóriákhoz kapcsolódhatnak a tartalmak. Egy szótárban a kategóriákat háromféleképpen rendezhetjük el: egyrészt lehetséges, hogy csak egyszerűen fel vannak sorolva, anélkül, hogy hierarchiát alkotnának. Lehetséges egy egyszerű fa, olyan, mint a merevlemezünkön a mappák -- ilyenkor egy kategóriának egy szülőkategóriája van, de természetesen egy szülőnek több gyermeke is lehet. S végül a harmadik lehetőség, a gráfszerű kialakítás, ahol egy kategóriának számos szülőkategóriája is lehet, ezáltal egy bonyolult, de a tartalmaink szerepét az oldalon pontosan lefedő rendszert alkotva.

    A kategóriák megjelenhetnek egy blokkban, ahogy ezen az oldalon is történik.

    A modulok-blokkok sorát most még az archívum (archive) modult említem. Ennek a megjelenése egy naptár blokk, aminek segítségével kiválaszthatunk egy adott napot, és megjelennek az akkor készült tartalmak. Ha szeretnénk elérhetővé tenni a régebbi tartalmainkat (amelyek már nem férnek bele az első tízbe), akkor ez egy jó választás lehet ennek megoldására.

    Ilyen egyszerűen születik tehát egy Drupal site:

    • elkészítjük a szótárakat és a kategóriákat
    • kiválasztjuk a szükséges blokkokat, modulokat.
    • már lehet is feltölteni az oldalakat!

    A programozók saját igényeik szerint egészíthetik ki a rendszert, nekik ajánlom, hogy első ismerkedésként nézzék meg, hogy kezeli le a "node.module" a főoldalt, vagyis a "node path"-ot. Elsőként a "node_menu" függvényt érdemes megnézni, ott egy 'path' => 'node' bejegyzést lehet látni, ezen keresztül a "node_page" eljárás hívódik meg, onnan pedig a "node_page_default"-ra kerülünk. Érdemes megnézni még a "node_link" függvényt is. További példák vannak elvileg a http://drupal.org/doxygen/drupal/ címen, bár nekem mostanában nem töltődnek be a példaoldalak. Addig is megtalálhatjuk őket a http://drupal.kollm.org/tmp/drupal-phpdoc/ oldalon.

    Nos, ennyit bevezetésül, mindenkinek javaslom, hogy nézzen körül a beállítási lehetőségek között, és próbálja ki, mi mire való!

    A lusták modulja: taxonomy_html

    Egy nagyon gyorsan változó portálod van? Nincs kedved/időd állandóan a saját gyártmányú blokkjaidat szerkesztgetni és azt szeretnéd, hogy a taxonómiában beállított kategóriák egyből megjelenjenek a honlapodon? Ha igen, akkor a taxonomy_html.module -t neked találták ki..

    Vágjunk a közepébe: mit is csinál pontosan ez a modul? Blokkokat gyárt a taxonomiában szereplő szótárakból. Lépésről lépésre szeretném megmutatni, hogy mennyire egyszerűen.
    Elsőként is, töltsük le taxonomy_html a modult és másoljuk be a portálunk modules könyvtárába. Ezután engedélyezzük a modulok alatt az újdonsült szerzeményünket. Most pedig egy konkrét példán keresztül mutatom be, hogy működik.


    A taxonomy menüpontban létrehozok egy "Receptek" szótárt, azon belül pedig egy "süti" kategóriát, mivel szeretném a Bakláva receptemet feltenni. A "Receptek" -et a recipe kategóriába tettem. (A recipe is egy modul, amit külön le kel tölteni és installálni.)




    Nyomás a beállítások/blokkok menüpontba és láss csudát, ott csücsül a "receptek" blokk, már csak engedélyeznünk kell a kis négyzet kipipálásval.


    Ezek után hiába lessük a főoldalt, nem jelenik meg a "Receptek" blokk. Mégpedig azért, mert még nincs benne tartalom, az automatizálás csak létező tartalommal működik. Tehát tartalom beküldése menü -> recept (recipe) -> a recept begépelése. Megadom azt is, hogy a recepteken belül a süti kategóriában jelenjen meg:



    Beküldés és a főoldalon megjelenik a munkánk gyümölcse:


    Egy kis finomhangolás: a beállítások/modulok alatt található a taxonomy_html modul link, ha erre kattintunk, beállíthatjuk, hogy kihagyjon a blokkgyártásból bizonyos szótárakat. Válasszuk ki a listából (Omitted Vocabularies) ami nem kell.


    Csonti

    Ultimate Gallery

    Köszönet e cikkért mib kollégának.

    Elöljáróban annyit szeretnék megjegyezni, hogy nagyon sok galéria leírás van, viszont egyik sem elégítette ki azt a tudást amit elvárnék, így nekiálltam megcsinálni a sajátomat, amit ugyancsak lehetne még tökéletesíteni (és hogy mit azt majd a végén részletezem), de a célnak megfelel.

    Milyen modulokra lesz szükségünk?

    • cck
    • imagefield
    • filefield_paths
    • views
    • views attach module (node content nézett miatt)
    • imagecache + imagecache action (opcionális)
    • image_fupload
    • lightbox2

    A megvalósítás lépései

    Node

    Először létrehozunk 2 imagecache kép mintát, amit használni akarunk majd a galéria kiskép és nagykép megjelenítéseknél (referenciak_kiskep, referenciak_nagykep).

    Ez után 1 új tartalom típust (galéria) csinálunk, amiben kikapcsoljuk az alapértelmezett beállításokban hogy címlapra kerüljön, és ha van a hozzászólásokat is tiltjuk,

    galeria_node.png

    galeria_node2.png

    hozzáadunk egy fupload mezőt, és a következő beállításokat eszközöljük rajta: a multiple images per node-t választjuk, filepaths beállításba beállítjuk hogy az url-t és a file nevét tisztítsa meg, nagy betűket kicsinyítse le (az útvonal beállítás opcionális, én szeretem ha külön menti el a többi file-tól), ezen kívül hogy szükséges és az értékek száma korlátlan.

    galeria_node3.png

    galeria_node4.png

    galeria_node5.png

    galeria_node6.png

    A mező megjelenítésben label-t kikapcsoljuk, bevezetőre beállítunk egy kép megjelenítést (mindegy hogy mit, mivel nem ezt használjuk), a teljes nézetet meg elrejtjük.

    galeria_node7.png

    Views

    A viewsban 2 nézet fogunk létrehozni. Az egyik a galériákat gyűjti össze, a másik a node típust (galeria) formázza meg.

    Hozzunk létre egy új nézetet, névnek adjuk page_galeriak (ahol a page utal arra az oldalra ami a galériákat összegyűjti), nálam ez a referenciak oldal, így én a referencia_galeriak nevet adtam neki (továbbiakban page helyett a referenciát használom). A view type tartalom. Adjunk hozza egy page nézet típust. Sok beállítási lehetőség van de ami nekünk fontos az a következők:

    A szűrőknél 2 dolgot állítunk be, tartalom: közzétett és tartalom típus: Galéria

    A mezőknél ami fontos a tartalom: fupload mező amit a galeria típusnál beállítottunk. A többszörös értéket pipájuk be és értéknek adjuk az 1-et. A formátum résznél meg válasszuk az a imagecache mintát amit a kis képekhez készítettünk (nem a lightbox2-féle verziót).

    A page settings-nél meg állítsuk be a pathot és a menüt amihez hozzáadjuk.

    galeria_views.png

    galeria_views2.png

    galeria_views7.png

    Hozzuk létre a második nézetet is:

    Név referencia_node_content, view type tartalom. Adjunk hozzá egy új node_content nézet típust. A szűrőknél a beállítások ugyan azok mint az előbb, a mezőknél annyiban módosul hogy nincs többszörös érték csoportosítás és a formátumnál a lightbox2-t állítjuk be a kiskép nagykép váltáshoz. (ligthbox2: kiskep->nagykep). Az argumentumnál a tartalom node id-t állítjuk be és ami fontos az a validator galéria típus. A node content settings-nél a tartalom típus a galéria.

    galeria_views3.png

    galeria_views5.png

    galeria_views6.png

    Ezzel meg is volnánk. Ami még hiányzik az egy vissza link a galériákból, amit könnyen hozzá tudunk adni a node_content view template file-hoz. Mivel én a rács megjelenítést használom a tpl.php-m a views-view-grid--referencia-node-content--node-content-1.tpl.php. A file végére illesszük be ezt:
    ahol a referenciak az a oldal ahol összegyűjtjük a galériákat.

    A kész galéria

    galeria.pnggaleria2.png

    Pro

    • A taxonomyval ellentétben úgy lehet képeket törölni hogy azt látjuk is.
    • Ha akarjuk az ajaxos pager könnyen megvalósítható.
    • A galéria létrehozása és a képek feltöltése egy azon lapon történik a tartalom beküldésben, ellenben image gallery-vel ami taxonomyt használ, és elösször a galériát kell létrehozni (ami nem a tartalom beküldés oldalon van!), utánna meg a képeket beküldeni egyesével (lehet image import is de ahoz elöbb serverre fell kell tölteni képeket, ami megintcsak gáz), így az image gallery nem user frendly.

    Kontra, vagyis mit lehetne még fejleszteni rajta?

    Ami kimaradt az a galériában galéria funkció, ami könnyen megoldhatunk a node reference url widgettel, viszont ez még több megoldandó feladatott eredményezne. pl. hogyha kitörlünk egy szülő galériát akkor az összes gyermek galériát is kitörölje a képekkel együtt. Ezen kívül még kéne egy breadcrumb funkció ahol a galériákat tudnánk nyomon követni. Az én véleményem az hogy ez csak összezavarná usereket, így jobb ha galériának nem lehet gyermek galériája.

    És az elmaradhatatlan hibák

    A filefield path beállításánál nekem nem működött a külön galériák szerinti kép mentés, és az imagecache sem törli ki a létrehozott majd törölt képek file-jait. (és ezzel a modul fejlesztők is tisztában vannak, szal még nem tökéletes). A másik hiba ami még előjöhet hogy fupload modul nem kompatibilis az fck editorral így minden a törsz mezőbe beírt szöveget töröl és <!--break--> jelet írja be helyette így én ideglenesen ki is kapcsoltam fck editort a galéria tartalom típusnál.

    Sok sikert hozzá, MiB

    A Magyar Drupal Kézikönyvről

    A Magyar Drupal Kézikönyv ilyen formában történő létrejöttét a Drupal könyv (book) modulja tette lehetővé. Ennek segítségével a webhely bármely tartalmát be tudjuk illeszteni a kézikönyvbe, kialakítva egy tartalmi rendszert a különböző információk könnyű elérhetősége érdekében.

    A teljes kézikönyv egyben nyomtatható változatban is elérhető, illetve az egyes alfejezetek külön-külön is kérhetőek nyomtatóbarát formában minden alájuk tartozó tartalommal együtt.

    Reményeink szerint a kézikönyv kialakítása igazi kollaboratív együttműködő formában valósulhat meg. Webhelyünk minden felhasználójának lehetősége van 'történet' típusú tartalmak beküldésére, melyek hírként, cikként, vagy akár kézikönyv lapként is funkcionálhatnak. Azt sem zárja ki semmi, hogy egy időtálló hír vagy cikk a kézikönyv tartalomjegyzékében is megjelenjen. Ezért szeretnénk minden felhasználónkat buzdítani arra, hogy járuljon hozzá a kézikönyv bővítéséhez, hozzászólások formájában tegyen javaslatot egyes oldalak jobbítására. A beküldött tartalmakat a webhelyek adminisztrátorai a megfelelő helyre sorolják majd be.

    A Drupal.hu és a kézikönyv licence

    A Magyar Drupal Kézikönyv és a Drupal.hu más tartalmai a Creative Commons Attribution-ShareAlike 2.0 (magyarul Creative Commons Nevezd meg! - Így add tovább! 2.0) licenc szerint érhetők el, és használhatók fel. Ez röviden azt jelenti, hogy a dokumentum újrahasznosításakor az eredeti szerzőket mindenképpen ki kell emelni, és a keletkező dokumentum más licenc alatt nem terjeszthető. Ezen két megkötés akkor nem kötelező érvényű, ha a szerzők egy kérelmezőt kivételes lehetőségekkel ruháznak fel. Ez a rövid összefoglaló természetesen nem helyettesíti a licenc teljes szövegét.

    A Magyar Drupal Kézikönyv tartalmaz lefordított részeket a Drupal Handbook dokumentumból, mely ugyanezen licenc szerint érhető el és használható fel, és melynek szerzői listája a Handbookban olvasható.

    A Drupal.hu fejléce Juan23 Creative Commons Attribution-NonCommercial-ShareAlike licenc szerint közzétett fotójának felhasználásával készült.

    Fogalomtár

    B

    Blokk #
    A blokkok dobozok, amik általában a honlap oldalsávjaiban helyezkednek el. A blokkokat létrehozhat a rendszer adminisztrátora, ekkor általában statikus szöveget tartalmaznak, de a blokkok tartalmát modulok is előállíthatják dinamikusan frissülő tartalommal, pl. a legfrissebb hozzászólások blokkja.

    Back to Top

    C

    CMS (Content Management System) #
    Lásd: Tartalomkezelő rendszer
    Cron #
    Az angol chronograph szó rövidítése. A linux rendszereken az időzített feladatok beállítására használt segédprogram. A Drupal hatékony használatához szükséges a cron használata.

    Back to Top

    D

    Drupal #
    A Drupal szó a holland Druppel szóból jött létre, magyar fordítása: csepp. A Drupal egyszerre tartalomkezelő rendszer, honlapépítő keretrendszer és utal a Drupal rendszer körül kialakult közösségre is.
    Druplicon #
    A Druplicon a Drupal kabala figurája. A szó a Drupal és az Icon (magyarul ikon) szavak összevonásából keletkezett.
    Drush #
    A drush egy PHP nyelven írt parancssori segédeszköz, ami felgyorsítja a honlap fejlesztését és adminisztrálását.

    Back to Top

    E

    Egyszerű oldal #
    Az egyszerű oldal egy olyan tartalomtípus, amely a honlap statikus szövegeit tartalmazza. Ezek az oldalak elérhetők a honlap menürendszeréből, vagy más oldalról belinkelve. A Drupal telepítése után azonnal használható ez a tartalomtípus, mert a Drupal alapértelmezett telepítési profiljában engedélyett.

    Back to Top

    Gy

    Gyorsítótár #
    A Drupal alaprendszere gyorstárazza a névtelen felhasználók által megtekintett oldalakat és blokkokat az adatbázisban. Emellett más modulokkal segítségével is megvalósítható a gyorsítótár, pl.: boost, memcache, authcache.

    Back to Top

    M

    A morzsák vagy morzsaútvonalak olyan linkek, amik egy keskeny vízszintes navigációs sávban helyezkednek el, általában az oldal tetején. Ezek a linkek próbálják mutatni, hogy az aktuális oldal hol helyezkedik honlap oldalainak hierarchiájában. A kenyérmorzsa-navigáció elnevezése a Jancsi és Juliska című népmeséből ered: a Felhasználó úgy ássa bele magát a webhely „rengetegébe”, ahogy Jancsi a későbbi visszataláláshoz kenyérmorzsát hint az útra. Egy példa a Drupal kézikönyvből:
    Címlap » Magyar Drupal Kézikönyv » Telepítés lépésről lépésre

    Back to Top

    N

    Névtelen látogató #
    A névtelen látogató mindenki, aki az honlapot böngészi, de nincs bejelentkezve. A névtelen felhasználók felhasználói azonosítója 0, és a Névtelen látogató csoportba tartoznak.

    Back to Top

    R

    Rövid webcímek #
    Alapértelmezésben – a Drupal telepítése után – ilyen egy oldal URL-je:
    http://www.example.com/?q=node/83
    Ha engedélyezzük a rövid webcímek használatát (Adminisztráció » Beállítások » Keresés és metaadatok » Rövid webcímek), akkor az URL cím így lesz átírva:
    http://www.example.com/node/83

    Back to Top

    Sz

    Szöveg formátumok #
    A szövegformátumok szűrőkből állnak, amelyek átalakítják a felhasználók által bevitt szövegeket, például kiszűrik a káros HTML jelölőket, vagy kattintható hivatkozássá alakítják a webcímeket.

    Back to Top

    T

    Tartalom #
    A honlapon található információt hordozó szövegeket, képeket stb. nevezzük tartalomnak. A legfontosabb tartalmakat Drupal alatt node-nak hívják, de emelett léteznek más tartalmak is, pl. hozzászólások, csatolmányok.
    Tartalomkezelő rendszer #
    A tartalomkezelő rendszer (TKR vagy angol rövidítéssel CMS) egy marketing kifejezés azokra a szoftverekre, amelyeket több személy együttműködésével készülő munkák koordinálására dolgoztak ki.
    Bővebben: http://hu.wikipedia.org/wiki/Tartalomkezel%C5%91_rendszerek
    Tartalomtípus #
    Minden olyan tartalom – ami node – besorolható egy tartalomtípusba. A különböző tartalomtípusoknak vannak közös jellemzőik, pl. a tartalom létrehozásának időpontja, közzétett-e a tartalom, és vannak csak az adott tartalomtípusra vonatkozó jellemzők. Tartalomtípust létrehozhat a honlap adminisztrátora, de a Drupal moduljai is definiálhatnak ilyet.

    Back to Top

    Gyakran Ismételt Kérdések

    IRC

    Miről van szó?
    A Drupal.hu fekete öves kommentelőit és használóit találhatod meg az alábbi IRC csatornákon. Ha gyors válaszra vársz, nézz be, tedd fel a kérdéseid, hasonlóan a drupal.hu fórumon, igyekszünk válaszolni is.

    Mire jó?
    Ha szeretnél aktív tagja lenni a magyar közösségnek, nézz be és maradj egy csevejre.

    Csatornák:

    • #drupal.hu
      általános drupallal kapcsolatos kérdések merülnek fel
    • #drupalhu-contrib
      inkább fejlesztőknek fenntartott csatorna

    Javasolt IRC kliensek:

    Konfigurálási javaslatok:

    • Szerver: irc.freenode.net
    • User name: javasolt a drupal.hu felhasználó neved
    • Karakter kódolás: kérlek figyelj rá, hogy a beviteli forma utf-8 legyen.

    Regisztráld a nick nevedet a Freenode IRC hálózatán

    Amikor első alkalommal lépsz be a Drupal közösségnek helyet adó Freenode IRC csatornára, akkor érdemes a nick nevedet beregisztrálni a NickServer segítségével, hogy később ne használhassa azt senki más.

    A nick név gyakorlatilag a felhasználói nevedet jelenti az IRC csatornán. Azt javasoljuk, hogy ha lehet, akkor ez egyezzen meg vagy a Drupal.org vagy a Drupal.hu portálokon használt azonosítóddal. Így könnyebben ismerünk fel a csetszobában.

    Kövesd a következő kezdő lépéseket az állandó nicknév létrehozásához:

    1. A csatornára belépéskor meg kell adnod a nick nevet, pl: VezeteknevKeresztnev
    2. A belépés után gépeld be következő sort helyesen kitöltve. A szögletes zárójelek nélkül írd be a választott jelszót és az email címedet.

      /msg NickServ REGISTER [jelszo] [email]

    3. Hamarosan kapsz egy levelet a freenode-tól a következő tartalommal:

      In order to complete your registration, you must send the following command on IRC:

      /msg NickServ VERIFY REGISTER nickneved azonositojelszo

    4. A levélben kapott /msg kezdetű sort másold ki és írd be az IRC kliens parancssori ablakba, ezzel igazolod vissza a regisztrációdat.
    5. Lehetőséged van arra, hogy mások számára elrejtsd a korábban megadott email címedet a következő parancs használatával:

      /msg NickServ SET HIDEMAIL ON

    6. Amennyiben az IRC kliens nem tárolja el az azonosító nevet és jelszavat, úgy az alábbi parancs elküldésével tudod magadat azonosítani:

      /msg NickServ IDENTIFY nicknev jelszo

    Hasznos tanácsok:

    • Ha elakadnál valahol az IRC használatában vagy a regisztráció során, akkor kérd a magyarországi közösség aktív tagjainak segítségét a fórumot használva.

    Linkgalériával kapcsolatos kérdések

    A portálon található Linkgaléria segítségével áttekintést kaphatunk a Drupal rendszer felhasználási területeiről és a hazai Drupal fejlesztésekről.

    Hogyan tudom a linkgalériában megjelentetni a honlapomat?
    Regisztráció és bejelentkezés után a Tartalom beküldése -> Link menüponton keresztül.
    Mire kell figyelnem a beküldésnél?
    Gyakori hiba az űrlap kitöltésénél, hogy a felhasználók felcserélik a „Webhely neve” és a „Link webcíme” mezőket. A webhely neve a galériában megjelenő tartalom címe lesz, pl. „Drupal – közösségi portál”. A link webcíme a webhely címe a http:// előtaggal együtt, pl. http://drupal.hu. Kérjük segítsd a munkánkat a mezők pontos kitöltésével.
    Milyen címkéket tegyek a beküldött tartalomra?
    A címkék a drupal.hu adminisztrátorait segítik a tartalom kategorizálásában. Bármilyen címke használható, akár több is, de ezeket az adminisztrátorok átírhatják annak érdekében, hogy a látogatók könnyebben át tudják tekinteni a Drupal felhasználási területeit. Például nincs külön „szobafestő” és „vízvezetékszerelő” címke, ezeket „mesterember” címszó alatt vonjuk össze.
    Mi szerepeljen a leírásban?
    A leírásban szerepelhet egy legfeljebb egy mondat hosszúságú leírás a webhely tulajdonosának tevékenységéről. Ezen túl csak a fejlesztés technikai vonatkozásairól szóló szöveget fogadunk el. Az adminisztrátorok fenntartják a jogot, hogy a megítélésük szerint túlságosan reklámízű, vagy nyilvánvalóan keresőoptimalizálási célú szövegeket átírják vagy teljesen töröljék.

    Ezt a szabályt újonnan léptettük életbe, a korábban beküldött linkeknél előfordulhat hosszabb tevékenységi leírás, ezeket utólag nem moderáltuk.

    Ki készíti a képernyőképet?
    Az adminisztrátorok.
    Sikerült telepítenem a Drupalt, beküldhetem a webhelyet a galériába?
    Gratulálunk a sikeres telepítéshez, de a galériába csak működő webhelyeket veszünk fel. Kérjük akkor küldd be a linket, ha már van értékelhető tartalom a honlapon.
    Mikor jelenik meg a beküldött link a galériában?
    Az adminisztrátorok legalább havonta egyszer közzéteszik a beérkezett linkeket. Ha egy hónapnál régebben beküldött link nem jelent meg, kérjük jelezd a kapcsolati űrlapon keresztül a hibát és utánanézünk.
    Ki és milyen szempontok alapján dönt arról, hogy melyik webhely kapja meg az „Ajánlott” jelzést?
    Az „Ajánlott” jelzés odaítéléséről az adminisztrátorok egymás között egyeztetnek. Fontos megjegyezni, hogy a hazai Drupal fejlesztések színvonala egyre emelkedik. Egy olyan honlap, ami néhány évvel ezelőtt még kiemelkedőnek számított, ma már nem biztos, hogy megkapná az „Ajánlott” jelzést. Ezért a megjelölt webhelyek inkább a trendek áttekintését teszik lehetővé.
    Politikai honlapokra és webfejlesztők bemutatkozó webhelyeire a félreértések elkerülése végett nem teszünk „Ajánlott” jelzést. Ezt a szabályt újonnan léptettük életbe, a korábban beküldött linkeknél előfordulhat ajánlás politikai vagy fejlesztői oldalakon.
    Találtam az interneten egy Drupal alapú webhelyet, beküldhetem?
    Természetesen. Nem szükséges, hogy a beküldő a webhely tulajdonosa, vagy fejlesztője legyen.
    Találtam a galériában egy szép Drupal alapú webhelyet, én is ilyet szeretnék magamnak. Hogyan tudom felvenni a fejlesztővel a kapcsolatot?
    A legtöbb webhelyen a láblécben vagy külön impresszum oldalon feltüntetik a fejlesztő elérhetőségét. Ha ilyet nem találunk, kérdezzük meg a webhely tulajdonosát. Végső esetben itt a fórumon is érdeklődhetünk. Arra nincs garancia, hogy az a felhasználó, aki a webhelyet a galériába beküldte, azonos a fejlesztővel.
    Beküldhetek-e olyan webhelyet, amelyet nem Drupal rendszer működtet?
    A galériában csak Drupal alapú honlapokat mutatunk be, az adminisztrátorok a forráskód ellenőrzésével kiszűrik a más technológiával készült webhelyeket.
    Beküldhetek-e olyan webhelyet, amelyet Drupal rendszer működtet, de nem magyar nyelvű?
    A galériában csak magyar nyelvű webhelyeket szerepeltetünk. Természetesen szívesen látunk többnyelvű honlapokat, ha az egyik nyelv a magyar – ebben az esetben kérjük, hogy a beküldött webcím a magyar nyelvű nyitólapra mutasson.
    Hibát találtam a galériában, mi a teendőm?
    Kérjük jelezd a kapcsolati űrlapunkon keresztül. Lehetséges hibák például:
    • nem működő link
    • nem Drupal alapú honlap
    • többszörös beküldés

    Köszönjük a beküldött linkeket, kellemes és tanulságos nézelődést kívánunk!