Dobra dva tedna nazaj sem začel razmišljati, kako bi svojo spletno stran predelal v PHP kodo. Pa ne, da bi bilo z ColdFusion kaj narobe (no, mogoče je to, da je plačljiv), temveč me je gnala gola radovednost, kako izgleda programiranje spletnih rešitev v PHP.

Poleg tega je bil dodatni moment tudi to, da je PHP že vgrajen v OS X in zanj ni potrebno plačevat nobene licence. In da ne bi bil polovičen, sem se odločil, da tudi bazo zamenjam iz MS SQL Express 2005 v MySQL v5.1.

Kot že rečeno, na OS X je PHP že naložen, aktiviramo ga zgolj z odkomentiranjem vrstice v /private/etc/apache2/httpd.conf konfiguracijski datoteki Apache web serverja:

LoadModule php5_module libexec/apache2/libphp5.so

Še največ težav je bilo sPHPjem na Windowsih. Na Win2k3 serverju sem imel težave, če je bil PHP poinstaliran v Program Files. Na enih mašinah je delalo, na enih ni. Tako, da sem na koncu pristal z instalacijo PHPja na rootu C: diska. Čudno.

V konfiguraciji PHP.INI sem spremenil naslednje:

output_buffering = On # oz. 8192, odvisno od mašine
default_charset = "utf-8"
date.timezone = CET

No, seveda je med razvojno in produkcijsko mašino še nekaj razlik, ki pa niso bistvene.

Če sem hotel na Macu uporabljat bazo, sem imel dve možnosti: Oracle Express ali pa MySQL. Seveda izbira ni bila težka. Že pred časom sem se poigraval z MySQLom, ki pa takrat ni imel uporabnih grafičnih orodij za ad-hoc opravila. V verziji 5.1 je to čisto drugače! Poleg tega obstaja na Windows okolju tudi t.i. Migration utility, ki prenese podatke iz (skoraj) katerekoli druge podatkovne baze v MySQL. In dela skoraj popolno. Težave sem imel samo pri pretvarjanju tabel, ki vsebujejo DEFAULT vrednost. Ne vem zakaj, ampak v nekaterih primerih se orodje odloči in uporabi naslednjo sintakso:

imepolja INT NULL DEFAULT (0)

za katero pa se izkaže, da ne deluje. Pravilno je naslednje:

imepolja INT NULL DEFAULT 0

Ko je bilo to poštimano in sem prenesel podatke iz MsSQL Express 2005 serverja v MySQL, sem naletel na prvi resni problem.

Ko sem izpisoval tekstualne podatke, ki so vsebovali šumnike (ščž...), se Š in š nikakor nista hotela izpisovat. Namesto njiju je bil ? (vprašaj).

Malo Googlanja mi je dalo naslednjo rešitev:

SET NAMES 'utf8' COLLATE 'utf8_slovenian_ci';

To je prvi ukaz, ki ga iz PHPja pošljemo MySQLu, da pravilno interpretira UTF-8 kodirane znake v bazi. Čudno, ker vsa MySQL orodja niso kazala težav. Očitno je to povezano zgolj s PHP in MySQL.

Ko sem obšel te prve težave, je sledilo prekodiranje CFML v PHP. Zamudno in dolgočasno.

Lahko rečem, da večjih težav nisem imel. Še največ mi je sivih las naredila ReReplace iz CFMLja, ki v stringu zamenja substring z uporabo regular expression. Sintaksa, ki jo uporablja CFML je namreč drugačna od PHPjeve. Pa še v PHPju so se odločili, da starejšo opustijo in uporabljajo zgolj Perl kompatibilno v prihodnjih verzijah PHPja.

Za dostop do baze podatkov sem našel super knjižnico EZSQL Justina Vincenta, ki poenostavi dostop do baze do maksimuma. Za konekcijo uporabim zgolj:

require_once('inc/ezsql_core.php');
require_once('inc/ezsql_mysql.php');
$db = new ezSQL_mysql('user','pass','DB','host');

in nato za branje podatkov:

$recordset = $db->get_results('SQL query');

Za zdaj lahko rečem, da sem prezentacijski del aplikacije uspešno prekodiral v PHP ostane mi še servisni/administrativni del. Tam pa je kode krepko več in me čaka še precej neprespanih noči.

UPDATE: Kogar zanima lahko pogleda novonastalo stran na /~blaz na serverju. Deluje na PHP in MySQL, medtem, ko trenutna stran še vedno teče na CFML/MsSQL.