Összegyűjtöttem a keresőoptimalizáláshoz használható drupal modulokat. A listát folyamatosan frissíteni, bővíteni fogom. Ha ismersz más modult ami még hasznos lehet, a hozzászólásoknál jelezheted.

Drupal SEO modulok táblázat.

Az Állás.IT egy informatikai állás és munkakereső weboldal. Úgy gondolom van igény egy olyan oldalra, ahol a munkavállalók elmondhatják a véleményüket az egyes cégekről, és ahol kérdéseket tehetnek fel az álláshirdető cégnek még mielőtt jelentkeznének a pozícióra.

Egy másik fontos szempont az oldal kialakításánál az egyszerű és letisztult kezelőfelület volt. Én nagyon nem szeretem a kilométer hosszú formokat, és szerintem más sem. Ezért a hirdetésfeladás űrlap csak a legeslegfontosabb mezőket tartalmazza. Minden másra ott a hirdetés szövege.

Az egyszerűség ellenére az oldalon használt címke rendszer igen erőteljes eszköz, nagyon jól kereshetővé válik ezáltal az oldal.

Bevezető reklámkampánynak indítottam egy nyereményjátékot, ahol lehet nyerni akár egy iPhone 4 telefont egy twitter üzenetért és egy regisztrációért cserébe. Szerencsére nagyon népszerű a játék, a yamm.hu trendben többször első pozícióban volt a játék.

Az oldal természetesen Drupalban készült, ezt mondanom sem kell. A bejelentkezésénél és üzenet küldésnél használt modális felugró ablakot elég nehezen sikerült megvalósítani, azt hittem erre létezik kész modul. Sajnos a létező modulok, itt használhatatlanok voltak. Később tervezek erről egy plusz bejegyzést, volt néhány érdekes dolog amit megtanultam ezzel kapcsolatban.

Az oldal és a játék külalakja bVisual munkáját dicséri, aki ilyen szép logókat is tud csinálni:

Nagyon bízom az oldal sikerében, eddig minden jól alakul :)

Probléma: Ha Debian vagy Ubuntu szerveren futtatsz Drupal-t és a session kezeléssel kapcsolatos beállításokat nem állítottad át a php.ini-ben, akkor a Drupal sessions tábla soha nem lesz ürítve, ezért túl nagyra fog duzzadni, napról napra egyre jobban lelassítva a weboldaladat.

Megoldás: A Drupal settings.php-be szúrd be ezt a két sort:

és esetleg finomhangold ezt a sort:

Egy másik megoldás, ha a .htaccess fájlba vagy az Apache virtualhost definícióba szúrod be ezt a két sort:

Miért csak Debian alapú szervereken?

Nade mit is csinál ez a két sor és miért kell ezzel külön foglalkozni a Debian alapú szervereken?

Ahhoz, hogy megértsük a problémát, bele kell kicsit mélyednünk a Drupal lelkivilágába.

Nem csak az asztali gépemen fut Ubuntu, hanem szervernek is szívesen használom. Így vettem észre, hogy az f1vilag.hu oldalon, ami egy elég forgalmas site, a session táblában nagyon sok bejegyzés van. Hamar kiderült, hogy a táblából soha nem kerülnek ki a régi sorok, mindig csak az újak kerülnek beszúrásra.

Utánanéztem, hogy ez hogyan lehetséges, és egy kis keresgélés után kiderült, hogy a Drupal a sess_gc nevű függvényében ürítené a táblát. Az is hamar kiderült, hogy ezt a függvényt nem közvetlenül hívja meg a Drupal, hanem indirekt módon, a PHP-t kéri meg, hogy néha hívogassa ezt a függvényt, amikor a PHP azt jónak látja. Ezt egyébként úgy éri el a Drupal, hogy a session_set_save_handler függvény 6. paramétereként megadja visszahívandó callback függvényként a 'sess_gc'-t.

A PHP egy véletlen sorsolással dönt arról, hogy mikor kell meghívni a munkamenet szemétgyűjtőt, ismertebb nevén a session garbage collectort. A fent beállított értékek esetén, minden 100 oldalletöltés esetén átlagosan 5 alkalommal fog végrehajtódni a takarítás.

Ez mint szép és jó, de miért nem teszi ezt meg magától a PHP Debian alatt és miért teszi meg más rendszerek alatt? A választ megkapjuk, ha bepillantunk a php.ini ide vonatkozó részébe egy Ubuntu vagy Debian alatt:

Debian alatt tehát ki van kapcsolva a php beépített session garbage collection funkciója, és helyettesítve van egy ütemezett feladattal (cronjob). Ami viszont csak annyit tesz, hogy a php session fájljait törölgeti félóránként. Ezért nem lesz soha meghívva a drupal sess_gc függvénye és ezért nő a sessions tábla a végtelenségig. A php.ini-ben, mint fent olvashattuk, nem is érdemes visszakapcsolni ezt a funkciót. Inkább a Drupal-ban állítsuk vissza ezt a funkciót, amelynek hatására már rendszeresen meg fog hívódni a sess_gc függvény és nem nő a végtelenségig a sessions tábla.

Bár a Drupal projekt CVS-ről GIT-re vált, azért még így is elég sokan vagyunk, akik verziókezelésre Subversiont használunk, a Drupal közösségen belül és kívül egyaránt.

Egy verziókezelő használata során nekem mindig szükségem volt valamilyen eszközre, amely vizuálisan ábrázolja a különböző verziók, branch-ek közötti eltéréseket, vagy egyszerűen csak böngészni lehet vele a verziókezelőben tárolt adatokat, azaz a repository-t.

A WebSVN egy jól bevált Subversion böngésző, amelyet most Drupal szintaxis kiegészítéssel fogunk fűszerezni.

Hozzávalók

• telepített subversion verziókezelő
• telepített webszerver PHP-vel ugyanazon a szerveren
• WebSVN telepítő csomag, letölthető itt: http://www.websvn.info/download/
• Drupal GeSHi filter modul, letölthető itt: http://drupal.org/project/geshifilter

Elkészítés

Bizonyosodjunk meg róla, hogy a telepített subversion szerver és a http szerver (pl. Apache) működik.

Töltsük le a subversion verzióhoz megfelelő WebSVN verziót. 1.4-es SVN felett már használható a legfrissebb, 2.3-as WebSVN. A subversion verziószámát így deríthetjük ki:

WebSVN telepítés

A WebSVN telepítése gyerekjáték. Csomagoljuk ki a letöltött fájlt egy könyvtárba, ahonnan a webszerver majd ki fogja szolgálni. Majd kövessük a doc/install.html utasításait. Ez mindössze annyit fog jelenteni, hogy az include/distconfig.php fájlt le kell másolnunk include/config.php néven, majd ezt a fájl értelemszerűen szerkesztenünk kell.

A config.php fájlban meg kell mutatni a WebSVN-nek, hogy hol találja az svn repositorykat. Ehhez a $config->addRepository() vagy a $config->parentPath() megfelelő beállítása szükséges. A beállításhoz minden szükséges információ rendelkezésre áll a config.php fájlban megjegyzés formájában.

A WebSVN a repositorykat az svn és az svnlook parancsok segítségével fogja olvasni, úgyhogy ezek elérhetőek kell legyenek a path-ban webszerver felhasználó számára. Ha mégsem, akkor a config fájlban a parancsok pontos helye is beállítható.

A WebSVN futtatásához nem szükséges adatbázis. Ha eddig mindent jól csináltunk, akkor van egy működő WebSVN-ünk, próbáljuk ki!

Drupal syntax highlight

Az utolsó lépés a legérdekesebb, Drupal szintaxis kiemelőt fogunk beállítani a WebSVN-hez. Ehhez a Drupal GeSHi filter modulból fogjuk kölcsönvenni azt a fájlt, amelyik a Drupal függvények és konstansok definícióját tartalmazza.

Töltsük le és csomagoljuk ki a Drupal GeSHi filter modult. Mindegy hova, most épp nincs szükség telepített Drupal-ra. Keressük meg a geshifilter/geshi-extra/drupal6.php nevű fájlt (ha drupal 5 szintaxis kiegészítést szeretnénk, akkor a drupal5.php fájlt használjuk) és másoljuk át a fájlt a már telepített WebSVN lib/gheshi nevű könyvtárába. Ebben a könyvtárban vannak a programozási nyelvek leírói. Itt fogjuk megtalálni a perl.php-t, a php.php és 156 másik nyelv leíróját.

Legutolsó lépésként már csak azt kell elmagyarázni a WebSVN-nek, hogy mely fájlok esetén szeretnénk drupal szintaxis kiemelést látni. Ehhez nyissuk meg újra az include/config.php fájlt és bizonyosodjunk meg arról, hogy a $config->useGeshi() parancs nincs megjegyzésbe téve. Illetve szúrjuk be még ezt a sort:

Ezzel elértük, hogy a module, inc, stb. kiterjesztésű fájlokat a drupal 6 nyelvűnek értelmezi a WebSVN és ennek megfelelő szintaxis kiemelést alkalmaz majd.

Ha mindent jól csináltunk, és megjelenítjük például egy drupal modul forráskódját (*.module) a WebSVN-ben, akkor a Drupal mag függvényei és konstansai kiemelten jelennek meg és link-ként viselkednek, amelyek az api.drupal.org-ra mutatnak. Emellett természetesen megmarad a PHP szintaxis kiemelés is, amely linkek viszont a php.net-re mutatnak.

A bejegyzés megírásához ezeket a verziókat használtam:
Subversion: 1.6.6 (r40053)
WebSVN: 2.3.1
GeSHi filter: 6.x-1.3

Az eredeti receptre Wim Leers blogján akadtam rá: http://wimleers.com/article/run-your...drupal-syntax-highlighting, köszönet érte!

A múlt heti bejegyzésben arról írtam, hogy egy gyors weboldal miért jelent versenyelőnyt a konkurenciával szemben. Kétféle sebesség probléma lehet, a kliens oldalon akkor van gond, ha a böngésző program nehezen vagy lassan jeleníti meg az oldalt. Szerver oldalon pedig akkor van gond, ha a böngészőnek indokolatlanul sokat kell várnia a szerverek válaszára.

A Drupal boost modul egy szerver oldali megoldás: az anonim felhasználók oldalletöltéseit teszi villámgyorssá.

Tisztán emlékszem a 2. Magyar PHP konferenciára, ott hallottam először a Drupalról. Abban az időben nagyon foglalkoztatott a weboldalak sebességének optimalizálása, azon belül is az előre legenerált statikus html oldalak kiszolgálásának voltam nagy rajongója. Fel is tettem a kérdést az előadónak, hogy a Drupal tud-e ilyet. Ha jól emlékszem, valami olyasmit válaszolt Goba, hogy az alap rendszer nem tudja, de biztosan készíthető hozzá ilyen modul.

Nos, hölgyeim és uraim, a Drupal boost modul egészen pontosan ezt csinálja: előre legyártott statikus html fájlokat szolgál ki az anonim felhasználóknak. Ezáltal teljes egészében kihagyva a buliból a PHP, Drupal, SQL stacket.

Ez a megoldás villámgyors oldal kiszolgálást eredményez, és egyben hatalmas tehertől szabadítja meg a webszervert. Persze vannak hátrányai is a megoldásnak, de előbb nézzük röviden hogyan működik.

A Boost modul működése

Először telepíteni kell magát a modult. Ez fog gondoskodni a statikus html fájlok mentéséről. Létre kell hozni egy „cache” nevű könyvtárat a Drupal telepítés gyökerében, ide fognak kerülni a html fájlok. Végül pedig a .htaccess fájlba be kell másolni egy nagy adag kódot, itt történik a varázslat: ez gondoskodik a html fájlok kiszolgálásáról.

A .htaccess fájlba másolt kód több különböző feltételt figyel, és ha mindegyik teljesül, akkor a Drupal index.php helyett az elmentett statikus fájl kerül kiszolgálásra. Ilyen feltétel például, hogy nem létezik a DRUPAL_UID nevű cookie, azaz hogy nem bejelentkezett felhasználó nézi az oldalt, vagy hogy GET kérésről beszélünk, és nem POST-ról.

Az eredmény: villámgyors oldal kiszolgálás az anonymous látogatók számára.

A cache fájlok érvénytelenítése

Ha egyszer elkészült egy oldalhoz egy statikus gyorstár fájl, és a fent említett feltételek teljesülnek, akkor az bizony ki lesz szolgálva. A kiszolgálás pillanatában ugyanis nincs lehetőségünk mérlegelni, hiszen nem fut le semmilyen Drupal vagy PHP kód. Éppen ezért alaposan oda kell figyelni, hogy mikor kerül érvénytelenítésre egy oldal gyorstár változata.

Először is, van egy beállítható felső idő határ. Ha ennél régebbi a cache fájl, akkor a boost törli az időzített feladatok (cron) segítségével.

Ha egy node oldalról beszélünk, akkor a node módosításakor is törli a cachet. Ha hozzászólás érkezett a node-hoz, szintén megy a cache a kukába. Ha egy node megkapja a „Promoted to front page”, azaz címlapra helyezés státuszt, akkor meg a kezdőlap lesz törölve. Persze ez csak a Drupal alapértelmezett kezdőlapjával működik. Ha saját kezdőlap megoldásunk van, és használni akarjuk a boost-ot, akkor nekünk kell gondoskodni a címlapi gyorstár törléséről.

A taxonómia lista oldalak fájljait is helyesen üríti a modul, amikor kell. Sőt elvileg CCK tartalomra hivatkozás mező használata esetén, ha változik a hivatkozás, akkor is helyesen törlődnek a megfelelő node gyorstárak.

Mindezeken felül persze lehet, hogy szükségünk lesz saját érvénytelenítő kódot is írni. Ha egyedi címlapot használunk, akkor mindenképpen.

Hátrányok

Az egyik hátránya a modulnak, hogy csak az Apache kiszolgálót támogatja teljes egészében. Márpedig maga az Apache is egy elég komoly lassító tényező, mint ahogy múlt héten egy hozzászólásban is írták. Elvileg nginx, lighthttpd és IIS7 használata is megoldható, többé kevésbé. Én ezeket nem próbáltam még.

A másik gond magából a módszerből adódik: mivel kikerüljük a Drupal-t, ezért az alaprendszerbe épített statisztika modul, illetve hasonló analitika megoldások egyáltalán nem fognak működni. Jelenleg egy nagyon izgalmas, saját fejlesztésű modulon dolgozom, amely azonban épít a Drupal mag statisztika megoldására. Ezért sajnos a kettő együtt nem működik.

Szintén a technológiából adódik, hogy a weboldal jobb és bal sávjaiban elhelyezett dobozok tartalma nem mindig frissül, és ezért Boost használata esetén néha furcsán inkonzisztens adatok jelennek meg. Illetve a véletlenszerűen változó dobozok, például 5 véletlenül kiválasztott fórum téma az elmúlt 1 hétből, sem úgy működik, mint ahogy kellene neki.

Mikor megnéztem a forráskódot, megdöbbenéssel tapasztaltam, hogy a Boost modul hatalmas! 280 KB-nál nagyobb a PHP kód mérete. Egyrészt azért ilyen nagy, mert sok kód kell az különböző cache fájl érvénytelenítési esetek kezelésére. Másrészt sok extra dolgot tud, talán feleslegesen is (lásd lent). És elég sok beállítási lehetősége is van. Egyszóval nagy és bonyolult modul, jobban örültem volna, valami egyszerű és nagyszerű megoldásnak.

Egyéb érdekességek

A Boost modul favorizálja a tömörített (gzip) kiszolgálást, méghozzá elég agresszíven. Állítólag némely proxy szerver felülírja a böngésző által küldött HTTP fejlécét, hogy ne fogadjob GZIP tömörített adatot. A modul egy trükkel (IFRAME-ben meghívott GZIP-pel tömörített oldalban lévő javascripttel beállít egy cookiet) megpróbálja kideríteni hogy az aktuális böngésző támogat-e gzip tömörítést, és ha igen, akkor az Accept-Encoding fejléctől függetlenül GZIP-el küldi az adatot.

Van egy beépített web robot is a Boost-ban. Annyit tesz, hogy cron futás alkalmával bejárja az oldalunkat (konfigurálható, hogy ezt hogyan tegye), ezzel előmelegítve a gyorstárat. Mikor van erre szükség? Ha olyan weblapot készítünk, amire várhatóan kevés oldalletöltés érkezik. Ekkor ugyanis a cache általában túl régi lesz, azaz a látogatók többnyire gyorstárazás nélküli oldallal találkoznak majd.

Konklúzió

Nagyszerű modul, ha az ember együtt tud élni a kötöttségekkel: Apache kiszolgáló, nem mindig frissülő dobozok és az anonim látogatói statisztika hiánya a Drupalban. Utóbbi miatt jelenleg én sajnos egyetlen oldalon sem használom. Persze ha egy szerverem nem bírná már a terhelést, akkor nyilván feltenném: inkább lássák a látogatók az oldalt és nekem ne legyen látogatottsági adatom, mint hogy ne is lássák :)