Bekijk Volledige Versie : Php 4 end of life message
V v Zuydewijn
03/10/07, 15:28
http://mtabini.blogspot.com/2007/08/now-showing-phps-true-colours.html
En? Wie is er nog niet klaar voor het einde van php4 dat er nu toch echt aan komt?
Ben benieuwd...
Wij zijn er al helemaal klaar voor. We bieden sinds iets meer dan een jaar al niet eens meer PHP4 aan.
Er draaien nog wat oude klanten op PHP4, maar nieuwe klanten nemen we er niet op aan.
In mijn optiek ben je ook wel erg traag als je nu, na 2.5 jaar dat PHP5 stable beschikbaar is, je er nog steeds niet klaar voor bent.
Draait hier goed, sinds een maand c.q. sinds de tijd dat ik een eigen bakkie heb :p
/me gaat in oktober helemaal over. Ons grote shared hosting platform is er al wel klaar voor, maar als default taal werd het niet eerder gewenst (optioneel was 't wel mogelijk). Nu moeten we, maar da's ook alleen maar goed.
Hier zijn we er helemaal klaar voor :D
We hebben hier nog 1 legacy machine ten behoeve van een aantal klanten, maar die moeten binnenkort ook echt over.
Ik heb nog een server met klanten die van php4 afhankelijk zijn en daar maak ik mij nog niet druk over. Redhat blijft php4 nog een paar jaar onderhouden (RHEL4) dus wat is het probleem?
De rest draait uiteraard al lang op php5....
Ramon Fincken
03/10/07, 21:30
Zat of zit eraan te komen.
Net als destijds met PHP3, vaak voor scripters/webdevelopers een goeie stok achter de deur om bepaalde coding nog eens goed door te nemen :)
AlfaHosting
03/10/07, 21:46
We hebben nog een paar servers op PHP4 omdat ze nog steeds vraag naar is, zelfs door nieuwe klanten.
Hoe zijn de ervaringen van het naast elkaar draaien van php4 en php5? Ik heb daar het een en ander over gelezen, en zo lijkt mij het uitfaseren voor de klanten een minder pijnlijke zaak. Ik wil ze niet opeens confronteren met falende scripts en websites die het niet meer doen omdat ik zo nodig wil upgraden. Naar php5 is nog nooit gevraagd door m'n klanten..!
Of is dit wellicht al ergens besproken en heb ik dat over het hoofd gezien?
Op de server waar ik dat op zou willen proberen c.q. testen staat DirectAdmin (DirectAdmin 1.31.0/Apache Apache 1.3.37/MySQL 4.1.21/CentOS 4.4). Ik las ergens dat DirectAdmin PHP5 nog niet ondersteunt, standaard, maar heb je daar last van c.q. gaat er iets mis (in DirectAdmin) dan als ik het toch probeer?
php4 en php5 als cgi draaien met suphp bijvoorbeeld , werkt perfect.
crazycoder
04/10/07, 10:28
Hoe zijn de ervaringen van het naast elkaar draaien van php4 en php5? Ik heb daar het een en ander over gelezen, en zo lijkt mij het uitfaseren voor de klanten een minder pijnlijke zaak. Ik wil ze niet opeens confronteren met falende scripts en websites die het niet meer doen omdat ik zo nodig wil upgraden. Naar php5 is nog nooit gevraagd door m'n klanten..!
Ik denk dat je ze de gelegenheid moet geven om hun spul uit te testen. Naast elkaar blijven draaien lijkt mij geen goed plan, anders blijft men het nog gewoon draaien..
Nog genoeg standaard scriptjes die nog steeds van register_globals afhankelijk zijn.. Terwijl het al zeker 4 jaar bekend is dat het standaard uit zal gaan worden gezet!
Wij zijn sinds deze maand bezig alle oudere servers welke nog zijn voorzien van PHP4 om te zetten naar PHP5, hiernaas zullen wij op deze server php4 in cgi mode laten draaien.
Na circa 4 a 6 maanden zal PHP4 compleet verdwenen zijn.
De klant heeft dan voldoende tijd gehad zijn/haar website aan te passen.
Nieuwe klanten krijgen automatisch PHP5. Er zijn nog enkele klanten die PHP4 nodig hebben voor (Slechte) scripts die niet goed willen werken onder PHP5. Helaas.
Wij zijn sinds deze maand bezig alle oudere servers welke nog zijn voorzien van PHP4 om te zetten naar PHP5, hiernaas zullen wij op deze server php4 in cgi mode laten draaien.
Na circa 4 a 6 maanden zal PHP4 compleet verdwenen zijn.
De klant heeft dan voldoende tijd gehad zijn/haar website aan te passen.Waarom nu nog PHP4 als CGI aanbieden?
Waarom ben je niet maanden terug al begonnen met PHP5 als primaire taal?
Moet eerlijk bekennen dat we op ons shared platform nog PHP4 draaien, maar over een week of 2 gaat ons cluster live en per die datum is bij ons ook PHP4 EOL.
Freakingme
04/10/07, 17:39
Ik denk dat je ze de gelegenheid moet geven om hun spul uit te testen. Naast elkaar blijven draaien lijkt mij geen goed plan, anders blijft men het nog gewoon draaien..
Als je het naast elkaar draait, kan de klant mooi testen enzo.
Dat de klant het 'gewoon blijft draaien' moet hij weten, op een gegeven moment stopt dat php4 toch. Het is m.i. dus gewoon de verantwoordelijkheid van de klant dat die toch op een gegeven moment z'n dingen migreert naar php5
Als je het naast elkaar draait, kan de klant mooi testen enzo.
Dat de klant het 'gewoon blijft draaien' moet hij weten, op een gegeven moment stopt dat php4 toch. Het is m.i. dus gewoon de verantwoordelijkheid van de klant dat die toch op een gegeven moment z'n dingen migreert naar php5
Maar zoals je in dat artikel wat in het begin gelinkt was ook kon lezen is het gevolg, als je het niet meer ondersteunt, dat mensen zeggen: "je hebt m'n website vernield, ik ga naar een ander". Want het is tóch altijd de schuld van de hoster, in de ogen van de gemiddelde klant.. Laat ze bij PHP toch eens fatsoenlijk downward compatible worden! En, nog een probleem is: wanneer je DirectAdmin installeert: deze is nog steeds niet standaard van php5 voorzien. Ik krijg binnenkort een nieuwe server online, en daar staat dan ook weer vrolijk de standaard DA installatie op mét php4..
Maar zoals je in dat artikel wat in het begin gelinkt was ook kon lezen is het gevolg, als je het niet meer ondersteunt, dat mensen zeggen: "je hebt m'n website vernield, ik ga naar een ander". Want het is tóch altijd de schuld van de hoster, in de ogen van de gemiddelde klant.. Laat ze bij PHP toch eens fatsoenlijk downward compatible worden! En, nog een probleem is: wanneer je DirectAdmin installeert: deze is nog steeds niet standaard van php5 voorzien. Ik krijg binnenkort een nieuwe server online, en daar staat dan ook weer vrolijk de standaard DA installatie op mét php4..
DA heeft tegenwoordig ook de custombuild optie, dan heb je standaard php 5 en apache 2 :) Hoewel dat hier nog geen 1x probleemloos heeft gewerkt, het is dan ook nog in beta.
Wij hebben net een volledige overstap naar PHP5 achter de rug, op zich viel het reuze mee.. alleen wat klanten die moeite hadden met het niet meer mogen includen van urls (allow_url_fopen) en OsCommerce is een RAMP op PHP5.. verder alles ok :)
Ik ga zelf binnekort ook bijna eigen servers opstraten. PHP 5 is natuurlijk nu al een must, maar er schijnt dus nog veel vraag te zijn naar PHP 4.
Ramon Fincken
05/10/07, 08:18
dan zou ik zeggen start direct met PHP5, scheelt je ook weer het overzetten en problemen die kunnen onstaan bij klanten :)
Maar zoals je in dat artikel wat in het begin gelinkt was ook kon lezen is het gevolg, als je het niet meer ondersteunt, dat mensen zeggen: "je hebt m'n website vernield, ik ga naar een ander". Want het is tóch altijd de schuld van de hoster, in de ogen van de gemiddelde klant.. Laat ze bij PHP toch eens fatsoenlijk downward compatible worden! En, nog een probleem is: wanneer je DirectAdmin installeert: deze is nog steeds niet standaard van php5 voorzien. Ik krijg binnenkort een nieuwe server online, en daar staat dan ook weer vrolijk de standaard DA installatie op mét php4..Je kan echter zonder problemen PHP5 compilen op een DA systeem, daar heb je custombuild niet voor nodig.
Ik compile PHP5 altijd gewoon vanuit de source tegenover Apache 2 (die wel met custombuild is gemaakt).
Net zoals MySQL5, dat gaat prima.
Nu nog nieuwe servers (of het afgelopen half jaar) met PHP4 opzetten is echt achterhaald.
Ik begrijp die ophef allemaal niet hoor, de meeste(99%?) scripts, draaien gewoon goed op php5, de meeste zaken die je tegenkomt is iets met config variables die je zelf kunt zetten zoals je wilt.
Wij hebben net een volledige overstap naar PHP5 achter de rug, op zich viel het reuze mee.. alleen wat klanten die moeite hadden met het niet meer mogen includen van urls (allow_url_fopen) en OsCommerce is een RAMP op PHP5.. verder alles ok :)
Goed om te weten, ik heb diverse klanten die OsCommerce gebruiken..
We hebben heleboel klanten die oscommerce op php5 draaien. Het vergt enkel aanpassingen in de code. Deze zijn te vinden op hun site. Daarnaast zijn ze bezig met nieuwere versie die enkel op php5 werkt.
Ik heb heleboel overzetting achter de rug van php4 naar 5. De meeste problemen waren van klanten die oude scripts (phpbb, joomla, mambo etc) draaiden.
Sinds ik aantal zaken goed heb beveiligd (register globals, magic quotes uit etc) zijn de scripts veel stukker beter geschreven.
Geen problemen met OSC hier op PHP5. Als je het goed wilt doen, draai je PHP in CGI met mod_suexec voor Apache en suphp voor PHP. Nadeel is dat het allemaal (wat) langzamer loopt dan de standaard Apache module en PHP in CLI. Wil je het laatste doen kan het ook, maak dan gewoon een cron aan zodat de bestandsrechten eens per 10 minuten goed gechownd worden naar de user, dit ivm de apache:apache uploads. Dit probleem is overigens ook bij PHP4.
Verder kent PHP5 een 'compatiblity mode' die je aan kunt zetten zodat het een en ander iets minder strict hoeft. De vrienden van Byte hebben een leuk stukje online: http://www.byte.nl/docs/Php-Vijf-Veranderingen.html
Uiteraard ga je NIET in een 'compatiblity mode' draaien, dat is dwijlen met de kraan open!
Wij hebben onze PHP aardig strikt staan:
expose_php = Off
display_errors = Off
register_globals = Off
register_argc_argv = Off
register_long_arrays = Off
magic_quotes_gpc = Off
enable_dl = Off
Dat dwingt je klanten echter wel om goede code te gebruiken.
We draaien zo al meer dan 20.000 hosting accounts op deze instellingen en dat gaat echt prima.
We horen bijna niemand waar zijn code niet werkt. En als het wel zo is, dan is het echt code uit het stenen tijdperk.
Je moet niet altijd maar alles blijven gedogen, want daar schiet jij en je klant uiteindelijk ook niets mee op.
Een beetje pushen vanaf jouw kant is niets mis mee.
Daarnaast echt geen mod_suexec pakken, want PHP in CGI is traag en je kan geen .htaccess gebruiken.
Voor Apache 2 hebben we mod_ruid, dat verlost je van al die problemen.
dreamhost_nl
06/10/07, 14:29
Daarnaast echt geen mod_suexec pakken, want PHP in CGI is traag en je kan geen .htaccess gebruiken.
Je bedoelt waarschijnlijk dat je geen php variabelen kunt declareren in een .htaccess bestand ? .htaccess bestanden op zich kunnen gewoon gebruikt worden in via phpsuexec gecompileerde Apache/PHP. Wil je php variabelen declareren, doe je dat gewoon via een eigen php.ini bestand in de directory waarvoor de wijziging dient te gelden.
Je bedoelt waarschijnlijk dat je geen php variabelen kunt declareren in een .htaccess bestand ? .htaccess bestanden op zich kunnen gewoon gebruikt worden in via phpsuexec gecompileerde Apache/PHP. Wil je php variabelen declareren, doe je dat gewoon via een eigen php.ini bestand in de directory waarvoor de wijziging dient te gelden.Klopt, dat bedoel ik. Even verkeerd verwoord.
Men een eigen php.ini geven is link, want dan kunnen ze ALLES veranderen, dat kan via .htaccess niet.
dreamhost_nl
06/10/07, 17:50
Men een eigen php.ini geven is link, want dan kunnen ze ALLES veranderen, dat kan via .htaccess niet.
Dat is zeker niet zo. Hier zijn uiteraard restricties aan verbonden. In .htaccess kun je even zoveel PHP variabelen neerzetten als in een eigen php.ini bestand. Het zal echter niet allemaal worden meegenomen...
Dat ben ik niet met je eens, want er zijn vars die niet in een .htaccess kunnen, die wel in een php.ini kunnen.
Maar ik kan het verkeerd hebben, leg uit! :)
SebastiaanStok
23/10/07, 20:45
Mensen die url-fopen-include nodig hebben horen niet op het web thuis...