Simítások a frissen telepített rendszeren

Hojtsy Gábor képe

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.