ugrás a tartalomhoz

A WAMP és a 64 bites Windows 7

tisch.david · 2011. Aug. 27. (Szo), 22.34

Ú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.

 
1

Saját gépemen meglehetősen

bugadani · 2011. Aug. 27. (Szo), 22.57
Saját gépemen meglehetősen igénytelenül XAMPP-ot használok (túl sok volt a bajom a virtuális linuxon fejlesztéssel, főleg a shared directory szivatott lépten-nyomon, meguntam). Na azzal semmi ilyen szívás nincs/nem volt.
2

Nem tudom

Poetro · 2011. Aug. 27. (Szo), 23.29
Sose tudtam rájönni, mi ezekben a csomagokban a jó, én mindig csak a szívást hallom ezek felől. Én már több mint 8 éve egyesével telepítem fel az Apache / PHP párost a gépre (gyakran a MySQL el is marad) és az első telepítéstől eltekintve minden flottul ment, pedig azóta már elhasználtam pár gépet otthon, és amikor még munkahelyen dolgoztam, akkor ott is.

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.
3

WAMP vs egyedi telepítés

Granc Róbert · 2011. Aug. 28. (V), 06.53
Ha jól értem a szövegből, akkor nem a WAMP csomaggal van itt gond, hanem a PHP-vel (tényleg, ki kellene próbálnom, van 64 bites windowsom is), az nem kezeli jól a zárójeles útvonalakat. Akkor pedig teljesen mindegy, hogyan telepíted, WAMP-ként vagy külön-külön.

Ha jól látom, talán nem is PHP probléma...
4

inkább XAMPP

orosznyet · 2011. Aug. 28. (V), 14.03
Én eleinte manuálisan raktam fel a dolgokat (PHP,MySQL,Apache), de sokszor akadtak verziók, volt pl amit egy-az-egyben összeférhetetlen volt. Aztán jött a XAMPP, ami profin konfigolja magát, legyen szó XP leletről, 64 bites WIN7-ről, probléma nélkül oda telepítem ahova akarom.

Valamit nagyon jól csinálok, mert nekem még 1x sem volt ilyennel bajom.
5

Csak egyszer kell összerakni...

saxus · 2011. Aug. 28. (V), 20.41
A baj vélhetően az, hogy a php.ini-ben azon path bejegyzéseket, melyek neve zárójelet tartalmaz


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.
6

WIMP?

thekingr · 2011. Aug. 29. (H), 08.20
WIMP esetleg szerintem sokkal jobb mint a WAMP. Kevesebb vele a baj és szinte mindent tud sőt akár többet is mint az Apache (legalábbis windows alatt).
7

A WAMP - Nekem

tisch.david · 2011. Aug. 29. (H), 09.47
Sziasztok!

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
8

új gép, új szenvedés

Gixx · 2011. Aug. 31. (Sze), 12.34
Én nagyon hamar megúntam, hogy folyton újra kell telepíteni mindent, ha valamiért újra kellene rakni a Windowst (win98 és XP korszakban azért pár havonta megtettem).

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.
9

Néhány hónapja írtam neked

bugadani · 2011. Aug. 31. (Sze), 13.00
Néhány hónapja írtam neked egy részleges hibajegyzéket, de még mindig viszont látom a hibákat, amiket találtam ;) Igazából azóta nem nagyon volt erőm tovább keresni, emiatt elnézésedet kérem.
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.
10

Javítások

Gixx · 2011. Aug. 31. (Sze), 13.36
Sajnos az otthoni PC-m két hónapja tökösen, alaplaból döglött meg, a laptop meg még a Carmageddon 2-t sem képes futtatni, ami meg azért nem mai game :)

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 :)
11

Persze, érthető, és tényleg

bugadani · 2011. Aug. 31. (Sze), 13.57
Persze, érthető, és tényleg főleg csak stilisztikai jellegű hibák vannak, illetve 1-2 nyelvtani, de ezek a megértést lényegében nem nehezítik. Egy része hiba, másik része következetlenség, harmadik pedig angoltalanság. A konzolos kódok épp annyira jók voltak, hogy a leírás alapján meg tudjam csinálni a szervert, ami azért jelent valamit :)
Természetesen a lakásod véletlen se menjen rá, az árfolyam meg egy jó darabig még ott lesz az egekben sajnos...
12

1. Optimális esetben az AMP

deejayy · 2011. Szep. 1. (Cs), 14.40
1. Optimális esetben az AMP csomag windozon semmilyen installt nem igényel. Egyetlen parancsot kell kiadni, ami beregisztrálja az apache-ot szervízként, amit aztán persze gyorsan át is lehet állítani kézi indulásúra.

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.
13

Egy PHP-ben mi lehet

Poetro · 2011. Szep. 1. (Cs), 14.46
Egy PHP-ben mi lehet platformfüggő?

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
14

Rosszul kérdeztem, elnézést

deejayy · 2011. Szep. 1. (Cs), 19.19
Rosszul kérdeztem, elnézést :)

Egy PHP scriptben mi lehet platformfüggő?
15

system() és a ` operátor így

bugadani · 2011. Szep. 1. (Cs), 19.38
system() és a ` operátor így nagyon hirtelen, illetve szöveges fájlok esetén például a sorvége karakter is változik oprendszerenként (bár ez utóbbi a legkisebb gond)
16

Attól tartok a

deejayy · 2011. Szep. 2. (P), 11.19
Attól tartok a rendszerparancsok hívása a legtöbb tárhelyszolgáltatónál biztonsági korlátozásokba ütközik. Emellett, milyen általános célú weboldal engedheti meg magának, hogy egy ilyen rendszerhívással késleltesse a weboldal betöltését?

2. PHP_EOL.
17

PHP

Poetro · 2011. Szep. 2. (P), 12.21
Eddig PHP-ról volt itt szó, nem tárhelyszolgáltatókról és weboldalakról. Elvégre PHP-t parancssorban is sokan használnak, gondolok itt például janoszen I proclub-ra, vagy például a Drupal parancssori környezetére, a drush-ra, vagy a szinte minden keretrendszerben előforduló kódgeneráló eszközre. Ezek szoktak futtatni rendszerparancsokat, valamint cron-ból sok más alkalmazás is szokott rendszerparancsokat futtatni. Például ImageMagick-kel képeket generálunk, folyamatokat ellenőrzünk. Itt a fórumon is volt már pár kérdés azzal kapcsolatban, hogyan tudunk például szolgáltatásokat kezelni PHP-ból. Fontos gondolni az adminisztrációs felületekre, amik lehet komolyabb feladatokat is ellátnak, mint amit a weboldal látogatója lát.
18

Nem érdemes telepítgetni...

whiteman0524 · 2011. Szep. 4. (V), 18.48
És nem érdemes a WAMP-ot használni, helyette inkább próbád ki az XAMPP-ot. Abból van telepítős és tömörített kicsomagolós megoldás is. A telepítős megoldással én állandóan csak szívtam, mert indításnál mindig hibákat dobott egy idő után. A csomagolt tömörített verziót nem kell telepíteni, csak kicsomagolod valahová és kész is van. Akár egy USB-re is felrakhatod és onnan futtathatod, mert mindent egy mappába tesz bele, és semmit se kell beállítani, vagy konfigurálni sőt még a registry-t se fogja teleszemetelni. Teljesen tiszta megoldás. Ha nem kell akkor meg egyszerűen törlöd az egész mappát és mintha ott se lett volna. Elég régóta használom így az XAMPP-ot és én is 64bites Win 7-el rendelkezem. Soha semmilyen problémám nem volt még vele, ezért Erősen ajánlom. A WAMP-ot meg szvsz felejtsd el.