A Drupal tartalomkezelő rendszer mindenképpen igényel egy PHP feldolgozási képességgel felvértezett webkiszolgálót. Javasolt az Apache webszerver szoftver valamely aktuális változatának használata. Az Apache és a PHP telepítéséről Windows rendszerre a Weblabor egyik cikkében bővebben lehet olvasni. A Drupal a Microsoft Internet Information Server (IIS) használatával is tud működni, azonban ilyen kiszolgálón többmindenre kell figyelnünk, hogy biztonságos legyen a telepítésünk, ráadásul a szép webcímek használatától eleve elesünk. Ezért az IIS szerver nem a legjobb választás Drupal működtetésére. Unix/Linux rendszeren szinte biztos, hogy már eleve rendelkezésre áll egy PHP képes Apache webkiszolgáló.

A Drupal igazán kényelmesen működik külön virtuális hoszton, de bármilyen könyvtárrendszerbe is beilleszthető, egy meglévő webhely alkönyvtárában is kiválóan működtethető.

Az adatok tárolásához MySQL vagy PostgreSQL adatbáziskezelő rendszer használata támogatott. Ezért valamelyik adatbázis szerver jelenléte feltétlenül szükséges. Ideális esetben a Drupal adatainak tárolásához egy külön adatbázis szintű felhasználót kaphatunk (hozhatunk létre), és egy különálló adatbázist használhatunk erre. A Drupalnak az sem okoz ugyanakkor problémát, hogy egy adatbázison osztozzon más programokkal, hiszen a használt táblák neveit előtagokkal láthatjuk el, és így az azonos adatbázist használó más programok tábláival elkerülhetjük a keveredést. Ha saját magunknak kell adatbáziskezelőt telepíteni, akkor ebben a Weblabor erről szóló cikke nagy szolgálatot tehet. A cikk a PHPMyAdmin telepítését is leírja, melynek nagy hasznát fogjuk venni.

Annak érdekében, hogy a webhely leendő regisztrált felhasználói megkaphassák induló jelszavukat, a szerverünkön telepített PHP-nek támogatnia kell a levélküldést. Ez már az első adminisztrátor felhasználó létrehozásakor is érdekes lehet, ezért fontos rá odafigyelni. Ha szolgáltatót választunk Drupal webhelyünk működtetésére, akkor mindenképpen ellenőrizzük, hogy a PHP-ből történő levélküldéssel nem lesz probléma. Megkerülő megoldásokat kell használnunk, ha a szolgáltatónk a levélküldést nem támogatja.

Fontos megemlíteni, hogy a Drupal kereső indexelője és más elemei időzített feladatok formájában, a weblap megjelenítő lekérésektől lehetőleg elkülönítve futtatandók. Ehhez a webszerverünknek cron támogatással kell rendelkeznie, vagy a poormanscron modult kell telepítenünk a Drupal rendeltetésszerű üzemeltetéséhez.

Nem feltétlenül szükséges, de Apache szerver használata esetén jelentősen javíthat a teljesítményen, könnyítheti a telepítést illetve jobb kereső helyezéseket biztosíthat a nemzetközi keresőkben is, ha a webszerverünk feldolgozza a Drupal által adott .htaccess fájlt és biztosítja a mod_rewrite modult. Ezt sajnos az ingyenes szolgáltatók nem szokták engedélyezni.

A továbbiakban feltételezzük, hogy egy támogatott adatbázis, egy webszerver és egy PHP értelmező rendelkezésre áll, a Drupal telepítője úgyis figyelmeztet, ha ezen eszközök verziószáma nem kielégítő.

Az itt kialakult beszélgetés inspirálta ezt az írást.

Sokaknak gondot okoz kialakítani a local környezetüket úgy, hogy annak szerkeztete megegyezzen az osztott hoszting környezetben lévővel.
Erre a legegyszerűbb megoldás a docker4drupal által biztosított megoldás amit olyanra lehet alakítani amilyen a szerveren van.
Nem fogom oprendszer specifikusan írni, mert a dockert mindegyiken ugyanúgy kell használni. A lényeg, hogy a docker és a docker-compose fel legyen telepítve és el legyen indítva.

Példaként vegyük azt az esetet amikor a hoston az alábbi könyvtárba kerül a drupal:

/var/www/mysite/web

Ebből mi tulajdonképp annyit tudunk, hogy a drupal minden alkotórésze a web mappában van az index.php -vel együtt, semmilyen komponens nem kerül a szülő mappába.

Töltsük le a docker4drupal könyvtárat vagy klónozzuk le git alkalmazással innen:
Docker4Drupal
ha megvan tömörítsük ki ha szükséges.

A projekt létrehozásának a lépései:

• Hozzunk létre a projektünknek egy d10teszt könyvtárt.
• Másoljuk be a docker4drupal könyvtárból a docker-compose.yml és .env fájlokat a d10teszt könyvtárba.
• A másolt .env fájlban állítsuk be a PROJECT_NAME és PROJECT_BASE_URL változókat (a PROJECT_BASE_URL be állított domainen fog az oldal betöltődni)
• Ha szükséges állítsuk be a php verziót a szerveren használt verzióra.

Lépjünk be a d10teszt könyvtárba és adjuk ki a következő parancsot:

docker-compose up -d

Ez egy csomó mindent letölt és ha minden rendben akkor elindítja a szükséges konténereket. Ha hiba nélkül lefutott akkor beléphetünk a php konténerbe:

docker-compose exec php bash

Most bekerültünk egy virtuális környezetbe ahol használhatjuk a composert a projektünk karbantartására.
Hozzuk létre a projektet:

composer create-project drupal/recommended-project web

Ez a parancs létrehozza a drupal projektet a web mappába.
Sajnos ez a struktúra nem lesz kompatibilis a szerveren lévő struktúrával ezért lépjünk be a web mappába:

cd web

és töröljük a web és vendor könyvtárakat:

rm -rf web vendor

Ezután a composer.json fájlt kell módosítani, hogy ne a web mappába akarjon telepíteni hanem egy szintre telepítse a drupal könyvtárakat és a vendor könyvtárt, mint a szerveren.
Tehát módosítsuk a következőket a composer.json fájlban:

"drupal-scaffold": {
  "locations": {
    "web-root": "./"
   }
},

és az „installer-paths” alatt minden web/ legyen eltávolítva. Itt egy minta csak át kell nevezni json-ra Minta composer file
Ha ez megvan akkor újrainstallálni a drupalt:

composer install -o

Most már a drupal és a vendor egy könyvtárba került.
Szükségünk lesz egy jól működő drush-ra is:

composer require drush/drush

Ha ez is megvan akkor már létrehozhatjuk a drupalunkat:

vendor/bin/drush si --db-url=mysql://drupal:drupal@mariadb/drupal

vagy letölthetjük ftp-n a szerverről és bemásolhatjuk az adatbázissal együtt, így már nem okozhat gondot a szerver szerkezet. Ebben az esetben a composer.json „require” részt ki kell egészíteni a használt modulokkal.

Ha a PROJECT_BASE_URL=testd10.localhost akkor a drupal oldal a http://testd10.localhost:8000 címen lesz elérhető.

Ha nem akar valaki dockert használni, mert van WAMP vagy LAMP a localhostra telepítve akkor is ugyanez a menete onantól, hogy beléptünk a php konténerbe. A site install parancsban módosítani kell az adatbázis adatokat a tényleges adatbázisnévre, felhasználónévre és jelszóra valamint a mariadb helyett localhost kell

vendor/bin/drush si --db-url=mysql://db_user:db_password@localhost/db_name

Letöltés

A Drupal alapvető telepítéséhez elegendő annyit tudnunk, hogy szükségünk van a Drupal alaprendszerre és a magyar fordítás csomagjára. A következő fájlokat kell letöltenünk:

A fordítást mindig a localize.drupal.org weboldalról érdemes letölteni, mert ott található meg a legaktuálisabb fordítási állapot.

Kitömörítés

Amennyiben frissen telepített webszerverrel van dolgunk, vagy szolgáltatónknál saját felhasználói mappánkban még semmi sem található, választhatjuk ezt a mappát is a Drupal telepítésére. Ha azonban meglévő honlaphoz akarjuk illeszteni a tartalomkezelőt, akkor egy alkönyvtárat is nyithatunk a Drupal állományai számára a web területünkön. (Néhány későbbi kellemetlenséget elkerülhetünk, ha nem alkönyvtárba, hanem (al)domainre telepítünk.) Figyeljünk arra, hogy a Drupal csomag egy könyvtárban tartalmazza a szállított állományokat. Erre a könyvtárra nem lesz szükségünk (vagy legalábbis nem ezen a néven), csak a tartalmára. A következőképpen tudjuk kitömöríteni a Drupal csomag tartalmát:

Ugyanebbe a könyvtárba kell kitömörítenünk a magyar fordításban kapott fájlokat is. A magyar csomag úgy van kialakítva, hogy egyrészt a meglévő Drupal könyvtárrendszerbe helyezi saját fájljait, másrészt egy új telepítési profilt is ad a rendszerhez. Gondoskodjunk arról, hogy a magyar fordítás csomag tartalmát is a Drupal könyvtárába másoljuk.

Ennek eredményeképpen egy olyan könyvtárrendszert kell kapnunk, amelyben a Drupal alapcsomagjának és a magyar nyelvű telepítést lehetővé tevő telepítési profilnak is megjelennek a könyvtárai és fájljai. A továbbiakban az itt látható (webről elérhető) tartalmú könyvtárat nevezzük a Drupal könyvtárának.

Jogosultságok beállítása

Unix rendszeren a bemásolt állományok alapértelmezett jogosultsága (állományokra 644, könyvtárakra 755) biztos, hogy alapesetben megfelelő lesz. Ha mégsem, akkor a chmod paranccsal tudjuk a jogosultságokat megváltoztatni. Hozzunk létre a Drupal telepítési könyvtárában egy files nevű mappát. Ebben fogja a Drupal tárolni a feltöltött állományokat, ezért a webszerver felhasználójának joga kell legyen a könyvtárba történő állomány mentésre. Ezt elérhetjük úgy, hogy a webszerver felhasználójához rendeljük a könyvtárat (a chown parancssal), vagy 777-es jogosultságot adunk rá: chmod 777 files. Windows rendszeren is annak megoldása szükséges, hogy a Drupal lássa a mappájában lévő állományokat, a files könyvtárba pedig írni is tudjon.

A telepítés során szükség lesz arra, hogy a sites/default/settings.php fájlt a telepítő írni tudja. Addig nem tudjuk megkezdeni a telepítést, amíg ez a fájl nem írható, ezért a telepítés előtt a PHP számára ezt ugyancsak írhatóvá kell tennünk. Annak érdekében, hogy a telepítés után ne felejtsük el ezt a jogosultságot visszavonni, a Drupal figyelmeztetni fog bennünket a telepítés után az írhatóság megszüntetésére. Ha nem vonjuk vissza a PHP-től az írhatóságot, akkor az biztonsági kockázatot jelent a Drupal számára.

Fájlok feltöltése a szerverre

Ha mindezeket a műveleteket nem közvetlenül a szerveren végezzük el, szükségünk lesz még egy FTP (vagy jobb szolgáltatók esetén SCP) programra, amivel a fájlokat fel tudjuk tölteni a szerverre. Ügyeljünk arra, hogy a jogosultságokat az FTP programunk nem feltétlenül viszi át, így a szerveren ezt külön be kell állítanunk. Ráadásul a rejtett fájlokat nem mindig mutatják ezek a programok, és a .htaccess ilyennek minősül. Ezért külön figyeljünk arra oda, hogy ezt is sikerült feltöltenünk (sajnos az ingyenes szolgáltatók nagy része ezt nem engedi, ott nem fogjuk tudni ezt a fájlt feltenni).

Webhelyünk biztonsága és a .htaccess

A Drupal többek között biztonságosságával tűnik ki a széles körben használt, meggondolatlanul fejlesztett rendszerek táborából. Nem árt azonban, ha mi is odafigyelünk a biztonság szavatolására. Ennek alapvető eszköze az, hogy a Drupal csomagban szállított .htaccess jelenlétéről és végrehajtásáról gondoskodunk. Ez az állomány garantálja, hogy a PHP megfelelő biztonsági beállításokkal futtassa a Drupal csomagban található szkripteket, valamint hogy a nagyvilág számára nem publikus állományok ne legyenek elérhetőek böngészőből. Annak érdekében, hogy a .htaccess állomány parancsai helyesen feldolgozásra kerüljenek, a Drupal telepítési mappájára az Apache szerverben az AllowOverride All kitételnek kell szerepelnie. Ha ez teljesül, akkor nem tudjuk a Drupal mappában található különböző .module, .engine és hasonló egyedi kiterjesztésekkel ellátott állományokat böngészőből elérni, és a PHP beállításai is megfelelőek lesznek. Sajnos ingyenes szolgáltatóknál a .htaccess alkalmazását jellemzően nem engedélyezik, ott ennek hátrányaival és lehetséges biztonsági problémáival együtt kell élni.

Kezdő Drupal felhasználóként ajánlott, hogy legalább első alkalommal a saját gépünkön kialakított lokális szervert használjuk az ismerkedéshez.

Mivel a (PHP, Apache, MySQL) szerver alkalmazások önálló telepítése nem mindig egyszerű feladat, próbálkozhatunk előre csomagolt, és minden szükséges alkalmazást telepítő és bekonfiguráló programokkal is. Ezek közül csak egyet nézünk meg közelebbről, a többi alkalmazása hasonló.

XAMPP

Windows alatt az egyik ajánlott csomag az XAMPP. Ennek segítségével ki tudunk alakítani egy a Drupal számára megfelelő futtatókörnyezetet (szervert).

A letöltött telepítőprogram lényegében a telepítéskor szokásos kérdéseket teszi fel (pl. a telepítési könyvtár).

A telepítés után a Start menüből és parancssorból is vezérelhetjük az alkalmazásokat, de legegyszerűbb az XAMPP Control Panel használata. A Control Panellel az Apache és a MySQL futtatását kell kezdeményeznünk.

Telepítés után

A webszerver telepítéskor megadott könyvtáron belül létrejött a htdocs nevű alkönyvtár. E könyvtár tartalmát tekintjük a webszerver dokumentum-könyvtárának, vagyis (elsősorban) e könyvtár tartalmát tudja a webszerver statikus vagy dinamikus módon kiszolgálni. Legegyszerűbb lehetőség tehát itt létrehozni pl. egy drupal nevű alkönyvtárat, és a telepítés során ebbe kicsomagolni a letöltött telepítő fájlok tartalmát.

Ha begépeljük a böngészőnk cím sorába

• a http://localhost útvonalat, akkor az XAMPP admin felülete,
• a http://localhost/pma esetén a PhpMyAdmin oldala, míg
• a http://localhost/drupal esetén a majdani Drupal oldalunk

fog elindulni.

Otthoni, tanulásra szánt telepítés esetén alapértelmezetten a root nevű és jelszó nélküli felhasználót fogjuk tudni az adatbázis elérésére használni.

Amennyiben saját adatbázis szerverünket üzemeltetjük, mindenképpen létre kell hoznunk a Drupal számára egy adatbázist és egy felhasználót, mely ebben az adatbázisban műveleteket tud végezni. Ha szolgáltatónk biztosítja számunkra az adatbázist, akkor onnan kell megtudnunk a használható adatbázis nevét, illetve a műveletek végzésére jogosult felhasználó nevét és jelszavát. A Drupal MySQL és PostgreSQL adatbáziskezelőkkel tud együtt dolgozni. Sajnos néhány kiegészítő nem működik PostreSQL-lel, a népszerűbb kiegészítők azonban mindenképpen elérhetőek mindkét adatbázis rendszeren.

Figyeljünk arra, hogy a Drupal telepítéséhez (és később a modulok bekapcsolásakor valamint frissítéskor) ennek a felhasználónak táblák létrehozására (CREATE TABLE), meglévő táblák módosítására (ALTER TABLE) és táblák törlésére (DROP TABLE) is joga kell, hogy legyen. A Drupal telepítője figyelmeztet, ha valamilyen szükséges művelet nem végezhető el a megadott névvel és jelszóval.

MySQL beállítása

Az alábbiakban a MySQL 4.1 vagy újabb esetén követendő (azonos gépen futó szerverre vonatkozó) lépéseket taglaljuk. Nem érdemes MySQL 4.1-nél korábbi MySQL verziót használni, mert az nem támogatja jól a Drupal által is használt UTF-8 kódolást. Parancssorból a következőképpen van lehetőségünk az utasítások megadására:

PHPMyAdmin használata

Ezeket a műveleteket a PHPMyAdmin webes felhasználói felületén is elvégezhetjük, amennyiben megfelelő jogosultsággal rendelkezünk adatbázisok és felhasználók létrehozására.

Ha csak egy adatbázisban dolgozhatunk egy adott felhasználóval, akkor ezt kell elfogadnunk.

A Drupal számára ezzel előkészítettük az alaprendszert, elindulhat a telepítés.

Miután előkészítettük a fájlrendszert és az adatbázis rendszert, már csak a webes telepítőt kell futtatnunk, amely beállítja a Drupal számára a használt adatbázist, nevet és felhasználót, illetve létrehozza az alapértelmezésben alkalmazott adatbázis szerkezetet. Ennek elindításához látogassunk el webböngészőnkkel a http://example.com/drupal/install.php címre, ahol a http://example.com/drupal/ az a hoszt illetve könyvtár webszerveren elérhető címe, ahova a fájlokat előkészítettük.

Itt a magyar telepítést alkalmazva egy telepítési profil választó képernyő fogad bennünket (angol nyelven). Csak a második profilt választva van lehetőségünk a teljesen magyar nyelvű telepítést követően azonnal magyar nyelven használni a rendszert, ezért válasszuk ezt. Az első profil a Drupal rendszerrel alapkiépítésben jár, ez nem fogja a Drupal felületét a telepítés során magyarítani. A profil választást követően a profilhoz elérhető nyelvet is ki tudjuk választani. Itt a magyar mellett döntünk.

Innentől kezdve magyarul szól hozzánk a telepítő. Ha valamit elrontottunk az előkészítésben (például nem írható a telepítő számára a sites/all/default.php fájl), akkor itt fog figyelmeztetni bennünket arra, hogy addig nem folytathatjuk a telepítést, amíg ez nem megoldott. A korábban ismertetett lépéseket követve azonban azonnal az adatbázis beállító képernyőt kell kapnunk.

Itt alapértelmezésben csak a felső űrlapelem csoport látható, az alsót nekünk kell lenyitnunk, ha a számunkra fontos adatokat csak ott tudjuk beállítani. Sok webszerveren elegendő, ha az aktuális gépen feltételezzük az adatbázis kiszolgálót, és nem használunk speciális portot vagy táblázat név előtagokat. Ilyenkor a haladó beállításokkal nem kell törődni, csak a használt adatbázis típust, adatbázis nevet, felhasználói nevet és jelszót kell megadni a korábban beállított vagy a szolgáltatótól kapott adatok szerint.

Továbblépve a rendszer megpróbálja ellenőrizni, hogy minden szükséges adatbázis művelet elvégezhető-e. Ha a telepítéshez elengedhetetlen műveletek valamelyikére a megadott adatbázis felhasználó nem jogosult, vagy valamilyen adatot hibásan adtunk meg, akkor erre figyelmeztet, és a hibát meg kell oldanunk. Ha azonban minden jól megy, akkor a telepítő beállítja a tábláinkat, és a magyar nyelvű felülethez szükséges szövegeket is az adatbázisba tölti.

Egy olyan telepítési sikerességet mutató képernyő fogad bennünket, ami jelzi, hogy nem szabad elfelejtenünk a beállítási fájl írási jogának visszavonását.

A Webhely információk alatt adhatjuk meg a weboldal egészére vonatkozó néhány alapbeállítást. A weboldal neve nemcsak az oldal felső részén, a logó mellett jelenik meg, hanem a böngésző címsorában is. Az email cím mezőben megadott cím fog feladóként szerepelni minden olyan levélben, amelyet a rendszer (pl. regisztrációkor) küld, ezért erre a címre fog válasz is érkezni a látogatók részéről.

A telepítés következő lépéseként létre kell hoznunk egy felhasználót, amely a továbbiakban minden jogosultsággal rendelkezni fog a rendszer adminisztrációját illetően. Ez lesz az első számú felhasználó.

Először a kívánt felhasználói nevet és email címünket kell megadnunk. A megadott felhasználónév a belépéshez lesz szükséges, de a további látogatók is ezen a néven fognak bennünket látni. (Itt érdemes hangsúlyozni, hogy van lehetőségünk a magyar helyesírás szabályai szerint leírni a nevünket.)

Az e-mail cím nem fog az oldalon publikusan megjelenni, maga a Drupal rendszer küldhet rá fontos üzeneteket, vagy kapcsolati űrlapon keresztül feladott üzenetek lesznek erre a címre elküldve.

A jelszó megadásánál egyből értékelést is kaphatunk a jelszavunk „erősségét” illetően. (Érdemes a lehető leginkább követni az olvasható információkat, hiszen egy Drupal rendszer esetén az adminisztrátor jelszava a honlap feletti teljes hatalmat jelenti.)

Webszerver beállítások

Az alapértelmezett időzónát a látogatóközönség zömének időzónája szerint érdemes beállítani.

Ha a webszerverünk szolgáltatásai lehetővé teszik, érdemes a rövid webcímek használatát engedélyezni. (Ennek célja a ?q= webcím résztől való megszabadulás.) Ha nem tudjuk kiválasztani az Engedélyezett lehetőséget, a szolgálatatás megfelelő működése érdekében a webszerver konfigurálásához kell nyúlnunk.

Végül a frissítési figyelmeztetéseket is érdemes bekapcsolva tartani, hogy az újabb, hibajavító verziók megjelenése esetén a hibákat egyből orvosolni is tudjuk.

A telepítés sikeresen befejeződött, most már a működő webhelyre léphetünk.

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.

Ha a honlapot nyilvános helyen fejlesztjük, célszerű azt offline állapotba helyezni, és csak a honlap publikálható állapotba kerülésekor visszahelyezni online állapotba.
(Később, pl. a Drupal frissítése, egy modul telepítése, vagy éppen biztonsági mentés készítése esetén is érdemes ezt a lehetőséget használni.)

Mindezt a Webhely karbantartás adminisztrációs oldalon tehetjük meg. Az offline kapcsolón túl a látogatók számára megjelenítendő üzenetünket is megfogalmazhatjuk.

Az oldal offline állapotára folyamatosan figyelmeztet bennünket (az adminisztrátort) a Drupal oldalunk: minden oldal tetején olvashatjuk az „Offline módú működés” feliratot.

Az offline állapotnak még „veszélye” az is, hogy kilépés után maga az adminisztrátor sem fog tudni a szokásos módon belépni, hiszen a nyitóoldalon csak az előbb megfogalmazott üzenet olvasható, nincs lehetőség a belépésre. Ezért érdemes megjegyezni, hogy ha bármilyen szituációban begépelhetjük a ?q=user szöveget a honlap URL-jének végére a böngészőnk cím sorába, máris kapunk egy belépési lehetőséget.

A webhely információk adminisztrációs oldal néhány beállítását már telepítéskor megtehettük (név, e-mail cím), ezen azonban utólag változtathatunk, illetve néhány további jellemzőt beállíthatunk.

A következő három mező (Jelmondat, Küldetés, Lábléc üzenet) sminkfüggő, hogy megjelenik-e a publikus oldalakon. Bizonyos sminkek megjelenítik ezeket a szövegeket az oldalon. (Az alapértelmezett Garland smink mindegyiket megjeleníti.)

A névtelen felhasználó megnevezése (pl. Névtelen vagy Vendég) olyan esetekben fog megjelenni,amikor a tartalom vagy megjegyzés „tulajdonosaként” a Drupal nem tud mást megjeleníteni.

A node alapértelmezett címlapot csak akkor szokás megváltoztatni, ha a kezdőoldalt nem a friss hírekkel akarjuk megtölteni.

Ez a videó a Drupal 6 távoli szerverre történő telepítését mutatja be lépésről lépésre. A videó a következőket tárgyalja: Drupal letöltése és kicsomagolása, fájlok felmásolása a szerverre, adatbázis létrehozása, magának a telepítésnek az elvégzése, végül az időzített feladatok és a .htaccess fájl beállítása.

A videót Dianiska Balázs készítette.

Ha eddig még sosem próbáltad ki a Drupalt, akkor itt a nagyszerű alkalom!

A Drupal magyar nyelvű népszerűségének növekedésével jogosan merült fel a kérdés, hogy miként telepíthető a különböző ingyenes szolgálatatók szervereire. Ezeken a kiszolgálókon általában különböző védelmeket építenek be, melyek korlátozzák a felhasználó mozgásterét, egyrészt a felhasználók egymástól való megvédése érdekében, másrészt a szerver egészségének megtartása végett. Ezek azonban nem minden esetben jönnek jól annak, aki Drupal rendszert szeretne telepíteni.

Eddig a következő tapasztalatokat sikerült összegyűjteni a különböző rendszereken:

UltraWeb

Két alapproblémával kell megküzdeni a telepítéshez. Először is az UltraWeb valamiért egy belső átirányítást használ arra, hogy az index.php fájlnevet nem tartalmazó kéréseket az index.php-re irányítsa, ezért a webcímben átadott paramétereket nem kapja meg. Így a telepítés után bármilyen linkre kattintva továbbra is a honlapot kapjuk. Annak érdekében, hogy az index.php bekerüljön a linkekbe, a következőt keressük meg a common.inc fájlban az url() függvényben:

Cseréljük le a következőre:

Azaz minden esetben legyen benne az index.php a kérés címében.

Ettől kezdve a linkekre kattintva be tudjuk regisztrálni első felhasználónkat és elkezdhetjük beállítani a rendszert. Sajnos a második hiba, amivel találkozni fogunk, az valóban a Drupal hibája. A fordítási állomány feltöltésekor open_basedir hibát kapunk, mert a Drupal a PHP feltöltési könyvtárában próbálja megnyitni a fájlt, amit az UltraWeb beállítása nem enged meg. Amíg ezt a Drupalban nem javítják ki, addig a következőt ajánljuk. Vegyük fel a Magyar nyelvet az add language oldal lenyíló menüjéből, majd kapcsoljuk be (enabled) és állítsuk be azt alapértelmezettnek (default). Ezután töltsük fel a hu.po állományt, és a következő szkriptet az UltraWebes FTP gyökérkönyvtárunkba, és a szkriptet a böngészőből meghívva telepítsük a magyar fordítást:

include_once 'includes/common.inc';
include_once 'includes/locale.inc';
if (file_exists('hu.po')) {
// Drupal 4.5.0 esetén
// $file = 'hu.po';
// Drupal 4.5.1 vagy újabb verzió esetén
$file = (object) array('filepath' => 'hu.po');
_locale_import_po($file, 'hu', 'overwrite');
header('Location: index.php');
exit();
}
echo 'A hu.po nem található!';
?>

Ha minden jól megy, akkor automatikusan visszakerülünk a Drupal rendszerünk kezdőlapjára, ahol a beköszönő oldal már magyarul fog minket üdvözölni. Sajnos a menü továbbra is angol, mert a rendszer nem észlelte az új fordítás feltöltését, és a menü gyorsítótárat nem törölte. A modulok listáján a beállítások mentésével elérhetjük, hogy a menü gyorsítótár törlődjön, és a menüt is magyarul kapjuk meg. A továbbiakban a kiegészítő modulok fordításait hasonlóképpen tudjuk feltölteni, a modul csomagjában kapott hu.po importálásával.

Azt mindenképpen tartsuk észben, hogy mivel a .htaccess állományt nem engedi feltölteni az UltraWeb, a különböző speciális kiterjesztésű (.theme, .module, stb) állományaink nem védettek, azok a webről olvashatóak lesznek.

A cron.php időzített futtatását az Ultraweb adminisztrációs oldalán állíthatjuk be. A szolgáltató 3 időzítést engedélyez, így naponta 3x lehetséges az adatbázis leindexelése.

Rövid webcímek használatára nincs lehetőségünk.

FreeWeb

A FreeWeb rendszerével kapcsolatban sajnos az a tapasztalatunk, hogy olyan mértékben korlátozzák a PHP beállításait, hogy ez nem teszi lehetővé a Drupal életképes futását. A fájl feltöltési méret limit 10k-ra van állítva, azaz a több mint 400k méretű fordítási állomány nem tölthető fel. Ez azt is jelenti, hogy később egy képet vagy PDF állományt sem tudunk majd valamely tartalmunkhoz fűzni, tehát a kilátások nem túl jók. Mégis megpróbálhatjuk a fenti módszert a hu.po feltöltésére és külön szkripttel történő importálására. Akkor azt fogjuk tapasztalni, hogy a FreeWeb rendszeren maximum öt másodpercig futhatnak a PHP szkriptek, ami a fordítás importáláshoz nem elegendő. Ezt a futási limitet programból nem tudjuk állítani.

TVN.hu

Ennél a szolgáltatónál annyira kevés a PHP szkriptek számára megengedett memória használat, hogy ez egy funkcionális Drupal webhely számára nem tűnik elegendőnek.

Ezt az oldalt tervezzük a jövőben bővíteni további tapasztalatokkal, amennyiben azok rendelkezésre állnak. A telepítési problémákat továbbra is a fórumban szerencsés megvitatni, itt az eredmények summás megfogalmazása kaphat helyet.