mysql_connect() in php5.5

Door Jochem D op 10-02-2016 06:11

1.846 views

Ik zit met een php5.5 vraagje.. Op de server waar ik m'n websites host staat php5.4, maar deze wordt binnenkort geupgrade naar php5.5.
Nu zie ik dat vanaf phph5.5 de mysql_connect() functie niet meer wordt ondersteund en het probleem is dat ik bij al mijn websites van deze functie gebruik maak om verbinding te maken met de database.
Vanwege dit probleem heb ik de belangrijkste site verhuisd naar een server waar php5.3 ook wordt ondersteund. Maar als ik op deze server de site op php5.5 laat draaien, dan werkt deze nog steeds als een trein... Pas na het inschakelen van error_reporting(-1) zie ik enkele foutmeldingen, maar alles wordt nog steeds keurig naar de database geschreven en uitgelezen.

Hoe kan het dat dit toch werkt onder php5.5?

Ariën

10-02-2016 08:06 gewijzigd op 10-02-2016 08:07

Vanaf PHP 5.5 wordt dit alleen nog maar standaard bestempeld als 'binnenkort verwijderd'.

De tijdelijke oplossing is om E_DEPRECATED meldingen te verbergen, waarna je alles in de tussentijd ombouwt naar de Mysqli- of PDO-functies.

Jochem D

10-02-2016 19:54

Top! Ik zie dat ik tot php7 heb om de websites aan te passen.

Ben van Velzen

10-02-2016 19:59

Dat is dus vrij kort dag als je pech hebt, PHP 7 is al een tijdje uit.

Ariën

10-02-2016 20:14

Eind dit jaar minimaal:
http://php.net/supported-versions.php

Dan wordt PHP 5.6 niet meer actief ondersteund, en zullen de meeste hosting PHP7 standaard gaan ondersteunen.
Ik voorzie nu al een enorm feest, net als de introducering van de superglobals in 2002 ofzo.

Ben van Velzen

10-02-2016 20:16

Een beetje Y2K all over again inderdaad, zal erg leuk worden om te zien hoe dat zich ontwikkelt.

Thomas van den Heuvel

10-02-2016 21:11 gewijzigd op 10-02-2016 21:14

En als je slim bent schrijf je op zijn minst een wrapper.

De volgende keer dat er dan iets verandert in PHP-land (in de database-provincie) hoef je, met een beetje geluk, enkel de implementatie van de wrapper aan te passen in plaats van alle losse hardcoded instanties van een specifieke database-driver te moeten nalopen her en der verspreid door je broncode...

Zelfs als je tegenwerpt dat dit met een search/replace ook zo is gepiept is de (impact van de) hoeveelheid veranderde code in het eerste geval nog steeds stukken kleiner.

Een ezel stoot zich in het algemeen...

Reageren

Inloggen om te reageren