Bevezetés
Gondolom, többekkel előfordult már, hogy volt egy olyan PHP-kódja, ami valami miatt nem az elvárható eredménnyel futott le. Ilyenkor nincs mit csinálni, lehet debuggolni. És ekkor szembesül az ember azzal, hogy az nem lesz olyan egyszerű…
A legegyszerűbb PHP-telepítésnél nincs debugger, azaz lépésenként nem lehet futtatni, töréspontokat elhelyezni, változók értékeit vizsgálni. Mármint automatikus módon. Amit lehet csinálni, az az, hogy megsaccolni, hol a hiba, és ezután a megfelelő helyeken a megfelelő változók értékeit kiíratni (akár echo, print_r vagy var_dump segítségével). Ha az adott helyen az elvárható érték adódik, akkor lehet továbblépni. A módszer működik, bár kissé favágás jellegű.
Persze nem én vagyok az első felhasználó, aki ezzel a problémával szembesül. A Zend cég kínál PHP IDE-t, a megfelelő áron. Itt csak az árral volt a probléma (a kalózkodással kíméljetek, valószínűleg én is szoftveres leszek, ezután illene, hogy én azért gondoskodjak a legális szoftverhasználatról a lehetőségeken belül).
Léteznek ingyenes megoldások is, de ezek többnyire a szolgáltatások terén hagynak kívánnivalót maguk után. De most végre sikerült találnom egy megoldást (több helyen kifejtve az interneten
Rövid összegzés
Azok kedvéért, akik vagy nagyon értenek hozzá, vagy csak bizonyos részek érdeklik őket, álljon itt egy rövid összefoglaló a lépésekről (a lépéseket természetesen nem feltétlen ebben a sorrendben kell végrehajtani, de érdemes pl. az Eclipse-et feltelepíteni, mielőtt össze akarod kapcsolni az XDebug-gal 🙂 ):
- Alapvető PHP környezet beállítása
- XDebug telepítése a PHP-hoz
- Az Eclipse PDT projekt telepítése
- Az Eclipse-hez XDebug plugin telepítése
- Egyéb nyalánkságok
Feltételezések
Annak érdekében, hogy a cikk olvasható maradjon, és ne tegyen ki kisebb könyveket, bizonyos feltételezésekkel élek az olvasó ismereteire vonatkozóan:
Az alapvető PHP környezet telepítését nem részletezném. Ha gondot okoz, akkor nem javaslom a cikk további olvasását sem, ugyanis az Eclipse nem egy könnyen megtanulható, egyszerű eszköz, és a megfelelő beállítás szintén gondot okozhat. Esetleg ha feltétlen ragaszkodsz hozzá, léteznek olyan csomagok, amik egyben tartalmaznak Apache-ot, PHP-t és MySQL-t (pl. MAMP, WAMP, LAMP, stb.). A cikk további részében feltételezem továbbá, hogy a php.ini szerkesztése (megtalálása) nem okoz gondot.
Nincs módom/időm az összes elérhető rendszeren és verzióval tesztelni a környezetet, így csak korlátozott tapasztalatokat tudok megosztani. Az íráskor az Eclipse Core pluginek a jelenlegi legfrissebb, 3.3-as verzióval futnak, a PHP 5.2-es verziójú Apache (2.2.4) modulként futtatva. Az XDebug a 2-es verziónál tart (helyenként 0.2-esként hivatkoznak rá). A saját rendszerem Mac OSX 10.4 alapon fut, és erre a fent említett programok általam lettek lefordítva. A debugger ezen a rendszeren tökéletesen működött, gondot nem tapasztaltam.
PHP és XDebug
Az XDebug telepítése érdekesebb kérdés – szükség van egy lefordított modulra belőle – Windowsra és Linuxra van belőle a hivatalos XDebug oldalon, legalábbis bizonyos PHP verziókhoz, ha más platformon futtatod (mint én az OSX-szel), vagy nem megfelelő a PHP verzió, akkor lehet fordítani, vagy esetleg a Komodo IDE-jébe befordított változat is használható, amint az egyik OSX-es forrás is ajánlja. A fordítással kapcsolatban volt egy félmondatos megjegyzés, hogy azért nem azt követi, mert állítólag ahhoz a PHP-t (és azzal együtt az Apache-ot is) le kellene fordítania.
Erre én nagy bátran arra gondoltam, hogy mivel úgyis MacPorts-sal (korábban DarwinPorts) telepítettem fel a rendszert, és ezáltal lefordítottam, gondoltam, bátor leszek, és lefordítom inkább forrásból, minthogy egy harmadik gyártó programját kelljen használni, vagy hogy másik fizetős szoftvert telepítsek ezért a gépemre (pontosabban a demóját). Még egyszer: Linuxra és Windowsra van bináris változat is, azokat lehet használni, csak arra kell ügyelni, hogy a saját PHP verziónkhoz való változatot töltsük le.
Ha megvan a bináris változat, akkor jöhet a bűvészkedés a php.ini fájllal. A következő néhány sort kell beszúrni a fájlba:
xdebug.remote_enable=1
xdebug.remote_handler=dbgp
xdebug.remote_mode=req
xdebug.remote_host=127.0.0.1
xdebug.remote_port=9000
Megjegyzés:Windows felhasználók esetén a lefordított bináris nem .so, hanem .dll kiterjesztéssel rendelkezik, és érdemes lehet a php bővítményei közé rakni (de természetesen ez nem kötelező); valamint a fájlnevet is megfelelően módosítani kell.
Abban az esetben, ha rossz XDebug binárist kaptunk, itt elképzelhető, hogy a PHP nem indul el – velem előfordult. A fordítás során ugyanis egy gusztustalan hibába futottam: sikerült 4.3-as PHP-hoz lefordítanom az XDebug-ot, és ez az 5.2-es PHP-val nem működik együtt, méghozzá olyan szinten, hogy a PHP el sem indult, hanem mindenféle különös hibaüzenetet dobált. Hogy ez hogyan jött elő? Az OSX 10.4 gyárilag tartalmaz egy 4.3-as PHP-t, amit elég nehézkes eltávolítani a rendszerből, ezért inkább MacPortsszal mellételepítettem az 5.2-es változatot. Ugyanakkor a fordításkor egyéb paraméterek megadása nélkül a 4.3-ast találta meg. Amikor a fordításkor megfelelő paraméterrel megadtam az 5.2-es PHP elérési útját, az így kapott binárissal rögtön elindult a PHP.
Eclipse
Mi is az az Eclipse? Egy teljesen nyílt IDE (gyengébbek kedvéért: integrált fejlesztői környezet). Nyílt azért is, mert teljesen nyílt forráskódú, és azért is, mert pluginalapú. Ez azt jelenti, hogy ha egy másik nyelvhez akarsz fejlesztői környezetet használni, azt ugyanúgy el lehet készíteni az Eclipse IDE felett, és ugyanazokat az elemeket képes is használni (például az Eclipse PDT-vel együtt feltelepülnek azok a pluginek is, amivel a Java fejlesztést lehet végezni). Mindezek felett az Eclipse Java nyelven íródott, ezért nagyszerűen egyforma (lassan) működik az összes nagyobb operációs rendszeren (persze a gépigénye megvan, rengeteg memóriát eszik például).
Netes bogarászás alapján az Eclipse PDT (Php Development Tool) plugincsomag kellően jó választásnak tűnik. Ha korábban nem volt telepített Eclipse és csomagkezelőből sem tölthető le akár mert az operációs rendszerhez nincs csomagkezelő (pl. Windows), akár mert az elérhető csomagkezelő nem tartalmazza (pl. OSX-en a MacPorts), akkor legegyszerűbb a
PDT Project oldaláról lehúzni. Egyébként a frissítések között is megadható az http://download.eclipse.org/tools/pdt/updates/ URL, és azon keresztül is telepíthető. Ez használható a Linuxon csomagkezelőből telepített Eclipse esetén is (a beépített frissítések egyébként a Help menü Software Updates pontja alatt érhető el – a lehető leglogikusabb hely a funkcióhoz :-p).
Léteznek egyéb PHP kiterjesztések is az Eclipse rendszerhez, de azok vagy abbamaradtak (pl. a PHPEclipse csomag utolsó kiadása 2005-ös), vagy még nem jutottak el egy bizonyos érettségi fokra. Természetesen a PDT Project sem jutott fejlődésének csúcspontjára, de előnye, hogy a PHP-t támogató Zend (is) mögötte áll, és arra készül, hogy az egész platformját átírja Eclipse alapra, miután a projekt megfelelő szintre eljutott.
Maga a telepítés teljesen magától értetődő, nem is fektetnék rá nagyobb hangsúlyt.
Eclipse és XDebug
Módosítás: 2007. szeptember 26-án.
Na, ez szép fázis. Az Eclipse PDT jelen helyzetben nem támogatja beépítve az XDebug-ot. Persze nincs semmi veszve, hisz az Eclipse pluginelhető rendszer, és a feladathoz létezik plugin. Ezt az Eclipse plugint kell még telepíteni az azEclipse Bugzilla-ról (a tervek szerint ez a funkció később bekerül az Eclipse PDT-be, de az még arrébb van). A megfelelő verzió választása itt is fontos lehet. Fontos: nem véletlenül nincs más helyen letölthető verzió. Szerencsére az Eclipse pluginek telepítése és eltávolítása egyaránt egyszerű művelet: bemásolás az Eclipse pluginkönyvtárába
Nekem ez a rész teljesen simán működött, a plugin létrehozta a szükséges új View-kat, beállítópanel(rész)eket. De mivel ez még nem hivatalos plugin, nem biztos, hogy mindenhol tökéletesen működni fog, óvatos kezelést igényel.
A 2007. szeptember 17-én megjelent Eclipse PDT már beépítve tartalmazza az XDebug-on keresztüli debuggoláshoz szükséges plugineket – és megváltoztatták a módot is, ahogy XDebug-os debug session-öket lehet létrehozni. Mostantól nem külön debugtípus az XDebug-on keresztüli, hanem a debug mód egyik paramétere a választott debugger.
Ha korábban az én írásom alapján állítottad össze a rendszert, és használtad a debuggert, és hagytad az Eclipse-nek, hogy frissítse magát, akkor azt vehetted észre, hogy mindenféle hibaüzenet nélkül megszűnik a debuggolás, a töréspontoknál nem áll meg futás közben, stb.
A probléma megoldására két megoldás van: az egyszerűbb az, hogy eltávolítod a meglevő Eclipse-et, és újratelepíted az új verziót (ezzel biztosan eltűnik minden hivatkozás az időközben elavulttá vált Bugzillán közölt pluginre), vagy ha nagyon profi vagy, akkor megpróbálhatod kézzel kihackelni a pluginek közül a kapcsolódó részeket.
Ha ezzel is megvagy, akkor már (elvileg) van egy teljesen működőképes PHP-debuggolásra alkalmas fejlesztői környezeted.
Amikor persze a Debug-ot meghívod, figyelni kell rá, hogy a felajánlott lehetőségek közül azokat válaszd, amiknek a nevében XDebug van – a másik másfajta debuggerhez való.
Egyéb nyalánkságok
Természetesen a lehetőségek itt még messze nem merültek ki. Például az Eclipse-et könnyű rávenni arra, hogy CVS vagy SVN verziókezelő rendszerrel szinkronizálja a projektet. A CVS támogatás a legtöbb Eclipse-verzióban benne van (konkrétabban én még nem láttam olyat, amiben ne lenne benne 🙂 ). Az SVN-hez legegyszerűbb a Subclipse plugin letöltése. Részletes telepítési útmutató a projekt oldalán található. A használata elsőre furcsa lehet (a Workspace view-ban a Project jobb gombos menüjében a Team menüben találhatóak az ehhez tartozó részek).
Hasznos lehet, ha a PHP projekt olyan mappába kerül, amit a webszerver is lát. Ez Eclipse alatt kis fejtörést igényel, ugyanis az Eclipse workspace alapon működik – viszont a workspace mappát nem (feltétlenül) érdemes a helyi gépen levő webszerver elérhetőségébe tenni. Én azt csináltam, hogy a workspace-t a saját mappámban hoztam létre, míg amikor ezen belül projekteket hoztam létre, azoknál gondoskodtam róla, hogy az Apache által kezelt mappába jöjjön létre a megfelelő mappa (ez az új projekt varázsló egyik pontjánál elérhető szolgáltatás, alapértelmezetten le van tiltva).
Az aktuális projekthez tartozó debug útvonalakat (pl. a felparaméterezett index-fájl, stb.) érdemes felvenni a rögzített debug módok listájára, sokkal gyorsabban felhasználható, különösen, ha hozzám hasonlóan olyan url-en keresztül érhető el a php-fájl, amit az Eclipse nem jól „tippel” meg.
Azok a bizonyos utolsó szavak
Balage volt olyan kedves, hogy a cikk egy félkész változatát tesztelte a Kubuntu Linux-án. A tapasztalata szerint a rendszer csomagkezelője által telepített 3.2-es Eclipse-core nem volt kompatibilis a linken elérhető Eclipse PDT-vel, az Eclipse honlapjáról letölthető változat meg nem igazán akart futni (pl. üres splash screen, csomagkezelője első nekifutásra kifagyott). Nem is sikerült megoldani így a gondot. Azoknak, akik hasonló cipőben járnak, tudom ajánlani az EasyEclipse PHP módját. Lényegesen egyszerűbben telepíthető, mint a teljes Eclipse csomag, benne van többek között a Subclipse plugin is, és nagyobb hangsúlyt fektetnek a kompatibilitásra, ugyanakkor ezért a rugalmasságban kell fizetni: nem biztos, hogy bármely Eclipse plugin gond nélkül együttműködik vele, illetve csak csomagként lehet frissíteni tudomásom szerint. Én ezt sem teszteltem, de Balage-nál megoldotta a gondokat.
És végül egy bizonyos „copyright” célú megjegyzés: az csak a véletlen műve, hogy nem olyan régen János egy hasonló témájú írást jelenített meg az oldalán: PHP fejlesztői környezet berendezése. Nem használtam fel semmit az írásából, nem a Zend debuggerét használtam fel. Erre két okom is volt: nem rajongok a csak egy dll/so formátumban terjesztett megoldásért teljesen nyílt rendszer összerakásakor (ugyan nem nézem meg a forrást, de csak megnyugtatóbb, ha én fordítom le… az meg már tényleg csak mellékes, hogy a Windows-nál is zártabb OSX felett építem fel ezt a rendszert… 🙂 ), valamint én ehhez találtam leírást. Az meg már csak hab a tortán, hogy ezzel elméletben remote debuggingra is lehetőség van, de ezt már végképp nem használom ki.
Sok sikert mindenkinek a rendszer használatához, ha van, aki megosztja a tapasztalatait, örömmel venném, ha kiegészíthetném vele ezt a leírást.
