Onderwerp: Php 4 end of life message

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.

Oorspronkelijk geplaatst door crazycoder

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

Oorspronkelijk geplaatst door Freakingme

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

Oorspronkelijk geplaatst door brinkie

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.

dan zou ik zeggen start direct met PHP5, scheelt je ook weer het overzetten en problemen die kunnen onstaan bij klanten

Oorspronkelijk geplaatst door brinkie

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.

Oorspronkelijk geplaatst door X-Hosted

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:

Code:

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.

Oorspronkelijk geplaatst door Wido

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.

Oorspronkelijk geplaatst door dreamhost_nl

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.

Oorspronkelijk geplaatst door Wido

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