conpresso 4.1.6 mit PHP 5.5 bzw. 5.6?

[Gandalf]

Hallo zusammen,

mein Provider kündigt PHP 5.3 ab und bittet um Umstellung auf 5.5, alternativ stünde auch 5.6 bereits zur Verfügung.

Wer hat denn bereits damit Erfahrungen sammeln können, auch im Hinblick meiner verwendeten Mods wie: Gästebuch, Kontaktformular, Search-Mod und das Bilderalbum 4.3.


P.S.: mal auf die Schnelle PHP 5.5 getestet:

- Gästebuch: Feld Notiz wird nach absenden geleert, da es ein Pflichtfeld bei mir ist, wird kein neuer Eintrag hinzugefügt.

- conpresso: bestehende Artikel inhaltlich geändert und gespeichert liefert einen leeren Inhalt zurück, nur die Überschrift 2überlebt".


Mist...

Gruß gandalf

[MarkusR]

Grundsätzlich läuft CPO 4.1.6 ganz normal auf PHP 5.6.
Habe gerade mal eine Installation auf einem neuen Server gemacht.

Wenn Inhalte verloren gehen, dann bestimmt welche mit Umlauten. Dann versucht irgendwas auf UTF-8 zu kommunizieren (die mySQL-DB oder der Apache).
Das muss man unterbinden, dann sollte alles funktionieren.

Außer natürlich veraltete Module.
Gästebuch und Kontaktformular (u.v.m.) werden ja von mod_form abgedeckt.

Was hier mit PHP 5.4 läuft sollte auch mit 5.6 laufen
http://www.conpresso4.de/_rubric/index. ... rticle1075

[Gandalf]

Hallo Markus,

laut PHP Info läuft mein Apache mit:

exif.encode_unicode ISO-8859-15 ISO-8859-15

(sofern ich den korrekten Parameter erkannt habe)

Meine MySQL-DB jedoch mit utf-8. Liegt dann da das Problem?

Weshalb gibt es bei PHP 5.3 keine Umlaut-Probleme, jedoch mit PHP 5.5/5.6?

Wenn ich umstelle werden vorhanden Umlaute in den Artikeln korrekt angezeigt, der Fehler tritt nur bei neuen bzw. geänderten Artikeln auf.

Was könnte ich tun?

Gruß gandalf

[MarkusR]

Das Problem kam mit PHP 5.4

Bis PHP 5.3 wurden alle PHP-Konvertierungen (z.B. htmlspecialchars) standardmäßig in ISO ausgeführt, wenn es nicht anderes angegeben wurde.
Ab PHP 5.4 wird UTF benutzt. Dafür müssten aber auch alle Dateien in UTF vorliegen, die DB in UTF laufen, die Tabellen UTF codiert sein etc.
mySQL hat aber als Standard LATIN1, also ISO... bis ein Provider auch daran schraubt oder die Linux Distribution so kompiliert wurde.
CPO ist daher so überarbeitet worden, dass jegliche Konvertierung explizit in ISO stattfindet.

Du müsstest eben mal prüfen, ob PHP, Apache, mySQL sowie die Kollation der Tabellen und jedes Feldes auf ISO bzw. LATIN laufen.
Es lohnt sich also ein Blick in die Konfigurationsdateien des Servers.

[Gandalf]

Nun, das was ich analysieren konnte:

MySQL:
character_set_client utf8
character_set_connection utf8
character_set_database latin1
character_set_filesystem binary
character_set_results utf8
character_set_server latin1
character_set_system utf8
collation_connection utf8_general_ci
collation_database latin1_german2_ci
collation_server latin1_german2_ci


PHP wie geschrieben auf ISO-....

Demnach müsste es an der MySQL Konfig liegen, nur wenn ich es denn selbst aud ISO... ändern kann, muss ich noch prüfen, was passiert mit den bereits generierten Daten, würden dann die Umlaute falsch bzw. gar nicht mehr dargestellt (hier bestehende Artikel)?

Gruß gandalf

[MarkusR]

Du wirst ja wohl Backups haben, so dass Du es selbst ausprobieren kannst, oder? Ansonsten besser Finger weg und anderen Provider suchen.

Hast Du kein phpmyadmin?
Da steht bei jeder Tabelle und jedem Feld die Kollation dabei...

Du hast aber noch gar nicht geprüft, ob es überhaupt die Umlaute sind, die das Problem (leere Felder) verursachen, vorher lohnt sich auch keine weitere Mutmaßung.

Man kann versuchen in CPO die korrekte Kodierung zu erzwingen

Code: Alles auswählen

$this->Link_ID=mysql_connect($this->Host, $this->User, $this->Password);
mysql_query("SET character_set_results = 'latin1', character_set_client = 'latin1', character_set_connection = 'latin1', character_set_database = 'latin1', character_set_server = 'latin1'", $this->Link_ID);

Bei Interesse kann ich das auch genauer beschreiben, aber bitte erst einen Test mit und ohne Umlaute machen...

[Gandalf]

Hallo Markus,

klar ich kann da schon einiges einstellen etc. und die Kollation hatte ich bereits mitgeteilt:

latin1_german2_ci

Habe nun mal weitere Testungen durchgeführt:

- Artikelüberschrift wird korrekt gespeichert
- Untertitel wird verworfen
- Artikeltext wird verworfen

Gleich ob mit oder ohne Umlaute. Artikelüberschrift mit Umlauten keine Probleme....

Leider sehe ich in den Protokolloptionen keine Fehlerhinweise von PHP, daher vermute ich mal wird es irgenwie an MySQL liegen.

- Tabelle cpo4_content_text, Spalte "Text" nichts eingetragen
- Tabelle cpo4_content_html, Spalte "htmle" nichts eingetragen

[MarkusR]

Dass die Umlaute nicht ursächlich sind macht die Sache deutlich problematischer.

Kannst Du denn via phpmyadmin in die Felder etwas eintragen?
Wird das Eingetragene in phpmyadmin angezeigt?
Wird das Eingetragene dann auch in CPO angezeigt?
Wird etwas in CPO gerade eben Eingetragenes in phpmyadmin angezeigt?

Die Kollation kann übrigens für jede Tabelle und jedes Feld einzeln eingestellt werden. Ich gehe jetzt mal davon aus, dass Du Tabellen UND Felder geprüft hast...

Gehe ich eigentlich richtig in der Annahme, dass einfach nur im Hostingpaket von PHP 5.3 auf PHP 5.5 umgeschaltet wird, Du also nicht probeweise fünf Minuten in eine frische Installation oder zumindest einen Transfer investiert hast?
Wenn das ein bestehender Auftritt ist, hast Du ggf. Änderungen vorgenommen und Module installiert, diese aber bisher noch nicht erwähnt?
mod_text und mod_editor wären erwähnenswert...

[MarkusR]

Darf ich mal raten? hosteurope?

Ich kann das Problem dort nachvollziehen.

Was passiert: Beim Speichern des Inhalts wird $_POST['content'] nicht übergeben! Genauer gesagt kommt es beim Script gar nicht an!

Ursache: keine Ahnung, vielleicht die Variableneinschränkung durch suhosin

[MarkusR]

Ursache gefunden:

Es sind die Klammern in den Namen der Formularfelder, also z.B.
content[Teaser (html)][html]

Grund: die suhosin-Direktive suhosin.request.array_index_blacklist steht auf '"+<>;() und erlaubt somit keine Klammern!

Damit ist zumindest die PHP 5.5 Installation von hosteurope nicht mit Conpresso kompatibel.

Dass das aber kein PHP Problem ist zeigt meine Installation auf PHP 5.6

Ab morgen soll bei hosteurope ja auch 5.6 verfügbar sein, dann werde ich das nochmal testen.

[Gandalf]

Markus gut geraten!

Ja es ist HostEurope und habe noch ein paar Tests gemacht.

- zunächst mit PHP 5.3 Testartikel erfolgreich erstellt
- auf PHP 5.5 umgestellt
- per phpmyadmin sowohl den Untertitel als auch den Artikelinhalt erfolgreich ändern können
- wird dann auch im Frontend in geänderter Form angezeigt
- ändere ich dann im Backend den Untertitel und/oder den Artikeltext erhalte ich sowohl im Frontend als auch im backend nur leere Felder

- interessant dabei: in der DB stehen die Inhalte aber nach wie vor drin.....

Wenn Du doch auch bei HostEurope bist, dann laufen Deine Publikation sicherlich noch nicht mit PHP 5.5....

[MarkusR]

Wenn Du doch auch bei HostEurope bist, dann laufen Deine Publikation sicherlich noch nicht mit PHP 5.5....

Einige meiner Kunden sind dort.
Natürlich bin ich bei 5.3 geblieben (und werde bis Februar auch dabei bleiben).
Mal sehen ob zumindest 5.6 dort funzt...

[MarkusR]

Hm, was auch immer "Einführung zum 13.10.2015" bedeuten soll, bei keinem einzigen Webpack habe ich heute PHP 5.6 gefunden.

Meine Supportanfrage ist auch noch nicht beantwortet, ob das mit der Blacklist so bleiben soll und auch bei 5.6 so sein wird...

@Gandalf:

alternativ stünde auch 5.6 bereits zur Verfügung.

bei Dir ist 5.6 schon verfügbar? Wie sieht es damit aus?

[MarkusR]

Nachdem ich denen jetzt über mehrere Kundenaccounts auf den Sack gegangen bin hier eine Antwort des Supports:

Der Wert wird auch in der PHP Version 5.6 default so gesetzt sein.
Sie können diesen Wert aber über eine .htaccess editieren

php_value suhosin.request.array_index_blacklist XYZ

XYZ Bitte entsprechend anpassen.

Habe ich natürlich gleich gemacht.

Code: Alles auswählen

php_value suhosin.request.array_index_blacklist ""

geht nicht.

Es muss was zwischen den Anführungszeichen stehen, ganz weglassen geht auch nicht. Also musste ich mich für ein Zeichen entscheiden dass ich garantiert nicht als Feldbezeichnung benutzen werde und bin beim ANSI-Character 255 gelandet: ÿ

Das steht jetzt in meiner .htaccess:

Code: Alles auswählen

php_value suhosin.request.array_index_blacklist "ÿ"

und es funktioniert!

[Gandalf]

Hallo Markus,

hatte eben auch mal auf 5.6 umgestellt und die Parameter gesichtet, wie bereits von Dir berichtet bleiben diese gleich (Default).

Hatte gestern auch eine Anfrage an den Support gestellt, bisher keine Antwort, da scheint man Dich bei HostEurope wohl besser zu kennen

Werde mal die .htaccess "Lösung" testen.