PeHa ICT

Nu PHP 5.4 dan officieel gereleased is eergisteren, ben ik meteen maar overgegaan op het updaten van deze server, waarop onder andere dit blog draait, maar ook webmail en een aantal andere sites. Wetend dat een aantal van de sites zijn roots nog heeft in de tijd dat Register Globals nog aan stond, is het steeds weer spannend bij een grote upgrade of alles een beetje blijft werken.

Om te beginnen heb ik eerst de stap PHP 5.3.8 naar 5.3.10 gemaakt.

Het voordeel dat ik hierin zag: testen van de upgrade procedure, zonder al te grote stappen te maken, en om het hele configure commando met al zijn opties even te controleren. na

configure --met-opties --en-nog-meer-opties make make install 

en een restart van Apache draaide alles weer als vanouds.

Daarna heb ik ik een aanpassing gedaan in de lijst met opties: in heb aangegeven dan de file php.ini voortaan gezocht moet gaan worden in /etc/php54/, waar dat voor PHP 5.3 in /etc/php53/ was. Op die manier kan elke php-versie dus zijn eigen ini file hebben, voor het geval daar lastige verschillen in zouden voorkomen. De rest van de opties heb ik gelijk gehouden. (ik heb bij installaties op nieuwe kale server altijd problemen met "library X is niet beschikbaar" en "cannot find file xyz.h", zodat dan steeds weer pakketjes bij geïnstalleerd moeten worden.)

Dat gaf verbazingwekkend weinig problemen. Alleen aan het eind van het configure commando kwam nog een lijstje te voorschijn met options die kennelijk uit een hele oude php versie stamden. Op zich geen probleem: ze worden genegeerd, maar ik heb ze wel verwijderd. Daarna begon het testen van websites.

De recentste sites en backends zijn geschreven op een server die al op PHP 5.3 draaide. Daar waren geen problemen te verwachten en zijn ook niet gevonden.

Webmail van Roundcube versie 0.6 gaf problemen met errors mbt PEAR error functies: die werden als static aangeroepen, terwijl dat niet de bedoeling was. Kennelijk is de error-reporting op dat punt een stuk stricter geworden. Gelukkig was er een update naar versie 0.7 mogelijk, maar het upgrade script heeft last van dezelfde foutmelding. Handmatige upgrade was ook mogelijk. Toch bleef deze fout optreden. Ik heb dat als snelle fix maar opgelost door op de betreffende regels een @ voor PEAR::setErrorHandling(PEAR_ERROR_CALLBACK, 'rcube_pear_error'); Was waarschijnlijk ook te regelen geweest met het aanpassen naar het error-reporting niveau, zodat dergelijke meldingen niet naar voren komen, maar ik wil alle meldingen wel eerst zelf graag zien.

Ik moet wel opmerken dat ikzelf zo ongeveer de enige gebruiker ben van deze webmail site en dat foutmeldingen dus niet zo ernstig zijn als op een webmail pagina die door onbekenden wordt gebruikt. Ook de software waar dit blog op draait, gaf foutmeldingen. Veel foutmeldingen en warnings. De pagina was vrijwel onleesbaar. Een melding die hier nogal eens voorkwam en die ook in een enkele jaren oude webshop (http://auslandsblumen.de) opdook: in een class die een method van een parent wil overrulen, moet de definitie van die method wel gelijk zijn:

<?php 
class MyParent 
{
    public function foo()
    {     
    }
}  

class MyClass extends MyParent
{
    public function foo($bar)
    {
    }
} 

?>

De aanwezigheid van $bar als parameter van de method foo() in MyClass levert een warning op, omdat deze parameter niet in de parent aanwezig is. Op zich logisch, maar de fout zit kennelijk op nogal wat plaatsen verstopt.

Zoals ik het nu zie, draait de voorkant van alle site goed. Of elke uithoek van de backends probleemloos draait, is even af te wachten. Veel van de sites draaien maanden zonder tussenkomst van een beheerder