ugrás a tartalomhoz

Weblabor váltás: miért éppen Drupal?

Hojtsy Gábor · 2004. Már. 18. (Cs), 22.57
Weblabor váltás: miért éppen Drupal?
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.

Frissítés: A felület fordítások megosztására a Drupal 4.5.0 és újabb változatok Gettext alapú megoldást biztosítanak, illetve a szűrők kimeneteinek gyorsítótárazása is megoldott beépített szolgáltatásként az alapcsomagban, ezért ezek a hátrányok a cikk írása óta eltűntek. A lapos jogosultságrendszert egy hibrid, tartalmankénti jogosultság meghatározást is támogató megoldás váltotta le, mely a megfelelő kiegészítők használatával szinte bármilyen tartalom elérési séma megvalósítását lehetővé teszi.


Ö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.
 
Hojtsy Gábor arcképe
Hojtsy Gábor
A Weblabor szerkesztője, mérnök informatikus. Több nemzetközi webfejlesztéssel és tartalomkezeléssel foglalkozó konferencián adott már elő, a hazai Web és Drupal konferenciák egyik szervezője. Szabadidejében legszívesebben amatőr színjátszással és énekléssel foglalkozik. Meggyőződése, hogy a pirospöttyös az igazi.
1

Meglátogattam az opensourcec

Anonymous · 2004. Már. 20. (Szo), 11.31
Meglátogattam az opensourcecms.com-ot, és letöltöttem egy angelinecms-0.6.0 nevezetű rendszert. Kicsit meglepődtem mikor kicsomagolás közben vírust talált a keresőm...
2

weblabor kereső

suppasonic · 2004. Már. 30. (K), 14.01
A drupalt igazítom épp egy leendő honlaphoz, és gondom volt az utf-8 kódlappal, amit a drupal alapból használ, és megváltoztatni admin felületen nem enged. a keresés sem működött az ékezetes betűk miatt, amíg bele nem nyúltam az includes/common.inc-be. átírtam pár dolgot (iso-8859-2-re) és most minden ok. ezt azért mondom, mert a weblabor keresője nem működik, és a forrásból úgy látom, hogy utf-8-at használ a lap és a betűk is elég kuszák.

Goba, egyébként ott voltam a konferencián, amikor a drupalról beszéltél, és lehet, hogy zaklatnálak majd, ha lesz kérdésem a saját drupal telepítésemmel/magyarításommal kapcsolatban.
3

Kereső

Bártházi András · 2004. Már. 30. (K), 14.39
Szia!

A mi keresőnk mnoGoSearchre épül, és annak, hogy nem működik most, egészen más okai vannak (épp raknék fel egy új verziót, és nem volt időm még bejezni).

-boogie-
4

drupal kerdes

Anonymous · 2004. Aug. 21. (Szo), 22.12
Udv,

vegigolvastam ezt a rendkivul hosszu irast, hogy miert dontottetek a drupal mellett.
Azt mar tudom, hogy valoszinuleg profi programozok vagytok, magas szintu angol nyelvtudassal, es olyan korokben mozogtok, ahol sajat szakzsargon jarja.
Az irasbol azt is megtudtam, hogy jo nehany mas tipusu fejlesztesrol is vannak informacioid es sok angol nyelvu levelezopartnerrel tartod a kapcsolatot, meg konferenciakra jarkalsz es gondolom, jol is erzed magad.

Azonban ebbol a rendkivul hosszu irasbol tovabbra se tudom, hogy mi az a drupal es mire jo?

En nem akarok semmilyen hiper-szuper portal rendszert, hanem mindossze egyetlen egy pici, aprocska, kis szerkesztosegi programot szeretnek, aminel lehessen definialni nehany alapveto tipust, ugymint rovidhir, hir, tudositas, interju, cikk - ezeknek legyen egy sablonja, es kesz, tudjam hasznalni.

Az eddigi rendszerek - a phpnuke volt az utolso, amit megneztem - azonban megmaradnak a felszines szinten, ugymint "hir kuldese", mert a programozok nem tudjak, mi a kulonbseg a hir meg a tobbi kozott, es kesz, a valasz az, hogy "allj neki programozni, ha nem tetszik."

Szoval a kerdesem az, hogy ez a drupal nevu megoldas alkalmas-e megfelelo sablonok elkeszitesere, vagy tudtok-e egy normalis szerkesztosegi programrol, amit esetleg ki tudok probalni valami portal rendszeren belul, vagy ahelyett?

Konstruktiv valaszokat varja:

gedeon at softhome.net
5

Miért ne tudná?

Hojtsy Gábor · 2004. Aug. 22. (V), 14.19
Persze én tudom, hogy tudja, ezért könnyen válaszolok így :) A Drupalban vannak beépített tartalom típusok, mint a story (sokmindenre használható egyszerű típus), fórum téma, blog bejegyzés, stb. Ezen kívül programozói szinten is lehet új tartalom típusokat definiálni, és van egy flexinode nevű kiegészítő modul, amivel grafikus felületen klikkelheted össze az új típust. A megjelenésére ad valamilyen alapértelmezést, ezt sablnozással lehet felülbírálni (kódszerkesztéssel).
6

re: Miért ne tudná?

Anonymous · 2004. Aug. 22. (V), 20.06
Goba,
akkor kerlek, keress meg email-en: gedeon at softhome.net

Nemreg probaltam a webmester hixes listan is tajekozodni,
eddig csak annyit irtak, hogy sok program van, probaljam ki.
Nekem viszont nem kell sok program sok modullal, csak
egyetlen egy modult akarok hasznalni, de azt tobb kulonbozo
stilussal kellene ellatni, tehat sok altipus kellene.
Ebben keresek segitseget, hogy lehet megvalositani.

Korabban egy Php-nuke programot probaltam ki, mert volt magyar
nyelvu weboldala, tamogatast remeltem, de az volt a valasz,
hogy nem vallalnak modositast, csinaljam meg magam es tegyem
kozze. En meg nem tudok programozni. :(

G
7

furcsa

Anonymous · 2004. Szep. 1. (Sze), 22.54
Érdekes a kérésed, egymodulos és mégis sokmodulos rendszert szeretnél - a news, az article stb modulok ugye többen vannak:) a drupal vagy a nuke rendszerekben számodra sok felesleges modul lehet, de hát ezeket kikapcsolhatod...

őszintén szólva én még nem nagyon láttam ilyen multifunkciós modult, az adminisztrációs felülete is érdekes lehet; ha sikerrel jársz, szólj.

Egyébként tényleg ne várd, hogy mások megírják helyetted a te speciális igényű kódodat - ingyen.