Keresés

Részletes böngészhető fordítási információ

Hojtsy Gábor képe

Mostantól érhetőek el webhelyünkön a fordító csapat külön információs oldalai, amelyeken részletek találhatóak a csapat által alkalmazott fordítási konvenciókról, sőt a munkához használt változáskövető rendszer teljes aktuális tartalma is böngészhető. Ebben megtalálhatóak a legfrissebb fordítások a kiegészítő modulok és sminkek fordításaival is. Mindez nem jelenti azt, hogy a magyar felület fájlok nem kerülnek fel a drupal.org csomagoló rendszerébe, a saját kényelmes felületünk azonban a fordítás állapotának és a fordító személyeknek a nyomonkövetésére is alkalmas.

Kategóriák: 

Modulok fejlesztése

Hojtsy Gábor képe

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.

Modulok helye, elnevezése és a hurkok

Hojtsy Gábor képe

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.

A visszafogó könnyebben beállítható felületet kapott

Hojtsy Gábor képe

A Drupal arról is ismert, hogy nagyon jól ellen tud állni a terhelés nagy ugrásainak is, melyeket szokatlanul nagy forgalom okozhat. Ezekben az esetekben egy jól beállított Drupal rendszer a visszafogó (angolul throttle) funkcionalitásnak köszönhetően ki tudja kapcsolni a rendszer egyes részeit (modulokat, blokkokat), így csökkentve az egyes oldalak előállításának erőforrásigényét.

Ez a beállítás mindeddig nem volt túl intuitív, hiszen a visszafogó sok szintet támogatott ugyan, de lényegében csak kettőt különböztetett meg. Ezen kívül az egy perc alatt érkező kérések számát kellett megadni, ami nem feltétlenül könnyen becsülhető. Az új rendszerben valóban csak két szint létezik, és a bekapcsolás ezentúl a webhelyen lévő anoním vagy belépett felhasználók számához köthető. Ez a változás azért lehet előnyös, mert folyamatosan figyelhetjük az online felhasználók számát, míg az utóbbi egy perc kiszolgált kéréseinek áttekintésére ilyen eszköz nem áll rendelkezésére. Ezen kívül jellemző, hogy a keresőrobotok és az új látogatók anoním felhasználólóként jelennek meg a rendszerben, és pont ezek okozzák általában a problémát, ezért a számuk jó alap lehet a terhelés becslésére.

A változás a 4.6.0-ás kiadásban jelenik majd meg, a fejlesztői verzióba a mai napon került be, jelentősen csökkentve ezzel a modul forráskódjának méretét.

Formok implementálása: mi változott az 4.5-ben?

kuller képe

Ugyan nem másik rendszer, de migráció:

Eddig 2 saját "modult" vagy inkább modulnak látszó tárgyat:) fejlesztettem a drupalhoz. Ezek tulajdonképpen függvényraktárak, így egy tartalomként beküldött függvénynév és paraméter (és a PHP kapcsoló) segítségével oldalakat, lekérdezéseket tudok generálni és menüpontokat illeszteni hozzájuk. Mindkettő külön rendszerben fut. Mindkettő tartalmaz formokat. Amikor upgradeltem 4.5-re mindkettő működése megváltozott: a modulok nem az indulási oldalt hívják meg a submit gomb lenyomása után, hanem az alap "node"-t.

Lebutítottam az egyik modult erre: "function telefonkonyv(){print(form(form_textfield('Névre', 'textfield_nev', $node->textfield_nev, 40, 40 ) . form_submit('Keresés'), $method = "post"));}", a hibajelenség megmaradt. Így már majdnem biztos, hogy a form környékén lehet a hiba. Megnéztem a form implementációját: változatlan. ("http://drupaldocs.org/api/4.5/function/form") Azonban valami változhatott (az eval függvény környékén), mert most már a php nyitó és záró tagokat is bele kell plántálni a kódba. Az $action paramétert nem használom, de beírva az urlt-sem jó. Sőt ha álnevet adok a lapnak, akkor sem lesz jó. A böngésző címsorában kiírja a helyes urlt, de nem hívja meg. Ha frissítek akkor sem, csak ha az urlbe viszem a kurzort és nyomok egy entert. (Firefoxot használok.)

Gondoltam, hogy a modulok bezavarhatnak, mert a toxonomy_menu, nodeperm_role, nodeperm_taxonomy és a nodeperm_user modulokat használom. Kikapcsoltam őket, de a hibajelenség továbbra is fennáll. Végül a view jogokat mindenkinek megadtam és a toxonomy_menu-t sem használom már, a "telefonkönyv" modulnak nem a taxonomy_menu generálja a menüt, sajnos eredmény nélkül.

Megakadtam, nem tudom merre keressek tovább..

Drupal SQL nélkül

Anonymous képe

Az lenne a kérdésem, hogy elképzelhető-e (van-e jele annak, hogy) a Drupal SQL nélkül is menjen a jövőben? Sajnos valamiért a rendszergazdánk nem akar MySQL-t telepíteni, pedig jócskán megkönnyítené a dolgomat:( Esetleg tudnátok egy megbízható SQL nélküli portálmotort mondani?

üdv: yaanno

Fórum: 

Lektorált fordítás

Anonymous képe

Szorgos munka zajlik a fordító csapatban! Menet közben sok minden felmerült, akit esetleg részletesebben érdekel, az láthatja az archívum-ban.

A lényeg, amiért most jelzéssel élek: igény látszik más szempontú fordítási megoldásra is.

Az egyik: tegezős változat,

A másik: néhány esetben más szóhasználat és eltérő megoldás.

Aki szívesen résztvesz a módosítás kialakításában, az
jelezzen itt
, vagy a Skype használatával az a.tamas felhasználót keresve.

Valójában a fordító csapat által már kimunkált hivatalos kiadás a színvonalas lektorálásáról van szó, ezzel egy-két alternatív megoldást is ajánlva a Drupal.hu-n.

Smink

barbq@www.femfatal.hu képe

olvastam a "theme" körüli vitákról, és arról, hogy a smink tűnik a legjobb választásnak... én mégis idegenkedem tőle.

ha már antropomorfizáljuk a "theme" szót, a smink helyett miért nem inkább a "maszk"? Szerintem jobban fedi a "themeing" lényegét, mert a smink mögött felismerhetőek az alapvonások, míg egy maszkban egészen máshogy is kinézhetsz.

Szervert vált a Drupal.org

Bártházi András képe

A Drupal.org honlap az utóbbi időben kicsit lelassult, köszönhetően a 4.5.0-s kiadás megjelenésének, s az ezt követő érdeklődésnek (napi több, mint 10 000 feletti látogatószámuk van). Most úgy döntöttek, hogy egy új, modernebb szerverre állnak át a héten, s egyúttal hosztoló céget is váltanak. A váltás közben előfordulhat, hogy nem lesznek elérhetők az oldal szolgáltatásai, mint a weblap, levelezőlisták és a CVS repository.

A régi szerver egy PIII, 1 GHz-es gép volt, az új egy Pentium Xeon, 3 GHz-es gép lesz. A régi szerver nem csak a Drupal.org-ot, s kapcsolódó szolgáltatásait, hanem más oldalakat is kiszolgált, így valószínűleg nagyságrendi változás fog beállni az oldal sebességét illetően.

Az oldal terhelt állapota azonban nem csak lassúságot, de a Drupalt használók számára előnyt is jelentett, ugyanis ennek kapcsán a fejlesztők ki tudtak próbálni pár javítást, melyek növelték az oldal sebességét (már benn vannak a CVS-ben).

A fejlesztők a támogatásokat is szívesen fogadják a felmerült költségeik kapcsán (LinuxTag brosúra, illetve most a szerver költségei).

Az eredeti hír: Drupal.org, speed and the future.

Kategóriák: