PHP request_order

Egy érdekes eset kapcsán kérték a segítségemet. Egy fórumot a tulajdonosai saját szerverre költöztettek és utána azt tapasztalták, hogy a beállításokat nem tudják megváltoztatni. Ezt úgy kell elképzelni, hogy az admin felületen átállítják pl. a fórum nevét és elküldés után minden marad a régiben.

Mivel a naplókban releváns bejegyzéseket nem találtam a hibát illetően, ezért első körben cache problémákra gyanakodtam, aztán kis fejvakarás után kiderült, hogy a php.ini-ben volt a probléma forrása.

Amit tudni kell, hogy a default php.ini-t használták, nem állítottak át benne semmit.

A request_order beállítatlan volt:

request_order =

A dokumentáció szerint, ha a request_order nincs beállítva, akkor a variables_order-ben beállítottak érvényesülnek, ami itt nem történt meg. Vagy csak én értelmezem rosszul a dokumentációt...

Beállítás után a hibajelenség megszűnt:

request_order = "GP"

E örö e bódottá!

Hozzászólások

Mint egy ex php és mint jelenleg full stack js developer az utóbbi időkben egyre jobban rühellem a php szerverek tutujgatását.

Kajak, múltkor is egy meglévő gagyi keretrendszerben tutujgattam egy félkész oldalt, a sok évek óta használt és megszokott php5.3 és 5.6 alatt.
Windowson minden szép és jó és mikor tölteném fel demo szerverre (ami egy NORMÁLISAN bekonfigolt, többek által használt webszerver) naná, hogy nem akart semmi sem működni (display_error on, de fehér képernyő). Jó, persze a framework volt inkább a ludas, de totál kiborított, hogy a kis projekből lett egy nagy (új munkahely mellett) és a végén még létemre még az élesítéssel is killódnom kellett (ráment 2 estém), hogy egyáltalán az ügyfél meg tudja nézni.

Úgyhogy most erős indíttatásom van megismerkedni mondjuk a meteor.js-el. Bár ahogy azt néztem az direktben webappokhoz való...

---------------------------------------
Devmeme - fejlesztői pillanatok

nem a vindoze hasznalata a valodi problema (bar en inkabb rudtancolnek egy melegbarban), hanem hogy masmilyen kornyezetben fejlesztesz, mint amilyen a demo szerver (meg gondolom a prod is). A docker / virtualis gepek koraban luxus nem azonos kornyezetet eloallitani, mint az app vegleges helye...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Az utóbbi két évben egy kisvállalkozásnál dolgoztam. Ott megtanultam, hogy gyorsan kell működő kódot, az teljesen mindegy, hogy milyen sz*r, mennyire karbantartható/átlátható a kód, meg hogy hol, min és mivel fejlesztünk, lényeg, hogy át lehessen adni úgy, hogy úgy tűnik jó a kód.

Most, hogy váltottam biza meg kell küzdenem a saját belső harcaimat és lassan már én is tudom már jól, hogy célplatformra fejleszteni aranyat ér és a devszerver nem az ördögtől való.

De akkor is. Lassan már mindent hh-ban írnak és (relációs adatbázist is már csak a b*zik használnak... :D) a Cassandra is tör felfelé, mint a talajvíz, nekem is fejlődnöm kell valamilyen modernebb irányba.

Egyébként a topiknyitó témához kapcsolódik

---------------------------------------
Devmeme - fejlesztői pillanatok

Szerintem meg előny. Mert ha tényleg platformfüggetlen kódot írsz (a PHP elvileg platformfüggetlen, meg egy csomó más nyelv), akkor szerintem kifejezetten előny, ha nem azon fejlesztesz, ami a végleges rendszer lesz.
Az persze nem kérdés, hogy kell olyan tesztrendszernek lennie, amely azonos az élessel.
Viszont a fejlesztői rendszernek egyáltalán nem kell annak lennie.
Tanuljon meg a fejlesztő platformfüggetlen kódot írni.

Mert ha tényleg platformfüggetlen kódot írsz

errol nem volt szo, ill. egyaltalan: miert kellene platformfuggetlen kodot irni? A topikindito foruma, ill. winben demo szervere egy jol leirhato kornyezet. Sok esetben az boven eleg, hogyha a cel platformon elketyeg a cucc, es nincs ra uzletileg igeny, hogy meg n+1 kornyezetben is mukodjon.

Mondom, van annak letjogosultsaga, hogy a Linux kernel vagy a java egy kenyerpiriton (smart toaster rulez) is fusson (es epp ezert egy csomo olyan dolog kell a kodba, ami az egyes plaformok kulonckodeset lekezeli), de nagyon sok szoftver, megoldas stb. nem ilyen.

Minel kevesebb kornyezetet kell tamogatnod, annal tobbet tudsz optimalizalni. A docker-t is pont azert hoztam elo, mert ott a futtatokornyezetet is az alkalmazas melle csomagolod: write once, run everywhere (ahol a docker el tud indulni).

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

"miert kellene platformfuggetlen kodot irni? "
Tehát azt mondod, hogy egy terméknél, amit el akarsz adni, és platformfüggetlen runtime-on írod, akkor platformfüggő kódot írsz, hogy csak bizonyos OS alatt működjön? Akkor már miért nem olyan nyelven, és runtime-on, amivel az OS minden szolgáltatását ki tudod használni? Totál értelmetlen például Javaban Windows-only szoftvert készíteni.

egy terméknél, amit el akarsz adni, és platformfüggetlen runtime-on írod,

nem egeszen. A docker nem platformfuggetlen, ill. a virtualis gep (bar elvileg akarmilyen architekturat tamogathat) sem az. Szamomra mindkettonek pont az a lenyege/haszna, hogy egy definialt kornyezetet csinalhatsz benne.

Ha a topikinditotol egy kisse elkanyarodunk a piler (egy email archivalo megoldas) fele, akkor nem szandekosan kerulom a platformfuggetlenseget (bar a C-t aligha lehet platformfuggetlen nyelvnek tekinteni), hanem kivalasztottam egy bizonyos OS-t (=Linux), es azon ill. arra fejlesztem. Nem arrol van szo, hogy utalom a tobbi unix-ot, pl. solaris, freebsd (btw. ezeken is elfut a cucc amugy), hanem arrol, hogy sokkal konnyebb egy OS-t, azon belul 1 disztribuciot, ill. egy jol definialt kornyezetet szem elott tartva elkesziteni egy random termeket. Pl. lehet, hogy a vevo linux disztribuciojanak aktualis libxxx.so-ja bug-os / nem jo, de nem szamit, mert a piler melle csomagolt futtato kornyezetben (akar egy docker kontener, akar pl. egy OVA/OVF image) a jo verzio van. Valamilyen egzotikus linuxod pl. gentoo van? Deploy-old a kontenert. Windows-od (hyper-v) van? Telepitsd az OVF-et.

Az valoban igaz, hogy ha javaban irtam volna, akkor tan meg egy kenyerpiriton is elfutna a piler, de ez szamomra sosem volt cel. Az egyik versenytars termek (amit ismerek) egyebkent pont javaban keszult, igy "nativan" elmegy linuxon, vindozen, a kenyerpiriton, de megsem hiszem, hogy pusztan ez komolyan befolyasolna akar az o, akar az en piaci reszesedesemet.

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Vagy csak sikerült kialakítani rendes test, staging, stb. környezeteket, és így nem szükséges a dev gépen kódot futtatni. :)

> A docker / virtualis gepek koraban luxus nem azonos kornyezetet eloallitani, mint az app vegleges helye...

Ezzel azért így vitatkoznék. Ha a környezet definíciója annyi, hogy "php+mysql" akkor talán. Mondjuk ezzel le is fedtük a magyar szoftverfejlesztés elég jelentős részét, szóval lehet, hogy mégis igazad van. ;) Ha viszont ennél bonyolultabb a helyzet, nem biztos, hogy az a workflow a jó, hogy mindenki a dev PC-n tesztel.

Attól függ, mit értünk dev PC-n. Az, hogy milyen OS-en írod a kódot (milyen IDE-vel, meg szövegszerkesztővel), az hullamindegy. Az csak egy bytesorozat. Szerintem különböző dolog a "dev PC" meg a "dev környezet". A dev PC az, amit a fejlesztő arra használ, hogy a kódot elkészítse. A dev környezet meg szerintem az, hogy az a környezet, amit a fejlesztő kedvtelése szerint telepíthet, újraindíthat, és debugolhat (azaz megakaszthatja a program(rendszer) futtaatását, anélkül, hogy más felhasználó (aki lehet fejlesztő is), ebből bármit érzékelhetne.
Simán lehet egy ilyen környezet a dev PC-n is (akár dockerben, akár VM-ben, akár magán az IDE mellett), tökmindegy, ez csak fejlesztésre való: a kód működésének ellenőrzésére, viszgálatára.
És épp ezért szükség lehet a dev gépen is kódot futtatni, nincs ezzel semmi baj.
Nyilván nem fogom egy debug erejéig megakasztani a staging környezetet, mert épp debugolok egy metódust. Vicces lenne.

> Szerintem különböző dolog a "dev PC" meg a "dev környezet".

Igen, ezért hangsúlyoztam, hogy a konkrét számítógépről beszélünk, amin a kódot pötyögik be, nem a dev környezetről. :)

(Legalább) Egy dev környezet természetesen kell, ami bizonyos esetekben lehet akár a fejlesztők gépein is - én inkább azzal az állítással vitatkoztam, hogy a "masmilyen kornyezetben fejlesztesz, mint amilyen a demo szerver" rossz dolog.

Ha a környezet definíciója annyi, hogy "php+mysql"

meg te is tudod, hogy nyilvan nem annyi. Adott esetben meg az is fontos lehet, hogy mi az egyes php modulok 'alatt' levo lib***.so-k verzioja. Pont ezert beszeltem futtato kornyezetrol. Ha pedig a hajszalpontosan leirt kornyezet megvan a dev pc-n, akkor miert is ne lehetne azon tesztelni (valamennyit)?

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

> Ha pedig a hajszalpontosan leirt kornyezet megvan a dev pc-n, akkor miert is ne lehetne azon tesztelni (valamennyit)?

Ha teljesen ugyanaz, akkor nyilván oké. Ezért írtam azt, hogy ha annyi a definíció, hogy php+mysql, akkor sima ügy. Természetesen még én is tudom, hogy lehet tovább definiálni a verziókat, de az a komplexitáson már nem sokat változtat.

A legtöbb céges projekt, ami túlmutat a php+mysql weblapfejlesztésen, ott viszont már nem olyan triviális mindenkinek fenntartani a saját PC-jén egy saját dev környezetet.

Természetesen még én is tudom, hogy lehet tovább definiálni a verziókat, de az a komplexitáson már nem sokat változtat.

ok, akkor nem magyarazom, ha nem erted

A legtöbb céges projekt, ami túlmutat a php+mysql weblapfejlesztésen, ott viszont már nem olyan triviális mindenkinek fenntartani a saját PC-jén egy saját dev környezetet.

miert is? Mindenki pont ugyanazt a Dockerfile-t kapja (vagy keszen a kontenert), es igy pont ugyanazt a kornyezetet hasznalhatja. Bebikonnyu.

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Lehetne egy olyan tool, ami a phpinfo() kimenetét parsolja, és az alapján megadja a fordítási opciókat és a beállításokat! Illetve két szerver aktuális beállításait tudná összehasonlítani. Elég általános, h egy ilyen költözésnél felmerül ezekkel valami probléma.

Őőőő... minek parsolni a kimenetet, ha ott vannak a teljesen korrekt függvények a beállítások lekérdezésére? (ini_get, ini_get_all, php_version, get_loaded_extensions etc.)

rejtett subscribe

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Azért itt nagyon esélyesnek tűnik, hogy programozási hiba van a háttérben, nagy valószínűséggel ugyanolyan nevű adatok érkeznek GET és POST paraméterkent, ami nem túl szép dolog.

Nincs azzal semmi baj, ha nem a $_REQUEST -et hasznalod, hanem ahonnan tenyleg varod az adatokat ($_GET / $_POST).
Ha valaki tenyleg $_REQUEST-et hasznal es tenyleg elkuldi $_GET -ben es $_POST -ban ugyan azzal a nevvel ugyan azt a valtozot mas ertekekkel, akkor megerdemli hogy szopjon vele

// Happy debugging, suckers
#define true (rand() > 10)

"es tenyleg elkuldi $_GET -ben es $_POST -ban ugyan azzal a nevvel ugyan azt a valtozot"
Mivel gy HTTP request nem lehet egyszerre GET és POST, ezért ez csak úgy lehetséges, hogy ha:
1. Van egy formod, aminek az action-je már egy olyan URL, ami tartalmaz query stringet, méghozzá olyan formátumban, amely a HTML specifikáció szerinti GET típusú formok application/x-ww-form-urlencoded kódolásának felel meg, & jelekkel elválasztott key=value párok. Amúgy a query string formátumára nincs semmilyen megkötés általánosságban, teljesen a fogadó fél dönti el, hogyan értelmezi.
2. Ez a formod azonban valójában POST-os, és a bodyban application/x-ww-form-urlencoded típusú tartalom van.
3. A formban van olyan field, amely megfelela query stringben valamely kulcsnak.

Ilyenkor valóban a programozó feladata eldönteni, hogy a POST body, vagy a GET body élvez prioritást, esetleg a paraméternek egyszerre több értéke is lehet.
DE: nem a runtime (a PHP runtime és annak konfigja) a felelős annak eldöntésében, hogy melyik élvez prioritást. A request_order pont ezt csinálja. Ez rossz.
Mivel a drágalátos programozó (PHP Steve) meg baszik gondolkodni, nem tudja, hogy valójában ilyenkor a keretrendszer és annak konfigja dönt, és úgy programoz, hogy az ő szoftveréhez a runtimeot is konfigolni kell, azaz nem self-contained az alkalmazás, ez megint rossz.

Ilyen az, amikor egy buta programozó összekerül egy rossz nyelvvel és runtime-mal.

"Ilyenkor valóban a programozó feladata eldönteni, hogy a POST body, vagy a GET body élvez prioritást, esetleg a paraméternek egyszerre több értéke is lehet.
DE: nem a runtime (a PHP runtime és annak konfigja) a felelős annak eldöntésében, hogy melyik élvez prioritást. A request_order pont ezt csinálja."

Szó sincs róla. A programozó használhatja a $_GET és $_POST szuperglobális tömböket az adatok elérésére - már ha ez külön nincs tíltva. A request_order csak a $_REQUEST tömbre vonatkozik, ami még a $_COOKIE tömb adatait is tartalmazza az említetteken kívül. Sőt régebben még a $_FILES is elérhető volt benne. Ez jelenleg csak egy plusz lehetőség. (Histórikusan meg annyit érdemes róla tudni, h régebben a register_globals opcióval be lehet kapcsolni h a globális scope-ban változóként elérhetőek legyenek a post,get, cookie adatok. És ha ütközés volt akkor melyik legyen az érvényes. De ez már a múlt szerencsére.)

" ugyanolyan nevű adatok érkeznek GET és POST paraméterkent, ami nem túl szép dolog."
Egyrészt egy metódus egyszerre nem lehet GET és POST. Ezek kizáró dolgok. Azaz nincs olyan, hogy egyszerre GET paraméter és POST paraméter.

Olyan van, hogy URL query string, meg olyan van, hogy request body és abban application/x-www-form-urlencoded kódolású tartalom, meg olyan van, hogy GET típusú form. Ez utóbbi esetben van az, hogy a query string értéke lesz a form fieldek értéke. De ekkor nincs POST ugyebár, GET típusú a form.

Miért lenne ezzel baj? A PHP hülye implementációja a baj.

Ugyanis a HTML specifikáció szerint az application/x-www-form-urlencoded típusú kódolás esetén a form adatai POST esetén nem a query string részei lesznek, hanem a HTTP body részei, speciális kódolással.

Persze, ehhez kéne ismerni a HTTP és a HTML specifikációt, de hát a PHP fejlesztők basznak rá. Van $GET meg $POST aztán csá, azt se tudják, melyik micsoda és mire való.

Azért ne keverjük itt a dolgokat össze. A query string használható (és ezt a specifikáció sem zárja ki) POST esetén is. Az hogy a query string szerepel az uri-ban, nem lesz automatikusan GET valamiből, nem is értem honnan vetted ezt. A kettőt nyugodtan lehet használni párhuzamosan, másra valók egyszerűen.
A PHP implementációjával sincs effektíve baj, mivel a $_REQUEST egy nem specifikált dolog, ráadásként kellően testre szabható ahhoz, hogy legyen lehetőséged értelmesen használni.
Az, hogy valaki ész nélkül használja, az nem az implementáció hibája. Az hogy valaki egyáltalán használja, az már egy más kérdés. Akkor amikor bekerült a nyelvbe, jó ötletnek tűnt kategória

// Happy debugging, suckers
#define true (rand() > 10)

"Az hogy a query string szerepel az uri-ban, nem lesz automatikusan GET valamiből"
Nem is állítottam. Azt állítottam, hogy GET action esetén lesz a form fieldekből query string. Semmi mást nem állítotam.

"A PHP implementációjával sincs effektíve baj, mivel a $_REQUEST egy nem specifikált dolo"

Azt azért érzed, hogy ez paradox. A $_REQUEST nem specifikált, és ez így van jól. Na ne vicceljünk. Pont te mondod, hogy a query string és a post-ban küldött form tartalom másra való, mégis jónak gondolod a $_REQUEST létét. Na ne vicceljünk már. Ha ezek másra való dolgok, akkor meg kell őket különböztetni. Az, hogy létezik $_REQUEST, az egy hatalmas design hiba. De hát mit várunk a PHP-től, ahol alapos tervezés nem igazán volt soha sem.

By design megadhatod a REQUEST működését, ami pont úgy fog működik ahogy megadtad és aztán úgy használhatod ahogyan akartad. Ez nem design hiba, hacsak nem programozói oldalról. Tiltsuk be C-ben a pointerek használatát, mert szarul is lehet használni, ráadásként elég könnyen, wtf?

// Happy debugging, suckers
#define true (rand() > 10)