Weblabor

A Weblabor váltott. Mégpedig nem kis lépést tettünk: PostNuke rendszerünkről egy teljesen más családba tartozó keretrendszerre váltottunk, a nyílt forráskódú Drupal csomagra. Biztos vagyok benne, hogy sokakban felmerül a kérdés, hogy miért pont ezt a rendszert "szúrtuk ki", és miért nem választottuk a kényelmes megoldást, maradva a PostNuke mellett; illetve miért nem fogtunk saját keretrendszer kialakításába, mely kifejezetten a saját igényeink kielégítésére született volna. Készen állunk a válaszokkal.

A Weblabor 1999 májusában indult nagy tervekkel, melyekből az idő és a résztvevők jelentős számának hiánya miatt az első időszakban csak néhány komolyabb ötlet valósult meg. Kezdetben statikus oldalak, majd saját fejlesztésű Perl háttérprogramok és Verhás Péter JAMAL feldolgozója által generált oldalak uralták a webhelyet. A jelenlegi Weblabor már egyáltalán nem hasonlít az eredeti oldalra, az akkori elképzeléseket azonban minden korábbinál jobban megközelíti. Ez azt jelenti, hogy közösségi szolgáltatásokat biztosít non-profit módon, úgy, hogy ez lehetőleg az olvasók egy részét is az aktív és produktív részvételre buzdítsa.

A jelenlegi Weblabor tartalmi hátterét lényegében a 2001-ben indult, és szintén sok hullámvölgyet megélt PHPInfo adja, kiegészülve az eredeti Weblaborból megmaradt népszerű levelezőlistákkal és ezek archívumával. Az egyesüléssel az volt a szándékunk, hogy a hírekben, fórumokban, linkgyűjteményben és archivált levelekben felhalmozott óriási tudásanyag elérését megkönnyítsük, egységes felületen elérhetővé tegyük. Olyan rendszerre volt tehát szükségünk, mely mindezeket lehetővé teszi számunkra alapkiépítésben vagy kevés fejlesztéssel.

Rendkívül fontos szempontnak tartottunk, hogy a bevitt tartalmakat a Weblabor és a PHPInfo részéről is megőrizhessük, tehát olyan rendszerre volt szükségünk, amelybe a PostNuke által kezelt adatainkat és a leveleket is be tudtuk importálni. Nem volt elhanyagolható szempont, hogy a rendszerben az általunk is népszerűsített web szabványok használatával jelenjenek meg ezek a tartalmak, mely lehetőség szerint jó kereső találatok elérésében is segíthet minket.

Választásunk megértéséhez mindenképpen érdemes szem előtt tartani, hogy végső soron nem egy sokadik portálrendszer kifejlesztésével szerettünk volna felvágni az olvasók előtt. Ha egy ilyen rendszert saját célunkra fejlesztünk ki, akkor nem lett volna elegendően általános, tehát publikálásának nem lett volna hatása az egyébként is kellően telített tartalomkezelő-rendszer palettán. Ha azonban általános rendszert fejlesztettünk volna, akkor ez egyrészt jelentősen több időbe telt volna, másrészt utána a további fejlesztés koordinálásával, a 'termék' támogatásával kapcsolatos kérdésekkel is foglalkoznunk kellett volna. Mi pedig éppenséggel a közösség érdekében végzett tartalomszolgáltatáshoz kerestünk egy rendszert, és nem egy újabb keret fejlesztését szerettük volna a vállunkra venni. Természetesen a Weblabor készítői legtöbben saját CMS rendszerekkel is rendelkeznek, ezek azonban nem nyílt forráskódú termékek, és így a céljainkra történő adaptálásba nehéz lett volna segítőket is bevonni.

A legegyszerűbb választás kétségtelenül az lett volna, ha a PostNuke rendszer mellett maradunk, hiszen ez már úgy-ahogy működött, és adatmigrációra sem lett volna szükség. Valójában végeztünk egy 'gondolatkísérletet' ezzel az ötlettel, amikor a PostNuke külsőjét a PHPInfo megjelenéséről a Weblaborra állítottuk át. Az erre a célra fejlesztett smink (theme) készítésekor alaposan bele kellett ásnunk magunkat a PostNuke belső világába. A PostNuke nem ad támogatást arra, hogy a tartalom összeállítása során több ponton is beavatkozzon egy webhely tulajdonos a folyamatba saját PHP kódjával. A PostNukehoz készült URL szépítő eljárások is mind úgy működnek, hogy a generált kimenetet alakítják át, és a bemeneten visszaalakítják azokat. Hasonló problémáink akadtak, amikor szabványos HTML kód generálására próbáltuk rávenni a rendszert. A HTML generálás utáni utólagos szűrőket kellett alkalmaznunk, mert a PostNuke legtöbb része nem sminkelhető. Ezzel csak részben tudtuk csökkenteni a PostNuke által generált HTML szemetet.

Ráadásul a PostNuke által megjelenített oldalak minden esetben teljesen adatbázisból generálódnak, amely igen lassúvá és a szerver számára terhelővé teszi a PostNuke futtatását. A különböző felhasználói opciók sokszor az URLekben is megjelennek, ezzel az URLek továbbküldésére nincs lehetőség. A különböző modulok inkább lazán egymás mellett élnek, minthogy együttműködnének, a linkek és a fórumok eléggé önálló adatbázis struktúrával és kóddal rendelkeznek, az adatbázisban tárolt adatokat is duplikálják. Ez nem könnyítette meg számunkra az adatok tisztítását.

Tudjuk, hogy a PostNuke fejlesztők dolgoznak az említett hibák javításán, ám éppen az ezek körüli viták okozták a Xaraya és az Envolution CMS projektek elindulását. Az a tény, hogy az eredeti fejlesztők jó része kivált a PostNukeból, azt is sejteti, hogy nem lesz komoly fejlődés a közeljövőben. Ráadásul a Nuke rendszerek körüli nagy szegmentálódás azt is jelzi, hogy a különböző (eredetileg a PHPNukeban illetve Thatwareben gyökerező) projektek nem támogatják jól a fejlesztői együttműködést, és az erők összpontosítása helyett a széthúzás felé hajlanak. Ez nem túl jó cégér egy CMS-nek sem.

A Nuke rendszerek családjában úgy tűnt, hogy ígéretes fejlesztések jelentek meg, ezek azonban csak később fognak beérni, nekünk pedig jelen időben volt megoldásra szükségünk. Így sokkal szélesebbre kellett nyitnunk a látcsövünket, és olyan termékeket kellett értékelnünk, mint az ezPublish, a Typo3 és a TikiWiki. Ezek a programok óriási előnyben vannak a Nukeokkal szemben azt tekintve, hogy nem kénytelenek a korábban hibásan definiált belső felületeket (API-kat) továbbra is támogatni. Ez a legerősebb visszafogó hatás az igen komoly népszerűségnek örvendő rendszerek fejlesztésében. A rengeteg kész külső modul ugyanis egyik pillanatról a másikra használhatatlanná válna, ha nem kompatibilis változások állnának be az API-ban.

A TikiWiki egy újnak számító, ám óriási ütemben fejlődő tartalomkezelő rendszer, mely meglévő programokat használ fel, nem próbálja meg újra feltalálni a kereket. Így Smarty ismeret birtokában például rögtön neki lehet állni a sablonok készítésének. A Typo3 és az ezPublish ehhez képest sokkal régebb óta jelen lévő rendszerek. A három vizsgált rendszernek az a célja, hogy általános megoldást nyújtson a sokféle tartalomkezelési formákra (híreket közlő webhelyekre, blogokra, wikikre, galériákra, és még nagyon sokminden másra). Ezzel az általánossággal együtt jár bizonyos bonyolultság, amely egy hosszabb tanulási folyamatot igényel a termék teljes birtokbavétele előtt. Ha például a Typo3 képernyőképeit böngésszük, rögtön szembe ötlik, hogy rengeteg szolgáltatást nyújtó komplex rendszerről van szó. Emlékeztetnék azonban arra, hogy nem felvágni szerettünk volna, hanem az igényeinket kielégítő rendszert kerestünk. Minél több résztvevőt szeretnénk bevonni a közösségből a tartalomkészítésbe, és ezért nem volt elfogadható egy ilyen bonyolultságú rendszer. Egyszerűvé kell tennünk a hozzájárulást ahhoz, hogy legalább ez ne akadályozza azokat, akik szívesen részt vennének. Fejlesztői oldalról ugyanakkor mind a Typo3, mind az ezPublish új nyelvek megtanulását igényli, melyekkel a sablonokat, folyamatokat leírhatjuk, az ezPublish pedig még teljesen saját formátumot is használ a belső dokumentációhoz. Így mindhárom rendszer sok (saját fejlesztésű vagy újrahasznált) kódot igényel a háttérben, melyek mind potenciális hibaforrások és a teljes keret futtatását is lassítják.

Természetesen még számos CMS-t górcső alá vehettünk volna. A cmsinfo.org oldalon például számos CMS-hez kapcsolódó hír olvasható, melyek között nyilván sok értékes darab van. Ha mindet megvizsgáltuk és kipróbáltuk volna, akkor soha nem került volna sor az átállásra, hiszen mire megismerünk ennyi CMS-t közelebbről, már kezdhetjük elölről az időközben bekövetkezett változások figyelésével. Az opensourcecms.com oldalon ráadásul számos tartalomkezelő ki is próbálható, így telepíteni sem kellene. Ez azonban a saját céljainkra történő testreszabhatóság ellenőrzésére természetesen nem elég.

A szerencsének vagy a sorsnak köszönhetjük, hogy sikerült szembe találkozni a Drupal rendszerrel. Ez a keret a Nuke rendszerektől teljesen függetlenül fejlesztett, külső kódokat nem igénylő, önállóan működő program. Alapja a szolid és jól karbantartott mag, összefogott és aktív kiterjesztés készlettel. Minden nyílt forráskódú Drupal kódot a központi CVS szerveren fejlesztenek, mely eleve értelmetlenné teszi egy új változat kiválását. A legtöbb előre vivő gondolatot, kódot a fejlesztők beépítik az alaprendszerbe, és mivel minden kód együtt van, különösebb probléma nélkül lehetséges alapvető változtatásokat végrehajtani a belső API-ban. Az esetlegesen CVS-en kívül fejlesztett saját modulok frissítéséhez segítséget adnak a kiadások közötti változások összegyűjtésével. Új modulok vagy sminkek felvétele a CVS-be nagyon könnyen elvégezhető, azok letölthetően is megjelennek a Drupal webhelyén. A közös verziókezelő rendszer arra sarkallja a fejlesztőket, hogy egymás moduljaiban talált hibákat is javítsák, így a bejelentett hibák hamar megoldódnak. A fejlesztők által készített projekt kezelő modul teszi lehetővé a hibajelentéseket, és a különböző csomagok letölthető változatainak publikálását.

A teljesen a Drupal-csapat által fejlesztett kód célirányos megoldásokat tesz lehetővé, ugyanakkor azt sem zárja ki, hogy az oldalak megjelenéséhez a Smarty vagy bármely más sablonkezelő illesztését is lehetővé tegye, így egyszerre lehet kompakt és nyílt a rendszer. Ezzel együtt a külső könyvtárakra épülés problémájától is megszabadul a Drupal. Az adatbázis absztrakció az egyetlen kivétel. Itt MySQL esetén saját megoldást használ a Drupal, más adatbázisoknál a PEAR:DB szolgáltatásait. Mivel mi MySQL adatbázist használunk, a gyors Drupal kódot alkalmazhatjuk.

Természetesen nem minden esetben volt teljes mértékben megfelelő a Drupal által nyújtott megoldás számunkra. Először is azt kellett meggyőző módon biztosítani, hogy minden adat importálható legyen a PostNuke adatbázisból. A Drupal CVS szerverén szerencsére már volt egy MySQL script, ami eléggé 'okos' volt ahhoz, hogy magától is sokmindent importáljon. Ennek ellenére jelentős fejlesztést kellett végezni rajta, mely végül PHP-ben történő átírást jelentett. Ki kellett egészítenünk a programot a linkek és az XForum migrációjával. Az adatok átmentésekor nem pontos másolat készítése volt számunkra a legfontosabb, az adatok tisztítását sokkal fontosabbnak tartottuk. Sikerült megegyeznünk az egyszerű BBCode leíró nyelv használatát illetően a webhelyen tárolt szövegekhez. A hírek ugyanakkor (helyenként hibás) HTML-t használtak, a fórum bejegyzések pedig BBCode és HTML keverékét. Ez utóbbit az a történelmi tény okozta, hogy többféle fórum szoftveren ment már keresztül az a hozzászólás archívum, ami jelenleg is elérhető nálunk. Ezért végül jelentős mennyiségű. csak a Weblabor adataira jellemző átalakítást kellett beépítenünk a migráló kódba, melyekkel már elérhettük, hogy egy gombnyomásra a Drupalban tudjuk az összes Weblabor adatot.

Az adatok átvétele nem volt elegendő, több kiegészítő telepítésére is szükség volt, hogy a PostNukeban használt funkciókat itt is elérhetővé tegyük. Ezen kívül többet is szerettünk volna nyújtani, és minden eszközzel meg szerettük volna könnyíteni a keresett információk elérését és későbbi visszanézését. Ezért olyan elemek kerültek az oldalra, mint a tartalmak idő szerinti nézete, a teljes archívum, a webhelyen belüli gyorslinkek (bookmarkok) használatának lehetősége a belépett felhasználók számára. Ezek egy része speciálisan a saját igényeinkre történt fejlesztés, más része feljavított (és a közösség számára visszaforgatott) Drupal modul. A modulok fejlesztése során tárulnak fel a rendszer igazi előnyei és hátrányai.

A Drupal kódjának legnagyobb előnye, hogy modulárisan szervezett, a fejlesztők feltett szándéka, hogy ugyanolyan, vagy nagyon hasonló funkciót megvalósító két kiterjesztés ne kerüljön a CVS-be, illetve több szálon futó fejlesztések végül egyesüljenek. Így például a levelezőlista kereső készítésekor újra tudtuk hasznosítani a lapozó funkciót. A rendkívül rugalmas URL kezelésnek köszönhetően saját moduljaink által kiadott tartalmakat más modulok URL-jei közé tudtuk vegyíteni, így az URL-ek felől nézve a tartalmak logikai elrendezése diadalmaskodik a megvalósítási részletek felett.

Nem csak pozitív oldala van a Drupalnak, a testreszabás során két komolyabb hátránnyal kellett megküzdeni. Az egyik a felület más nyelvekre történő fordítását lehetővé tevő alrendszer. Ez lényegében arra korlátozódik, hogy minden webhely készítő saját magának képes legyen a felület feliratait lefordítani. A legnagyobb probléma egy rendszerezett fordítás elosztó hiánya, hiszen így nem egyszerű megosztani a fordításokat. Létezik azonban egy praktikus localegettext kiterjesztés, mely lehetővé teszi, hogy GNU Gettext eszközökkel végezhessük a felület fordítását. A Drupal magja azonban sok helyütt nem volt alkalmas ilyen formában történő fordításra, ezért több javítást kellett eszközölni a kódokon, melyek végülis az alaprendszer részei lettek. Jelenleg is folyik a localegettext-hez hasonló funkcionalitás beépítése a magban található locale modulba, mely lehetővé fogja tenni a fordítások hatékony terjesztését.

A Drupal jelenleg egy másik problémával is küszködik, mégpedig a kidolgozatlan szűrő rendszerrel. Ha nem csak HTML elemeket szeretne valaki használni a tartalmakban (hírekben, cikkekben, fórum bejegyzésekben, stb.), akkor azokat a szűrő rendszer segítségével tudja transzformálni HTML-be. Lehetséges, hogy egy-egy ilyen transzformáció sokáig tart, és teljesen felesleges minden oldal megjelenítéskor elvégezni. A Drupal jelenleg nem biztosít lehetőséget arra, hogy a transzformált szövegeket gyorsítótárazzuk. Saját fejlesztésként először a színezett forráskódok átalakított változatait gyorsítótáraztuk, így segítve valamennyire ezen a problémán. Azonban minél több szűrőt vezettünk be az oldalon, annál nagyobb problémát okozott ez a hatékonynak nem mondható tartalom-kezelés. Így készítettük el a filter_cache modult, ami bárki számára elérhető a Drupal CVS szerverén. Mivel a Drupal felhasználói és fejlesztői között jelentős tábor van, akik hozzánk hasonlóan nem szeretik a teljes HTML használatot engedélyezni a tartalmakban, egy javított szűrő rendszer fejlesztésére nagy igény mutatkozik, így ez ez a gyorsítótárazó kód várhatóan a Drupal 4.5.0 része lesz.

Más webhelyeken felmerül a 'lapos jogosultságrendszer' támogatásának problémája, ami számunkra nem különösebben okozott nehézséget, hiszen nyílt közösséget építünk. Ez a probléma abban gyökerezik, hogy általános jogosultságok megadására van lehetőség, azaz ha valaki hírek olvasására jogot kap, akkor minden publikált hírt el tud olvasni, a hírekre egyenként nem adható korlátozás.



Összefoglalva nem gondoljuk azt, hogy a Drupal a legjobb rendszer, kiterjesztése során a hibáit is feltártuk. Számunkra mégis úgy tűnik, hogy ezzel a választással minden szempontból jobb rendszert használhatunk, mint a PostNuke, hiszen nemcsak könnyebb használni, de programozni is egyszerűbb. A Weblabor működtetéséhez használt Drupal kiegészítések közül minden általánosan is használható elemet a rendszer CVS-ében is közzétettünk, így a webhelyünk számára készült javításokat és fejlesztéseket a közösség is élvezheti.

A PHP Konferencia CMS Maraton nevű előadásán a tartalomkezelő paletta két másik neves képviselőjével hasonlítjuk össze a Drupal rendszert, felvillantva az előnyeit és hátrányait egyaránt. Az előadás talán még több okot mutat arra, hogy miért éppen a Drupal mellett döntöttünk.