Webseite nach Umstieg auf php 5.4 nicht mehr lesbar
0 
Der Martin
0 0 Der Martin
0 0 Quellcode
0 Der Martin
0 0 Der Martin
0 0 0 0 1 
dedlfix
0
1
Webseite nach Umstieg auf php 5.4 nicht mehr lesbar
Guten Tag,
ich suche nach einem Ansatz, warum meine Webseite nach einem Umstieg von php 5.3 auf 5.4 nicht mehr vernünftig interpretiert wird.
Ich habe mir auf php.net alle nicht abwärtskompatiblen Dinge angeschaut, aber mir ist nichts aufgefallen, was ich fälschlicherweise in meinen Scripten nutze.
Was mir auffällt:
Meine Include-Dateien scheinen nicht oder nur teilweise durch den php-Interpreter zu laufen.
Viele escapte Anführunhszeichen bleiben escaped, weil sie nciht durch den Interpreter gelaufen zu sein scheinen. Dadurch entsteht reiner Datenmüll im Browser, das ist ja klar.
Ich weiß nicht recht, wo ich ansetzen soll. Hat jemand vielleicht Ähnliches mal erlebt oder gesehen und kann mir einen Ansatz geben, wo ich weiter nachforschen soll?
Konni
-
Hallo,
ich suche nach einem Ansatz, warum meine Webseite nach einem Umstieg von php 5.3 auf 5.4 nicht mehr vernünftig interpretiert wird.
an der Umstellung der PHP-Version an sich wird's wohl eher nicht liegen; eher schon an bestimmten Einstellungen (PHP und/oder Webserver), die bei der Umstellung möglicherweise geändert wurden.
Meine Include-Dateien scheinen nicht oder nur teilweise durch den php-Interpreter zu laufen.
Viele escapte Anführunhszeichen bleiben escaped, weil sie nciht durch den Interpreter gelaufen zu sein scheinen. Dadurch entsteht reiner Datenmüll im Browser, das ist ja klar.
Das klingt abenteuerlich.
Ich weiß nicht recht, wo ich ansetzen soll.
Ich auch nicht. Deswegen zeig doch bitte mal ein paar Beispiele - also PHP-Quellcode, und das, was dann tatsächlich im Browser als Quellcode (nicht Browser-Anzeige) ankommt. Vielleicht findet man da einen Ansatz.
So long,
Martin-
Moin!
Umstieg auf php 5.4
Viele escapte Anführunhszeichen bleiben escaped, weil sie nciht durch den Interpreter gelaufen zu sein scheinen. Dadurch entsteht reiner Datenmüll im Browser, das ist ja klar.
Das klingt abenteuerlich.
Ich weiß nicht recht, wo ich ansetzen soll.
Ich auch nicht.
Wissen wäre übertrieben. Aber ich habe da so eine gewisse Ahnung...
Was zu tun ist:
- error_reporting angemessen benutzen
- Fehler beheben.
Jörg Reinholz
-
Hi,
Wissen wäre übertrieben. Aber ich habe da so eine gewisse Ahnung...
daran dachte ich auch schon. Aber das würde nach der Umstellung nicht bewirken, dass plötzlich Backslashes übrigbleiben (ich nehme mal an, dass der OP diese Form von Escaping meinte).
- error_reporting angemessen benutzen
- Fehler beheben.
Leicht gesagt. Um Fehler zu beheben, muss man sie erstmal erkennen.
So long,
Martin -
Hi,
Wissen wäre übertrieben. Aber ich habe da so eine gewisse Ahnung...
In meiner 5.2.9 Version läuft alles und dort steht in meiner php.ini:
; Magic quotes for incoming GET/POST/Cookie data. magic_quotes_gpc = Off
; Magic quotes for runtime-generated data, e.g. data from SQL, from exec(), etc. magic_quotes_runtime = Off
; Use Sybase-style magic quotes (escape ' with '' instead of '). magic_quotes_sybase = Off
Also wirds daran eher nicht liegen.
Ich versuche jetzt, den Code so weit zu reduzieren, dass ich ein Beispiel posten kann, das klein ist und auch auf 5.4 nicht läuft, ok?
Konni
-
Ich versuche jetzt, den Code so weit zu reduzieren, dass ich ein Beispiel posten kann, das klein ist und auch auf 5.4 nicht läuft, ok?
Also:
Datei index.php
<?php include("./abc.php"); include ("./".menue.""); ?>Datei abc.php
<?php define ( 'menue', 'header123.inc' ); ?>Datei header123.inc:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <HTML> <HEAD> </HEAD> <body> <? echo ("<div>Mein Text</div>"); ?> </body> </html>Ausgabe im Browser:
Mein Text"); ?>Quelltext:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <HTML> <HEAD> </HEAD> <body> <? echo ("<div>bla</div>"); ?> </body> </html>Konni
-
n'Abend,
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <HTML> <HEAD> </HEAD> <body> <? echo ("<div>bla</div>"); ?> </body> </html>was mir hier auffällt, ist die Verwendung von "Short Open Tags" in dieser (und nur dieser) Quelldatei. Ist die PHP-Einstellung short_open_tags seit der Umstellung vielleicht deaktiviert worden? Danach sieht es zumindest ganz stark aus. Die Konsequenz ist, dass die Zeichenfolge "<?" nicht mehr als Anfang eines PHP-Codeblocks gilt, sondern der nachfolgende Quellcode direkt in der Ausgabe zum Browser landet.
Aber das ist jetzt nur geraten ...
Davon abgesehen: Die Großschreibung von HTML-Tagnamen ist weder üblich noch empfohlen. Normal ist Kleinschreibung; bei XHTML wäre sie sogar Pflicht. - Das hat aber nichts mit dem beschriebenen Problem zu tun.
So long,
Martin-
Hi (der) Martin,
Ist die PHP-Einstellung short_open_tags seit der Umstellung vielleicht deaktiviert worden? Danach sieht es zumindest ganz stark aus.
Ich kanns mal "long" testen, aber eigentlich solls ab 5.4 sogar so sein, dass short open tags offiziell unterstützt werden... Zitat: "Die Kurzschreibweise, um Variableninhalte direkt auszugeben („<?=$variable?>“) ist auch ohne Aktivierung der „short_open_tag“-Option (php.ini) verfügbar."
Davon abgesehen: Die Großschreibung von HTML-Tagnamen ist weder üblich noch empfohlen. Normal ist Kleinschreibung; bei XHTML wäre sie sogar Pflicht. - Das hat aber nichts mit dem beschriebenen Problem zu tun.
Hast Du natürlich recht... mach ich auch eigentlich... ich hab grad meinen "anno toback editor" hergenommen, der macht das automatisch...
Konni
-
Hallo,
Ist die PHP-Einstellung short_open_tags seit der Umstellung vielleicht deaktiviert worden? Danach sieht es zumindest ganz stark aus.
Ich kanns mal "long" testen, aber eigentlich solls ab 5.4 sogar so sein, dass short open tags offiziell unterstützt werden...
Zitat: "Die Kurzschreibweise, um Variableninhalte direkt auszugeben („<?=$variable?>“) ist auch ohne Aktivierung der „short_open_tag“-Option (php.ini) verfügbar."ich hätte jetzt nicht gewusst, ab welcher Version das so ist, aber prinzipiell war mir der Umstand auch bekannt. Nur ob die Unterstützung der Kurzform "<?=" automatisch auch "<?" mit einschließt, darüber bin ich mir nicht sicher.
Ein Versuch könnte sich also lohnen.
Ciao,
Martin-
Hi (der) Martin,
Ich kanns mal "long" testen, aber eigentlich solls ab 5.4 sogar so sein, dass short open tags offiziell unterstützt werden...
Zitat: "Die Kurzschreibweise, um Variableninhalte direkt auszugeben („<?=$variable?>“) ist auch ohne Aktivierung der „short_open_tag“-Option (php.ini) verfügbar."ich hätte jetzt nicht gewusst, ab welcher Version das so ist, aber prinzipiell war mir der Umstand auch bekannt. Nur ob die Unterstützung der Kurzform "<?=" automatisch auch "<?" mit einschließt, darüber bin ich mir nicht sicher.
Ein Versuch könnte sich also lohnen.
Du hast (vermutlich) recht. Ein erster (Pre)test bestätigt Deine Vermutung!! Das muss ich morgen weiter verfolgen, heut' schaff ichs nicht mehr, aber mein reduzierter Code reagiert tatsächlich erfolgreich auf den long tag! Danke, Martin. Ich werde (vermutlich schaff ichs aber erst morgen abend oder übermorgen) berichten, ob mein Produktivscript ebenso erfolgreich auf den long tag reagiert!
Konni
-
Danke, Martin. Ich werde (vermutlich schaff ichs aber erst morgen abend oder übermorgen) berichten, ob mein Produktivscript ebenso erfolgreich auf den long tag reagiert!
Also. Es lag auch, aber nicht nur daran. Es gab ein weiteres Problem, nämlich, dass in meinem neuen XAMPP auch die mysql-Version eine andere war und in der neueren Version scheinen die Spaltennamen "post" und "get" geschützte Begriffe zu seoin, was einen mysql-error auslöste.
Beide Fehler zusammen ergab eine echte Codesuppe, die wieder vernünftig interpretiert wurde, nachdem ich sie ausgemerzt hatte.
Danke (hier vor allen an Martin) und Grüße
Konni
-
Tach,
Es gab ein weiteres Problem, nämlich, dass in meinem neuen XAMPP auch die mysql-Version eine andere war und in der neueren Version scheinen die Spaltennamen "post" und "get" geschützte Begriffe zu seoin, was einen mysql-error auslöste.
get ja, post nein: https://dev.mysql.com/doc/refman/5.7/en/keywords.html
mfg
Woodfighter-
get ja, post nein: https://dev.mysql.com/doc/refman/5.7/en/keywords.html
mfg
WoodfighterAh, ok. Aber selbst "get" muß neu sein, das ging früher fehlerfrei durch...
Konni
-
Tach!
get ja, post nein: https://dev.mysql.com/doc/refman/5.7/en/keywords.html
Ah, ok. Aber selbst "get" muß neu sein, das ging früher fehlerfrei durch...
Klickst du den Link an, findest du dich im Handbuch wieder. Dann siehst du auf der linken Seite Links zum selben Thema der vorhergehenden Versionen. Da kannst du statt zu mutmaßen nachschauen.
Reservierte Bezeichner lassen sich mit `Backticks` entschärfen.
dedlfix.
-
Reservierte Bezeichner lassen sich mit `Backticks` entschärfen.
Klar, ist längst geschehen, aber trotzdem danke für den Tip.
"get" ist ab mysql 5.6 dabei...
Konni
-
Moin!
Reservierte Bezeichner lassen sich mit `Backticks` entschärfen.
Gerade wurde in guter Grund genannt, in (my)SQL alle selbst gewählten Bezeichner von Anfang an mit den Backticks zu versehen, statt zu hoffen, dass diese auch `oben ohne` noch in ein paar Jahren gültige Bezeichner für Datenbanken, Tabellen, Spalten, Funktionen, Views, ... sonstwas sind.
Jörg Reinholz
-
Gerade wurde in guter Grund genannt, in (my)SQL alle selbst gewählten Bezeichner von Anfang an mit den Backticks zu versehen, statt zu hoffen, dass diese auch `oben ohne` noch in ein paar Jahren gültige Bezeichner für Datenbanken, Tabellen, Spalten, Funktionen, Views, ... sonstwas sind.
Absolut! Ich hasse Backticks und habe die immer über die letzten Jahre gelöscht. Ist jetzt zwar nicht so dramatisch, weil ich recht eindeutige Spaltenbezeichner habe, aber mit "get" hats mich dann jetzt doch erwischt...
Konni
-
-
-
-
-
-
-
-
-
Moin!
was mir hier auffällt, ist die Verwendung von "Short Open Tags" in dieser (und nur dieser) Quelldatei.
So wie der Fehler JETZT beschrieben ist würde auch ich sagen, short open tags ist deaktiviert. Ich würde aber dazu neigen, nicht an der php.ini herumzufummeln, sondern die PHP Skripte zu ändern:
<? -> <?php
Jörg Reinholz
-
-
Moin!
Datei header123.inc:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <HTML> <HEAD> </HEAD> <body> <? echo ("<div>Mein Text</div>"); ?> </body> </html>Es ist schlechte Praxis, wenn man Dateien, die PHP-Code enthalten, nicht mit der Dateiendung "php" versieht.
Der Grund ist, dass ohne Endung "php" die Datei nur dann als PHP interpretiert werden kann, wenn sie via
include()/require()eingebunden wird - aber nicht, wenn man sie aufgrund irgendeines blöden Zufalls via URL direkt anspricht. Denn der Webserver ist gewöhnlich so konfiguriert, dass er nur Dateien mit der Endung "php" an den Parser schickt, alles andere aber nicht.Auf diese Weise könnte man also an eventuell wichtigen Quellcode gelangen, indem man die Datei "header123.inc" direkt im Browser aufruft.
Das tatsächliche Problem hier ist zwar das Verwenden von Short-Open-Tags, die nicht zum Server-Setting von PHP passen, es ist aus Sicherheitsgründen aber ebenfalls zu vermeiden.
Eben gerade weil man sich bei den Einstellungen von PHP auch nicht sicher sein kann, ob die Short-Open-Tags funktionieren oder nicht, sollte man sie ebenfalls vermeiden.
Damit sind übrigens seit PHP 5.4 nur noch die hier gemeint:
<? ?>. In PHP 5.3 und vorher allerdings AUCH die hier:<?= $var ?>- letztere sind aber nur als Kurzform von<?php echo $var ?>zu gebrauchen.Mit anderen Worten: Ab PHP 5.4 kann man ohne Angst diese beiden Formen nutzen:
<?php ?>und<?= $var ?>. In PHP 5.3 konnte man nur die erste Form bedenkenlos nutzen.Letzte Bemerkung: Warum zum Kuckuck hast du noch PHP 5.2 installiert? Es ist langsam und hat sehr wichtige Features nicht, allen voran Namespaces! Heutzutage will man eigentlich schon PHP 5.5 nicht mehr nutzen, das wird seit 10. Juli 2015 nur noch mit Security-Patches versorgt und ist (Stand heute) in 10 Monaten am Ende seiner Lebensdauer.
Ein PHP-Hoster sollte heutzutage mindestens PHP 5.6 anbieten, und schon mal Äußerungen hinsichtlich PHP 7 getätigt und diesbezügliche Anfragen nicht mit Stirnrunzeln beantwortet haben.
Grüße Sven
-
Hallo Sven,
Auf diese Weise könnte man also an eventuell wichtigen Quellcode gelangen, indem man die Datei "header123.inc" direkt im Browser aufruft.
Das habe ich vergangenheitlich per htaccess vermieden, aber Du hast recht. Ich habe jetzt (das war verteufelt viel Arbeit) alle Scripte umgeschrieben und alle .inc-Dateien in .php Dateien umbenannt.
Mit anderen Worten: Ab PHP 5.4 kann man ohne Angst diese beiden Formen nutzen:
<?php ?>und<?= $var ?>. In PHP 5.3 konnte man nur die erste Form bedenkenlos nutzen.Hm... ob ich das nun als Verbesserung empfinde?
Letzte Bemerkung: Warum zum Kuckuck hast du noch PHP 5.2 installiert? Es ist langsam und hat sehr wichtige Features nicht, allen voran Namespaces! Heutzutage will man eigentlich schon PHP 5.5 nicht mehr nutzen, das wird seit 10. Juli 2015 nur noch mit Security-Patches versorgt und ist (Stand heute) in 10 Monaten am Ende seiner Lebensdauer.
Das ist (bzw. war) meinem etwas in die Jahre gekommenen XAMPP geschuldet, das ich erst jetzt mal auf einen neueren Stand gebracht habe. Aber auch im Produktivbetrieb kann ich "nur" zwischen 5.3 und 5.5 aussuchen...
Konni
-
-
-
-