PHP-t futtató, *üzleti célokra használt* (pl. hosting, belső rendszer) szerveremen 5.3-at

PHP

használok
22% (107 szavazat)
tervezek bevezetni 3 hónapon belül
5% (23 szavazat)
tervezek bevezetni 6 hónapon belül
4% (22 szavazat)
tervezek bevezetni 12 hónapon belül
4% (19 szavazat)
nem tervezek bevezetni, maradok 5.2-en
9% (47 szavazat)
nem tervezek bevezetni, maradok 5.1-en
1% (4 szavazat)
nem tervezek bevezetni, maradok 5.0-n
0% (2 szavazat)
nem tervezek bevezetni, maradok régebbi verzión
2% (11 szavazat)
Egyéb/nem érint a szavazás
53% (260 szavazat)
Összes szavazat: 495

( Tyra3l | 2010. 11. 18., cs – 10:39 )

ha sajat, igenyes(nem hasznalsz olyan feature-t, ami mar 5.2-ben is ellenjavalt/deprecated volt) kodrol van szo, akkor kb. az idozona beallitasa az egyetlen feladat az upgrade soran.

As far as PHP 5.2 is concerned 5.2.15 is the last release before EOL
that was announced this summer, the goal of this release is to
finalize the various key and security fixes that were made since the
last release.

aki meg nem migralt, kezdjen gondolkozni rajta.

Tyrael

"ha sajat, igenyes(nem hasznalsz olyan feature-t, ami mar 5.2-ben is ellenjavalt/deprecated volt) kodrol van szo, akkor kb. az idozona beallitasa az egyetlen feladat az upgrade soran."

Pl:

func_get_arg(), func_get_args() and func_num_args() can no longer be called from the outermost scope of a file that has been included by calling include() or require() from within a function in the calling file.

*Update:
Ismerek olyan Webservice -t, amely a relativ névterek miatt sajnos 5.1.6 felett nem működik (ebben lehetett ezt a hibát kihasználni).Nem folytatom...ennyit az igényes kódról.

szerintem az ilyen kod:

foo.php: 


function bar($a, $b){
  include 'baz.php';
}
bar(1, 2);

bar.php: 


$args = func_get_args();

kivul esik az igenyes kod hatarain.
szerintem.

a masik megjegyzesedre: gondolom a nevterek helyett hatokort, vagy scope-ot akartal mondani, mivel ugye nevterek csak 5.3-mal kerultek be a nyelvbe (elotte is volt mondjuk 1 darab nevter, a globalis, de a mondatodban tobbes szam szerepelt)

Tyrael

Pedigy mennyi minden nem mukodik rendesen 5.3-mmal... hajjaj... Mi akaratunkon kivul megleptuk a migraciot... Hat... megbantuk...
Hosting szolgaltatokent nem kotheted ki, hogy nalad csak igenyes kod lehet.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

nekem egyedul a windows verzioval voltak problemaim, ott bizonyos module-ok nem voltak meg(sot firebird asszem csak most fog windows buildbe visszakerulni 5.3.4-el), mondjuk windows amugy is elegge mostohagyerek pecl ugyben(jo tudom, pierre-tol letoltheto egesz szep szamu extension, meg forgathatok magamnak visual studio express-bol, de azert nem ugyanaz, mint egy pecl install imagick)

ettol fuggetlenul hosztingszolgaltatokent szopo, de ez altalaban minden migralasnal ilyen.
hamarosan mondjuk mindenkinel forro lesz a talaj, mert 5.2.15 utan nem lesz security support sem, aztan nem hiszem, hogy sokaig fogjak lyukason uzemeltetni a szervereket a szolgaltatok, inkabb torjon el a felhasznalo siteja.

Tyrael

Hat, meg nekunk is van PHP4-es webszerverunk, mert a felhasznalok ezt kertek.

Egyebkent meg nincs olyan, hogy torjon el a felhasznalo site-ja. A felhasznalo _fizet_ konkretan neked azert, hogy a site-ja megfeleloen mukodjon, es ot baromira nem erdekli a te nyomorod. Ha azt mondod, hogy innentol kezdve torott a site, akkor fogja, es elviszi olyan szolgaltatohoz, aki tud neki adott esetben 5.2-es PHP-t adni. Ez neked -1 fizeto ugyfel.

Egyebkent meg jail-lel / chroot-tal nagyon szepen meg lehet oldani a dolgot, es akkor mindenki olyan PHP-t kaphat, amilyet megerdemel.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

elhiszem, de valoszinunek tartom, hogy ha a php4es siteokat folyamatosan deface-elni fogjak a script kiddiek valami remote exploittal, akkor meg szinten nem lesz elegedett a felhasznalo a szolgaltatassal.
ami szerencse, hogy van meg 1-2 olyan enterprise disztro, aminek meg van olyan verzioja, amiben meg tamogatott a php4 (RHEL v4 pl.) igy egyreszt ott meg talan lehet "biztonsagosan" futtatni php4-et, masreszt az ott felfedezett/bejelentett biztonsagi hibakat illetve a javitasokat esetleg at tudod peccselni magadnak.
de ez mar egy doglott lo, minnel kesobb kezded migralni a usereidet, annal nehezebb melo lesz.

azt gondolom tudod, hogy a linuxos chroot by-design nem jo jailnek, grsecurity nelkul ki lehet maszni belole.

Tyrael

Figyelj, ha a szar kod tulajdonosa rendesen fizet azert, hogy neki mukodjon a weboldala, akkor nekem kutyakotelessegem azt biztositani. Hogy en ezt hogy oldom meg, az az ugyfelet nagyonbaromira nem fogja erdekelni.
Egyedileg persze lehet par ugyfel fejevel beszelni, hogy figyelj, ez igy nem jo, igy kellene csinalni, de ebbol nem lehet rendszert csinalni, sokan azt sem tudjak mi az a PHP, amire jobb vagy bal klikkel kell kattintani a weboldalon? Es ezek is fizetnek.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

És azért is fizet, hogy 3x annyit szívjál miatta, vagy esetleg kapcsold ki a biztonsági beállításokat, mert nem megy másképp a gányolása?
Az olyan, aki azt se tudja mi a PHP, az ne fejlesszen oldalt, sírva könyörgöm. Így is rengeteg a balfasz már.
--
Discover It - Have a lot of fun!

a gányolt pistikék prédául úgy születnek, hogy
a szolgáltatónál PHP Version 4.4.9 van,
otthon meg meg a munkahelyen "gyári"
PHP Version 5.3.2-1ubuntu4.5 (10.04 LTS server LAMP),
az ehhez vadászott 1200 oldalas PHP4-es manuállal.

:) félnapokat töltök a búsban :)

(IE8; Firefox; Chrome; Opera; Safari)

Az is lehet, teljesen mindegy.
Figyelj, van annyira 1 bites pistike is, hogy letölt egy akármilyen zip-et, feltölti a tárhelyre, aztán megnyitja browserbe, és sír hogy nem megy. Meg se nézi, hogy miért, bele se néz az kódba, nem is érdekli, és nem is akarja tudni. (Pedig ha megnézné, látná, hogy mi a baja, és akár 5 mp alatt javítható lenne.) Annak szerinte mennie kell, mert volt egy honlapja, ott látott róla egy screenshotot, meg egy 5 soros leírást, akkor annak mennie kell.

Tehát ha én urandomból szedek valami tartalmat, összetarolom, feltöltöm egy oldalra, csinálok hozzá egy fake screenshotot, és írok mellé 3 sort, hogy miez, biztos lehetsz benne, hogy lesz olyan, aki letölti, megpróbálja, és aztán menni fog panaszkodni, hogy miért nem megy a kód.
--
Discover It - Have a lot of fun!

( plastik | 2010. 11. 18., cs – 11:19 )

tart karokkal udvozoltem a late static bind-ot!:)

( traktor | 2010. 11. 18., cs – 12:28 )

"Egyéb/nem érint a szavazás"
Es hol maradt a "csak az eredmeny erdekel" string? Hosszu hagyomany tort ezzel meg. :D

( andrewjsi | 2010. 11. 18., cs – 14:33 )

(Használom) Méghozzá pár napja... Azóta nem alszom, fogy a kávém, a türelmem és egyre többször mondom ki, utálom, haragszom... A usernek persze hiába mondom. Karikás szemekkel üdv!

Elég 5.2-ről is. Számtalan user azonnal szól, hogy nem megy a weblapja normálisan. Ezeknek lehet magyarázni főleg, ha valahol ezért még pénzt is adtak, tehát ők maguk nem értenek hozzá és nem is értik miért kellene fizetni azért valakinek, hogy átírja a site-ot. Főleg, hogy egyik nap jó volt, másnap meg már nem?!
Na magyarázza el nekik az ember:)

Jellemzoen azt, hogy ezek drupal, joomla, meg egyeb ilyen nagyon minosegi kodok, raadasul nem is up-to-date verziok, nalunk pl. egy csomo drupal5 van, ami pl. abszolute nem kompatibilis a 5.3-as PHP-val. De meg a legfrissebb cuccokkal is vannak kulonfele nyugok, kezdve azzal, hogy a php.ini -ben par beallitast csak ugy talalomra atneveztek, meg par beallitasnak valtozott a defaultja. Igazabol ezert nem szeretem az ilyen projekteket, baromira nem enterprise minoseg, es meg raadasul szarnak is a visszafele kompatibilitasra.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

drupal5 lassan szinten kikerul a tamogatasbol, hiszen nemsokara erkezik a D7.
az abszolut nem kompatibilis kicsit tulzas, pontosabban eleg sok melot raktak azert a drupal fejlesztok a php5.3 kompatibilitas javitasaba:
http://drupal.org/node/360605
http://drupal.org/node/853064
de valoban nem tamogatott hivatalosan az 5.3 a D5-tel.

milyen beallitasokat neveztek at talalomra?
itt fel van sorolva par valtozas config teren:
http://hu.php.net/manual/en/migration53.ini.php
talan ez tunik egyedul "atnevezesnek", de meg ez sem az igazan:
- zend_extension_debug and zend_extension_ts have been removed. Use the zend_extension directive to load all Zend Extensions

szerintem ennel durvabb valtozasok voltak 5.0 <-> 5.1 <-> 5.2 kozott, persze jo lenne, ha ok nelkul nem torne soha visszafele kompatibilitas.

Tyrael

Van meg, az allow_url_fopen is valtozott allow_url_open -re, es az 5.3-mmal csendben megszunt az ini visszafele kompatibilitasa.

A drupallal kapcsolatban: elsosorban nem is a drupal core a gond, hanem a modulok. Ott meg D6 eseteben is vannak aprobb meg cseprobb nyugok. Es az ugyfelnek eleg egy piros sor a webes feluleten, hogy csorgesse a telefont.

Hat igen, jo lenne, ha legalabb adott foverzion belul kompatibilisek lennenek egymassal a PHP verziok.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Bizony bármilyen hihetetlen is, meg kell nekik érteni, hogy egy oldal karbantartását is ugyanúgy meg kell csinálni, mint a szerverét, vagy mint egy autóét, időközönként el kell vinni szerelőhöz. Akkor is ha jó volt. Kedvenc beszólásom, amikor user mondja, hogy "De eddig jó volt.". Igen, mostmár meg nem jó, meg kell javítani.
--
Discover It - Have a lot of fun!

Mindkettő fontos. De a php fejlesztők szeretik elfelejteni, hogy ugyanúgy karban kell tartani egy oldalt is, mint bármi mást. Azt hiszik, hogy egyszer megcsinálták, és akkor az úgy jó, elmegy az idők végezetéig, piszkavassal se kell hozzányúlni. Hát nem.
A kódba meg nem szoktam belenézni, mert nem az én dolgom, csak akkor derül ki hogy kukába való, amikor módosítasz valamit a php.ini-be, és valamilyen funkció meghal, aminek éppen semmi köze a módosított beállításhoz. Mert mondjuk ha a fájljogosultság nem 777 akkor die(), és éppen nem érdekli, hogy valójában tudja-e írni-olvasni. Vagy épp frissítesz egyet, phpn vagy ftp szerveren, és elkezd nem működni az ftp-n feltöltés, 0 byte a feltöltött fájl, mert a drága nem zárja le a feltöltött fájlt close-zal, mert minek az. Átír egy font colort akárhol, és lehal egy tök másik helyen egy függvény. És akkor ő váltig állítja, hogy márpedig nem ő rontotta el, semmi köze a hibához, eddig jó volt, az én hibám csináljam meg, stb. Próbáld elmagyarázni neki, hogy márpedig ő rontotta el, javítsa ki a kódot, az hogy eddig éppen ment, az csak a véletlen műve. Lehetetlen. Egy lovat hamarabb megtanítasz integrálni.
Ott vannak emelett még pl. olyanok, hogy halvány lila fogalmuk nincs, mi az az encoding, az oldal úgy néz ki, hogy a fájlok latin2, a db táblák latin1, amúgy az oldal meg utf8-ba működik. Valami csoda folytán, meg össze vissza dekódolással eléri, hogy jól látszanak a karakterek, és a tárolás is megy. Csak mondjuk ez pont addig jó, amíg mondjuk frissítésnél le nem fut egy mysql table upgrade, és az amúgy utf8 adatokat végig nem szántja latin1 szerint. Akkor is jön, hogy elromlott, rosszak lettek az ékezetek. Persze, mert szarul csinálta meg. Hozzáteszem, ilyenkor általában a backup is szar. Ezek után veri az asztalt, hogy márpedig az úgy hibátlan, csináljam vissza... Hogyne.
És mindezt évi párezer forintért? Na nem.
--
Discover It - Have a lot of fun!

Picit a masik oldalrol: munkatars meselte multkor, hogy valakiknek fel lett teve a nagy kerdes, hogy nem akar-e szep meg uj meg modern meg csilivili rendszert. Erre jott a valasz, hogy minek? Ott a regi DOS-s program, pont azt tudja, amit nekik kell, 8 eve kellett benne utoljara hibat javitani.

Az mas kerdes, hogy a PHP arra nem kepes, hogy kisebb verziovaltasok eseten is kompatibilis maradjon onmagaval...

----------------
Lvl86 Troll

Persze, csak az ha nem lesz fejlesztve, frissítve, karbantartva, akkor se történik semmi, mert egy olyan gépen van, ami belső háló, rendszerint tűzfal mögött, de olyan is előfordul, hogy egy őskori dedikált 486 vagy p1 arra a feladatra, hogy ezt az egy programot vigye. Hálózat nélkül, szeparáltan. Emellett 1 vagy viszony kevés, meghatározott számú humanoid használja. Ezekbe nincs pl. biztonsági kockázat.

De más a helyzet egy oldallal, ami kint van a neten, publikusan, és pl. a mai napig valami régi (tehát nem is a legutolsó) php4-en fut, mysql4 és apache 1.3-mal, és olyan OS-sel, ami amúgy rég nem supportált, register globals és hasonló finomságokkal....
--
Discover It - Have a lot of fun!

( melon | 2010. 11. 18., cs – 15:07 )

A 'használok' opciót választottam, de az az igazság, hogy van még 5.2-es is, ott 3 hónapon belül lesz upgrade.

( Nyosigomboc v | 2010. 11. 18., cs – 15:19 )

Nem uzleti, de 5.3 van, ahol van. (egyeb/nem erintet jeloltem)

--
The iPad: Because the iPhone was too small for other people to notice you.

( wladek1 | 2010. 11. 18., cs – 19:58 )

php-fpm miatt mar nem igenyel patchelest; naná...

En az apache-val inkabb a nyitott fajlok mennyisege miatt szopok egy helyen, PHP miatt halistennek eddig nem kellett. Meg egyebkent, az Apache + PHP kombo eleg stabil, ha a PHP-nak nincs valami nyugje, akkor az Apache-nak sincs.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

( r1pp3rj4ck | 2010. 11. 28., v – 01:25 )

hmm en egy tervezek 3 honapon belult valasztottam, bar most is 5.3-at hasznalunk dev-szerveren, de csak 3 honapon belul lesz fent elesen :D