[php] Abändern alter PHP-Skripte auf neue PHP-Versionen

[Enrico Weigelt]

* Burkes <burkes at gmx.de> schrieb:

<snip>
> Ich bitte heute um Euere Mithilfe. Ich möchte, für mich und andere,
> eine kleine Anleitung für das Umschreiben und Anpassen alter
> PHP-Skripte auf neuere PHP-Versionen erstellen. 
Oh, da hast Du Dir was vorgenommen ;-)

<snip>
> a) Zu lösen sei dies durch die Verwendung von $_SERVER['PHP_SELF'],
> wobei $_Server als array alle Übergabewerte enthält, wobei die
> automatische Umwandlung durch register_globals on natrlich nebenher
> laufen kann. 
> 
> b) Seit 4.1 gibt es ferner auch $_REQUEST - ein assoziatives Array
> zusammengesetzt aus den GET, POST und Cookie Variablen; dürfte wohl
> nur für Fremdskripte interessant sein, die mit diesem Array arbeiten.
ACK. Das solltest Du IMHO immer nehmen.

<snip>
> Allerdings: in einem Diskussionsarchiv,  wo jemand mit $PHP_SELF
> nicht klarkam, fand ich die folgende, abschließende Nachricht: 
> 
> ##################
> Mein Provider-Support teilte mit: Verwenden Sie bitte PHP_REQUEST
> anstelle von PHP_SELF. Ist ein offizieller Bug der aktuelle PHP
> Version. 
> #################

Wieso spielt der Provider eine buggy-Version auf einen Produktionsserver auf ?

<snip>
> c) Verkomplizierend kommt hinzu, dass der  Zugriff über Array früher
> anders notiert wurde, nämlich über 
> 
>   $HTTP_SERVER_VARS['PHP_SELF'], 
> 
> und, was Übergabevariable betrifft: $_GET und $POST, genauer:
> 
>    $HTTP_GET_VARS (sofern per HTTP-GET-Methode übergeben wurde)
>    $_GET (offenbar Kurzform zu oben mit zusätzlichem Vorteil, dass
> sie automatisch global ist)
>    $HTTP_POST_VARS (sofern per  HTTP-POST-Methode übergeben wurde).
>    $_POST (Kurzform, automatisch global)

Okay, das kann man evtl. mit einem preload-Script beheben.

<snip>
> d) Und da gibts noch eine Variable Skript_Name, das offenbar es nur
> unter Apache gibt, und das auch so etwas wie PHP_Self zu sein scheint
> (ich hab's nicht getestet)
Also was unter $_SERVER liegt, ist SAPI-abhängig.

<snip>
> a) Angeblich haben viele PHP-Versionen einen BUG bei PHP_SELF; man
> müsse erst ein ? oder nochmehr Text anhängen, dann funktioniere es
> (ähnliches habe ich auch erlebt, hielt es aber nicht für einen Bug).
> Auf irgendeiner PHP-Seite fand ich dann folgenden Beitrag:
Das zu beheben ist der Provider zuständig.

<snip>
> Es handelt sich im Abschnitt "Error handling and logging" und die
> Zeile 
> 
>    "error_reporting  = E_ALL" 
Das kannst Du auch auf E_ALL & ~E_WARNING oder so setzen, dann sollte
das verschwinden (siehe manual).

<snip>
> Diese Meldungen zerschießen das Layout, auch wenn das Programm
> funktioniert. Es werden offenbar auch Nicht-Fehler (aber
> Schwachstellen) angezeigt. 
Das müßen nicht unbedingt Schwachstellen sein, vielmehr mögliche
Fehlerquellen. Als Entwicklungstool sind die Warnungen ganz gut
(so wie bei perl -w), aber auf einem Produktionssystem gehören sie
IMHO ausgeschaltet.

<snip>
> müssen. Mich interessiert in dem Zusammenhang nur, wie man speziell
> mit Übergabevariablen umgeht, wenn man sie das erste mal im Skript
> hat. z.B. wäre denkbar: $neu=""; $neu=$_Server['neu'] aber ich habe
> keine Ahnung, ob das einen Sinn hat.
Nein, so bringt Dir das nichts, denn die Warnung kommt ja durch den 
Zugriff $_server{'neu'} (wenn der Key nicht existiert) und nicht durch
die Zuweisung. Ergo dann schon:
    if (isset($_server{'neu'}) $neu = $_server{'neu'};
oder auch
    @$_server{'neu'}
vielleicht auch
    if (!isset($_server{'neu'}) $_server{'neu'} = '';
    

<snip>    
> 4. Ich habe seit einer Woche das PHP 4.3 installiert, basierend auf
> Xitami, und register_globals on gesetzt und Fehlermeldungen
> reduziert. Die meisten Skripte gehen jetzt, aber manche php-Variablen
> gehen trotzdem nicht. Wahrscheinlich habe ich sie fehlerhaft
> definiert und sie gingen nur zufällig, so habe ich die Variable stets
> kleingeschrieben, das ergab im Endeffekt einen leeren String, wenn
> man aber ein Fragezeichen und/oder weiteren Text anhing, dann klappte es . 
die Superglobals sollten IMHO immer groß geschrieben werden, deren 
Inhalte z.T. auch (z.b. in $_SERVER).

<snip>
> Ich habe jetzt als Erstmaßnahme folgendes gemacht, zu Beginn jedes
> Skripts: $self = $_SERVER['PHP_SELF'] und im Text habe ich alle
> $php_self durch $self ersetzt. Klappt. 
> 
> Aber jetzt gehts weiter - die Skripts sollen auch auf anderen Servern
> laufen, z.B. mit älteren PHP-Versionen (wo es noch kein $_SERVER gab)
> und/oder anderen Einstellungen. 
> 
> Was könnte man bezgl. PHP_SELF tun?
Am besten Du definierst dir eine sauberer Schnittstelle bzw. nimmst die
neuste (stabile!) und baust für die anderen PHP-Versionen Adapter,
die Du per preload reinholst.

<snip>
> Kann/Soll man eine der o.g. Ersetzungsformeln verwenden oder eine
> andere erarbeiten, soweit es um alte Skripte geht?
> Und was könnte man bezüglich der Übergabevariablen innerhalb des
> Skripts tun? 
Nein, alles nur schlechte Hacks, die einem in Zukunft nochmal auf die
Füße fallen werden.

> Annex: Was könnte man bezgl. PHP_SELF von vornherein tun, wenn man
> künftig pogrammiert?
Also wie ich das so sehe, ist es in der aktuellen API immernoch 
$_SERVER{'PHP_SELF'} - und so sollte es für die Zukunft auch bleiben.
Wenn den PHP-Leuten irgentwann mal einfällt, daß es auf einmal
doch nicht mehr so sein sollte, dann halt einfach den PHP-Code patchen
oder mittels preload script nachhelfen. 

Es gibt in der Softwareentwicklung nichts schlimmeres als inkonsistente
Schnittstellen. Hier macht das PHP-Coreteam sehr viel falsch und der
"große Feind" M$ sehr viel besser (obwohl ich nichts von deren ASP halte)

Ich denke wir sollten doch mal hinsetzen und einige scharfe Schnittstellen
definieren. Dort wird dann ganz klar definiert, welche Variablen wo 
existieren und welche extensions/routinen/symbole vorhanden sind.
Eine konkrete PHP-Umgebung erfüllt diese Schnittstelle entweder - dann
laufen die darauf basierenden Programme auch - oder eben nicht und der
Provider muß nachhelfen.

cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service

  phone:     +49 36207 519931         www:       http://www.metux.de/
  fax:       +49 36207 519932         email:     contact at metux.de
  cellphone: +49 174 7066481
---------------------------------------------------------------------
 -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops --
---------------------------------------------------------------------