Fragen zum PHP Interpreter

Frage: Wie vergleicht sich PHP mit anderen bekannten Webentwicklungssystemen?

PHP ist ein Bytecode-Compiler, der das Script beim Aufruf compiliert. PHP kann als CGI-Programm oder als Bestandteil des Webservers ( mod_php ) ausgeführt werden. Als CGI-Programm ist es beliebig portabel, als Modul ist es für eine Reihe von populären APIs verfügbar. PHP unterstützt Datenbankzugriffe nicht nur über ODBC (oftmals Treiber von schlechter Performance und mit unvollständigen API-Implementierungen), sondern auch über die Native API einer ganzen Reihe von Datenbanken. Dazu LDAP, IMAP und eine Reihe anderer Datenbanken, außerdem HTTP, FTP-Protokolle (Intelligent Agent-Programmierung) und Direktzugriff auf Dbase und DB/DBM-Dateiformate. Dynamische Generierung von PNG-Bildern mit der libgd und der freetype library. Volltextindices und Suchmaschinen über externe Open Source Programme (MySQL Fulltext und andere). Gateways nach Java und COM existieren und werden mitgeliefert. Zahlreiche Spracherweiterungen vorhanden, der Quelltext des Interpreters liegt vor und ist Open Source. Die Syntax folgt der C, Java, Javascript, Perl-Familie von Sprachen. Ausgezeichnete Dokumentation und glänzender Support, wie bei Open Source üblich (Mailinglisten in Deutscher und Englischer Sprache). Sessionmanagement seit Version 4 eingebaut.

Cold Fusion ist eine Interpreter-Markup-Language. Es handelt sich um eine reine Interpretersprache mit der Option, Seitenquelltext auf der Serverseite durch "Codierung" zu verschleiern (das ausgegebene HTML muss selbstverständlich lesbar sein). Cold Fusion kann als Modul in Apache ausgeführt werden oder als CGI-Programm. Da es nicht Open Source ist, ist seine Verfügbarkeit über Plattformgrenzen beschränkt: Ursprünglich nur auf Windows verfügbar, ist Linux-Support mittlerweile für einige Distributionen vorhanden; Solaris wird ebenfalls unterstützt. Datenbankzugriff erfolgt über ODBC. LDAP, IMAP und einige andere Dinge werden unterstützt, andere Protokolle müssen ggf. über Dritthersteller oder Erweiterungen von Herstellerseite zugekauft werden. Intelligent Agents können erstellt werden. Keine Generierung von GIF-Bildern on-the-fly. CF kann Texte mit einer eigenen Engine (Verity) volltextindizieren und dann darauf zugreifen. Zahlreiche Spracherweiterungen vorhanden (Custom Tag Library beim Hersteller). Syntax: Tagschreibweise, um bei Anfängern den Eindruck einer Programmiersprache zu vermeiden. Neuere Versionen von Cold Fusion haben Java- und COM-Interfaces.

Microsoft ASP ist keine Scriptsprache, sondern ein Framework für die Einbindung einer solchen. Es stellt mehr eine API dar, die beliebige Scriptsprachen verwenden können, um Variablen über die Lebensdauer einer Seite hinaus persistent zu machen, um mit dem Webserver und anderen Scriptsprachen kommunizieren zu können und um andere, Microsoft-spezifische Eigenheiten ansprechen zu können. Mit MS-ASP werden zwei Scriptsprachen mitgeliefert (JavaScript und VisualBasic), aber es existieren weitere, von Microsoft unabhängige Sprachen (etwa Perl), die ebenfalls ASP verwenden. ASP ist fester Bestandteil des IIS auf NT bzw. Windows 2000/XP, es gibt aber auch andere Webserver (z.B. Sambar Server ), die ASP unterstützen. Da es sich beim IIS mit ASP um ein Microsoft-Produkt handelt, sind Supportoptionen, -preise und -Qualität sofort klar ( Hinweis: Seit Windows 2000 verlangt Microsoft eine zusätzliche Internet Connection License für den IIS, wenn dieser am Internet betrieben werden soll). Unterstützung anderer Plattformen ist kaum möglich, da ASP starken Gebrauch von den OLE/COM/DCOM-Fertigkeiten der MS-Plattform macht: Selbst nach der Portierung (etwa durch Chilisoft oder Software AG) steht man immer noch vor dem Problem, die entsprechenden OLE/COM/DCOM-Objekte auf der Nicht-Microsoft Plattform verfügbar zu machen. LDAP, IMAP und andere Dinge sind über den OLE/COM/DCOM-Mechanismus möglich, entsprechende Objekte sind eventuell von Drittanbietern zu kaufen.

mod_perl und embedPerl sind ein Mechanismus, mit denen man den Perl-Interpreter als Bestandteil des Apache-Webservers ausführen kann und mit dem man dann Perl-Programme mit HTML mischen kann. Programme werden proaktiv geladen und compiliert, sodass die typische Startup-Latenz von Perl-Programmen als CGI wegfällt. Der Speicherverbrauch ist beträchtlich, die Geschwindigkeiten von PHP und und mod_perl liegen in etwa gleichauf. Unterstützt wird der Apache Webserver auf allen Plattformen. mod_perl ist prinzipiell in der Lage, alle Perl-Module auf dem CPAN auszuführen, daher werden alle von Perl unterstützten Datenbanken (einschließlich ODBC und einer Menge nativer Interfaces) unterstützt, ebenso LDAP, IMAP, LibGD. Syntax folgt der von Perl... Negativ fällt hier vor allen Dingen der übermäßige Speicherverbrauch bei größeren Projekten auf und die auf Anfänger abschreckend wirkende Vielfalt von Sprachkonstrukten und Bibliotheken. Besondere Pluspunkte für erfahrene Programmierer sind die Ausdrucksstärke und Vielfalt der Sprache und ihrer Konstrukte und die wirklich umfassende Sammlung von Bibliotheken.

Apple Webobjects sind ein System, mit dem ein kleines, im Source vorliegendes Rumpf-C-CGI-Programm über einen remote procedure call mit einem als Coprozess laufenden Anwendungsprogramm kommuniziert. Das Anwendungsprogramm ist mit dem Webobjects Toolkit in Objective-C geschrieben und wird dann compiliert; es ist ein Maschinenprogramm. Kommunikation erfolgt durch das Datenbank-Kit von Apple über die Native API der unterstützten Datenbanken mit beliebigen Datenbanken. Apple bietet außerdem eine exzellente Entwicklungsumgebung mit GUI-Designer (ja, erzeugt auch HTML :-) ) und einem sehr schönen ER-Modeller und Debugger (gdb mit einem sexy Outfit). Webobjects skaliert sich ausgezeichnet durch das verwendete RPC-Schema (Apple Portable Distributed Objects auf einem beliebigen etablierten RPC-Mechanismus aufsetzend) und die Möglichkeit, den Application Server zu replizeren. Interessant ist die ungeschlagene Geschwindigkeit und die extrem gute Entwicklungsumgebung.

Frage: Wie vergleicht sich die Performance von PHP zu Perl?

PHP erzeugt wie Perl beim Start des Programms Bytecode und führt diesen dann aus. Dabei liegt PHP mit Perl geschwindigkeitsmäßig in etwa gleichauf. Ebenso wie Perl braucht auch PHP dafür eine größere Startup-Zeit, in der das Programm analysiert und übersetzt wird. Mit einem Bytecode-Cache kann man diese Zeit senken, indem man PHP Speicher zum Caching für Bytecode bereitstellt.

Der Zend-Optimizer und viele andere Bytecode-Caches optimieren den PHP-Bytecode noch einmal und holen je nach Anwendung Geschwindigkeitsgewinne heraus. Diese Gewinne können in Benchmarks signifikant sein - ihre praktische Bedeutung wird ebenfalls merkbar sein, aber sicherlich nicht so extrem wie in den Benchmarks. Die Anwendung des Optimizers würde die Startup-Zeiten des PHP-Interpreters noch weiter erhöhen, deswegen werden sie in der Regel mit einem Bytecode-Cache zusammen verwendet. Der Zend-Optimizer ist ein closed source Produkt, aber es existieren auch OSS-Alternativen.

Ein Bytecode-Cache kann häufig verwendeten Bytecode erkennen und im Interpreter im Speicher halten. Der Interpreter braucht diesen Bytecode dann nicht mehr zu laden, zu analysieren und zu übersetzen, sondern kann ihn direkt aufrufen. Durch den Bytecode-Cache erhöht sich der Speicherverbrauch des Interpreters und bei unzureichendem Speicherausbau der Maschine kann sich das negativ auf die Performance des Gesamtsystems auswirken.

Man sagt, dass PHP leichter zu erlernen sei als Perl und dass PHP-Code leichter zu lesen und damit billiger zu warten wäre als Perl-Code. Das ist sicherlich eine Frage der Übung - man kann in beiden Sprache nicht mehr wartbare Programme entwickeln bzw. in beiden Sprachen selbstdokumentierenden Code abliefern.

Frage: Wie kann ich mein ASP-Programm in PHP übersetzen?

Mit Hilfe des Konverters asp2php kann man große Teile seiner ASP-Anwendung zunächst einmal in PHP übersetzen lassen. In vielen Fällen sind kleinere Nacharbeiten oder wenigstens Nachkontrolle notwendig.

Frage: CGI PHP oder Modul?

Siehe auch Webserver verstehen und tunen von Kristian Köhntopp.

Jedes Mal, wenn eine Seite mit PHP-Code darauf ausgeführt werden muss, muss der PHP-Interpreter gestartet werden. Wird PHP als CGI-Programm installiert, bedeutet dies, dass am Anfang der Seite ein neuer Prozess erzeugt werden muss und der PHP-Interpreter in diesen Prozess geladen werden muss. Dies verbraucht eine ganze Menge Systemressourcen. Am Ende der Seite endet auch der Interpreterprozess und aller Speicher wird freigegeben. Ebenso werden alle Filehandles geschlossen und damit alle Datenbankverbindungen aufgegeben.

Installiert man PHP dagegen als Modul, etwa in einem Apache-Webserver, dann ist das PHP-Modul Bestandteil des Webservers und ständig geladen. Es kann außerdem Datenbanklinks über die Lebensdauer einer PHP-Seite hinaus offen halten, was speziell bei Oracle-Datenbanken große Performancevorteile bringt.

Nur mit einem CGI-PHP ist es möglich, PHP als Scriptsprache zur Erstellung von "Shellscripten" einzusetzen.

Viele Massen-Webhoster setzen bevorzugt CGI-PHP ein, weil es sich leichter auf eine Weise installieren lässt, die die Systemsicherheit nicht gefährdet. CGI-PHP erlaubt den Einsatz der Apache-Erweiterung suexec , die Erstellung einer chroot() -Umgebung und die bessere Kontrolle der durch den Anwender verbrauchten Systemressourcen.

Praktisch alle großen PHP-Sites setzen PHP als Modul ein, weil die Performance hier deutlich besser ist.

Frage: Portable PHP-Scripte

PHP ist weitgehend unabhängig von der verwendeten Systemplattform. Von den Funktionen microtime() und crypt() ist bekannt, dass sie sich beiden Betriebssystemen unterschiedlich verhalten.

Einige PHP-Module stehen nicht unter allen Systemplattformen zur Verfügung. So ist das Posix-Modul systembedingt nur unter Unix sinnvoll einsetzbar und das DCOM-Modul nur unter Windows verfügbar.

PHP unterscheidet in Funktionen nicht zwischen den verschiedenen Verzeichnistrennern / und \ . Man sollte jedoch beachten, dass ein Backslash in Strings als \\ geschrieben werden muss. Möchte man erfahren, wie der Verzeichnistrenner auf einem System heißt, kann man die vordefinierte Konstante DIRECTORY_SEPARATOR benutzen.

Frage: Zeitgesteuerte PHP-Scripte und Shellscripte

"echo" als PHP-Script "echo.php":

#! /usr/bin/php
<?php
  echo "argc = {$_SERVER['argc']}\n";
  foreach ($_SERVER['argv'] as $k => $v) {
    echo "_SERVER['argv'][$k] = $v\n";
  }
?> 

Dies setzt ein installiertes Binary von PHP in /usr/bin/php voraus. Seit PHP 4.3.0 wird PHP (ob Webserver-Modul oder CGI-Version) immer mit dem CLI (Command Line Interface) ausgeliefert (UNIX/Linux: ein Binary namens "php", Windows: "php.exe"). Dieses kann für Standalone-Applikationen benutzt werden. Zusätzlich bietet das CLI noch einige weitere interessante Optionen und Eigenschaften

Ein solches Script lässt sich über die Unix-Zeitsteuerung cron bzw. äquivalente Programme regelmäßig aufrufen.

Dem Script steht das Array $_SERVER['argv'][] zur Verfügung, welches die Kommandozeilenparameter des Aufrufs enthält. Dieses Array kann auf die übliche Weise aufgezählt werden. Die Anzahl der Elemente des Arrays kann man mit der Funktion count() bestimmen oder in der Variablen $_SERVER['argc'] nachschlagen.

Hat man nur mod_php zur Verfügung, kann man eine bestimmte URL des Webservers durch PHP regelmäßig zeitgesteuert abrufen lassen. Dazu sind Tools wie wget oder lynx hilfreich.

Frage: Wie bette ich PHP in HTML ein? (Beispielprogramm)

PHP-Code wird mit Hilfe von SGML Processing Instructions (PIs) in HTML eingebettet. Der Code steht zwischen <?php und ?> (empfohlene Schreibweise):

<?php
  phpinfo();
 ?> 

Alternativ kann auch ein Script-Tag für Server-Side Scripting verwendet werden:

<script language="php">
  phpinfo();
</script> 

Falls die Konfigurationsvariable short_open_tag gesetzt ist (nicht empfohlen!), kann man den Namen der Scriptsprache in den PIs weglassen:

<?
  phpinfo();
 ?> 

Dies erlaubt auch schnelle Ausgabe des Wertes von Ausdrücken.

<?= $_SERVER['PHP_SELF'] ?>
<!-- kann anstelle von -->
<? echo $_SERVER['PHP_SELF'] ?>
<!-- geschrieben werden. --> 

Falls die Konfigurationsvariable asp_tags gesetzt ist (nicht empfohlen!), kann man auch

<%
  phpinfo();
 %> 

a la Microsoft schreiben. Dies wird von vielen Editoren (Frontpage, Dreamweaver) besser verstanden.

Frage: Wie kann ich auf Umgebungsvariablen zugreifen?

Man kann Umgebungsvariablen über die PHP-Einbaufunktion getenv() eine solche Variable lesen und sie mit Hilfe der PHP-Einbaufunktion putenv() setzen. Dies ist die empfohlene Methode.

Alternativ sind Umgebungsvariablen sind innerhalb von PHP als Variablen im Array $_ENV verfügbar. Die Umgebungsvariable HOME steht also als Element im Array $_ENV["HOME"] zur Verfügung.

<?php
  function somefunc() {
    // Empfohlen
    echo getenv("HOME"). "<br />\n";

    // $_ENV ist superglobal und automatisch in
    // Funktionen verfügbar.
    echo $_ENV["HOME"]<br />\n";
  }

  somefunc();
 ?> 

Mit Hilfe der Funktion phpinfo() bekommt man unter anderem auch eine Übersicht über alle diese Variablen.

Frage: Wie kann ich auf den HTTP-Request-Header zugreifen?

Allen CGI-Programmen stehen zusätzliche Zeilen des HTTP-Request-Headers als Umgebungsvariablen zur Verfügung. Die Headerzeile bla-fasel: laber wird dabei zur Umgebungsvariablen $_ENV["HTTP_BLA_FASEL"] mit dem Wert laber .

Zusätzliche Angaben hinter der URL der Seite stehen in der Umgebungsvariablen $_ENV["PATH_INFO"] zur Verfügung. So wird im Request http://example.com/test.php/additional/info der Anteil /additional/info in dieser Variablen zu finden sein.

Zusätzliche Angaben in der Form von Query-Strings wie sie von Formularen mit der METHOD="get" erzeugt werden, stehen in der Variablen $_SERVER["QUERY_STRING"] zur Verfügung. Ist der Query-String korrekt formuliert, werden diese Parameter auch als Variablen im Array $_GET vorbelegt. So wird der Request http://example.com/test.php?a=b&c=d die Umgebungsvariable $_SERVER["QUERY_STRING"] mit dem Wert a=b&c=d belegen und außerdem die Variablen $_GET["a"] mit dem Wert b und die Variable $_GET["c"] mit dem Wert d vorbelegen.

Verwendet man PHP als Apache-Modul, so kann man außerdem noch über die spezielle Funktion getallheaders() auf diese Request-Header zugreifen. Ein solches Script ist jedoch nicht mit einem CGI-Interpreter ausführbar, daher sollte man diese Funktion im Namen der Portabilität vermeiden.

Frage: Gibt es noch mehr interessante Variablen im Environment?

Der CGI-Standard definiert eine Reihe von Variablen, die vorhanden sein müssen. Eine Übersicht bekommt man wie üblich mit phpinfo() Von besonderem Interesse sind

$_SERVER["HTTP_REFERER"]

Die URL der Seite, die auf diese Seite verwiesen hat.

$_SERVER["HTTP_USER_AGENT"]

Die Browserkennung des abrufenden Browsers.

$_SERVER["REMOTE_ADDR"]

Die IP-Nummer des abrufenden Rechners. Dies kann die momentane IP-Nummer des tatsächlichen Abrufers (oft dynamisch vergeben und variabel) oder die IP-Nummer des Proxy-Servers sein, den der Abrufer verwendet.

Frage: Wie kann ich auf Kommandozeilen-Argumente zugreifen?

Wenn PHP über die Shell als Skriptsprache benutzt wird, ist es oft nützlich, auf der Kommandozeile Parameter zu übergeben. In PHP stehen die Variablen $_SERVER["argc"] und $_SERVER["argv"] zur Verfügung.

$_SERVER["argc"]

Anzahl der auf der Kommandozeile übergebenen Argumente.

$_SERVER["argv"]

Array mit den übergebenen Argumenten und dem Dateinamen im ersten Element.

Wenn ein PHP-Skript über das Web aufgerufen wird, enthalten diese Variablen die über GET übergeben Argumente. Man kann dieses Verhalten in der php.ini -Datei abschalten ( register_argv_argc ).

Beispiel:

tobias@dev:~ > cat arg.php
#! /usr/bin/php -q
# Getestet mit Suse Linux 8.1 (register_globals = off)
<?php
  echo "argc = {$_SERVER['argc']}\n";
  foreach ($_SERVER['argv'] as $k => $v) {
    echo "_SERVER['argv'][$k] = $v\n";
  }
tobias@dev:~ > ./arg.php foo bar baz
argc = 4
_SERVER['argv'][0] = /var/tmp/x.php
_SERVER['argv'][1] = foo
_SERVER['argv'][2] = bar
_SERVER['argv'][3] = baz 

Komfortables Parsing der Argumente bietet das PEAR-Paket Console_Getopt .

Frage: Wie kann ich einen Parameter von einer PHP-Seite an eine andere weitergeben?

Man kann Parameter an ein PHP-Script als HTTP-GET- oder HTTP-POST-Parameter übergeben. Die Übergabe von Parametern als HTTP-POST ist in code-post erläutert.

Einen HTTP-GET-Request erzeugt man, indem man einfach ein Link auf das gewünschte Script erzeugt und die Parameter mit der Funktion urlencode() codiert anhängt.

<?php

 $para1 = "dies ist ein string";
 $para2 = 42;

 $pstring = sprintf("para1=%s&amp;para2=%s",
		urlencode($para1),
		urlencode($para2));
?>
<a href="php/php-faq/static/meinscript.php%3F%26lt%3B%3Fphp%20print%20%24pstring%20%3F%26gt%3B.html">go</a> 

Das empfangende Script wird diese Parameter ganz normal entgegennehmen, automatisch decodieren und als Variablen mit den Namen $_GET["para1"] und $_GET["para2"] bereitstellen.

Die Länge der durch einen GET-Request übergebaren Parameter ist begrenzt. Im einem GET- oder POST-Request übergebene Parameter sind durch den Anwender leicht manipulierbar. Wie in Webserver verstehen und tunen diskutiert, ist es wesentlich besser, Sessionvariablen zu verwenden, wie sie durch Sessionfunktionen von PHP4 realisiert sind - im Gegensatz zu dem hier gezeigten manipulierbaren Verfahren sind Sessions nämlich sicher.

Frage: Wie kann ich eine PHP-Präsentation auf CD brennen?

PHP ist zur Ausführung auf einen Webserver angewiesen. Es ist zwar möglich, eine PHP-Präsentation mittels eines Spiders durchzugehen und das generierte HTML abzuspeichern, aber die Interaktivität und die Datenbankverbindungen gehen so verloren. Eine solche Offline-Version einer Website lässt sich z.B. mit einem der folgenden Tools herstellen:

• HTTrack (Windows)

• WebZIP (Windows)

• Wget (Unix/Linux: wget --mirror -k -E http://www.example.com/ )

Alternativ kann man dem Kunden einen Webserver mitliefern, den dieser dann auf seinem Rechner installieren muss und der dann die PHP-Scripte ausführt. Der Kunde wird dann unter der URL http://localhost/ auf die Anwendung zugreifen können.

Von IndigoSTAR Software gibt es den Webserver MicroWeb , der direkt von CD-ROM unter Windows gestartet wird. Man kann einen beliebigen Hostnamen definieren und per HTTP auf die Daten zugreifen (z.B. http://microweb/ ). Standardmäßig bringt MicroWeb Perl- und SSI-Unterstützung mit, man kann aber auch PHP (als CGI) einbinden (siehe Dokumentation). Natürlich sind auf der CD keine Datenbank- und Dateioperationen möglich; für letztere besorgt man sich am besten via getenv("TEMP") das temporäre Verzeichnis des Rechners und arbeitet damit auf der Festplatte.

Frage: Werden meine PHP-Seiten von einer Suchmaschine indiziert?

Ein Webspider bekommt bei der üblichen Konfiguration von Webservern in keinster Weise mit, ob die angeforderte Default-Datei (Directory-Index) eines Verzeichnisses nun home.htm, index.php oder irgendwie anders heißt.

Er wird diese Datei lesen, und dann werden die HTML-Tags extrahiert, die für das Ranking aber noch eine Rolle spielen können (<h1>...</h1>). Aus dem reinen Text werden meistens noch die Stopwörter entfernt und restliche Textbrei fließt dann aufbereitet in den Index. Die Meta-Tags spielen bei intelligenteren Suchmaschinen für das Ranking keine Rolle mehr.

Jede Suchmaschine könnte grundsätzlich dynamisch generierte Seiten genauso erfassen, wie statische Seiten, weil der Spider/Robot der Suchmaschine genauso ein Client ist, wie Dein Browser und nicht mehr und nicht weniger sieht als Dein Browser: nämlich den HTML-Code und den Content-Type. Endungen der Dateinamen spielen bei korrekt programmierten Suchmaschinen keine Rolle - entscheidend sind im Web stattdessen die übermittelten Content-Types.

Viele Suchmaschinenbetreiber werden jedoch keine dynamisch generierten Seiten erfassen, weil sie davon ausgehen, dass sich deren Inhalt sehr oft ändert und eine Indizierung der Seiten somit sinnlos ist. Wird nun bei einem HTML-Dokument aufgrund der Extension, des Pfadnamens (enthält das Schlüsselwort cgi ) oder offensichtlich per GET übergebener Parameter eine dynamische Generierung vermutet, werden diese Dateien von einigen Spidern nicht indiziert, bzw. entsprechende Links nicht verfolgt. Dies ist zwar ebenfalls falsch - stattdessen sollte sich der Spider nur nach dem Inhalt der Datei robots.txt richten - aber viele Sites haben nur ungenügende oder ganz fehlende robots.txt-Dateien.

Lies auch den Artikel von Tobias Ratschiller in der Suchfibel zu diesem Thema.

Frage: Wie kann ein Besucher meiner Seite den PHP-Code im Browser sehen?

Wenn der Webserver ordnungsgemäß konfiguriert ist und er PHP unterstützt, bekommt der Besucher der Seite den PHP-Code nicht zu sehen, da er vom Webserver geparst wird und nur der generierte HTML-Code an den Browser geschickt wird.

Folgende Szenarien sind jedoch denkbar, bei denen der Besucher den PHP-Code trotzdem zu sehen bekommt:

• Auf dem Webserver ist kein PHP-Parser installiert. In diesem Fall behandelt der Webserver den PHP-Code wie "normalen" HTML-Code und schickt ihn unbearbeitet (ergo ungeparst) an den Browser.

• Aufgrund einer Fehlfunktion des Webserver ist der PHP-Parser ausgefallen oder der Webserver benutzt ihn nicht mehr: In diesem Fall sieht der User ebenfalls den ungeparsten Source-Code im Browserfenster, da kein Parsing mehr stattfindet.

• Ein "böser Junge" verschafft sich per FTP Zugriff auf die Daten: Auch hier hat der User die Möglichkeit, den Source-Code einzusehen, da der PHP-Parser nur Dateien parst, die über den Webserver abgefragt werden. Andere Schnittstellen wie zum Beispiel FTP berücksichtigt er nicht.

• Ein User verschafft sich Zugriff auf den Webserver mit Telnet oder SSH: Auch hier kann er den PHP-Code ohne weiteres einsehen, indem er zum Beispiel cat irgendwas.php eingibt und der Inhalt der Datei irgendwas.php auf dem Bildschirm ausgegeben wird.

Siehe auch: php-kompilieren

In jedem Fall ist es sinnvoll, Code mit Datenbankpassworten in einem Verzeichnis abzulegen, das nicht durch eine URL erreichbar ist oder das mit einer .htaccess-Datei gegen Zugriff gesichert ist. Dieser Code kann dann mit Hilfe von include() oder require() eingebunden werden. Siehe dazu auch den Abschnitt db-passwort dieser FAQ.

Frage: Wie kann ich die Ausgabe meines Scriptes in einen anderen Frame umlenken?

Wenn das Script bereits läuft, gar nicht.

Es gibt einen inoffiziellen Lösungsansatz seitens Netscape, mit dem es möglich ist, die Ausgabe eines laufenden Scriptes in einen anderen Frame umzulenken. Dies ist jedoch nicht portabel: PHP läuft auf dem Server und weiß zunächst einmal nichts von den Frames eines Clients.

Es jedoch möglich, sich mit JavaScript eine Brückenseite zu schreiben (vom laufendem Script schreiben zu lassen), die mit Hilfe von onLoad() erneut eine PHP-Seite vom Server für einen anderen Frame anfordert ( top.anderesFrame.location.href="php/php-faq/static/seite1.php.html"; self.location.href="php/php-faq/static/seite2.php.html" ).

Von diesem Verfahren wird hier deutlich abgeraten, da viele User (bei manchen Firmen gehört das auch zu der Firmenpolicy) JavaScript aus Sicherheitsgründen abschalten. Dann bleibt der Bildschirm u.U. leer und der Besucher verwirrt. Wiederkommen wird er bestimmt nicht mehr.

Vor der Ausführung des Scriptes, ist es selbstverständlich möglich mittels <A href="php/php-faq/static/seite1.php.html" TARGET="andererFrame"> das Script in einem anderem Frame (bzw. mit javascript:window.open() geöffneten Fenster) ausführen zu lassen.

Frage: Wie kann ich mit PHP die Bildschirmauflösung des Browsers herausfinden?

Das geht im allgemeinen Fall nicht. PHP wird auf dem Server ausgeführt, nicht im Browser des Zielsystems.

Falls der Browser des Zielsystems JavaScript kann, falls dieser Browser JavaScript nicht disabled hat, falls die Firewall auf dem Weg zum Zielsystem nicht JavaScript ausfiltert und falls man an geeigneter Stelle ein Formular statt eines Links verwendet, dann kannst man in diesem Formular die Auflösung des Zielsystem durch JavaScript ermitteln lassen und an seine Site zurücksenden lassen. Mit den übrigen Fällen (Auflösung des Zielsystems nicht bekannt) muss man dennoch fertig werden.

Die Tatsache, dass die Bildschirmauflösung des Zielsystems bekannt ist, hilft natürlich nicht beim Design, solange man nicht auch weiß

• wie groß die verwendete Schrift ist,

• ob die verwendeten Zeichensätze auf dem Zielsystem zur Verfügung stehen,

• wie groß die Fenster auf dem Zielsystem zur Zeit gerade sind.

Man kann aus diesen Gründen davon ausgehen, dass eine auflösungsabhängige Darstellung auch dann auf mehr als der Hälfte der Zielsysteme nicht korrekt gerendert werden kann, auch wenn die Bildschirmauflösung des Zielsystems bekannt ist.