[php] Upgrade van veel websites php4 > php5

Pagina: 1
Acties:

Onderwerpen


Acties:
  • 0 Henk 'm!

  • geez
  • Registratie: Juni 2002
  • Laatst online: 18-09 21:41
Ik ben werkzaam bij een webdevlopment bedrijf, waar we hoofdzakelijk werken met de combinatie PHP/MySQL voor de websites. Echter gaat de hoster binnenkort PHP4 uitfaseren, waar de websites van een aardig aantal klanten nog op draaien.

Nu kost het testen van alle functionaliteit van alle websites op PHP5 veel tijd, en wanneer deze aangepast moeten worden gaat er nog veel meer tijd in zitten. Ik vroeg me af of er een tool bestaat die *.php files kan doorlopen op backwards compatibility, zodat er veel tijd bespaard kan worden.

Ik acht de kans klein maar wie weet :)

[ Voor 0% gewijzigd door geez op 21-04-2008 21:56 . Reden: typo ]


Acties:
  • 0 Henk 'm!

  • BBrunekreeft
  • Registratie: Mei 2004
  • Laatst online: 08:29

BBrunekreeft

Dus...

geez schreef op maandag 21 april 2008 @ 21:43:
Ik ben werkzaam bij een webdevlopment bedrijf, waar we hoofdzakelijk werken met de combinatie PHP/MySQL voor de websites. Echter gaat de hoster binnenkort PHP4 uitfaseren, waar de websites van een aardig aantal klanten nog op draait.

Nu kost het testen van alle functionaliteit van alle websites op PHP5 veel tijd, en wanneer deze aangepast moeten worden gaat er nog veel meer tijd in zitten. Ik vroeg me af of er een tool bestaat die *.php files kan doorlopen op backwards compatibility, zodat er veel tijd bespaard kan worden.

Ik acht de kans klein maar wie weet :)
Nou, misschien is de PEAR Package PHP_CompatInfo wat voor je...
Uit de beschrijving: "Find out the minimum version and the extensions required for a piece of code to run"

Edit: Ehm. Dit geeft dus aan wat de minimum versie is. Dat zal in jullie geval altijd PHP4 zijn :(

[ Voor 5% gewijzigd door BBrunekreeft op 21-04-2008 21:55 . Reden: misschien toch niet wat je zoekt. ]


Acties:
  • 0 Henk 'm!

Verwijderd

Bijzonder balen dat je host zijn bestaande servers gaat upgraden, meestal laat men de oude servers onaangeraakt en begint men met zulke grote upgrades met het installeren van nieuwe servers voor shared hosting ofwel krijg je de optie om zowel php4 als php5 te gebruiken op je pakketten.

Zo is het toch gegaan bij Combell, onze host, die sinds kort PHP5 hosting aanbiedt maar op hun volle / gebruikte servers php4 onaangeroerd laat. Als je zelf wil kan je pakket overgeplaatst worden naar een PHP 5 server, kostenloos. Goede service is geld waard hoor!

Mag ik vragen welke host je gebruikt?

Acties:
  • 0 Henk 'm!

  • GREENSKiN
  • Registratie: November 1999
  • Laatst online: 19-09 16:15
Wat wij doen... een PHP5 server er naast zetten en enkel nieuwe sites op die server plaatsen. Oude sites omzetten van PHP4 naar PHP5 op moment van grote toevoeging/wijziging aan de site. Deze moeten toch al onafhankelijk van de draaiende site ontwikkeld en getest worden, bovendien is er dan incentive voor de klant om budget vrij te maken.

Het blijft een pokke-klus :)

Acties:
  • 0 Henk 'm!

  • Kwastie
  • Registratie: April 2005
  • Laatst online: 19-09 10:42

Kwastie

Awesomeness

PHP4 was eind 2007 al bij mijn webhoster weg. heb ooit een klein tooltje geschreven die alle
$HTTP_SESSION_VARS omzette naar $_SESSION idem voor de cookie, global, post en get variable.
Meer deed hij niet, en had destijd ook geen zin om er echt meer tijd in te steken.

(mischien had je er eerder aan moeten beginnen? het was vanaf midden 2007 bekend dat eind 2007 de stekker uit PHP4 ging, hij word nog tot 8 augustus van dit jaar gesupport, voor grote beveilings lekken')

edit: Ik heb deze 'tool' niet meer.. (was zo'n 20 regels code ofzo, maar toch scheelde het wat werk :))

[ Voor 71% gewijzigd door Kwastie op 21-04-2008 22:30 ]

When I get sad i stop being sad and be awesome instead


Acties:
  • 0 Henk 'm!

  • Maestro
  • Registratie: Februari 2001
  • Laatst online: 17-09 22:18

Maestro

Verder met Jefferson vliegtuig

We hebben eind 2007 onze servers overgezet naar PHP5. We hebben van de op dat moment 181 PHP bevatttende websites welgeteld 1 probleem gehad. Dat was een incompatible IonCube extensie, wat met een herinstall door de developer was opgelost. Voor die tijd was PHP5 overigens al wel een jaar beschikbaar op die servers en de gebruikers/developers zijn ingelicht.

Ik zag er zelf enorm tegen op, maar het bleek flink mee te vallen. Wel hebben we een PHP4 server online gehouden om eventuele problemen snel te ondervangen. Ik heb toendertijd zelf ook naar een soortgelijk script gezocht, maar niets nuttigs gevonden.
Overigens heb ik zelf liever deze upgrade dan die van MySQL 4.0 naar 4.1 (die vervelender was als 4.1 naar 5.0)

Wire telegraph is a kind of a very, very long cat. You pull his tail in NYC and his head is meowing in LA. Do you understand this? And radio operates the same way: you send signals here, they receive them there. The only difference is there's no cat


Acties:
  • 0 Henk 'm!

  • spaceninja
  • Registratie: Juni 2007
  • Laatst online: 31-07 19:01
Het meest voorkomende probleem waar wij tegen aan liepen was $HTTP_POST_VARS, $HTTP_SESSION_VARS en $HTTP_GET_VARS die omgezet moesten worden.

Daarnaast was het een kwestie van op andere server zetten, via je host file alles even nalopen en 99% van de tijd geen problemen hebben.

Acties:
  • 0 Henk 'm!

  • Bosmonster
  • Registratie: Juni 2001
  • Laatst online: 18-09 16:28

Bosmonster

*zucht*

spaceninja schreef op maandag 21 april 2008 @ 22:48:
Het meest voorkomende probleem waar wij tegen aan liepen was $HTTP_POST_VARS, $HTTP_SESSION_VARS en $HTTP_GET_VARS die omgezet moesten worden.

Daarnaast was het een kwestie van op andere server zetten, via je host file alles even nalopen en 99% van de tijd geen problemen hebben.
Die had je zelfs in PHP4 niet meer horen te gebruiken, maar dat terzijde. Het voornaamste probleem dat ik tegen kwam met een aantal migraties was het verschil in gebruik van de date() functie in oudere code. Volgens mij was het zelfs ook maar een warning, dat je nu verplicht een timezone op moet geven. Maar dat was ook opgelost met een extra regel code toevoegen in de config met een timezone setting.

[ Voor 7% gewijzigd door Bosmonster op 21-04-2008 22:57 ]


Acties:
  • 0 Henk 'm!

  • geez
  • Registratie: Juni 2002
  • Laatst online: 18-09 21:41
Zelf ben ik maar één van de ontwikkelaars so to speak, ik had er persoonlijk ook eerder mee bezig gegaan aangezien het al enige tijd (begin Q4 2007 meen ik) bekend is. Ik had het er vandaag over met een projectmanager en we spraken af dat ik daar maar eens naar op zoek zou gaan.

Overigens verwacht ik ook weinig/geen problemen, althans met de projecten waar ik zelf aan gewerkt heb. Maar het zou toch fijn zijn om alles even langs te kunnen lopen voordat het definitief op php5 gaat :)

Acties:
  • 0 Henk 'm!

  • flowerp
  • Registratie: September 2003
  • Laatst online: 11-09 18:20
Niet voor het een of ander maar PHP 5 is van 2004. Zonder een flame war te willen starten, maar men zegt af en toe dat PHP zo'n snelle, lichte en dynamische taal is in tegenstelling tot het veronderstelde logge en bloated Java.

Waarom is men dan na bijna 4 jaar nog niet overgeschakeld naar een nieuwe versie? Als het allemaal zo licht en dynamisch is zou dat toch een peule-schilletje moeten zijn?

It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.


Acties:
  • 0 Henk 'm!

  • Gomez12
  • Registratie: Maart 2001
  • Laatst online: 17-10-2023
Simpele methode die wij ooit wel eens gehanteerd hebben is :
Hoster vragen om een php5 bak, copy websites op die php5 bak neerzetten, 100% errorlogging aan naar een errorlog, klanten/stagair vragen om het te gaan testen en meldingen te geven.
Meldingen verzamelen, errorlog ernaast. En dan maar eens gaan kijken hoe groot de schade is.

Zacht uitgedrukt niet echt de mooiste manier, maar hoster kwam 2 weken van te voren met de melding dat hij over ging naar php5 ( was toen nog een beta versie ).

en @flowerp : Misschien omdat je tegenwoordig 101 budgethosters hebt die liever lui dan moe zijn. Zonder enige kennis, en als je van php4 naar 5 gaat breken er toch een aantal dingen, dus krijg je hosters die liever niet het gezeur hebben en het zo lang mogelijk uitstellen.
Of je hebt een crm gekocht wat wel op php4 werkt en zonder support was het 3 tientjes goedkoper, dus als je hoster naar php5 wil overgaan ga jij opeens op je achterste benen staan en schreeuwen dat dit niet zomaar kan. Etc. etc.

Eigenlijk het gezeur wat je met alle updates hebt ( en tussen php4/5 breekt er redelijk wat als je depreciated dingen in php4 gebruikte )

In wezen hetzelfde probleem als java. Waarom heb ik nog een oude pc staan die geen java updates mag krijgen, niet omdat java zo log/bloated is, maar omdat ik gewoon switches heb die een webinterface hebben die alleen werkt met java vm 1.x, dat heeft niets met de taal an sich te maken, niets met de moeite van het updaten ( het niet updaten van die java kost me zo af en toe meer moeite vanwege plugindetections als ik een server webinterface op die pc ook open ), niets met log / bloated te maken.
Er zijn gewoon legacy programma's die niet/slecht onderhouden worden en breken.

Acties:
  • 0 Henk 'm!

  • Y0ur1
  • Registratie: Oktober 2000
  • Niet online
flowerp schreef op maandag 21 april 2008 @ 23:34:
Niet voor het een of ander maar PHP 5 is van 2004. Zonder een flame war te willen starten, maar men zegt af en toe dat PHP zo'n snelle, lichte en dynamische taal is in tegenstelling tot het veronderstelde logge en bloated Java.

Waarom is men dan na bijna 4 jaar nog niet overgeschakeld naar een nieuwe versie? Als het allemaal zo licht en dynamisch is zou dat toch een peule-schilletje moeten zijn?
Tja das wel een erg simplistische voorstelling van zaken, PHP5 code is gewoon niet helemaal backwards-compatible met PHP4, niet alle hosters willen dat 'risico' nemen. Daarom wordt er vaak bij nieuwe servers PHP5 geinstalleerd en worden de oude servers intact gelaten.

Je reactie heeft wel een ietswat flamerige grondtoon ;) PHP is inderdaad snel, licht en dynamisch, het heeft voor- nadelen maar kleine en middelgrote websites maak ik liever in PHP (met bij voorkeur een MVC framework als symfony) dan in Java(waar ik ook ervaring mee heb).

Acties:
  • 0 Henk 'm!

  • !null
  • Registratie: Maart 2008
  • Laatst online: 20-09 20:32
Er zullen uitzonderingen zijn, maar de meeste code voor PHP4 werkt ook gewoon in PHP5, weinig backwards compatibility problemen hoor. Zoals bosmonster al zei, had je die $HTTP arrays al niet meer moeten gebruiken, en nog een kleine moeite om over te zetten.
Dat zal straks met PHP6 erger worden, vooral voor de kwalitatief wat mindere scripts (register_globals anyone? :P, al is daar ook wat smerigs om heen te bouwen in 20 regels code)

[ Voor 27% gewijzigd door !null op 22-04-2008 10:15 ]

Ampera-e (60kWh) -> (66kWh)


Acties:
  • 0 Henk 'm!

  • Bosmonster
  • Registratie: Juni 2001
  • Laatst online: 18-09 16:28

Bosmonster

*zucht*

Y0ur1 schreef op dinsdag 22 april 2008 @ 00:25:
[...]

Tja das wel een erg simplistische voorstelling van zaken, PHP5 code is gewoon niet helemaal backwards-compatible met PHP4, niet alle hosters willen dat 'risico' nemen. Daarom wordt er vaak bij nieuwe servers PHP5 geinstalleerd en worden de oude servers intact gelaten.
Dat risico is uberhaupt niet aan de hoster om te nemen, maar aan de developer natuurlijk. Als ik een PHP4 hosting aanschaf verwacht ik niet dat de hoster er ineens PHP5 van gaat maken.

De keuze om een oudere applicatie die ontwikkeld is voor een major release te laten draaien op die major release is niet zo gek natuurlijk, dat doe je met bijna alle software volgens mij. Je gaat niet per definitie een goed lopende applicatie migreren alleen maar omdat er toevallig een nieuwe major release uit is van de taal.

[ Voor 7% gewijzigd door Bosmonster op 22-04-2008 10:23 ]


Acties:
  • 0 Henk 'm!

  • !null
  • Registratie: Maart 2008
  • Laatst online: 20-09 20:32
Ben ik met je eens, maar op een gegeven moment zul je toch over moeten. De vraag is dan of je er iedere keer op in moeten springen, op de nieuwe major release, of dat je 3 major releases later er een enorme klote klus aan hebt.

Ampera-e (60kWh) -> (66kWh)


Acties:
  • 0 Henk 'm!

  • Zyppora
  • Registratie: December 2005
  • Laatst online: 12-09 10:59

Zyppora

155/50 Warlock

flowerp schreef op maandag 21 april 2008 @ 23:34:
Niet voor het een of ander maar PHP 5 is van 2004. Zonder een flame war te willen starten, maar men zegt af en toe dat PHP zo'n snelle, lichte en dynamische taal is in tegenstelling tot het veronderstelde logge en bloated Java.

Waarom is men dan na bijna 4 jaar nog niet overgeschakeld naar een nieuwe versie? Als het allemaal zo licht en dynamisch is zou dat toch een peule-schilletje moeten zijn?
De reden dat PHP zo (relatief) snel, licht en dynamisch is, is omdat het interpreted is. Java is gecompileerd, maar draait op een VM, wat het zutje wat trager maakt. Als je echt snel/dynamisch/licht wil, moet je eens kijken naar Python of C.

PHP is niet zo backwards compatible als we zouden willen. Zoek even op 'register globals' of zo, en je vindt tal van klagende mensen wiens PHP website 'niet meer werkt'. Er zijn in de organisatie van PHP een aantal fouten gemaakt die rechtgezet moe(s)ten worden, en dit leidt tot compatibiliteitsproblemen.
Bosmonster schreef op dinsdag 22 april 2008 @ 10:21:
[...]


Dat risico is uberhaupt niet aan de hoster om te nemen, maar aan de developer natuurlijk. Als ik een PHP4 hosting aanschaf verwacht ik niet dat de hoster er ineens PHP5 van gaat maken.
Een hoster mag wel degelijk zeggen 'vanwege nieuwe features/betere beveiliging/ondersteuning/etc. gaan wij migreren van PHP4 naar PHP5'. Dit moet uiteraard wel ruim van tevoren aan de klanten doorgegeven worden, maar daar is niets geks aan.
Bosmonster schreef op dinsdag 22 april 2008 @ 10:21:
De keuze om een oudere applicatie die ontwikkeld is voor een major release te laten draaien op die major release is niet zo gek natuurlijk, dat doe je met bijna alle software volgens mij. Je gaat niet per definitie een goed lopende applicatie migreren alleen maar omdat er toevallig een nieuwe major release uit is van de taal.
Je kunt een applicatie wel toespitsen op een enkele release, maar je moet wel in de gaten houden waar een nieuwe major release voor is, niet alleen nieuwe functionaliteit, maar ook gaten dichten, dingen consistenter (en dus beter te onderhouden) maken, etc. Het is alleen maar goed dat toentertijd register_globals standaard uitgezet werd, ook al stuitte dat op veel boze devvertjes. Je applicatie zal dan ook aangepast moeten worden, maar daar wordt het dan wel beter op (in de meeste gevallen dan).

Phenom II X4 945 \\ 8GB DDR3 \\ Crosshair IV Formula \\ R9 290


Acties:
  • 0 Henk 'm!

  • !null
  • Registratie: Maart 2008
  • Laatst online: 20-09 20:32
Ja register_globals uit is idd een goeie zaak.
Maar in een taal zoals PHP moet je juist proberen het zo generiek mogelijk te houden, dat het versie onafhankelijk is. Dat is natuurlijk lastig als je in PHP3 begonnen bent, maar als je met PHP4 bent begonnen aan een applicatie was dat prima mogelijk.

Er zijn meer problemen wanneer je met MYSQL een versie update doet (van 4.0 naar 4.1.1, of van 4 naar 5). Overigens nog steeds te doen.

Ampera-e (60kWh) -> (66kWh)


Acties:
  • 0 Henk 'm!

  • mocean
  • Registratie: November 2000
  • Laatst online: 04-09 10:34
Neem gewoon een dedicated (virtual) server en installeer de exact gelijke config als waar je sites nu op draaien. Dat kost echt niet veel per maand, en je hoeft je nergens druk om te maken. Je kan dan als er updates komen rustig site voor site deze overzetten neer een PHP5 server en kijken of alles goed gaat.

Koop of verkoop je webshop: ecquisition.com


Acties:
  • 0 Henk 'm!

  • Bosmonster
  • Registratie: Juni 2001
  • Laatst online: 18-09 16:28

Bosmonster

*zucht*

Zyppora schreef op dinsdag 22 april 2008 @ 10:55:
[...]

Een hoster mag wel degelijk zeggen 'vanwege nieuwe features/betere beveiliging/ondersteuning/etc. gaan wij migreren van PHP4 naar PHP5'. Dit moet uiteraard wel ruim van tevoren aan de klanten doorgegeven worden, maar daar is niets geks aan.
Dat ben ik niet met je eens. Ik kies voor een hosting met een bepaalde major release. Dat heeft een reden. De hoster mag best aangeven dat bijvoorbeeld die server uitgefaseerd wordt of iets dergelijks, of dat ze je verplichten ivm veiligheidsrisico's een dedicated server te nemen met die oudere release, maar verplicht moeten upgraden naar een nieuwe major release is echt onzin.

Er zijn grote en dure applicaties waarbij het een klant heel veel geld kost om te upgraden. Het is niet de hoster die bepaalt of de klant die investering moet doen op dat moment en dat is dan in feite wel waar het op neer komt. Als een hostingpartij wel zo achterlijk zou zijn om dat te bepalen wordt het tijd voor een nieuwe partij. Eentje die meedenkt met zn klanten ipv een paar whizzkids die alleen aanzichzelf en aan versienummers denken.

[ Voor 9% gewijzigd door Bosmonster op 22-04-2008 14:17 ]


Acties:
  • 0 Henk 'm!

  • Zyppora
  • Registratie: December 2005
  • Laatst online: 12-09 10:59

Zyppora

155/50 Warlock

Bosmonster schreef op dinsdag 22 april 2008 @ 14:15:
[...]


Dat ben ik niet met je eens. Ik kies voor een hosting met een bepaalde major release. Dat heeft een reden. De hoster mag best aangeven dat bijvoorbeeld die server uitgefaseerd wordt of iets dergelijks, of dat ze je verplichten ivm veiligheidsrisico's een dedicated server te nemen met die oudere release, maar verplicht moeten upgraden naar een nieuwe major release is echt onzin.
Verplicht upgraden wil ik het niet noemen, en ik ben het met je eens dat een alternatief (dedicated hosting ofzo) aanwezig moet zijn, maar om het serverpark te beschermen mag een hosting provider best zeggen: volgende week knallen we PHP5 op onze servers, PHP4 zal tot en met [datum over X aantal maanden of zo] beschikbaar zijn, daarna is het over (en bij dit schrijven een tweede login voor uw PHP5 directory).
Bosmonster schreef op dinsdag 22 april 2008 @ 14:15:
Er zijn grote en dure applicaties waarbij het een klant heel veel geld kost om te upgraden. Het is niet de hoster die bepaalt of de klant die investering moet doen op dat moment en dat is dan in feite wel waar het op neer komt. Als een hostingpartij wel zo achterlijk zou zijn om dat te bepalen wordt het tijd voor een nieuwe partij. Eentje die meedenkt met zn klanten ipv een paar whizzkids die alleen aanzichzelf en aan versienummers denken.
Een gehackte website van de klant omdat de partij niet verder keek dan de klant zijn neus, da's pas lucratief :) Upgraden is meer dan alleen maar aan versienummers denken hoor, en ik hoop dat je met zo'n instelling niet in de IT wereld actief bent. Overigens vind ik een software pakket dat groot en duur is ook wel van updates/nieuwe versies voorzien mag worden die compatibel zijn met nieuwe releases van de programmeer/scripttaal, maar dat terzijde.

Phenom II X4 945 \\ 8GB DDR3 \\ Crosshair IV Formula \\ R9 290


Acties:
  • 0 Henk 'm!

  • Bosmonster
  • Registratie: Juni 2001
  • Laatst online: 18-09 16:28

Bosmonster

*zucht*

Ik zeg uiteraard niet dat je je major release niet van de laatste updates moet voorzien, dat lijkt me vanzelfsprekend.

Upgrade naar een nieuwe major is echter gewoon niet altijd een optie voor een klant. Daarom vind ik niet dat een hosting provider dat recht zomaar in eigen hand moet nemen, maar hier samen met de klant naar moet kijken.

[ Voor 48% gewijzigd door Bosmonster op 22-04-2008 15:06 ]


Acties:
  • 0 Henk 'm!

  • T_E_O
  • Registratie: Oktober 1999
  • Laatst online: 17-09 12:18
Wij hebben destijds voor onze klanten bij de upgrade naar PHP 5 een testomgeving ingericht met een kopie van alle bestanden en databases. De testomgeving was te benaderen door een andere (door ons opgezette) DNS-server in te stellen. Op die manier hebben klanten een ideale manier gehad om uitgebreid te testen en waren er bij de definitieve migratie geen vervelende verrassingen.

Acties:
  • 0 Henk 'm!

  • SH4D3H
  • Registratie: Juni 2004
  • Laatst online: 27-02 23:46
Bosmonster schreef op dinsdag 22 april 2008 @ 15:05:
Ik zeg uiteraard niet dat je je major release niet van de laatste updates moet voorzien, dat lijkt me vanzelfsprekend.
Maar wat als, zoals bij PHP4, de support voor die major release stopt?
Om de veiligheid van de websites van de klanten te kunnen blijven garanderen zul je dan wel over moeten naar de volgende major release òf je moet de oude release zelf verder ontwikkelen/patchen wat ook niet echt goedkoop zal zijn natuurlijk.

Acties:
  • 0 Henk 'm!

  • geez
  • Registratie: Juni 2002
  • Laatst online: 18-09 21:41
Persoonlijk vind ik het helemaal geen slechte zaak dat de hoster (Byte) naar PHP5 gaat, aangezien PHP4 zijn tijd nu wel heeft gehad. Security patches worden t/m 08-08-2008 doorgevoerd en dan is het echt voorbij. Bovendien ondersteunt Byte al jaren PHP5 en kan er geswitched worden tussen 4 en 5 middels een webinterface. Dus wat dat betreft prima geregeld.

Het plan is nu dan ook websites stuk voor stuk over te schakelen op PHP5, deze te testen en verder te gaan met de volgende. Mocht een website niet in één keer goed werken op PHP5 kan hij weer even op PHP4 gezet worden, aangepast worden en vervolgens over naar 5.

[ Voor 4% gewijzigd door geez op 22-04-2008 15:52 ]


Acties:
  • 0 Henk 'm!

  • dusti
  • Registratie: Oktober 2007
  • Laatst online: 08-12-2024
Ah, sommige hosters doen het nog anders, zoals die van mijn vriendin,
zij kreeg vandaag een mailtje binnen dat ze alle sites op nieuwe machines plaatsen, met php5.
Een tijdelijke link naar de nieuwe locatie met de melding dat je maar eens moet controleren of alles wel werkt... In de stelling dat wij het momenteel zeer druk hebben om dingen aan te passen zal het je maar overkomen...
Pagina: 1