PHP Seiten Inhalt wird im Browser geparst
0 0 
Felix Riesterer
0 0 0 Felix Riesterer
PHP Seiten Inhalt wird im Browser geparst
Hi Leute,
ich habe mich jetzt stundenlang durchs Netz gequält, aber nichts gefunden was mir annährend helfen würde.
Und zwar habe ich folgendes Problem:
Ich habe auf meinem Notebook Suse10.3 installiert, mit Apache 2 und PHP5.
Wenn ich nun über einen zuvor Konfigurierten vhost eine PHP Seite aufrufe, passieren bei 2 verschiednen Projekten 2 verschiedene Dinge :)
Nummer 1:
Die Seite bleibt weiß. Lässt man sich den Quellcode anzeigen, sieht man den PHP Code einer Configdatei, die in der ersten Zeile nach <?php vom aufgerufenen Script included wird.
Nummer2:
Auf der Seite erscheint der komplette (unformatierte) Quellcode der PHP Datei, einfach schön aneinander gereiht.
Der einzige unterschied ist neben dem Inhalt wohl, dass vor dem ersten include ein session_start zu finden ist.
Auf die üblichen Probleme habe ich schon geprüft. Das PHP5 Modul im Server ist geladen. Die Tipps unter folgendem Link habe ich berücksichtigt:
http://aktuell.de.selfhtml.org/artikel/server/apacheconf/apconf15.htm#a4
Was weiterhin mehr als komisch ist: Ich habe zusätlich auch einen PHPMyAdmin auf dem Server laufen. Diesen kann ich problemlos aufrufen. Hier scheint der Interpreter einwandfrei zu arbeiten.
Auch wenn ich in der shell via: "php5 test.php" ein Testscript aufrufe, klappt das.
Nun bin ich wirklich ein wenig ratlos.
Das einzige was mich fröhlich stimmt: Genau das gleiche Problem hatte ich beim letzten mal auch :) Ich weiß aber nicht mehr wie ich es gelöst habe. Ich bin mir nur noch sicher, das es keine 10 min gedauert hat.
Ich wäre echt froh um Hilfe, denn ich komme hier nichtmal mit Google weiter.
Viele Grüße,
Alex
-
Ok, dummheit wird bestraft.
Ein Blick in die php.ini - die Option
short_open_tags = On
gesetzt und nun klappts.Jaja ich weiß, schlamperei im Code :)
-
Liebe(r) aknyn,
Ok, dummheit wird bestraft.
das ist wohl wahr!
Ein Blick in die php.ini - die Option
short_open_tags = On
gesetzt und nun klappts.BÖSE!!! Mach das rückgängig! Du wolltest doch keine
schlamperei im Code
oder etwa doch?!?
Liebe Grüße aus Ellwangen,
Felix Riesterer.
--
ie:% br:> fl:| va:) ls:[ fo:) rl:° n4:? de:> ss:| ch:? js:) mo:} zu:)-
Ich möchte aber auch ungern knappe 9000 PHP Dateien, die zum großteil nicht von mir erzeugt wurden, manuell abändern, also sind wir jetzt mal so böse und lassen es stehen
-
Moin
Ich möchte aber auch ungern knappe 9000 PHP Dateien, die zum großteil nicht von mir erzeugt wurden, manuell abändern, also sind wir jetzt mal so böse und lassen es stehen
Da wünsche ich dir viel Spaß, wenn in einer folgenden PHP-Versiion diese Option standardmäßig auf "OFF" gesetzt wird und dann ähnliches passiert wie damals als register-globals "OFF" gesetzt wurde.
Man sollte doch nie den Weg des geringsten Widerstandes nehmen, sondern sich auch mal die Mühe machen es von vornherein richtig zu gestalten!
Gruß Bobby
--
-> Für jedes Problem gibt es eine Lösung, die einfach, sauber und falsch ist! <-
-> Nicht das Problem macht die Schwierigkeiten, sondern unsere Sichtweise! <-
ie:{ br:> fl:{ va:} ls:< fo:) rl:( n4:( de:> ss:) ch:? js:( mo:} sh:) zu:)-
Hi,
Da wünsche ich dir viel Spaß, wenn in einer folgenden PHP-Versiion diese Option standardmäßig auf "OFF" gesetzt wird und dann ähnliches passiert wie damals als register-globals "OFF" gesetzt wurde.
sogar noch Schlimmeres: die PHP-Scripts könnten auch sensible Daten enthalten, die dann für jedermann einsehbar sind.
freundliche Grüße
Ingo-
Moin!
sogar noch Schlimmeres: die PHP-Scripts könnten auch sensible Daten enthalten, die dann für jedermann einsehbar sind.
Dann gehört aber dem Programmierer endgültig der Arsch versohlt:
(1) Alles, was Daten enthält, gehört ausgelagert. (Grundsatz der Trennung von Daten und Programm.) parse_ini_file(), include, include_once, require, require_once sind hier die anzuwendenden Werkzeuge.
(2) Alle Daten/Dateien, die nicht über den Webserver abrufbar sein sollen, gehören grundsätzlich nicht in ein Verzeichnis unterhalb von DOCUMENT_ROOT.
(2a) Ist (2) nicht realisierbar (Einschränkung des Hosters) sind alle Dateien, die nicht über den Webserver abrufbar sein sollen in ein Verzeichnis zu schaufeln, welches gesperrt ist. (Für Apache: .htaccess mit "deny from all").
(2b) Zusätzlich zu (2) oder (2a) ist es ratsam auf einem Apache-Webserver die Dateinamen von Dateien, die nicht über den Webserver abrufbar sein sollen, mit '.ht' beginnen zu lassen, weil der Webserver auch dann das Listen (über den Autoindex) und die Auslieferung verweigert.MFFG (Mit freundlich- friedfertigem Grinsen)
fastix®
--
Als Freiberufler bin ich immer auf der Suche nach Aufträgen: Schulungen, Seminare, Training, Development
-
-
-
Liebe(r) aknyn,
Ich möchte aber auch ungern knappe 9000 PHP Dateien, die zum großteil nicht von mir erzeugt wurden, manuell abändern,
verständlich. Das sehe ich ein.
also sind wir jetzt mal so böse und lassen es stehen
Das sehe ich nun absolut _nicht_ ein. Du hast PHP... was man damit nur alles machen kann... z.B. ein Script schreiben, das sämtliche Deiner PHP-Dateien "repariert"...
Vielleicht bist Du nicht "jetzt mal so böse" sondern eher "jetzt mal so denkfaul"?
Liebe Grüße aus Ellwangen,
Felix Riesterer.
--
ie:% br:> fl:| va:) ls:[ fo:) rl:° n4:? de:> ss:| ch:? js:) mo:} zu:)-
Ciao!
Das sehe ich nun absolut _nicht_ ein. Du hast PHP... was man damit nur alles machen kann... z.B. ein Script schreiben, das sämtliche Deiner PHP-Dateien "repariert"...
Reicht hier nicht schon ein simples Suchen & Ersetzen über alle Dateien? Das können die meisten Texteditoren.
Einfach "<? " durch "<?php " ersetzen. Okay, für die Ausgabedinger "<?= $foo ?>" braucht man wohl einen regulären Ausdruck, um <?php echo($foo); ?>" draus zu machen, aber ein Problem sollte das auch nicht sein.Viele Grüße vom Længlich
-
echo $begrüßung;
Reicht hier nicht schon ein simples Suchen & Ersetzen über alle Dateien? Das können die meisten Texteditoren.
Einfach "<? " durch "<?php " ersetzen.Das geht nicht in jedem Kontext gut. Beispiel: echo '<?xml ...';
Okay, für die Ausgabedinger "<?= $foo ?>" braucht man wohl einen regulären Ausdruck, um <?php echo($foo); ?>" draus zu machen, aber ein Problem sollte das auch nicht sein.
Vor einem ?> wird kein Semikolon benötigt, und echo ist keine Funktion. Das Klammernsetzen macht hier aus der einfachen Variablen $foo einen Ausdruck. Es reicht also schon <?= gegen <?php echo_ zu tauschen. (Das _ stellt ein Leerzeichen dar)
echo "$verabschiedung $name";
-
Konnichiwa!
Reicht hier nicht schon ein simples Suchen & Ersetzen über alle Dateien? Das können die meisten Texteditoren.
Einfach "<? " durch "<?php " ersetzen.Das geht nicht in jedem Kontext gut. Beispiel: echo '<?xml ...';
Die zu ersetzende Folge zwischen den " ist Kleiner-Fragezeichen-Leerzeichen, "<?xml" wird also nicht ersetzt, und "<?php" wird auch nicht zu "<?phpphp". ;-)
Da die Zeichenfolge in Strings extrem selten vorkommen dürfte, kann man die Stellen, an denen das passieren kann, wahrscheinlich abschätzen und ggf. manuell korrigieren.Okay, für die Ausgabedinger "<?= $foo ?>" braucht man wohl einen regulären Ausdruck, um <?php echo($foo); ?>" draus zu machen, aber ein Problem sollte das auch nicht sein.
Vor einem ?> wird kein Semikolon benötigt, und echo ist keine Funktion. Das Klammernsetzen macht hier aus der einfachen Variablen $foo einen Ausdruck. Es reicht also schon <?= gegen <?php echo_ zu tauschen. (Das _ stellt ein Leerzeichen dar)
Daß man die Klammern nicht braucht, wußte ich, aber ich finde den Code so übersichtlicher, zumindest, wenn an der Stelle wirklich ein Ausdruck folgt und nicht nur eine Variable. Das mit dem Semikolon ist mir neu, danke! Dann reicht wirklich einfaches Suchen & Ersetzen.
Viele Grüße vom Længlich
-
echo $begrüßung;
Die zu ersetzende Folge zwischen den " ist Kleiner-Fragezeichen-Leerzeichen,
Dann ist alles eindeutig, und ich ziehe meinen Einwurf zurück.
Daß man die Klammern nicht braucht, wußte ich, aber ich finde den Code so übersichtlicher, zumindest, wenn an der Stelle wirklich ein Ausdruck folgt und nicht nur eine Variable.
Das finde ich nicht. Jeder Code-Bestandteil sollte einen Sinn haben. Wenn dort Klammern nur zur Zierde stehen, dann überlegt ich immer - und in dem Fall umsonst -, welchen Grund sie haben, dort zu stehen. Wenn sie dann auch noch manchmal aus technischen Gründen wegbleiben, dann verwirrt diese Inkonsequenz sicher mehr, als sie toll aussieht. Wie du vielleicht weißt (oder auch nicht), ist es schon ein Unterschied, ob da return $var; oder return ($var); notiert steht, besonders wenn der Wert per Referenz zurückgegeben werden soll (explizit notiert, oder bei Objekten ab PHP5 immer).
Das mit dem Semikolon ist mir neu, danke!
Vielleicht auch für dich neu: Wenn das ?> als Letztes in der Datei steht und auch kein HTML mehr folgt, kann man es komplett weglassen. Dann können sich auch keine Whitespacezeichen dahinter einschmuggeln.
echo "$verabschiedung $name";
-
Privit!
Das finde ich nicht.
Hehe, über Code-Konventionen könnte man immer ewig diskutieren. ;-) Und hin und wieder muß man sich ja auch einem vorhandenen Team anpassen, selbst wenn man bei einer bestimmten Konvention Brechreiz verspürt.
Wenn sie dann auch noch manchmal aus technischen Gründen wegbleiben, dann verwirrt diese Inkonsequenz sicher mehr, als sie toll aussieht.
Das auf jeden Fall, ja.
Vielleicht auch für dich neu: Wenn das ?> als Letztes in der Datei steht und auch kein HTML mehr folgt, kann man es komplett weglassen. Dann können sich auch keine Whitespacezeichen dahinter einschmuggeln.
Solche Extrawürste, die nur an bestimmten Stellen möglich sind, mag ich nun beispielsweise wieder nicht. ;-) Wegen des EVA-Prinzips enden die meisten meiner PHP-Dateien ohnehin mit HTML, da geht das also nicht. Höchstens in den includes, und in denen sehe ich nicht wirklich die Notwendigkeit, diesen beiden Bytes einzusparen.
Viele Grüße vom Længlich
-
echo $begrüßung;
Hehe, über Code-Konventionen könnte man immer ewig diskutieren. ;-) Und hin und wieder muß man sich ja auch einem vorhandenen Team anpassen, selbst wenn man bei einer bestimmten Konvention Brechreiz verspürt.
Es geht ja bei den () nicht darum, wo ein bestimmtes obligatorisches Zeichen hingesetzt wird (oder ob man auch einzeilige Anweisungen als Blöcke notiert), sondern darum, dass sie hier einen Einfluss auf das Ergebnis haben und manchmal schlicht falsch sind. Gegen solche Fehler in der Konvention sollte man schon aufbegehren (dürfen).
[...] ?> als Letztes in der Datei [...] kann man es komplett weglassen. Dann können sich auch keine Whitespacezeichen dahinter einschmuggeln.
[...] Höchstens in den includes, und in denen sehe ich nicht wirklich die Notwendigkeit, diesen beiden Bytes einzusparen.Es geht dabei weniger um die eingesparten 2 Bytes sondern um die eingesparten "Headers already sent"-Fehler, die sich gerade auch durch solche Nur-PHP-Code-Includes mit anhängenden Whitespace hinterm ?> ergeben.
echo "$verabschiedung $name";
-
-
-
-
-
-
-
-
-