PHP na sto a jeden způsob

3. prosince 2002

•

„Krátce po půlnoci se rozbouří telefon. Na druhé straně hlas zoufalého kolegy. Zůstal v práci déle, zavádí nový modul do intranetového systému. Vše se však hroutí, nefungují ani původní moduly. Začíná dlouhé pátrání po příčině, během kterého ve mně vzrůstá neblahé podezření. Modul je v pořádku, chyba je v odlišném interpretu PHP!“ Pokud i vás ničí podobné noční můry, tento článek vám snad nabídne řešení.

Problémem, který se v posledních měsících stále častěji diskutoval na mnoha domácích a především zahraničních serverech, je, samozřejmě, rychlý vývoj PHP. To se nyní dostalo do zvláštní mezifáze – už překonalo stádium „první opravdu použitelné verze“, tedy obvyklé verze 3, a ještě se nedostalo do stádia ustáleného prostředí s „postupným pokrokem v mezích zákona“. Naopak, verze 4 je pro PHP stádiem překotných změn, často velmi zásadních.

Současná situace ovšem způsobuje řadu problémů, které pramení především z velkého počtu různých verzí interpretů, které jsou na různých serverech provozovány. Pro vývojáře se tak ladění a zavádění každého programu stává pravým hororem, protože si prakticky nikdy nemůže být jist, zda budou jeho konstrukce pracovat nejen u něj, ale i na cílovém stroji, který bývá často zásadně odlišný, jak hardwarově, tak i softwarově.

Zdá se, že uvedený problém se neustále stupňuje a ještě nějakou dobu se stupňovat bude. Vzniká tak potřeba efektivního řešení, které by bylo snadno implementovatelné, transparentní a pokud možno co nejspolehlivější. Na některých specializovaných serverech se objevila řada úvah na toto téma, některé zcela nereálně navrhovaly pro každý vývojový projekt samostatný stroj s veškerým vybavením, jiné zas různé metody, jak na jeden server dostat více verzí interpretu PHP, popřípadě jak na jednom stroji provozovat několik serverů s různými verzemi PHP. Ani jedno však nebylo použitelné bez speciálních zásahů do skriptů nebo bez spolupráce s různými pomocnými programy.

Musím se přiznat, že mám rád jednoduchá univerzální řešení, čím univerzálnější, tím lépe. I já jsem řešil stejné problémy, v práci, mezi přáteli i v helpkonferencích. Nakonec jsem našel řešení, které mi přijde velmi efektivní a které se mi již osvědčilo v běžném provozu. Je založeno na schopnosti serveru Apache, což je nejčastější internetový server, na němž se PHP používá, předávat požadavky na zpracování skriptů externímu interpretu nejen v závislosti na druhu skriptu, ale i jeho lokaci.

Předpokládejme tedy, že používáme server Apache. Někde na disku máme také standardní interpret PHP, se kterým běžně pracujeme. Dále musíme nějak získat (stáhnout, překompilovat) interpret PHP s požadovanými odlišnými vlastnostmi, který pak uložíme také někam na disk, kde na něj může Apač „dosáhnout“. Pokud například máme v kořeni uložen adresář php, kde máme PHP verze 4.2.3, můžeme vytvořit adresář phpx, kam si uložíme vývojovou verzi 4.2.4-dev. Soubor httpd.conf, kde je uložena konfigurace Apače, pak doplníme o následující řádky (platforma Win98):

ScriptAlias /phpx/ „C:/phpx/“
<Directory „C:/phpx“>
    AllowOverride None
    Options None
    Order allow,deny
    Allow from all
</Directory>
Alias /phpmyadmin „C:/phpmyadmin/“
<Directory „C:/phpmyadmin“>
# nastavuji ovladač pro soubory s koncovkou .php
    AddHandler php-script .php
# požaduji volání externího interpretu
    Action php-script „/phpx/php.exe“
# aktivuji ovladač pro tento alias
    SetHandler php-script
    Options Indexes FollowSymlinks MultiViews
    AllowOverride None
    Order allow,deny
    Allow from all
</Directory>

V první části příkladu zavádím CGI interpret PHP, aby Apač věděl, kde jej má hledat. V druhé části nastavuji adresář, ve kterém leží můj oblíbený phpMyAdmin a zároveň nařizuji, aby požadavky na zpracování skriptů PHP z tohoto alias byly předány interpretu v adresáři phpx. Proč to celé dělám? Protože v PHP verze 4.2.3 je chyba ve zpracování určitého typu dat, s nimiž phpMyAdmin pracuje a které se takto elegantně vyhnu!

Jak vidíte, trik je velmi jednoduchý, využívá vlastně jen základy práce s aliasy. Úplně stejně jej lze použít ve spojení s virtualhostingem nebo různými metodami redirektu. Celé řešení mi zabralo jen pár hodin, nejvíce problémů jsem měl s pochopením dokumentace Apače a správného umístění handlerů, což mi nyní, když už znám správnou odpověď, připadá k smíchu. Popravdě řečeno, je to řešení tak jednoduché, až se mi nechce věřit, že jsem s ním přišel jako první, ale podle ohlasu v helpkonferencích se zdá, že Interval bude prvním serverem, který tuto metodu publikuje.

Samozřejmě, výše uvedené řešení má svá pro i proti. Nevýhodou je závislost na serveru Apache, implementaci obdobné metody jsem na jiných serverech nezkoušel (na IIS by snad šlo využít virtuálních serverů nebo něčeho podobného). Další nevýhodou je použití PHP jako CGI, z čehož plyne snížení výkonu a zvýšení zátěže serveru, oproti řešení s modulem PHP. Na druhou stranu se domnívám, že právě tato nevýhoda není například při vývoji a ladění aplikací zásadní. Výhody jsou zřejmé, všechny plynou z přítomnosti několika interpretů na jednom serveru. Lze tak například „upravit“ PHP podle individuálních potřeb zákazníků nebo přátel na komunitních serverech. Další je možnost testovat nové verze PHP bez nebezpečí „nabourání“ funkčního distribučního systému, nebo zajištění běhu nějaké aplikace, jejíž úprava by si vyžádala příliš velké náklady.

Věřím, že využití mnou uvedené metody vám může usnadnit život a že jistě najdete i jiné příležitosti k jejímu nasazení než ty, které jsem jmenoval. Tak či tak doufám, že jsem vám alespoň trochu pomohl, pokud ne přímo řešením vašeho problému, tak snad malou nápovědou, která vás k vašemu vlastnímu řešení dovede.