WAMP Server und php

[Janina Riemenschneider]

Ich habe ein Problem mit dem Wampstack. Beim alten Wamp-server (bitnami) lief kein php7.xxx. Daher habe ich Wampstacks 7.4.6.1 installiert. Lege ich Dateien im html-Format ab, ist alles schick. Ist jedoch php-Code, besonders Ausgabe (echo "...";) enthalten, wird die Seite unter Localhost nicht angezeigt. D.h. es wird nichts, nothing, rien, nada angezeigt.

Bin ratlos ...

LG Jane

[Tarzan]

Ich habe ein Problem mit dem Wampstack. Beim alten Wamp-server (bitnami) lief kein php7.xxx. Daher habe ich Wampstacks 7.4.6.1 installiert. Lege ich Dateien im html-Format ab, ist alles schick. Ist jedoch php-Code, besonders Ausgabe (echo "...";) enthalten, wird die Seite unter Localhost nicht angezeigt. D.h. es wird nichts, nothing, rien, nada angezeigt.

Bin ratlos ...

Das könnte ein Problem mit der Standard-Kodierung sein. Benutzt Du für die Ausgabe mit echo auch htmlspecialchars()?
Welche Kodierung benutzt der Webserver und welche ist bei PHP (auch im Skript) gewählt?

Kannst Du mit PHP Fehlermeldungen provozieren?
Sind error_reporting und display_errors eingeschaltet?
Was sagen die Logs des Apachen und von PHP?

Hoiohh Tarzan

[Tarzan]

Hi Jane,

wird denn PHP überhaupt ausgeführt?

Mit einem touch('xyz.test);` könntest Du das feststellen.

LG Tarzan

[Der Martin]

Guten Abend,

Ich habe ein Problem mit dem Wampstack.
Beim alten Wamp-server (bitnami) lief kein php7.xxx. Daher habe ich Wampstacks 7.4.6.1 installiert.
Lege ich Dateien im html-Format ab, ist alles schick. Ist jedoch php-Code, besonders Ausgabe (echo "...";) enthalten, wird die Seite unter Localhost nicht angezeigt. D.h. es wird nichts, nothing, rien, nada angezeigt.

Bin ratlos ...

Das könnte ein Problem mit der Standard-Kodierung sein.

nein. Wenn die nicht passt, würden eventuell manche Zeichen (vor allem Nicht-ASCII-Zeichen) nicht korrekt angezeigt. Aber es käme dennoch zumindest eine interpretierbare Anzeige.

Benutzt Du für die Ausgabe mit echo auch htmlspecialchars()?

Gute Frage, aber auch das hat nichts mit der Codierung zu tun. Ein Weglassen der angemessenen Maskierung hätte möglicherweise zur Folge, dass HTML-Steuerzeichen (vor allem '<', '&') unerwünschte Ergebnisse produzieren, aber es käme doch zumindest "irgendwas".

Wenn im Zusammenhang mit PHP also "gar nichts" als Antwort kommt, bedeutet das meistens, dass der Server die Anfrage gar nicht angemessen interpretieren und verarbeiten konnte. Also ein Problem, das viel tiefer sitzt als "nur" ein Fehler bei der Zeichencodierung.

Live long and pros healthy,
 Martin

[Tarzan]

Hi Martin,

Benutzt Du für die Ausgabe mit echo auch htmlspecialchars()?

Gute Frage, aber auch das hat nichts mit der Codierung zu tun.

Doch, kann es haben. Findet man sogar hier im Archiv, wenn man sucht!

LG
Tarzan

[Raketenphilosoph]

Doch,

Nein. Selbst wenn das stimmen würde, dann wäre die Antwort stark suboptimal.

Was Du meinst ist sicherlich der Versuch header zu senden, nachdem die BOM schon gesendet wurde. Das sollte mit PHP 7.x auf Grund der normalerweise aktivierten Ausgabepufferung nicht mehr relavant sein.

Und falls doch stände es im error.log.

[Tarzan]

Doch,

Nein. Selbst wenn das stimmen würde, dann wäre die Antwort stark suboptimal.

Doch! Schau bitte im Archiv nach, bevor Du hier sen Ignoranzteufel spielst.
Der Test mit der Ausgabe, die <br> enthält, deutet auch darauf hin.

Ein mb_internal_encoding() am Anfamg des Skriptes kann da (bei inkonsistent eingerichteten) Systemen erfahrungsgemäß helfen. Da es sich um ein WAMP-System mit Nachinstallation handelt, wird es vermutlich um eine widersprüchlichd Konfiguration handeln.

Selbstverständlich sollte immer erst in den beiden Error-Logs vom Apache und PHP geschaut werden.

Urschrei
Tarzan

[Tabellenkalk]

Hallo,

Doch!

oh?

Schau bitte im Archiv nach, bevor Du hier sen Ignoranzteufel spielst.

Wenn du behauptest, es findet sich im Archiv, bist du derjenige, der auch den Link darauf bringen sollte.

Der Test mit der Ausgabe, die <br> enthält, deutet auch darauf hin.

zumindest ich habe keine Ausgabe zu sehen bekommen, in der <br> enthalten war…

Gruß
Kalk

[Tarzan]

Hallo,

Doch!

oh?

Schau bitte im Archiv nach, bevor Du hier sen Ignoranzteufel spielst.

Wenn du behauptest, es findet sich im Archiv, bist du derjenige, der auch den Link darauf bringen sollte.

Bla, Bla. Das Problem, ist bekannt, punktum! Soll ich auch noch ne Kiste Bier daneben stellen?

Der Test mit der Ausgabe, die <br> enthält, deutet auch darauf hin.

zumindest ich habe keine Ausgabe zu sehen bekommen, in der <br> enthalten war…

Enthalten sollte aber nicht hat. Ich hatte den Intellekt hier für so hoch gehalten, dass man ein Bisschen selbstständig mitdenken kann. Hanbe ich mich da geirrt?

Zurück in den Urwald; die Affen sind schlauer! Tarzan

[Tabellenkalk]

Hallo,

Das Problem, ist bekannt, punktum!

Möglicherweise Dir, aber anderen offensichtlich nicht. Möglicherweise ist Dir aber auch bloß ein ähnliches Problem bekannt, daher die Bitte um einen Link.

Soll ich auch noch ne Kiste Bier daneben stellen?

Woneben genau?

Gruß
Kalk

[Tarzan]

Hi,

Das Problem, ist bekannt, punktum!

Möglicherweise Dir,

und diesem Forum. Du warst seinerzeit (ca. 4 bis 6 vor Corona) auch schon dabei!

Soll ich auch noch ne Kiste Bier daneben stellen?

Woneben genau?

Mir egal.
Hauptsache der Sicherheitsabstand wird eingehalten und die Marke stimmt.

Bleib gesund!
Tarzan

[Raketenwissenschaftler]

Wer behauptet, dieses oder jenes fände sich im Archiv, der muss liefern. Sonst müsste ich ja für Dich suchen…

Ich hatte den Intellekt hier für so hoch gehalten, dass man ein Bisschen selbstständig mitdenken kann.

Ich kann mich irren, aber ich glaube fast, dass Du und die angebliche TO die selbe Person sindn und dass der gesamte Thread hier nur provoziert wurde um zu diesem Ausbruch zu führen.

Du eierst hier auf Nebenproblemen herum (mb_encoding, zwei verschiedene error_logs), die jeweils nur bei seltenen(!) Fehlkonfigurationen auftreten und mit dem beschriebenen Fehler nichts zu tun haben (keine mb_Funktionen benutzt, gezeigter Test enthält nur Zeichen aus ASCII-Vorrat).

Soll ich auch noch ne Kiste Bier daneben stellen?

Für mich bitte nicht.

Zurück in den Urwald; die Affen sind schlauer! Tarzan

Falsche Anordnung. Muss heißen:

Tarzan! Zurück in den Urwald; die Affen sind schlauer.

[Raketenphilosoph]

Der Test mit der Ausgabe, die <br> enthält, deutet auch darauf hin.

Im Test fand die Ausgabe des <br> angeblich gerade nicht statt. Und bitte verrate, was das alles mit mb_internal_encoding() zu tun haben soll, wenn im gezeigten Testskript keine einzige Multibyte-Funktion benutzt wird:

encoding is the character encoding name used for the HTTP input character encoding conversion, HTTP output character encoding conversion, and the default character encoding for string functions defined by the mbstring module.

[Tarzan]

Der Test mit der Ausgabe, die <br> enthält, deutet auch darauf hin.

Im Test fand die Ausgabe des <br> angeblich gerade nicht statt.

Ja eben! Manno, seid Ihr hier zu blöd zum Mitdenken oder Roboter?

Und bitte verrate, was das alles mit mb_internal_encoding() zu tun haben soll, wenn im gezeigten Testskript keine einzige Multibyte-Funktion benutzt wird:

Woher soll ich das wissen? Ich habe PHP nicht verbrochen! Ich weiß nur aus Erfahrung und den früheren Diskussionen in diesem Forum, dass es genau bei dieser Indizienlage meistens hilft.

Solange die OP sich nicht wieder meldet zum Vorschlag, wars das dann für mich.

Tschüss
Tarzan

[JürgenB]

Hallo

Ja eben! Manno, seid Ihr hier zu blöd zum Mitdenken oder Roboter?

kannst du deine Ausdrucksweise mal etwas mäßigen?

Gruß
Jürgen

[Tarzan]

Hi,

Ja eben! Manno, seid Ihr hier zu blöd zum Mitdenken oder Roboter?

kannst du deine Ausdrucksweise mal etwas mäßigen?

Wie genau?

Horrido
Tarzan

[JürgenB]

Hallo

OK, dann mache ich hier mal zu.

Gruß
Jürgen

[Raketenkurskontrolle]

Der Apache schreibt ein error.log.

Sieh einfach dort nach bevor Du irgendwelche kruden Vermutungen anstellst oder solchen folgst.

[Raketenkurskontrolle]

Aber, bevor Du nach dem error.log suchst, überzeuge Dich davon, dass die gelieferte Seite wirklich leer ist. (Martin hat das schon mit anderen Worten geschrieben)

Es kann nämlich auch sein, dass PHP nicht installiert oder nicht aktiviert ist. In dem Fall erhält Dein Browser etwas geliefert, was er für „html“ hält und

<?php
...
?>

sieht für ihn aus, wie ein HTML-Tag ohne Inhalt. Also zeigt er nichts an. In der Quelltextansicht offenbart sich das. Übrigens ist das noch ein Grund, schließende php-Tags am Ende einer Datei wegzulassen:

Also notiere

<?php
phpinfo();

statt

<?php
phpinfo();
?>

[Janina Riemenschneider]

okay, danke für die schnellen Antworten.

Mir scheint, dass php nicht interpretiert wird.

mein Test-code:

<!DOCTYPE html>
<html lang="de">
  <head>
    
    <title>Testdatei</title>
	</head>
  
 <?php  echo "irgendwas<br>"; ?>

       sonstiger Text

  </body>
</html>

was im Quelltext steht:

<!DOCTYPE html>
<html lang="de">
  <head>
    
    <title>Testdatei</title>
	</head>
  
 irgendwas
       sonstiger Text

  </body>
</html>

Merkwürdig, dass phpinfo (mit schließendem tag) korrekt ausgeführt wird.

[Der Martin]

Hallo,

Mir scheint, dass php nicht interpretiert wird.

aus deiner Browser-Quelltextanzeige geht eigentlich klar hervor, dass PHP eben doch ausgeführt wird.

was im Quelltext steht:

<!DOCTYPE html>
<html lang="de">
  <head>
    
    <title>Testdatei</title>
	</head>
  
 irgendwas
       sonstiger Text

  </body>
</html>

Wenn PHP nicht interpretiert würde, dann wären auch die öffnenden und schließenden Tags <?php ... ?> in der Quelltextansicht noch zu sehen.

Live long and pros healthy,
 Martin

[Janina Riemenschneider]

Nun, merkwürdig finde ich, dass bei phpinfo der php-Teil interpretiert wird, jedoch nicht in der Testdatei.

[Raketenkurskontrolle]

Nun, merkwürdig finde ich, dass bei phpinfo der php-Teil interpretiert wird, jedoch nicht in der Testdatei.

Über Deine Testdatei können wir hier nur wenig sagen, weil die von Dir gezeigten Ausgaben erweislich in keinem Fall mit dieser übereinstimmen können.

Das Einzige, was demnach zu „sagen“ wäre, ist:

1. PHP wird grundsätzlich ausgeführt
2. Überprüfe genau, welche Datei Du gerade testest.
3. Und schau ins error.log!

[Janina Riemenschneider]

Sorry ... fetter Anfängerfehler. Ein schließendes </body> hat gefehlt und ich hasse den Cache!!

Vielen Dank für eure Hilfe. 🥰

[Raketenkurskontrolle]

Dankeschön … Bitteschön!

Ein schließendes </body>

Ah. Nein. Daran scheitert die Anzeige eines HTML-Dokuments im Browser nicht.

ich hasse den Cache!

Der kann zu Irrtümern führen, aber ich liebe ihn.

[Raketenkurskontrolle]

Also... Dein Skript ist nicht mit den Ausgaben in Übereinstimmung zu bringen.

Wenn Du …

<?php  echo "irgendwas<br>"; ?>

notierst, dann sollte das <br> auch im Quelltext der Ausgabe auftauchen. Tut es aber nicht.

Merkwürdig, dass phpinfo (mit schließendem tag) korrekt ausgeführt wird.

Das ist nicht „merkwürdig“. Der schließende PHP-Tag am Ende einer Datei ist überflüssig und nur in vielen (also nicht allen) Situationen schädlich. Z.B. eben wenn aufgrund einer Fehlkonfiguration das PHP nicht interpetiert oder ausgeführt wird und der Browser das ergo an ihn gelieferte PHP-Zeug für HTML hält, also nichts anzeigt. Das ist aber gerade kein Syntaxfehler, der zum Abbruch führt.