A WAMP és a 64 bites Windows 7
Újonnan vásárolt notebookomon 64 bites Windows 7 Professional virít. Erre voltam kénytelen a napokban WAMP-ot telepíteni PHP fejlesztéshez, ami nem is ment olyan könnyen. A tanulságokat megosztanám, hátha néhány nap munkát megspórolok vele valakinek.
Lelkes újoncként természetesen azonnal letöltöttem a WAMP 64 bites verzióját, és telepítettem a gépemre. Mivel az egyik projektben szükség volt rá, leszedtem a WAMP „hivatalos” 5.2.11-es PHP addonját is, és azt is telepítettem. Látszólag minden rendben volt, azonban az Apache ezzel a PHP verzióval nem indult el. Az ok – mint utólag kiderült – az, hogy a PHP 5.3 előtti addonok 32 bitesek, így használatukhoz a 32 bites WAMP telepítőt kell használni.
Feltettem tehát a 32 bites WAMP-ot, hozzá az addont, így az Apache el is indult. Mivel utálom, ha az egyes szoftverek teleszemetelik a C:\
-t, ezért – mint már évek óta – a C:\Program Files\Wamp
alá telepítettem a csomagot, pontosabban (64 bites rendszerről és 32 bites telepítőről lévén szó) a C:\Program Files (x86)\Wamp
alá.
Mint mondtam, az Apache futott, csak a PHP nem ment rendesen; nem volt jól konfigurálva, hiányoztak a kiterjesztések stb. Mintha nem az a php.ini
fájl lett volna használatban, amit én szerettem volna. Erre rácáfolt a phpinfo()
. Akkor hát mi a baj?!
A baj vélhetően az, hogy a php.ini
-ben azon path bejegyzéseket, melyek neve zárójelet tartalmaz, a PHP motor nem veszi figyelembe, helyettük (mindenféle hibajelzés nélkül!) az alapbeállításokat érvényesíti, így pl. az kiterjesztés könyvtárat is a C:\PHP5
alatt kereste nálam, egyebekről nem is beszélve. A C:\WAMP
alá telepítve a csomagot a jelzett hiba megszűnt.
Megoldás tehát: 5.3-as PHP előtti PHP verziók használatához 32 bites telepítő és pl. C:\WAMP
telepítési útvonal.
Saját gépemen meglehetősen
Nem tudom
Ahogy én látom ezeket a WAMP / XAMP stb. rendszereket, vagy működnek, és ha nem kell hozzányúlni, akkor jók, minden egyéb esetben csak hosszadalmas szívások vannak vele.
WAMP vs egyedi telepítés
Ha jól látom, talán nem is PHP probléma...
inkább XAMPP
Valamit nagyon jól csinálok, mert nekem még 1x sem volt ilyennel bajom.
Csak egyszer kell összerakni...
Használj relatív útvonalakat, hordozhatóbbá válik tőle a környezet. Nekem is 64 bites W7 profom van, teljesen jól működik a "C:\program files (x86)\Apache Software Foundation\PHP" -ből. (Saját mániám, hogy az Apache mellé rakom Win-n, általában úgy is együtt kell.)
Igaz, nem a telepítős nyavaját, hanem a zipest használom és az Apachet is magam telepítem. Néha ugyan ezzel is vannak apróbb szívások, de csak egyszer kell összerakni, azután stabil, mint a beton. És a legfontosabb: a WAMP, XAMP, EasyPHP és egyéb szemétbányákkal ellentétben nem szokott probléma lenni azzal, hogyha valami olyan bővítményt szeretnék felrakni, amely nem része semelyik alap terjesztésnek. Az ilyen összecelluxozott nyavalyákra ez nem mindig mondható el.
WIMP?
A WAMP - Nekem
Ez a WIMP érdekes felvetés. Nekem mondjuk személy szerint az Apache konfigurálhatósága sokkal átláthatóbb és érthetőbb, mint az IIS-é, de lehet, hogy csak jobban meg kéne ismernem.
Én egyébként fejlesztési környezetben azért szeretem jobban az ilyen konzerv megoldásokat, mert egyszerűbb telepíteni őket, egyszerűbb velük a szolgáltatásokat igény szerint elindítani és leállítani, és gyorsan és egyszerűen lehet velük az egyes PHP verziók között váltogatni. Ezen előnyök számomra ellentételezi az esetleges kényelmetlenségeket, bár az elmúlt 4-5 évben ennyit még sosem szívtam a WAMP-pal, mint most.
Üdv:
Dávid
új gép, új szenvedés
Aztán az is zavart egy idő után, hogy ha fel is rakok mindent szépen, attól még WAMP lesz és nem LAMP, ami a hosting szervereken van. Ó, mennyi szívás volt a platformkülönbségek miatt!
Végül döntöttem: VirtualBox + Ubuntu
Pro:
- egyetlen Image fájl Archiválható, verziózható, backupolható, hordozható gépek között és platformok között is
- kordában tartható, hogy mennyi tárhelyet és memóriát fogyasszon
- egyszer kell csak telepíteni, egy Windows reinstallkor csak a VirtualBox appot kell telepíteni és használható a korábban használt Image.
- LAMP lesz
- most már van legalább egy jó step-by-step leírás (bízok benne, hogy az)
- nem lesz teleszemetelve a Windows, nem lesznek kéretlenül elinduló szolgáltatások
- sokkal több leírás van a neten a LAMP-ra, mint WAMP-ra
- a folder sharing sem probléma már, korábban valóban az volt
Kontra:
- az Image sok helyet foglal, esetenként 10+ GB.
- FAT32 esetén 4 GB alatt kell maradni
- korábban nem volt egy jól összeszedett, step-by-step leírás hogyan is kéne ezt jól csinálni
Kis önreklám ugyan, de legyen: http://lamp.gixx-web.com/ :) Sokat kutattam, sokat teszteltem, sokat írtam és sokat illusztráltam. Nem 100%-ig hibamentes, de igyekszek up-to-date lenni és minden nyelvi és tartalmi hibát javítani.
Egyszer kipróbáltam: a teljes leírást követve a telepítés minden mókával és jósággal beállítva használatra készen 4 óra 20 perc volt. Egy délutánt megér, nem? :)
Egy pendrive-on cipelem a VBox Image fájlt, mindig nálam van biztonságban és csak egy VBox app kell, hogy használhassam.
Remélem, hasznát veszitek.
Néhány hónapja írtam neked
Kb 2-3 hónapig a virtuális LAMP konstrukcióval csináltam én is mindent, de azzal a különbséggel, hogy a windowson jól belakott netbeanssel fejlesztettem és shared folderral pakoltam át virtuális gépre a fájlokat. Egy ideig jó is, csak van, hogy megadja magát ez a módszer és valami miatt nem észleli a virtuális gép az új fájlokat (illetve terminál ls szép piros bejegyzésként reprezentálja) és csak újraindítás után tudtam folytatni a munkát. Ezen kívül semmi komoly problémám nem volt vele.
Javítások
Munkaidőben meg sajnos nem nagyon van módon orvosolni a hibákat.
Ha jól emlékszek, főleg nyelvtani hibák voltak (egyesszám-többesszám következetlenség), de a példakódok / screenshotok javítva lettek (remélem, mind).
Épp most olvastam végig, és nem találtam most olyan szemetszúró hibát, ami a telepítést akadályozná. Nálam ezek a kódok mentek, közvetlenül a teminálból másoltam ki.
Természetesen továbbra is várok minden hibajelentést, és amint lesz módom egy új gépet venni (CHF árfolyamfüggő a lakáshitel miatt), azonnal nekiállok. Addig csak a kritikus konzolparacs hibákat tudom megígérni, hogy javítom :)
Persze, érthető, és tényleg
Természetesen a lakásod véletlen se menjen rá, az árfolyam meg egy jó darabig még ott lesz az egekben sajnos...
1. Optimális esetben az AMP
2. Platformkülönbségek: úgy gondolom ezeket ki _kell_ küszöbölni még kódolási szinten. Egy PHP-ben mi lehet platformfüggő?
3. AMP csomag méret: 330 Mb. Emellé esetleg lehet tenni egy eclipse-et (szintén install mentesen) 170 Mb-ból. Durván számolva fél giga a dev környezet.
4. Én a hosts fájlban létrehoztam pár bejegyzést, ami a munkák domainjének másolata, egy x-xel a végén, mindegyik a 127.0.0.1-re mutat, így könnyen elérem őket.
Eredmény: a fenti fél giga becslés alap konfig. Ezen kívül lehet játszani azzal, hogy többféle php verziók, több mysql hoszt.
Én úgy csinálom, hogy a dev környezethez indítok egy apache-ot, a mysql tunnelezve van a test szerverről (lassú, de nyilván nem a gyorsaság ilyenkor a cél, vagy), ha mégis kell lokálban mysql, akkor azt is elindítom, úgy már lehet performanciát is mérni.
Fázisonként git push, kipróbálom a testszerveren is (ami linux), ha minden oké, akkor mehet élesbe.
Egy PHP-ben mi lehet
Kb. az összes PHP modul platformfüggő. Azaz minden operációs rendszerre külön kell lefordítani, illetve a megfelelő binárist csatolni. Na meg természetesen más környezetekben másképp működik kicsit a PHP. A dokumentáció ír is ezekről a problémákról (például Windows esetén fájlkezelés, process kezelés stb.). Csak hogy legyen pár érdekesebb példa: mail, flock, money_format, mktime
Rosszul kérdeztem, elnézést
Egy PHP scriptben mi lehet platformfüggő?
system() és a ` operátor így
Attól tartok a
2. PHP_EOL.
PHP
Nem érdemes telepítgetni...