MLF 1.7.3: Changed PHP 5.2 to 5.5 -> Empty titles and bodies (Technics)

by wo2010, Thursday, January 26, 2017, 14:36 (2619 days ago)

Hello,

we are still using "My little forum" V. 1.7.3. Lack of knowledge and time let us running the "running system".

But the provider now forced us to switch from PHP 5.2 (Apache Modul) to PHP 5.5 (CGI/FPM). So I did a complete database backup and then changed the settings in the server administration.

After that in the forum there are a lot of missing tread titles. And (nearly) all message bodies are empty.

Besides of this it is possible to create new threads, but the amount of words or letters seems to be very delimited (like SMS). At least in the preview I've tested - one user just left a new noticable longer entry.

Does anybody remember this behavior? What happens behind the curtain? Where are the levers to repair our forum? (The server administration didn't offer an option to switch back to the old PHP version.)

I need some help please.

Many thanks in advance.

Best regards
Wolfgang

Avatar

MLF 1.7.3: Changed to PHP 5.5 -> bugs, @Alfie?

by Auge ⌂, Thursday, January 26, 2017, 18:59 (2618 days ago) @ wo2010

Hello

we are still using "My little forum" V. 1.7.3. Lack of knowledge and time let us running the "running system".

[Description of several bugs]

Does anybody remember this behavior?

Yes, I had several notices about this misbehaviour in my own forum (actually disabled), where Alfie and I worked on the last version of MLF1 (1.7.6, bugfixes, new features and so on). I for myself led this forum run under PHP 5.6 without any of these problems, so I couldn't re-enact them.

But with your help we can solve the issues, I hope. Please put the following code into the inc.php after the comment block with the copyright notice and load the forum main page.

ini_set('display_errors', 1);
error_reporting(E_ALL);

I hope to get error messages. If so, please paste them here.

Best regards
Wolfgang

Are you a german speaker? It would be easier to write in german language.

A question to Alfie: Does you have any of these or similar problems with your beta of 1.8?

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

MLF 1.7.3: Changed to PHP 5.5 -> Special chars bug?

by wo2010, Thursday, January 26, 2017, 19:27 (2618 days ago) @ Auge

Hallo Auge,

vielen Dank für die Antwort. Und auch für das Angebot - auf deutsch ist es für mich in der Tat etwas leichter : -)

Ich habe vorhin noch etwas rumgestochert - und plötzlich kam beim Anblick ein Verdacht: Es scheint alle Texte zu betreffen (Titel und Inhalte), die Umlaute oder Sonderzeichen enthalten.

Ich hoffe, das ist die richtige Spur.

Vielen Dank für Eure Mühe. Und die Software überhaupt.

Mit freundlichen Grüßen
Wolfgang

Avatar

MLF 1.7.3: Changed to PHP 5.5 -> Special chars bug?

by Auge ⌂, Thursday, January 26, 2017, 19:52 (2618 days ago) @ wo2010

Hallo

Ich habe vorhin noch etwas rumgestochert - und plötzlich kam beim Anblick ein Verdacht: Es scheint alle Texte zu betreffen (Titel und Inhalte), die Umlaute oder Sonderzeichen enthalten.

Hmm, es ist natürlich möglich, dass das Auslesen der Daten aus der Datenbank oder deren Verarbeitung im Skript zu Problemen führt. Ich wüsste aber auf Anhieb nicht, wo man da ansetzen müsste. Die Datenbank speichert die Texte in einer bestimmten Kodierung. Beim Auslesen werden sie in einer bestimmten Kodierung herausgegeben. PHP verarbeitet die Daten in einer bestimmten Kodierung und der Webserver liefert die Daten in einer bestimmten Kodierung aus.

Diese "bestimmte Kodierung" muss nicht durchgängig eine sein, es können auch mehrere sein, was ein fehlerhaftes Verhalten wäre. Welchen Browser benutzt du?

Davon abgesehen: Hast du den von mir gezeigten Code in die ini.php eingebaut? Werden Fehler angezeigt?

Ich hoffe, das ist die richtige Spur.

Das ist zumindest mal eine Spur.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

MLF 1.7.3: Changed to PHP 5.5 -> Special chars bug?

by wo2010, Thursday, January 26, 2017, 22:52 (2618 days ago) @ Auge

Hallo Auge,

Davon abgesehen: Hast du den von mir gezeigten Code in die ini.php eingebaut? Werden Fehler angezeigt?

habe ich inzwischen gemacht - ohne erkennbare Auswirkungen. Schien es.

Dann loggte ich mich ein. Dabei kam:

Deprecated: mysql_escape_string(): This function is deprecated; use mysql_real_escape_string() instead. in /www/htdocs/....../login.php on line 70

Warning: Cannot modify header information - headers already sent by (output started at /www/htdocs/....../login.php:70) in /www/htdocs/....../login.php on line 91

Warning: Cannot modify header information - headers already sent by (output started at /www/htdocs/....../login.php:70) in /www/htdocs/....../login.php on line 110

Danach ging's weiter zur Anzeige.

Diese "bestimmte Kodierung" muss nicht durchgängig eine sein, es können auch mehrere sein, was ein fehlerhaftes Verhalten wäre. Welchen Browser benutzt du?

Firefox 45.7.0 ESR unter Win7. Bei Opera 12.17 dasselbe Bild.

Bin mal mit phpMyAdmin von der Seite her rangegangen - da konnte ich die "vermissten" Einträge sehen. Mit Umlauten.

Die Datenbank hat noch ein paar weitere Tabellen für andere Kleinanwendungen (die vor meiner Zeit installiert wurden - wie auch das Forum). Eine funktioniert reibungslos, auch mit Umlauten.

Die andere nicht, da kommt (auch ohne "Deine" Ergänzung im Forumscode - ist ja auch eine ganz andere Baustelle) die Meldung:

Fatal error: Call-time pass-by-reference has been removed in /www/htdocs/....../***.php on line 336

Hilft uns das für's Forum etwas weiter?

Mit freundlichen Grüßen
Wolfgang

PS: Werden bei diesen Zeilenangaben eigentlich die Kommentarzeilen mitgezählt?

Avatar

MLF 1.7.3: Changed to PHP 5.5 -> Special chars bug?

by Auge ⌂, Friday, January 27, 2017, 08:26 (2618 days ago) @ wo2010

Hallo

Hast du den von mir gezeigten Code in die ini.php eingebaut?


habe ich inzwischen gemacht

Dann loggte ich mich ein. Dabei kam:

Deprecated: mysql_escape_string(): This function is deprecated; use mysql_real_escape_string() instead. in /www/htdocs/....../login.php on line 70

Die Meldung sagt, dass die mysql_-Funktionen in zukünftigigen PHP-Versionen abgeschafft werden. Das ist mit PHP7 geschehen, was bedeutet, dass deine MLF-Version (1.7.3) mit PHP7 nicht mehr funktionieren wird.

Warning: Cannot modify header information - headers already sent by (output started at /www/htdocs/....../login.php:70) in /www/htdocs/....../login.php on line 91

Warning: Cannot modify header information - headers already sent by (output started at /www/htdocs/....../login.php:70) in /www/htdocs/....../login.php on line 110

Das sind (sogar ganz klassische) Folgefehler, die durch die erste Meldung ausgelöst werden.

Diese "bestimmte Kodierung" muss nicht durchgängig eine sein, es können auch mehrere sein, was ein fehlerhaftes Verhalten wäre. Welchen Browser benutzt du?


Firefox 45.7.0 ESR unter Win7. Bei Opera 12.17 dasselbe Bild.

Da der Fehler auf dem Webserver auftritt, sind seine Auswirkungen natürlich in allen Browsern zu sehen.

Bin mal mit phpMyAdmin von der Seite her rangegangen - da konnte ich die "vermissten" Einträge sehen. Mit Umlauten.

Gut, das ist ein Anhaltspunkt. Die Daten sind nicht kaputt, nur ihre Ausgabe bereitet die Probleme.

Deine Programmversion läuft noch mit der Kodierung ISO-8859-1 oder -15. PHP selbst interessiert das nicht, aber die Kommunikation mit dem SQL-Server oder die Auslieferung durch den Webserver an sich könnte Probleme bereiten.

- Hast du Zugang auf phpMyAdmin? Wenn ja, schaue bitte nach, ob die Forumstabellen selbst und die Textfelder eine Kollation aus dem Bereich ISO-8859-1 oder -15 haben.

- Öffne im Firefox bitte die Netzwerkanalyse (Extras=>Web-Entwickler=>Netzwerkanalyse (oder [STRG]+[Umschalt]+[Q]) und rufe das Forum bitte einmal auf. Dir werden nun alle ausgelieferten Ressourcen (HTML, CSS, JS, Bilder, etc.) aufgelistet. Klicke bitte auf die Seite selbst (forum.php, board.php oder welche Seite auch immer du aufgerufen hast). Rechts wird ein neuer Kasten mit den Metadaten der Anfrage und der ausgelieferten Antwort eingeblendet. Die Antwortkopfzeilen enthalten unter Anderem die Zeile "Content-Type", die in diesem Forum den Wert "text/html; charset=utf-8" hat. Welcher Wert wird bei dir angegeben?

Die Datenbank hat noch ein paar weitere Tabellen für andere Kleinanwendungen (die vor meiner Zeit installiert wurden - wie auch das Forum). Eine funktioniert reibungslos, auch mit Umlauten.

Aha.

Die andere nicht, da kommt (auch ohne "Deine" Ergänzung im Forumscode - ist ja auch eine ganz andere Baustelle) die Meldung:

Fatal error: Call-time pass-by-reference has been removed in /www/htdocs/....../***.php on line 336

Das halt also nichts mit dem Forum zu tun, wenn ich dich richtig verstehe.

Hilft uns das für's Forum etwas weiter?

Nein.

PS: Werden bei diesen Zeilenangaben eigentlich die Kommentarzeilen mitgezählt?

Soweit ich das überblicke, werden die Zeilen mitgezählt. Wäre ja auch doof, einen Hinweis auf einen Fehler in Zeile X zu bekommen, der wegen reichhaltiger Kommentierung des Codes hundert Zeilen weiter verursacht wird.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

MLF 1.7.3: Changed to PHP 5.5 -> Special chars bug?

by wo2010, Friday, January 27, 2017, 12:05 (2618 days ago) @ Auge

Hallo Auge,

Da der Fehler auf dem Webserver auftritt, sind seine Auswirkungen natürlich in allen Browsern zu sehen.

Nur als Ergänzung: Auch bei dem SQL-Dump über die Forums-Administration bleiben die Felder mit Umlauten leer.

Hast du Zugang auf phpMyAdmin? Wenn ja, schaue bitte nach, ob die Forumstabellen selbst und die Textfelder eine Kollation aus dem Bereich ISO-8859-1 oder -15 haben.

Die Kollation ist bei allen genutzten Tabellen und Zeichenfeldern "latin1_swedish_ci". Auch bei der _funktionierenden_ Drittanwendung.

Wenn ich mich per phpMyAdmin einlogge, gibt es neben unserer Datenbank noch eine zweite: "information_schema". Dort steht überall, soweit ich das überblicke, "utf8_general_ci".

Klicke bitte auf die Seite selbst (forum.php, board.php oder welche Seite auch immer du aufgerufen hast). Rechts wird ein neuer Kasten mit den Metadaten der Anfrage und der ausgelieferten Antwort eingeblendet. Die Antwortkopfzeilen enthalten unter Anderem die Zeile "Content-Type", die in diesem Forum den Wert "text/html; charset=utf-8" hat. Welcher Wert wird bei dir angegeben?

Nur "text/html".

Viele Grüße
Wolfgang

PS: Was bedeutet in phpMyAdmin die Information "Überhang" bei einigen Tabellen?

Avatar

MLF 1.7.3: Changed to PHP 5.5 -> Special chars bug?

by Auge ⌂, Friday, January 27, 2017, 13:44 (2618 days ago) @ wo2010

Hallo

Da der Fehler auf dem Webserver auftritt, sind seine Auswirkungen natürlich in allen Browsern zu sehen.


Nur als Ergänzung: Auch bei dem SQL-Dump über die Forums-Administration bleiben die Felder mit Umlauten leer.

Ja, wenn es das Skript überall auf die gleiche Weise tut, dann konsequenterweise auch überall falsch.

Hast du Zugang auf phpMyAdmin? Wenn ja, schaue bitte nach, ob die Forumstabellen selbst und die Textfelder eine Kollation aus dem Bereich ISO-8859-1 oder -15 haben.


Die Kollation ist bei allen genutzten Tabellen und Zeichenfeldern "latin1_swedish_ci". Auch bei der _funktionierenden_ Drittanwendung.

Gut. Nicht mehr zeitgemäß, aber für dein Skript passend.

Wenn ich mich per phpMyAdmin einlogge, gibt es neben unserer Datenbank noch eine zweite: "information_schema". Dort steht überall, soweit ich das überblicke, "utf8_general_ci".

Das sind Systeminterna, quasi die Standardvorgaben, wenn bei der Tabellenerstellung nichts anderes definiert wird. Allerdings gelten diese Standardvorgaben auch für die Verbindungen zum lesen und schreiben von Daten.

Klicke bitte auf die Seite selbst (forum.php, board.php oder welche Seite auch immer du aufgerufen hast). Rechts wird ein neuer Kasten mit den Metadaten der Anfrage und der ausgelieferten Antwort eingeblendet. Die Antwortkopfzeilen enthalten unter Anderem die Zeile "Content-Type", die in diesem Forum den Wert "text/html; charset=utf-8" hat. Welcher Wert wird bei dir angegeben?


Nur "text/html".

Aha! Dein Webserver sendet keine Information zur Zeichenkodierung.

Da sind also zwei mögliche Baustellen.

1. Verbindung mit der Datenbank, explizite Vorgabe der Zeichenkodierung ISO-8859-1 für die Verbindung.

// functions.php, irgendwo bei Zeile 260
 
 // connects to the database:
 function connect_db($host,$user,$pw,$db)
 {
  global $lang;
  $connid = @mysql_connect($host, $user, $pw);  // Datenbankverbindung herstellen
  if(!$connid) die($lang['db_error']);
  mysql_select_db($db, $connid) or die($lang['db_error']);
  return $connid;
 }
 
// ersetzen durch
 
 // connects to the database:
 function connect_db($host,$user,$pw,$db)
 {
  global $lang;
  $connid = @mysql_connect($host, $user, $pw);  // Datenbankverbindung herstellen
  if(!$connid) die($lang['db_error']);
  mysql_select_db($db, $connid) or die($lang['db_error']);
  mysql_set_charset("ISO-8859-1", $connid) or die($lang['db_error']); // <= neue Zeile, Funktion ab PHP 5.2.3 verfügbar
  return $connid;
 }

Bitte erst einmal bei Schritt 1 bleiben und das Ergebnis testen. Erst wenn erkennbar ist, dass sich etwas getan hat oder auch nicht, Schritt 2 ausführen.

2. Auslieferung der generierten Seiten

// inc.php, gleich hinter den Copyright-Block und die Festlegung für das Error-Reporting
 
header('Content-type', 'text/html; charset=iso-8859-1');

PS: Was bedeutet in phpMyAdmin die Information "Überhang" bei einigen Tabellen?

Für die einzelnen Felder in den Tabellen sind Größen, z.B. die in einer Textspalte speicherbare Anzahl von Zeichen (varchar(50)), vorgegeben. Wird diese Größenvorgabe durch die Daten nicht ausgenutzt, ergibt sich ein Überhang. Das ist nichts schlimmes. Bei vorhersehbaren Datenstrukturen kann man die Feldgrößen anpassen, bei einem Forum weiß man aber nicht, was und wieviel eigegeben wird. Also lebt man mit den Überhängen.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

MLF 1.7.3: Changed to PHP 5.5 -> Special chars bug?

by wo2010, Friday, January 27, 2017, 14:41 (2618 days ago) @ Auge

Hallo Auge,

danke für die Antwort.

1. Verbindung mit der Datenbank, explizite Vorgabe der Zeichenkodierung ISO-8859-1 für die Verbindung.

// connects to the database:
function connect_db($host,$user,$pw,$db)
{
global $lang;
$connid = @mysql_connect($host, $user, $pw); // Datenbankverbindung herstellen
if(!$connid) die($lang['db_error']);
mysql_select_db($db, $connid) or die($lang['db_error']);
mysql_set_charset("ISO-8859-1", $connid) or die($lang['db_error']); // <= neue Zeile, Funktion ab PHP 5.2.3 verfügbar
return $connid;
}[/code]

Bitte erst einmal bei Schritt 1 bleiben und das Ergebnis testen.

Hab die Zeile ergänzt. Doch kein schöner Erfolg: Die Seite bleibt beim Laden hängen. Ich sah in der Analyse einen Balken bei der board.php, der stehen bleibt. Weitere Komponenten kamen nicht dazu.

Erst wenn erkennbar ist, dass sich etwas getan hat oder auch nicht, Schritt 2 ausführen.

2. Auslieferung der generierten Seiten

// inc.php, gleich hinter den Copyright-Block und die Festlegung für das Error-Reporting
 
header('Content-type', 'text/html; charset=iso-8859-1');

Bringt sofort die Fehlermeldungen:

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator, webmaster and inform them of the time the error occurred, and anything you might have done that may have caused the error.

More information about this error may be available in the server error log.

Additionally, a 302 Found error was encountered while trying to use an ErrorDocument to handle the request.

Jetzt müßte ich wohl gucken, wo das Fehlerprotokoll zu finden ist.

Wird diese Größenvorgabe durch die Daten nicht ausgenutzt, ergibt sich ein Überhang.

Danke. Es bedeutet also anscheinend kein Überquellen von Daten, sondern eine Nichtausnutzung von reserviertem Speichervolumen.

Das klingt beruhigend. Das obige leider nicht.

Viele Grüße
Wolfgang

Avatar

MLF 1.7.3: Changed to PHP 5.5 -> Special chars bug?

by Auge ⌂, Monday, January 30, 2017, 10:17 (2615 days ago) @ wo2010

Hallo

1. Verbindung mit der Datenbank, explizite Vorgabe der Zeichenkodierung ISO-8859-1 für die Verbindung.

// connects to the database:
function connect_db($host,$user,$pw,$db)
{
// ...
mysql_set_charset("ISO-8859-1", $connid) or die($lang['db_error']); // <= neue Zeile, Funktion ab PHP 5.2.3 verfügbar
// ...
}[/code]


Hab die Zeile ergänzt. Doch kein schöner Erfolg: Die Seite bleibt beim Laden hängen. Ich sah in der Analyse einen Balken bei der board.php, der stehen bleibt. Weitere Komponenten kamen nicht dazu.

Hmm. Lege bitte mal eine PHP-Datei mit dem folgenden Inhalt an, lade sie hoch, rufe sie im Browser auf und melde bitte die Ausgabe zurück.

<?php echo phpversion(); ?>

2. Auslieferung der generierten Seiten

// inc.php, gleich hinter den Copyright-Block und die Festlegung für das Error-Reporting
 
header('Content-type', 'text/html; charset=iso-8859-1');


Bringt sofort die Fehlermeldungen:

The server encountered an internal error or misconfiguration and was unable to complete your request.

Mit dem hinzufügen dieser Zeile wird der Fehler ausgelöst? Kannst du bitte diese Zeile im Code belassen, aber die oben in der Funktion hinzugefügte Zeile weglassen/auskommentieren und dann das Forum noch einmal aufrufen?

More information about this error may be available in the server error log.

Steht da etwas drin?

Jetzt müßte ich wohl gucken, wo das Fehlerprotokoll zu finden ist.

Frage deinen Hoster bzw. schaue in dessen FAQ. Dort steht das typischerweise drin.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

MLF 1.7.3: Changed to PHP 5.5 -> Special chars bug?

by wo2010, Sunday, January 29, 2017, 19:41 (2615 days ago) @ Auge

Hallo,

das Rätsel ist ja leider noch nicht gelöst.

Bei einer Internetsuche stieß ich auf die folgende Seite, wo - so scheint mir - mehr oder weniger dasselbe Problem beschrieben wird:

"Werte mit Umlaut(ä,ü,ö) werden nicht aus Datenbank gelesen"
https://www.tutorials.de/threads/werte-mit-umlaut-ae-ue-oe-werden-nicht-aus-datenbank-gelesen.399...

Falls dort auch die für unsere Situation richtige Lösung gezeigt wird, bitte ich um weitere Hilfe. Mein PHP-/MySQL-Kurs liegt nämlich ca. 18 Jahre zurück ...

Inzwischen bin ich allerdings auch klüger, was die Texteingabe betrifft:

Nicht die Länge ist für das Funktionieren entscheidend, sondern eben auch das (Nicht-)Vorhandensein von Umlauten.

Immer, wenn im Titel und/oder Text ein Umlaut enthalten ist, wird in der Vorschau der entsprechende Teil leer angezeigt _und_ das jeweilige Eingabefeld gelöscht. Ohne Fehlermeldung.

Will ich aus dieser "demolierten" Vorschau heraus speichern, bekomme ich die entsprechenden Leer-Meldungen.

Speichere ich aber meinen Umlaut enthaltenden Eintrag _ohne_ Vorschau, gelangt er anscheinend unbeschadet in die Datenbank. Aber eben per Forum nicht wieder hinaus - wie bei den "alten" Einträgen.

Ich bin jetzt mal ein bißchen hoffnungsvoll
und danke im voraus.

Mit freundlichen Grüßen
Wolfgang

Avatar

MLF 1.7.3: Changed to PHP 5.5 -> Special chars bug?

by Auge ⌂, Monday, January 30, 2017, 10:10 (2615 days ago) @ wo2010

Hallo

Bei einer Internetsuche stieß ich auf die folgende Seite, wo - so scheint mir - mehr oder weniger dasselbe Problem beschrieben wird:

"Werte mit Umlaut(ä,ü,ö) werden nicht aus Datenbank gelesen"
https://www.tutorials.de/threads/werte-mit-umlaut-ae-ue-oe-werden-nicht-aus-datenbank-gelesen.399...

Falls dort auch die für unsere Situation richtige Lösung gezeigt wird, bitte ich um weitere Hilfe.

Das Problem ist das Gleiche, nur das Ziel ein anderes. Dort erfolgt die Verarbeitung und Speicherung offensichtlich mit ISO-8859, die Eingaben sollen aber in UTF-8 erfolgen und auch so behandelt werden. Du willst die Eingaben als ISO-8859-1 behandeln und speichern, die Verarbeitung uns Speicherung erfolgt aber wahrscheinlich als UTF-8.

Die Rollen der Kodierungen sind also vertauscht, ansonsten gleichen sich die Fälle.

Inzwischen bin ich allerdings auch klüger, was die Texteingabe betrifft:

Nicht die Länge ist für das Funktionieren entscheidend, sondern eben auch das (Nicht-)Vorhandensein von Umlauten.

Immer, wenn im Titel und/oder Text ein Umlaut enthalten ist, wird in der Vorschau der entsprechende Teil leer angezeigt _und_ das jeweilige Eingabefeld gelöscht. Ohne Fehlermeldung.

Will ich aus dieser "demolierten" Vorschau heraus speichern, bekomme ich die entsprechenden Leer-Meldungen.

Speichere ich aber meinen Umlaut enthaltenden Eintrag _ohne_ Vorschau, gelangt er anscheinend unbeschadet in die Datenbank. Aber eben per Forum nicht wieder hinaus - wie bei den "alten" Einträgen.

Danke für die hilfreiche Beobachtung.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

MLF 1.7.3: Changed to PHP 5.5 -> Special chars bug?

by wo2010, Tuesday, January 31, 2017, 21:44 (2613 days ago) @ Auge

Hallo Auge,

vielen Dank für die Antworten. Kann mich leider erst wieder in den nächsten Tagen um das Forum kümmern.

Ich weiß übrigens nicht mehr, was ich da gerechnet habe: Der Kurs liegt “nur“ 13 Jahre zurück ; -)

Viele Grüße
Wolfgang

Avatar

MLF 1.7.3: Changed to PHP 5.5 -> Special chars bug?

by Auge ⌂, Wednesday, February 01, 2017, 09:55 (2613 days ago) @ wo2010

Hallo

vielen Dank für die Antworten. Kann mich leider erst wieder in den nächsten Tagen um das Forum kümmern.

Schade, ich warte nun natürlich, wie auf glühenden Kohlen sitzend, auf Rückmeldungen. Ich hoffe, dass wir mit dem gestrigen Vorschlag auf dem richtigen Weg sind.

Ich weiß übrigens nicht mehr, was ich da gerechnet habe: Der Kurs liegt “nur“ 13 Jahre zurück ; -)

:-)

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

MLF 1.7.3: Changed to PHP 5.5 -> Special chars bug?

by wo2010, Friday, February 03, 2017, 00:20 (2611 days ago) @ Auge

Hallo Auge,

Schade, ich warte nun natürlich, wie auf glühenden Kohlen sitzend, auf Rückmeldungen. Ich hoffe, dass wir mit dem gestrigen Vorschlag auf dem richtigen Weg sind.

Verstehe ich.

Leider bisher keine Entwarnung : -((

<?php echo phpversion(); ?>

5.5.38-nmm2

Ein Infoscript für PHP weist aus: default_charset (local and master) "no value".

1. Einstellung in der php.ini.

Sehe ich derzeit keinen Zugang.

2. Eventuell bieten eure Hoster die Möglichkeit, einige der Einstellungen für PHP in einer eigenen php.ini, gerne auch als user.ini, in einem Benutzerverzeichnis zu ändern.

Muss ich fragen. Fühle mich ohnehin gedrängt, ihn hier auf mein Problem zu stubsen.

3. Vorgabe in einer .htaccess im Forumsverzeichnis.

Die gibt's da schon.

AddDefaultCharset ISO-8859-1
php_value default_charset ISO-8859-1

Erste Zeile war schon drin. Zweite ergänzt, aber derzeit keine Verhaltensänderung.

(Da ist außerdem noch ein Block mit Installations(?)-Einträgen bei einem vermutlich früheren Hoster drin:

<Files install.php>
AuthType Basic
AuthName "....................."
AuthUserFile /home/....../www/shared/.htusers
AuthGroupFile /home/....../www/shared/.htgroups
Require group admins
</Files>

Wird das noch gebraucht?)

3. inc.php:

Die beginnt jetzt

# Zur Fehlerbehebung Umlaute (02.02.2017)
ini_set('default_charset', 'ISO-8859-1');
# Zur Fehlersuche (26.01.2017)
ini_set('display_errors', 1);
error_reporting(E_ALL);

Nur die schon erwähnten Fehlermeldungen beim Einloggen ...

Die Suche nach "Problem mit Umlauten ab PHP5.5" lieferte mir einen Eintrag in der FAQ eines Hosters, der eine nachvollziehbare Änderung im PHP-Kern beschreibt.

Dort wird aber anscheinend über (neue?) Befehle ab PHP 5._6_ geschrieben.

Ob ich "einfach"(?) mal auf 5.6 umschalte(n lasse)?

Gute Nacht für gestern.
Wolfgang

Avatar

MLF 1.7.3: Changed to PHP 5.5 -> Special chars bug?

by Auge ⌂, Friday, February 03, 2017, 08:40 (2611 days ago) @ wo2010

Hallo

Danke auch für deine Rückmeldung.

<?php echo phpversion(); ?>


5.5.38-nmm2

Danke.

2. Eventuell bieten eure Hoster die Möglichkeit, einige der Einstellungen für PHP in einer eigenen php.ini, gerne auch als user.ini, in einem Benutzerverzeichnis zu ändern.


Muss ich fragen. Fühle mich ohnehin gedrängt, ihn hier auf mein Problem zu stubsen.

Das Problem wird deines bleiben aber vielleicht tut sich so eine einfache Möglichkeit, dies mit einer Zeile zu lösen, auf. Der Hoster wird, außer, du bist auf dem fraglichen Server der eizige Kunde, deinetwegen ganz bestimmt nicht die Serverkonfiguration anpassen.

AddDefaultCharset ISO-8859-1
php_value default_charset ISO-8859-1


Erste Zeile war schon drin. Zweite ergänzt, aber derzeit keine Verhaltensänderung.

Dann wird wohl auch bei dir eine PHP-Installation als FastCGI und nicht als Apache-Modul laufen. Das hat zumindest bei Sebastian Nast genau deswegen nicht funktioniert.

(Da ist außerdem noch ein Block mit Installations(?)-Einträgen bei einem vermutlich früheren Hoster drin:

Wird das noch gebraucht?)

Es wird meiner Meinung nach nicht von MLF gebraucht. Ich habe solche Zeilen im Kontext MLF zumindest noch nirgendwo gesehen. Ob das eine generelle Vorgabe deines Hosters ist oder für eine andere Anwendung benötigt wird, kann ich natürlich nicht beurteilen.

3. inc.php:


Die beginnt jetzt

# Zur Fehlerbehebung Umlaute (02.02.2017)
ini_set('default_charset', 'ISO-8859-1');
# Zur Fehlersuche (26.01.2017)
ini_set('display_errors', 1);
error_reporting(E_ALL);

Nur die schon erwähnten Fehlermeldungen beim Einloggen ...

Die Suche nach "Problem mit Umlauten ab PHP5.5" lieferte mir einen Eintrag in der FAQ eines Hosters, der eine nachvollziehbare Änderung im PHP-Kern beschreibt.


Dort wird aber anscheinend über (neue?) Befehle ab PHP 5._6_ geschrieben.

Nein, es geht schon umm die Umstellung der Standard Kodierung (default_charset) auf UTF-8 (bei denen mit PHP 5.6) und die dadurch auftretenden Probleme mit alten Skripten, bei denen einige Standardfunktionen für Zeichenketten platzen.

Ob ich "einfach"(?) mal auf 5.6 umschalte(n lasse)?

Ich denke, dass das für diesen Fehlerfall keine Änderungen bringt. Warum auch, die Kodierung wird in PHP 5.6 bestimmt nicht zurückgestellt worden sein.

Ich bitte darum, jenes Posting – auch die darin definierten Voraussetzungen – zu beachten.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

MLF 1.7.3: Changed to PHP 5.5 -> bugs, @Alfie?

by Alfie ⌂, Vienna, Austria, Friday, January 27, 2017, 11:23 (2618 days ago) @ Auge

Hallo Auge,

A question for Alfie: Does you have any of these or similar problems with your beta of 1.8?

Nein – aber meine PHP-Version ist immer noch 5.3.3-7…

--
Cheers,
Alfie (Helmut Schütz)
BEBA-Forum (v1.8β)

Avatar

MLF 1.7.3: Changed to PHP 5.5 -> bugs, @Alfie!

by Auge ⌂, Friday, January 27, 2017, 11:46 (2618 days ago) @ Alfie

Hallo Alfie,

schön, von dir zu lesen. :-)

A question for Alfie: Does you have any of these or similar problems with your beta of 1.8?


Nein – aber meine PHP-Version ist immer noch 5.3.3-7…

Dir sollte das Problem sowieso nicht unterkommen, wenn die Vermutung, dass die Ursache des Problems im Umgang mit der Zeichenkodierung zu suchen ist, zutrifft. Dein Forum ist ja schon auf UTF-8 umgestellt. Meine Vermutung ist nämlich, dass da zumindest teilweise automatische Vorgaben des Systems angewendet werden, die heutzutage typischerweise UTF-8 als Kodierung verwenden.

Ob das – wenn ich denn richtig liege – der MySQL-, der Webserver oder die PHP-Installation ist, ist noch zu ermitteln.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Nochmal zum Problem mit den Umlauten bei PHP 5.5

by Sebastian Nast, Tuesday, January 31, 2017, 10:43 (2614 days ago) @ wo2010

Hallo zusammen,

ich betreibe nun seit fast 10 Jahre das MB-Exotenforum ... eingerichtet 2007 ...

http://nast-sonderfahrzeuge.de/MB-Exotenforum/forum.php

... und bisher auch immer völlig problemlos.:ok:

Da jetzt auch mein Provider (All-Incl) die Unterstützung für PHP 5.2-5.4
einstellt, bin ich also gezwungen meine Seite auf min. PHP 5.5 umzuschalten.

Ich habe das mal probehalber gemacht, und da gabs dann im Forum auch das
Problem, das alle Threads und alle Postings in dehnen Umlaute ä, ö ,ü vorkommen
einfach nicht mehr angezeigt werden. Aber eben nicht nur das Wort mit
Umlaut wird nicht mehr angezeigt, sondern der ganze Post, bzw. der ganz
Thread sind einfach leer !?! :-(

z.Z läuft meien Seite mit der PHP-Version 5.2 ( als Apache-Modul)
aber schon mit der PHP-Version "5.2 ( als CGI/FPM)" gibts die Probleme
mit den Umlauten !?!? Und bei PHP 5.5 und 5.6 gibt es nur noch diese
"CGI/FPM" Version zum Auswahl, was auch immer das heißt ... :-)

Gibts da einen Lösungsansatz, das auch Texte mit Umlauten wieder
unter 5.5 ( als CGI/FPM)angzeigt werden, auch für einen nicht
IT-Experten wie mich ? ;-)

Gruß
Sebastian Nast

Avatar

Nochmal zum Problem mit den Umlauten mit Nachtrag

by Auge ⌂, Tuesday, January 31, 2017, 11:36 (2614 days ago) @ Sebastian Nast
edited by Auge, Tuesday, January 31, 2017, 17:43

Hallo

Ich habe deinen Eintrag mal an den hiesigen Thread gehängt, weil es das selbe Problem ist.

[Umstellung auf mind. PHP 5.5]

Ich habe das mal probehalber gemacht, und da gabs dann im Forum auch das
Problem, das alle Threads und alle Postings in dehnen Umlaute ä, ö ,ü vorkommen
einfach nicht mehr angezeigt werden. Aber eben nicht nur das Wort mit
Umlaut wird nicht mehr angezeigt, sondern der ganze Post, bzw. der ganz
Thread sind einfach leer !?! :-(

Wie du hier bestimmt schon gelesen hast, haben die ersten Versuche, das Problem zu beheben, nicht gefruchtet. Die Suche nach "Problem mit Umlauten ab PHP5.5" lieferte mir einen Eintrag in der FAQ eines Hosters, der eine nachvollziehbare Änderung im PHP-Kern beschreibt.

Das Problem ist, wie ich schon vermutete, die Umstellung der Standardkodierung auf UTF-8, womit die ISO-kodierten Umlaute nicht mehr funktionieren. Der FAQ-Eintrag gibt als Lösung an, die vorgegebene Kodierung für die Anwendung fest auf ISO-8859-1 einzustellen.

Weitere Recherchen führten mich zu mehreren Ansätzen.

1. Einstellung in der php.ini. Das wird bei Shared-Hosting-Angeboten typischerweise nicht möglich sein. Nähreres dazu bitte beim eigenen Hoster erfragen.

2. Eventuell bieten eure Hoster die Möglichkeit einige der Einstellungen für PHP in einer eigenen php.ini, gerne auch als user.ini, in einem Benutzerverzeichnis zu ändern. Auch hierzu bitte mal den Hoster fragen.

php.ini (oder wie auch immer sie heißt):

default_charset = "ISO-8859-1"

3. Vorgabe in einer .htaccess im Forumsverzeichnis. Leider sind nicht bei allen Hostern alle möglichen Features in der .htaccess nutzbar. Die obige Angabe sollte aber entweder funktionieren oder einen Fehler mit HTTP-Status 500 auslösen. Bitte mal ausprobieren.

.htaccess:

AddDefaultCharset ISO-8859-1
php_value default_charset ISO-8859-1

[edit]Korrektur des von Alfie gefundenen falschen Dateinamens im nächsten Absatz. Die Datei heißt inc.php.[/edit]

4. Setzen der Angabe beim Skriptstart. Die Angabe ist, wenn ich nicht falsch liege, in der inc.php des Forums zu setzen, da die überall eingebunden.

inc.php:

ini_set('default_charset', 'ISO-8859-1');

Ich hoffe, dass mit einem der Ansätze (je nachdem, welcher möglich ist) die Seiten zumindest vollständig, wenn vielleicht auch mit krüppeligen Umlauten, ausgegeben wird. Ich halte den dritten Ansatz mit der .htaccess am vielversprechendsten. Die Einstellung wäre so bereits mit dem Skriptstart vorhanden und ich gehe zudem davon aus, dass die meisten Hoster diese Angabe erlauben.

Wenn das klappt, können wir weiter sehen. Ich bitte um Rückmeldung.

Was mich nun überhaupt nicht mehr wundert, ist die Tatsache, dass weder Alfies Forum noch mein (abgeschaltetes) davon betroffen sind. Seines läuft noch auf PHP 5.3, meines mit PHP 5.6, aber beide laufen mit (unterschiedlich alten) Testversionen, die UTF-8-Unterstützung haben.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

Nochmal zum Problem mit den Umlauten mit Nachtrag

by Alfie ⌂, Vienna, Austria, Tuesday, January 31, 2017, 15:25 (2614 days ago) @ Auge
edited by Alfie, Tuesday, January 31, 2017, 19:32

Die Angabe ist, wenn ich nicht falsch liege, in der ini.php des Forums zu setzen, da die überall eingebunden.

ini.php:

ini_set('default_charset', 'ISO-8859-1');

In den Versionen <2 heisst das Teil inc.php.

--
Cheers,
Alfie (Helmut Schütz)
BEBA-Forum (v1.8β)

Avatar

Nochmal zum Problem mit den Umlauten mit Nachtrag

by Auge ⌂, Tuesday, January 31, 2017, 17:39 (2614 days ago) @ Alfie

Hallo

Die Angabe ist, wenn ich nicht falsch liege, in der ini.php des Forums zu setzen, da die überall eingebunden.

ini.php:

ini_set('default_charset', 'ISO-8859-1');


In the Versionen <2 heisst das Teil inc.php.

Ja. Und ich sollte das wissen.

Danke für die Korrektur.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Nochmal zum Problem mit den Umlauten - Und die Lösung

by Sebastian Nast, Thursday, February 02, 2017, 10:48 (2612 days ago) @ Auge

Hallo zusammen,

also ich, als nicht IT-Spezie, war mit dem Problem völlig überfordert.
Aber zum Glück haben wir in unserem Autoforum einen Kollegen der
nicht nur Mercedes-Fan ist, sondern auch beruftlicher IT-Experte.

Der hat das wieder hin bekommen. :ok:

Hier mal seine Antwort, was er gemacht, ich verstehe davon zwar kein
Wort, aber jedenfalls geht wieder alles ... :-)

"Soooo sollte nun alles wieder gehen
Also nach einigem gesuche lag es letztendlich an einer PGP Funkion „htmlspecialchars“

Diese Funktion ist vor JEDER Ausgabe in allen Dateien für das Forum eingebaut… Sie übersetzt sonderzeichen (ä) durch den entsprechenden HTML Code (&auml;) … Allerdings wurde die Default Value mal beim Wechsel zu PHP 5.3 umgestellt, früher war es latin und seitdem dann UTF-8… Da die Funktion also einen UTF8-Zeichensatz erwartet, aber stattdessen einen latin Zeichensatz bekommt, hat sie Probleme damit, weil sie das Format der Sonderzeichen nicht kennt…

Ich habe die Funktionsaufrufe nun so umgeschrieben, das er einen latin Zeichensatz (iso-8859-1) forciert. Also der Aufruf ist nun htmlspecialchars(<string>,ENT_COMPAT,'ISO-8859-1'). Damit wird eine latin Zeichenketter erwartet und dann geht wieder alles. Dummerweise kann man das nicht irgendwo als Default setzen… und so habe ich in allen Scripten jegliche Vorkommnisse der Funktion angepasst, waren auf jeden Fall über 500 :D"

Gruß
Sebastian Nast

Avatar

Nochmal zum Problem mit den Umlauten - Und die Lösung

by Auge ⌂, Thursday, February 02, 2017, 11:11 (2612 days ago) @ Sebastian Nast
edited by Auge, Thursday, February 02, 2017, 12:39

Hallo

also ich, als nicht IT-Spezie, war mit dem Problem völlig überfordert.
Aber zum Glück haben wir in unserem Autoforum einen Kollegen der
nicht nur Mercedes-Fan ist, sondern auch beruftlicher IT-Experte.

Der hat das wieder hin bekommen. :ok:

Ich befürchte, dass der Schein trügt. :-(

Meine Anmerkungen sind bitte nicht als Kritik, sondern als Richtigstellungen und Anregungen zu verstehen.

"Soooo sollte nun alles wieder gehen
Also nach einigem gesuche lag es letztendlich an einer PGP Funkion „htmlspecialchars“

Nein, an der Funktion selbst liegt es, wie ich später ausführen werde, nicht.

Diese Funktion ist vor JEDER Ausgabe in allen Dateien für das Forum eingebaut… Sie übersetzt sonderzeichen (ä) durch den entsprechenden HTML Code (&auml;)

Nein, die Funktion htmlspecialchars übersetzt zwar Sonderzeichen (im Kontext von HTML) aber nicht die Umlaute. Sonderzeichen sind <, > & sowie, wenn die entsprechenden Schalter gesetzt sind, " und '. Die Umlaute ersetzen würde die Funktion htmlentities. Die benutzen wir aber nicht.

Was allerdings zutrifft, ist der Umstand, dass die Umlaute durch die Umstellung der von PHP benutzten Standardkodierung auf UTF-8 die Skriptausführung stören und beenden. Die Beschreibung …

… Allerdings wurde die Default Value mal beim Wechsel zu PHP 5.3 umgestellt, früher war es latin und seitdem dann UTF-8… Da die Funktion also einen UTF8-Zeichensatz erwartet, aber stattdessen einen latin Zeichensatz bekommt, hat sie Probleme damit, weil sie das Format der Sonderzeichen nicht kennt…

… trifft also im Großen und Ganzen zu.

… Ich habe die Funktionsaufrufe nun so umgeschrieben, das er einen latin Zeichensatz (iso-8859-1) forciert. Also der Aufruf ist nun htmlspecialchars(<string>,ENT_COMPAT,'ISO-8859-1').

Zielführende Lösung an der falschen Stelle.

Dummerweise kann man das nicht irgendwo als Default setzen…

Doch das kann man und ich habe hier mehrere Ansätze beschrieben und um einen Test gebeten.

Alle diese Lösungen haben nämlich einen relevanten Vorteil gegenüber der Lösung deines Forumsmitgliedes. Sie gelten für den gesamten Skriptablauf aller zum Forum gehörenden Skripte. Es ist nämlich grundsätzlich keineswegs ausschließlich die Funktion htmlspecialchars betroffen. Es könnten noch weitere Stellen hochkommen, die nicht so oft aufgerufen werden und bei denen der Fehler nicht sofort auffällt.

Ich bitte also nochmals um einen Test (bevorzugt der dritten Lösung mit der .htaccess im Verzeichnis des Forums). Die Änderungen deines Mitstreiters sollten an der Stelle keine Probleme machen.

[edit]Die Änderungen beim Aufruf sollten zwar nicht stören, mit ihnen gibt es allerdings keinen Unterschied zwischen eingebauter oder nicht vorhandener .htaccess. Daher ist es sinnvoll, den Aufruf mit .htaccess mit einem Backup des Skripts im Zustand vor dem Umbau des Funktionsaufrufs von htmlspecialchars zu testen.

Weiterhin bitte ich auch um Tests durch andere Betroffene, um eventuell vorhandene Unterschiede in den Serverkonfigurationen zu erkennen.[/edit]

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Nochmal zum Problem mit den Umlauten - Und die Lösung

by Sebastian Nast, Thursday, February 02, 2017, 21:04 (2611 days ago) @ Auge

Hier nomal die Antwort von meinem IT-Spezie ... :-)

Nein, die 4 Möglichkeiten aus dem anderen Thread gingen bei dir nicht!
Das hatte ich natürlich alles vorher ausprobiert

Die .htaccess mit den Angaben ist auch noch auf dem Server, das hatte keinerlei Änderung gemacht, und auch die anderen Möglichkeiten über ini_set('default_charset', 'ISO-8859-1'); usw haben eben leider nicht funktioniert, das wäre ja schön gewesen. Daher musste ich es über diesen unschönen Workaround machen

Ich habe die entsprechende .htaccess nun auch in /forum_archiv/ gelegt, und auch hier geht es nicht, auch die anderen Lösungen werden dort nicht klappen. Und hier stehen auch ein paar Sachen darüber, das man es eben nicht global setzen kann

http://php.net/manual/de/function.htmlspecialchars.php

As of PHP 5.4 they changed default encoding from "ISO-8859-1" to "UTF-8". So if you get null from htmlspecialchars or htmlentities

Unfortunately, as far as I can tell, the PHP devs did not provide ANY way to set the default encoding used by htmlspecialchars() or htmlentities(), even though they changed the default encoding in PHP 5.4 (*golf clap for PHP devs*). To save someone the time of trying it, this does not work:

<?php
ini_set('default_charset', $charset); // doesn't work.
?>

Unfortunately, the only way to not have to explicitly provide the second and third parameter every single time this function is called (which gets extremely tedious) is to write your own function as a wrapper:

Also das Problem, welches durch diese Änderungen aus dem Thread behoben werden kann, ist wie es ausssieht ein anderes Problem als das, welches bei deinem Forum die Probleme machte

Gruß
Sebastian

Avatar

Nochmal zum Problem mit den Umlauten - Und die Lösung

by Auge ⌂, Thursday, February 02, 2017, 21:40 (2611 days ago) @ Sebastian Nast

Hallo

Danke für deine Rückmeldung.

Nein, die 4 Möglichkeiten aus dem anderen Thread gingen bei dir nicht!
Das hatte ich natürlich alles vorher ausprobiert

Gut, wäre schön gewesen, das schon vorher zu erfahren. Wenn du selbst die Info erst jetzt bekommen hast, ging das natürlich nicht.

Die .htaccess mit den Angaben ist auch noch auf dem Server, das hatte keinerlei Änderung gemacht, und auch die anderen Möglichkeiten über ini_set('default_charset', 'ISO-8859-1'); usw haben eben leider nicht funktioniert

So, ich habe nochmal die Suchmaschine meiner Wahl angeschmissen. Mir schwob im Hinterkopf herum, dass die Lösung, die PHP-Konfiguration per .htaccess zu manipulieren, nicht in jeder Installation funktioniert (Apache Modul vs. CGI/FastCGI). Und siehe da, mit PHP als Apache Modul geht es, als CGI/FastCGI geht's nicht.

Relevante Stelle des verlinkten Textes: "What you cannot do is put PHP directives inside .htaccess: this works only with PHP installed as an Apache module and would cause a 500 Server error with PHP installed as either CGI or FastCGI."

Hat jemand eine PHP-Installation als Apache-Modul auf seinem Server oder Webspace, kann er den Weg über .htaccess probieren. Ich würde mich über Rückmeldungen freuen. Da allerdings PHP als Apache Modul einigen Aufwand bei der Sicherung erfordert (ohne weitere Konfiguration laufen PHP-Skripte mit den Benutzerrechten des Webservers), wird von den Hostern aber verstärkt auf FastCGI gesetzt – PHP als CGI (ohne "Fast") ist hingegen quasi tot –, was dazu führt, dass man, solange die eigene MLF1-Installation keine UTF-8-Unterstützung hat, auf die Anpassung aller Funktionsaufrufe angewiesen ist. Mit einem Editor, der dateiübergreifendes Suchen-und-Ersetzen mit regulären Ausdrücken beherrscht, ist das aber, wenn auch aufwändig, so doch kein Hexenwerk.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

Ein Angebot

by Auge ⌂, Thursday, February 02, 2017, 22:22 (2611 days ago) @ wo2010

Hallo

Im Laufe der Diskussion dieses Threads sind einige Umstände klar hervorgetreten.

1. Das Problem ist die in MLF1 verwendete Kodierung (in Mittel- und Westeuropa ISO-8859-1 oder -15), die durch die nunmehr in PHP benutzte Standardkodierung UTF-8 zu Fehlern führt.
2. Nur bei PHP-Installationen als Apache-Modul kann die Festlegung der Kodierung einfach per .htaccess geändert werden.
3. Eine Lösung für PHP-Installationen als FastCGI, abseits der Anpassungen der Funktionsaufrufe, ist noch nicht bekannt. Eventuell bietet die mit PHP 5.3 eingeführte user.ini einen Ansatz. Mangels passender Installation konnte das bisher aber nicht getestet werden.
4. Die von mir von Alex übernommene Weiterentwicklung am MLF1-Zweig ist vor mehr als drei Jahren praktisch zum erliegen gekommen.
5. Der von Alex übernommene Stand mit der Version 1.7.6, der das Kodierungeproblem selbst auch hat, ist in meinem Repository weiterhin verfügbar.
6. Der Einbau und die Benutzung von Wrapper-Funktionen, die das Problem umgehen, sowie der Einbau einiger Bugfixes, die keine Brüche in Sachen Kodierung verursachen, in diesen Stand ist möglich. Allerdings ist das nicht mal in ein oder zwei Tagen erledigt.
7. Selbst eine neue Version, die das Problem umgeht, ist auf Dauer keine Lösung. Ziel muss eine Software mit UTF-8-Unterstützung sein, wie sie ja, wenn auch weitgehend unfertig, in Grundzügen vorliegt.

Achtung! Der hier drüber verlinkte Stand ist nicht installierbar!

Bevor ich aber anfange, Arbeit in die Ertüchtigung von MLF1 zu stecken, möchte ich wissen, ob es überhaupt ein Interesse daran gibt. Einerseits habe auch ich ein echtes Leben und andererseits bin ich momentan mit der Version 2.4 und einem responsiven Template für diese Version nicht unswesentlich ausgelastet. Ohne glaubwürdiges Interesse und ein wenig Hilfe werde ich mir diese zusätzliche Aufgabe nicht antun.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Ein Angebot

by wo2010, Friday, February 03, 2017, 14:54 (2611 days ago) @ Auge

Hallo Auge,

vielen Dank Dir und auch den anderen Helfern für die Mühen. Darf man sich wundern, daß nicht viel öfter über dieses Problem gestolpert wurde - bei derart einschneidender Konsequenz von Aktualisierung? Aber egal.

Ich danke auch für Dein Überlegungen, unter bestimmten Bedingungen MLF1 wieder auf's universelle Gleis zu bringen.

Um mir selbst sicher zu sein, was _ich_ jetzt möchte, müßte ich abschätzen, was für MLF1 und vielleicht gegen MLF2 spricht. Falls wir diese Option überhaupt haben. Ein eventuelles Upgrade wurde bisher nicht verfolgt, weil ich neben dem (wohl immer zu kurz geschätzten) Zeitbedarf auch ein fachliches Scheitern nicht ausschließen wollte.

Wenn Ihr selbst eine Zeit lang die Version 1 weiterentwickelt habt, dann hatte das doch Gründe. Für Links auf eine Pro-/Kontra-Diskussion wäre ich dankbar.

Ein Weg könnte also die Flucht nach vorn sein. Bekäme ich das denn hin mit diesem invaliden 1.7.3 als Basis? (Nach meiner Erinnerung waren da Zwischenschritte notwendig.)

Andererseits scheint die Slow-and-dirty-Lösung per Suchen/Ersetzen eine (zugegebenermaßen nervige) Fleißarbeit zu sein, die aber das baldige Aufatmen der Nutzergemeinde verheißt. Natürlich nur, wenn es keine zu berücksichtigenden grammatikalischen Fälle gibt wie bei "Dr. Murkes gesammeltem Schweigen" von Heinrich Böll ...

Hilfe will ich gern anbieten, wenn es sich um "angeleitete Tätigkeiten" oder Tests handelt. Erfahrung mit Z80-Assembler wird hier nichts bringen ; -)

Viele Grüße
Wolfgang

PS: Ich habe anscheinend das Bedingungsgefüge von "E-mail notification on reply of this posting" noch nicht richtig erfasst, deshalb auch den anderen Lösungsstrang zu spät bemerkt.

Avatar

Ein Angebot

by Auge ⌂, Friday, February 03, 2017, 19:07 (2610 days ago) @ wo2010

Hallo

Darf man sich wundern, daß nicht viel öfter über dieses Problem gestolpert wurde - bei derart einschneidender Konsequenz von Aktualisierung?

Viele Betreiber von MLF1-Installationen sind zu MLF2 gewechselt, als es inklusive Migrationstools verfügbar war. Nicht wenige sind auch auf andere Software gewechselt, wie auch hier in älteren Threads mit der Frage nach dem Import der Daten von MLF2 in andere Foren/Boardlösungen zu erkennen ist. Sicher haben auch einige Betreiber ihre Foren geschlossen. Es gibt hingegen nur wenige Betreiber, die über die Jahre bei MLF1 geblieben sind.

Um mir selbst sicher zu sein, was _ich_ jetzt möchte, müßte ich abschätzen, was für MLF1 und vielleicht gegen MLF2 spricht.

Das System von MLF1 ist weniger komplex als MLF2. Ein Eingriff in den Quellcode ist meiner Meinung nach etwas einfacher, auch wenn ich zugeben muss, dass ich den gesamten Code zuerst umformatierun musste, um ihn für mich lesbarer zu machen.

In MLF2 gibt es diverse Plugins aus externen Quellen, die hin und wieder, unabhängig von MLF selbst, gepflegt werden müssen. Das findet wohl meist nicht statt, so dass Lücken in den Plugins nur dann geschlossen werden, wenn neue Versionen von MLF2 neue Versionen der Plugins mit ausliefert. Solche Abhängigkeiten von Plugins gibt es bis zu Alex' letzter Version 1.7.6 in MLF1 nicht.

Es sind in MLF2 andererseits mittlerweile – auch durch die neben angesprochenen Plugins – eine Reihe von Features enthalten, die es in MLF1 nicht oder nur in meinem Entwicklungscode gibt.

Ob sich ein Umstieg lohnt, liegt, abseits des nun akut aufpoppenden Problems, an den Anforderungen und Featurewünschen. Einfach "Ja" oder "Nein" dazu sagen kann ich stante pede auch nicht.

Wenn Ihr selbst eine Zeit lang die Version 1 weiterentwickelt habt, dann hatte das doch Gründe. Für Links auf eine Pro-/Kontra-Diskussion wäre ich dankbar.

Wenn du einen Haufen Muße haben solltest, könntest du dich durch die Threads aus der Anfangszeit dieses Forums wühlen. Damals gab es dazu einge (vorwiegend technisch begründete) Diskussionen. Es ging unter anderem um anders und für einzelne auf unerwünschte Weise funktionierende Features, eine stärkere Abhängigkeit von JavaScript, die von manchen als zu viel Spielerei gesehen wurde und um die durch Smarty und die Plugins gestiegene Komplexität.

Ein Weg könnte also die Flucht nach vorn sein. Bekäme ich das denn hin mit diesem invaliden 1.7.3 als Basis? (Nach meiner Erinnerung waren da Zwischenschritte notwendig.)

Die Tatsache, dass dein Forum akut nicht funktioniert, sollte kein Hindernis darstellen, solange die Daten unversehrt in der Datenbank bzw. einem Backup der Datenbank liegen. Aber ja, der Umstieg auf eine aktuelle Version des 2-er Zweigs bedarf einiger Zwischenschritte, die ich allerdings nicht in Gänze kenne, da ich selbst nie einen solchen Umzug durchgeführt habe. So weicht die Datenbankstruktur in MLF2 von der in MLF1 ab, was durch Updatskripte angeglichen werden muss. Solche Skripte wurden von Alex zum Download angeboten, ich weiß allerdings nicht, ob und wenn ja wo die noch verfügbar sind.

Andererseits scheint die Slow-and-dirty-Lösung per Suchen/Ersetzen eine (zugegebenermaßen nervige) Fleißarbeit zu sein, die aber das baldige Aufatmen der Nutzergemeinde verheißt.

Ich glaube, dass das in ein paar Stunden machbar ist. Meine Freundin muss die mir nur geben. ;-)

Hilfe will ich gern anbieten, wenn es sich um "angeleitete Tätigkeiten" oder Tests handelt.

Es ginge um Tests.

Erfahrung mit Z80-Assembler wird hier nichts bringen ; -)

Nö, ich glaube das brächte tatsächlich nichts. So alt ist MLF1 nun doch nicht. :-)

PS: Ich habe anscheinend das Bedingungsgefüge von "E-mail notification on reply of this posting" noch nicht richtig erfasst, deshalb auch den anderen Lösungsstrang zu spät bemerkt.

Ich weiß das ehrlich gesagt auch nicht, weil ich mich nicht per Email informieren lasse. :confused:

Schau ich doch mal in den Code. … Grundsätzlich wird, wenn aktiviert, der Autor des Vorpostings informiert. Zusätzlich wird, ebenfalls, wenn aktiviert, der Autor des Eröffnungspostings informiert. Aber in diesem Thread gibt es eine Besonderheit. Der Ast, der mit Sebastians erstem Posting beginnt, wurde von ihm als eigenständiger Thread gestartet und von mir in deinen Thread eingehängt. Es ist durchaus möglich, dass dies ein un- oder nicht ausreichend berücksichtigter Spezialfall ist.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Ein Angebot

by wo2010, Saturday, February 04, 2017, 00:13 (2610 days ago) @ Auge

Hallo Auge,

danke für die Ausführungen.

Das System von MLF1 ist weniger komplex als MLF2.

In MLF2 gibt es diverse Plugins aus externen Quellen, die hin und wieder, unabhängig von MLF selbst, gepflegt werden müssen. [...] Solche Abhängigkeiten von Plugins gibt es bis zu Alex' letzter Version 1.7.6 in MLF1 nicht.

Es sind in MLF2 andererseits mittlerweile – auch durch die neben angesprochenen Plugins – eine Reihe von Features enthalten, die es in MLF1 nicht oder nur in meinem Entwicklungscode gibt.

Ich neige momentan dazu, erst einmal wieder 1.7 laufen sehen zu wollen. Gern auch als 1.7.6.

Andererseits scheint die Slow-and-dirty-Lösung per Suchen/Ersetzen eine (zugegebenermaßen nervige) Fleißarbeit zu sein.


Ich glaube, dass das in ein paar Stunden machbar ist.

Ich habe mal WinGrep über mein Programm-Backup laufen lassen und komme auf knapp 250 Exemplare von "htmlspecialchars". Die sehen allerdings doch verschiedener aus als erhofft.

Die bei Sebastian eingebaute Hilfskonstruktion "htmlspecialchars(<string>,ENT_COMPAT,'ISO-8859-1')" scheint sicherheitstechnisch etwas risikobehaftet zu sein (siehe https://d-mueller.de/blog/htmlspecialchars-richtig-nutzen-fallstricke/, da wird als Konstante ENT_QUOTES empfohlen).

Die an dieser Verweisstelle empfohlene Wrapper-Funktion hat Charme, soweit ich das überblicken kann.

Und um es nicht zu verschweigen: Internationale Zeichen im Text wären natürlich auch nicht schlecht. (Schade, daß ich zu wenig davon verstehe.)

Gute Nacht
Wolfgang

Avatar

Die Aussage des verlinkten Blogbeitrags ist falsch!

by Auge ⌂, Sunday, February 05, 2017, 14:14 (2609 days ago) @ wo2010
edited by Auge, Monday, February 06, 2017, 07:58

Hallo

Die bei Sebastian eingebaute Hilfskonstruktion "htmlspecialchars(<string>,ENT_COMPAT,'ISO-8859-1')" scheint sicherheitstechnisch etwas risikobehaftet zu sein (siehe https://d-mueller.de/blog/htmlspecialchars-richtig-nutzen-fallstricke/, da wird als Konstante ENT_QUOTES empfohlen).

Nur, um das klarzustellen. Das in dem Blogbeitrag skizzierte Fehlerszenario ist Bullshit! Ja, in einem Benutzernamen kann es, wie dort angesagt, ein Hochkomma geben, das einen Datenbankquery platzen lässt. Aber die dargelegte Lösung schießt meilenweit am Ziel vorbei.

Die Funktion htmlspecialchars ist dazu da, Texte für deren Ausgabe als Bestandteil eines HTML-Dokuments aufzubereiten. Sie ist nicht für die Aufbereitung von Datenbankqueries da. Dazu gibt es die Funktionen mysql_real_escape_string (alte Schnittstelle), mysqli_real_escape_string (neue Schnittstelle) bzw. Features der PDO-Schnittstelle [edit](Prepared Statements)[/edit], welche die Daten explizit für die Benutzung im MySQL-Kontext aufbereiten.

Die Lösung aus dem Blogbeitrag entschärft zwar das einfache Anführungszeichen/Hochkomma, andere für MySQL relevante Zeichen aber nicht. Die Lösung wiegt den Leser somit in trügerischer Sicherheit und sorgt zudem dafür, dass betroffene Zeichenketten mit dem maskierten Hochkomma statt im Rohzustand, den sie bei Benutzung der für MySQL gedachten Funktionen hätten, in der Datenbank liegen.

Wenn der Autor das als Lehrbeauftragter an der Hochschule Darmstadt, der er zu sein angibt, heute noch seinen Studenten vermittelt, ist das eine große Sicherheitslücke.

Screenshot vom 05.02.2017, 15:02 Uhr MEZ:

[image]

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Codierungs-Turbulenzen

by wo2010, Monday, February 06, 2017, 17:26 (2608 days ago) @ Auge
edited by wo2010, Monday, February 06, 2017, 18:12

Hallo Auge,

Nur, um das klarzustellen. Das in dem Blogbeitrag skizzierte Fehlerszenario ist Bullshit!

da dachte ich nun (für mich): Ein blindes Huhn findet auch mal ein Korn ; -)

Ich weiß viel zu wenig, um das alles richtig würdigen und werten zu können. Hier ist auch nicht die Stelle, um meine mangelhaften PHP-Kenntnisse zu vertiefen.

Die Lösung aus dem Blogbeitrag entschärft zwar das einfache Anführungszeichen/Hochkomma, andere für MySQL relevante Zeichen aber nicht.

Hm, ich hatte mich in dem kritisierten Blogbeitrag "htmlspecialchars richtig nutzen – Fallstricke" (bei meiner ersten Linkangabe war leider das Komma mit reingerutscht) auf den hinteren Abschnitt "Encoding" gestürzt, der ja der vermeintlichen oder tatsächlichen Reparatur "unseres Problems" durch Sebastian & Co. am nahesten kam.

Ich muß noch einmal darauf zurück kommen. Unter "Encoding" (wie allerdings auch im davorliegenden Abschnitt "Das verflixte Hochkomma") wird die Verwendung von ENT_QUOTES statt ENT_COMPAT empfohlen. Das habe ich ja auch so umgesetzt - in der Annahme, die (vielleicht nur wenig) bessere Variante zu benutzen.

Rein äußerlich scheint auch alles ok. Wenn ich allerdings phpMyAdmin benutze oder in den SQLDump gucke, sieht die Sache schon sehr verschieden aus. Ich vergleiche mal den Inhalt bei Einträgen _vor_ und _nach_ meinem Reparaturversuch.

Textbeispiel: 'Hochkomma' "Anführung"

- phpMyAdmin
vorher: \'Hochkomma\' \"Anführung\"
nachher: 'Hochkomma' "Anführung"

- SQLDump
vorher: \\\'Hochkomma\\\' \\\"Anführung\\\"
nachher: \'Hochkomma\' \"Anführung\"

Da werden wohl ggf. die Backslashes mitcodiert.

Welche Variante ist/wäre denn nun "richtig"? Doch ENT_COMPAT?

Dank und viele Grüße
Wolfgang

Avatar

Codierungs-Turbulenzen

by Auge ⌂, Monday, February 06, 2017, 18:48 (2607 days ago) @ wo2010
edited by Auge, Monday, February 06, 2017, 18:57

Hallo

Nur, um das klarzustellen. Das in dem Blogbeitrag skizzierte Fehlerszenario ist Bullshit!


da dachte ich nun (für mich): Ein blindes Huhn findet auch mal ein Korn ; -)

Wenn du nicht selbst programmierst, musst du dich natürlich auf Aussagen anderer verlassen. Dir bleibt ja nichts anderes übrig. Von daher ist es kein Problem, dass du diese Quelle nanntest.

Die Lösung aus dem Blogbeitrag entschärft zwar das einfache Anführungszeichen/Hochkomma, andere für MySQL relevante Zeichen aber nicht.


Hm, ich hatte mich in dem kritisierten Blogbeitrag "htmlspecialchars richtig nutzen – Fallstricke" (bei meiner ersten Linkangabe war leider das Komma mit reingerutscht) auf den hinteren Abschnitt "Encoding" gestürzt, der ja der vermeintlichen oder tatsächlichen Reparatur "unseres Problems" durch Sebastian & Co. am nahesten kam.

Die Wrapper-Funktion an sich passt schon. Die hat Sebastian so ähnlich wie du und auch Gestern ich eingebaut. Und, um das klarzustellen, statt ENT_COMPAT das weitergehende ENT_QUOTES zu verwenden, ist nicht falsch. Falsch ist das dort vorgestellte Szenario, mit htmlspecialchars inklusive ENT_QUOTES MySQL-Eingaben mit Anführungszeichen jeglicher Couleur maskieren zu wollen.

Verwirrend ist das der Aussage des Rests des Blogbeitrags widersprechende Ende. Dort wird nämlich korrekterweise doch auf mysql_real_escape_string und seine Geschwister verwiesen.

Ich muß noch einmal darauf zurück kommen. Unter "Encoding" (wie allerdings auch im davorliegenden Abschnitt "Das verflixte Hochkomma") wird die Verwendung von ENT_QUOTES statt ENT_COMPAT empfohlen. Das habe ich ja auch so umgesetzt - in der Annahme, die (vielleicht nur wenig) bessere Variante zu benutzen.

Falsch ist das, wie gesagt, nicht.

Rein äußerlich scheint auch alles ok. Wenn ich allerdings phpMyAdmin benutze oder in den SQLDump gucke, sieht die Sache schon sehr verschieden aus.

Ja, das ist ein generelles Leiden von MLF1 bis inklusive 1.7.7.

Ich vergleiche mal den Inhalt bei Einträgen _vor_ und _nach_ meinem Reparaturversuch.

Du vermischst hier mehrere Baustellen. Dein "Reparaturversuch" setzt richtigerweise bei der Generierung der HTML-Ausgabe an. Zu diesem Zeitpunkt hat das Skript die Daten bereits aus der Datenbank abgefragt. Alles, was mit SQL zu tun hat, ist schon geschehen und vorbei.

Textbeispiel: 'Hochkomma' "Anführung"

- phpMyAdmin
vorher: \'Hochkomma\' \"Anführung\"
nachher: 'Hochkomma' "Anführung"

Korrekt. Wobei das Leiden von MLF1 dafür sorgt, dass die Daten tatsächlich mit den Backslashes in der Datenbank liegen. Davon siehst du in phpMyAdmin nur nichts.

- SQLDump
vorher: \\\'Hochkomma\\\' \\\"Anführung\\\"
nachher: \'Hochkomma\' \"Anführung\"

Da werden wohl ggf. die Backslashes mitcodiert.

Ja. Ein Anführungszeichen – nehmen wir mal das einfache – wird für die Übergabe an die Datenbank im Query mit einem Backslash maskiert (\'). Ein Backslash selbst wird wiederum selbst mit einem Backslash maskiert. Andere relevante Zeichen werden ebenfalls so behandelt. Das macht die Funktion mysql_real_escape_string. Die zusätzliche unnötige Doppelung, die besonders bei Zitaten auftritt, stammt aus der fehlerhaften Behandlung der Eingaben beim erstellen von Postings.

Das alles hat aber nichts mit unserem Problem zu tun.

Die Funktion htmlspecialchars ist für die Maskierung von für HTML relevanten Zeichen in einer HTML-Ausgabe zuständig. Sie maskiert, wie ich schon einmal auflistete, die Zeichen < (wird zu &lt;), > (wird zu &gt;), & (wird zu &amp;), " (wird zu &quot;) und, wenn es aktiviert ist, das einfache Anführungszeichen/Hochkomma ' (wird in HTML 4 und XHTML 1 zu &#039; und in HTML5 zu &apos;). Für den letzten Fall muss natürlich auch die HTML-Version angegeben werden. Wir nutzen in MLF1 noch XHTML1. Der Funktionsaufruf muss also vollständig so lauten: htmlspecialchars($string, ENT_QUOTES | ENT_XHTML, 'ISO-8859-1');. Statt 'ISO-8859-1' kann man auch, wie ich es gemacht habe, $lang['charset'] einsetzen, nachdem man global $lang; in der ersten Zeile der Funktion notiert hat.

Welche Variante ist/wäre denn nun "richtig"? Doch ENT_COMPAT?

Behalte dein ENT_QUOTES. Das hat, wie ich hoffentlich verständlich ausführte, mit deiner Beobachtung nichts zu tun. Das dahinter liegende Problem muss gesondert gelöst werden. Dafür bräuchte ich deine und, falls er noch da ist, auch Sebastians Hilfe bei Tests.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Codierungs-Turbulenzen

by wo2010, Monday, February 06, 2017, 22:03 (2607 days ago) @ Auge

Hallo Auge,

danke für die Erklärungen. Ich denke, ich habe das meiste jetzt verstanden.

Ich sehe es jetzt so:

Bei der alten PHP-Version (hier 5.2) hat htmlspecialchars() in der Datenbank die Zeichenkodierung vorgefunden, für die es selbst auch voreingestellt ist. Die Umkodierung lief glatt.

Bei der neuen PHP-Version (hier 5.5) wird voreingestellt UTF-8 erwartet, was zu stillem Abbruch bei der ganzen ISO-8859-1-Textumsetzung des Feldes führt.

Dennoch bleibt (m)eine Frage.

Ich vergleiche mal den Inhalt bei Einträgen _vor_ und _nach_ meinem Reparaturversuch.

Wenn der Wrappercode grundsätzlich ok ist, habe ich mich unglücklich ausgedrückt.

"Vor der Reparatur" meinte ein fuktionierendes MLF 1 mit PHP 5.2, mit MLF 1.7.3,
"nach der Reparatur" ein funktionierendes MLF 1 (inkl. Wrapper) mit PHP 5.5.

Offenbar werden die Daten unterschiedlich in der Datenbank abgelegt. Bei PHP 5.2 (ich schreibe vorsichtshalber nicht "mit PHP 5.2") wurde mehr maskiert, jetzt bei PHP 5.5 offenbar nicht (mehr).

Also korrigiert:

Textbeispiel: 'Hochkomma' "Anführung"

- phpMyAdmin

bei PHP 5.2: \'Hochkomma\' \"Anführung\"
bei PHP 5.5: 'Hochkomma' "Anführung"


Korrekt. Wobei das Leiden von MLF1 dafür sorgt, dass die Daten tatsächlich mit den Backslashes in der Datenbank liegen. Davon siehst du in phpMyAdmin nur nichts.

Bei den "alten" Daten (von PHP 5.2) schon.

- SQLDump
bei PHP 5.2: \\\'Hochkomma\\\' \\\"Anführung\\\"
bei PHP 5.5: \'Hochkomma\' \"Anführung\"

Wir müssen (und sollten) das jetzt vielleicht auch nicht weitertreiben. Es scheint ja nach außen dennoch zu funktionieren.

Ich wollte es nur rechtzeitig melden - jetzt würde ich die frisch dazugekommenen Beiträge ggf. noch 'reparieren' können. Später wäre es vielleicht Strafarbeit.

Behalte dein ENT_QUOTES. Das hat, wie ich hoffentlich verständlich ausführte, mit deiner Beobachtung nichts zu tun. Das dahinter liegende Problem muss gesondert gelöst werden. Dafür bräuchte ich deine und, falls er noch da ist, auch Sebastians Hilfe bei Tests.

Ich will gern im Rahmen meiner Möglichkeiten helfen. Damals beim Kurs hatten wir uns einen WAMP-Server eingerichtet - ich hoffe, ich bekomme das aktuell auch noch hin.

Viele Grüße
Wolfgang

Avatar

Codierungs-Turbulenzen

by Auge ⌂, Tuesday, February 07, 2017, 08:21 (2607 days ago) @ wo2010

Hallo Auge,

Ich sehe es jetzt so:

Bei der alten PHP-Version (hier 5.2) hat htmlspecialchars() in der Datenbank die Zeichenkodierung vorgefunden, für die es selbst auch voreingestellt ist. Die Umkodierung lief glatt.

Bei der neuen PHP-Version (hier 5.5) wird voreingestellt UTF-8 erwartet, was zu stillem Abbruch bei der ganzen ISO-8859-1-Textumsetzung des Feldes führt.

Ja, sobald ein nicht zur Kodierung passendes Zeichen auftaucht, bricht die Funktion ab.

Offenbar werden die Daten unterschiedlich in der Datenbank abgelegt. Bei PHP 5.2 (ich schreibe vorsichtshalber nicht "mit PHP 5.2") wurde mehr maskiert, jetzt bei PHP 5.5 offenbar nicht (mehr).

Ah, jetzt wird ein Schuh draus (oder zumindest besteht die Chance dazu). Schreibe bitte den unten folgenden Code in eine Datei, speichere sie als test.php (oder wie du sie auch immer nennen willst), lade sie auf deinen Webspace und rufe sie im Browser auf.

<?php echo '<pre>' . ini_get('magic_quotes_gpc') . '</pre>'; ?>

Zitat aus dem PHP-Manual zu magic_quotes_gpc:

"Legt die magic_quotes Einstellungen für GPC (Get/Post/Cookie) fest. Ist diese Einstellung auf on, werden alle ' (einzelne Anführungszeichen), " (doppelte Anführungszeichen), \ (Backslash) und NUL's automatisch mit einem Backslash geschützt."

… und …

"Warnung Dieses Feature ist seit PHP 5.3.0 DEPRECATED (veraltet) und seit PHP 5.4.0 ENTFERNT."

Es sollte zu einem Fehler oder zur Ausgabe von 0 kommen. Diese PHP-Einstellung wurde, wie oben zitiert, mit PHP 5.4 abgeschafft. Das MLF1-Skript macht jedoch bis Version 1.7.6 exzessiv Gebrauch von dieser Einstellung. Das ist "das Leiden" von MLF1.

Nun sollte das kein Problem sein, weil etwas, was nicht hinzugefügt wird, nicht behandelt werden muss. Es ist jedoch bei Altinstallationen doch da. Es sind die wahrscheinlich hunderte oder tausende Stellen, an denen im Inhalt der Beiträge eines Forums diese Backslashes seit immer da sind und nun aus den vorhandenen Daten entfernt werden müssen.

Da magic_quotes_gpc nach den Regeln der Funktion addslashes arbeitet, ist dazu, wenn man nicht Masochist ist und händisch an die Sache herangeht, die Funktion stripslashes – eventuell, wegen Mehrfachsetzungen in Zitaten, in mehreren Durchläufen – das Mittel der Wahl. Aber sie entfernt wahrscheinlich auch die Backslashes, die z.B. in Windows-Hilfeforen als Verzeichnisnamen trennende Zeichen in Pfadangaben verwendet werden. "Wahrscheinlich", weil ich schon lange nicht mehr mit solchen Problemen zu tun hatte und mich nur noch dunkel daran erinnern kann, dass so etwas in Alex' damaligen MLF1-Projektforum diskutiert wurde.

Die Inhalte müssen schlussendlich aus der Datenbank entnommen, richtig behandelt und zurückgespeichert werden. Hier schlagen die je nach Anbieter unterschiedlichen Begrenzungen für Laufzeit und zugewiesenen Arbeitsspeicher für PHP-Skripte zu. Wie das zu lösen ist, müssen wir noch überlegen.

Wir müssen (und sollten) das jetzt vielleicht auch nicht weitertreiben. Es scheint ja nach außen dennoch zu funktionieren.

Ich wollte es nur rechtzeitig melden - jetzt würde ich die frisch dazugekommenen Beiträge ggf. noch 'reparieren' können. Später wäre es vielleicht Strafarbeit.

Da es, wie gesagt, eh "richtig" gemacht werden muss, kommen wir um "später" nicht herum. Im Zweifelsfall werden Texte vorübergehend falsch ausgegeben ("Carlo\'s Imbiss"). Das sieht unschön aus, macht aber technisch nichts kaputt.

Behalte dein ENT_QUOTES. Das hat, wie ich hoffentlich verständlich ausführte, mit deiner Beobachtung nichts zu tun. Das dahinter liegende Problem muss gesondert gelöst werden. Dafür bräuchte ich deine und, falls er noch da ist, auch Sebastians Hilfe bei Tests.


Ich will gern im Rahmen meiner Möglichkeiten helfen. Damals beim Kurs hatten wir uns einen WAMP-Server eingerichtet - ich hoffe, ich bekomme das aktuell auch noch hin.

Es wird eher darum gehen, Skripte mit Kopien Eurer Inhalte auf Euren Webspaces zu testen. Ich will eure Foreninhalte, wenn es sich vermeiden lässt, überhaupt nicht zu Gesicht bekommen. Wenn wir eine Lösung für Problem X erarbeitet haben – wer weiß, was auf uns wartet –, gehört dazu die Erstellung einer Kopie der Datenbanktabellen (geht über phpMyAdmin) und die Bearbeitung dieser Kopien mit den Skripten. Eine eigenen Serverinstallation braucht ihr nicht. Wenn alles gut läuft und die Ergebisse passen, brauchen die Tabellen nur umbenannt werden und ihr habt wieder ein von den Fehlern bereinigtes Forum.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

Codierungs-Turbulenzen

by Alfie ⌂, Vienna, Austria, Tuesday, February 07, 2017, 17:14 (2607 days ago) @ Auge

Hallo Auge,

Im Zweifelsfall werden Texte vorübergehend falsch ausgegeben ("Carlo\'s Imbiss"). Das sieht unschön aus, macht aber technisch nichts kaputt.

Auch nach etwaiger Korrektur noch immer falsch (Stichwort: Deppenapostroph). :-D

--
Cheers,
Alfie (Helmut Schütz)
BEBA-Forum (v1.8β)

MLF 1.7.3: PHP 5.2 zu 5.5 Umlaut-Probleme - meine Lösung

by wo2010, Sunday, February 05, 2017, 00:42 (2609 days ago) @ Auge

Hallo Auge,

ich habe mir ein Herz gefaßt und die hier in der Diskussion entwickelten Lösungsvorschläge auf die folgende Weise bei mir umgesetzt:

1. Suche aller Dateien (mit WinGrep), die "htmlspecialchars" enthalten.

2. Gleichzeitiges Öffnen all dieser Dateien (mit Notepad++) und globales Ersetzen von "htmlspecialchars" durch "htmlspecialchars_modif". (Ca. 250 Aktionen, ging blitzschnell.)

3. Ergänzung der Funktion "htmlspecialchars_modif()" in functions.php:

 
function htmlspecialchars_modif($string)
 {
   return htmlspecialchars($string, ENT_QUOTES, "ISO-8859-1");
 }
 

Zur Zeit sieht es (noch) so aus, als ob alles wieder funktioniert.
Warten wir's ab.

Nochmals großen Dank an Dich und alle anderen Beteiligten für die Unterstützung und die Anregungen.

Viele Grüße
Wolfgang

RSS Feed of thread