Sefrengo 1.6.6 - PHP7 Version, PHP7 Version von Sefrengo mit allen Bugfixes |
Willkommen, Gast ( Anmelden | Registrierung ) [ Hilfe | Mitglieder | Suche ]
Sefrengo 1.6.6 - PHP7 Version, PHP7 Version von Sefrengo mit allen Bugfixes |
Fri. 2. March 2018, 18:10
Beitrag
#1
|
|
Advanced Member Gruppe: Members Beiträge: 64 Mitglied seit: 09.01.2007 Mitglieds-Nr.: 572 |
Liebe Sefrengo Gemeinde,
In der Anlage schicke ich Euch die neuste Version von Sefrengo. Diese Version ist unter PHP7 lauffähig, wir haben sie jetzt bei mehreren Kunden auf recht grossen Websites im Einsatz. Wir haben da recht viel Arbeit reingesteckt und jede Menge Bugs aus der Vergangenheit behoben. Zum Core von Sefrengo sind noch folgende Plugins und Module, alle auf PHP7 umgestellt, hilfreich: Snippet replacement 1.3 Artikelsystem Plugin 1.7.5 Artikelsystem Modul 1.7.5 Newsletter System Plugin Benutzeregistrierung Benutzer löschen/Passwort zurücksetzen Kontaktformular 2.3.0 Viele Grüsse Harald Der Beitrag wurde von hman bearbeitet: Fri. 2. March 2018, 18:13
Angehängte Datei(en)
|
|
|
Tue. 25. February 2020, 23:15
Beitrag
#2
|
|
Member Gruppe: Members Beiträge: 35 Mitglied seit: 15.07.2006 Mitglieds-Nr.: 142 |
Moin allerseits,
nach meinem letztendlich erfolgreichen Umzug auf PHP7.1 (siehe weiter oben) hat mein Provider nun einen Serverumzug gemacht und auf dem neuen Server ist nur 7.2/3/4 vorhanden. Damit fingen die Probleme wieder an. .htaccess hatte erst auf 7.1 verwiesen (PHP Dateien gab's als Quelltext, nicht interpretiert), aber nach Umstellung auf 7.2 oder 7.3 oder 7.4 bekomme ich nun folgende Fehler: 1) Frontend zeigt Umlaute nicht mehr richtig an ("Nächste" statt "Nächste") - vermutlich ein malformed Content-Type header: “text/html; charset=”, laut w3.org Checker. Da wird wohl das charset durch irgendeinen Fehler nicht mehr richtig gesetzt. 2) Server error.log zeigt jede Menge Warnungen wie diese hier an (mit verschiedenen Konstanten/Dateien). Laut 7.2 Changelog wurde das von LOG auf WARNING erhöht, daher war das vmtl. vorher schon da. Meistens ist ein String tatsächlich das gemeinte, konnte ich aber nicht für alle checken. QUELLTEXT PHP Warning: Use of undefined constant make_navigation - assumed 'make_navigation' (this will throw an Error in a future version of PHP) in /home/www/doc/10756/svg69.de/www/backend/plugins/newssystem/module/module.nav.php on line 385: /usr/local/php-7.2/bin/php-cgi 3) Größtes Problem: backend lässt sich nicht mehr öffnen. Login kommt noch, aber bei jeglichen Daten kommt "Benutzername oder Ihr Kennwort ungültig". Dabei bleibt error.log unberührt, es werden durch das Backend keine Zeilen hinzugefügt. Habt ihr Ideen/Tipps, woran es liegen könnte (speziell dritter Punkt)? Danke Nils Der Beitrag wurde von MoinMoin bearbeitet: Tue. 25. February 2020, 23:16 |
|
|
Wed. 26. February 2020, 07:32
Beitrag
#3
|
|
Advanced Member Gruppe: Members Beiträge: 64 Mitglied seit: 09.01.2007 Mitglieds-Nr.: 572 |
Moin allerseits, nach meinem letztendlich erfolgreichen Umzug auf PHP7.1 (siehe weiter oben) hat mein Provider nun einen Serverumzug gemacht und auf dem neuen Server ist nur 7.2/3/4 vorhanden. Damit fingen die Probleme wieder an. .htaccess hatte erst auf 7.1 verwiesen (PHP Dateien gab's als Quelltext, nicht interpretiert), aber nach Umstellung auf 7.2 oder 7.3 oder 7.4 bekomme ich nun folgende Fehler: 1) Frontend zeigt Umlaute nicht mehr richtig an ("Nächste" statt "Nächste") - vermutlich ein malformed Content-Type header: “text/html; charset=”, laut w3.org Checker. Da wird wohl das charset durch irgendeinen Fehler nicht mehr richtig gesetzt. 2) Server error.log zeigt jede Menge Warnungen wie diese hier an (mit verschiedenen Konstanten/Dateien). Laut 7.2 Changelog wurde das von LOG auf WARNING erhöht, daher war das vmtl. vorher schon da. Meistens ist ein String tatsächlich das gemeinte, konnte ich aber nicht für alle checken. QUELLTEXT PHP Warning: Use of undefined constant make_navigation - assumed 'make_navigation' (this will throw an Error in a future version of PHP) in /home/www/doc/10756/svg69.de/www/backend/plugins/newssystem/module/module.nav.php on line 385: /usr/local/php-7.2/bin/php-cgi 3) Größtes Problem: backend lässt sich nicht mehr öffnen. Login kommt noch, aber bei jeglichen Daten kommt "Benutzername oder Ihr Kennwort ungültig". Dabei bleibt error.log unberührt, es werden durch das Backend keine Zeilen hinzugefügt. Habt ihr Ideen/Tipps, woran es liegen könnte (speziell dritter Punkt)? Danke Nils Hallo Nils, was hast Du gemacht, damit der "letztendlich erfolgreichen Umzug auf PHP7.1 " geklappt hat? Das Problem mit den Umlauten hattest Du das behoben, lief das Backend unter PHP 7.1 ? Wie hast Du installiert? Ausgehend von welchem Stand 7.1 oder 5.x ? Gruss Harald |
|
|
Thu. 27. February 2020, 21:03
Beitrag
#4
|
|
Member Gruppe: Members Beiträge: 35 Mitglied seit: 15.07.2006 Mitglieds-Nr.: 142 |
was hast Du gemacht, damit der "letztendlich erfolgreichen Umzug auf PHP7.1 " geklappt hat? Das Problem mit den Umlauten hattest Du das behoben, lief das Backend unter PHP 7.1 ? Wie hast Du installiert? Ausgehend von welchem Stand 7.1 oder 5.x ? Hallo Harald, Umlaute waren kein Problem, alles lief unter PHP 7.1. Installation lief glaube ich noch unter 5.x (ich konnte glaube ich noch ein paar Tage hin- und herschalten per .htaccess). Meine Notizen vom Umzug (vmtl. nicht mehr so ganz relevant, siehe weiter unten, aber zur Vollständigkeit): QUELLTEXT - Sefrengo 1.6.9 plus neue Module installiert - Backend ging nicht unter PHP7: Plugins deinstallieren, vmtl. backend-log - Frontend ging gar nicht mehr: cms/inc/config.php hatte "../backend" drin, muss bei mir aber "./backend" sein - Möglichst viele alte, ungenutzte Module rauswerfen (unklar, ob das was gebracht hat bzw. relevant war) - Startseite ging nicht: Im Layout war upcoming.php vom Kalender eingebunden - der war aber nicht php7 tauglich --> aktualisiert, danach alles schön - News-System hatte Probleme im Frontend und Backend * "&new" in diversen Dateien durch "new" ersetzt (PHP4?) * bbcode.php (in external): preg_replace mit "e" war weg, habe ich aber nicht umgeschrieben bekommen. Andere parse_bbcode mit einer anderen Variante irgendwoher aus dem Netz ersetzt, plus [br] manuell ergänzt * mysql durch mysqli ersetzt (4x), aber immer noch Warnungen (Parameter etwas anders, habe ich nicht bearbeitet) - wysiwyg2 zerstört Styles (class="mark"): um das Filtern zu unterbinden muss config.allowedContent = true in cms>>ckeditor>>sefrengo>>ckconfig ca. Zeile 90 eingefügt werden: CKEDITOR.editorConfig = function( config ) { config.allowedContent = true; - inc.con_edit.php Zeile 718: .split durch .explode ersetzt (gab einen Apache Fehler) - Mysqli Korrekturen (vorher war's falsch): $result = mysqli_query($db->Link_ID, $sql); - der db-Link-ID mysqli_fetch_array($result, MYSQLI_ASSOC) - das "I" Zwischenzeitlich hat mein Provider wieder PHP 7.1 freigeschaltet (siehe da, wenn man fragt, gibt es das doch noch) und das Backup von vor dem Umzug eingespielt - geht leider immer noch nicht. Sie waren aber so freundlich, mich auf die Sefrengo-Log-Datei hinzuweisen (ähm, selbst nicht dran gedacht), die nun folgende Fehlermeldung ausspuckt, wenn ich mich erfolglos am Backend anmelden will (die Session kann nicht erstellt werden, weil "form" statt einer Integer User-ID übergeben wird): QUELLTEXT MySql-Error:2020-02-27 (Thu) 20:22:44: error 1366 (Incorrect integer value: 'form' for column `db107560001`.`cms_sessions`.`user_id` at row 1) - Invalid SQL: insert into cms_sessions ( sid, name, val, changed, user_id) values ('8f72ca8a4a5502f8074afd821c8cafba', 'sefrengo', 'c2VmcmVuZ286JHR..(gekürzt)...ODM2NDcnOyA=', '20200227202244', 'form') MySql-Error:2020-02-27 (Thu) 20:22:44: error 1366 (Incorrect integer value: 'form' for column `db107560001`.`cms_sessions`.`user_id` at row 1) - Session: freeze() failed. Leider war meine Suche nach der richtigen Stelle im PHP-Code nicht erfolgreich, wo das denn jetzt falsch aufgerufen wird. Wo passiert der SQL Zugriff, in welcher Datei? Liegt das vielleicht an irgendwelchen anderen Änderungen auf dem Server? Der Provider schätzt die als nicht so relevant ein, aber hier die Beschreibung: http://www.artfiles.de/support/knowledgeba...try.html?id=152 Vielen Dank schonmal für die Reaktion und dass du dich damit beschäftigst! Gruß, Nils Der Beitrag wurde von MoinMoin bearbeitet: Thu. 27. February 2020, 21:05 |
|
|
Sat. 29. February 2020, 14:41
Beitrag
#5
|
|
Advanced Member Gruppe: Members Beiträge: 64 Mitglied seit: 09.01.2007 Mitglieds-Nr.: 572 |
Hallo Harald, Umlaute waren kein Problem, alles lief unter PHP 7.1. Installation lief glaube ich noch unter 5.x (ich konnte glaube ich noch ein paar Tage hin- und herschalten per .htaccess). Meine Notizen vom Umzug (vmtl. nicht mehr so ganz relevant, siehe weiter unten, aber zur Vollständigkeit): QUELLTEXT - Sefrengo 1.6.9 plus neue Module installiert - Backend ging nicht unter PHP7: Plugins deinstallieren, vmtl. backend-log - Frontend ging gar nicht mehr: cms/inc/config.php hatte "../backend" drin, muss bei mir aber "./backend" sein - Möglichst viele alte, ungenutzte Module rauswerfen (unklar, ob das was gebracht hat bzw. relevant war) - Startseite ging nicht: Im Layout war upcoming.php vom Kalender eingebunden - der war aber nicht php7 tauglich --> aktualisiert, danach alles schön - News-System hatte Probleme im Frontend und Backend * "&new" in diversen Dateien durch "new" ersetzt (PHP4?) * bbcode.php (in external): preg_replace mit "e" war weg, habe ich aber nicht umgeschrieben bekommen. Andere parse_bbcode mit einer anderen Variante irgendwoher aus dem Netz ersetzt, plus [br] manuell ergänzt * mysql durch mysqli ersetzt (4x), aber immer noch Warnungen (Parameter etwas anders, habe ich nicht bearbeitet) - wysiwyg2 zerstört Styles (class="mark"): um das Filtern zu unterbinden muss config.allowedContent = true in cms>>ckeditor>>sefrengo>>ckconfig ca. Zeile 90 eingefügt werden: CKEDITOR.editorConfig = function( config ) { config.allowedContent = true; - inc.con_edit.php Zeile 718: .split durch .explode ersetzt (gab einen Apache Fehler) - Mysqli Korrekturen (vorher war's falsch): $result = mysqli_query($db->Link_ID, $sql); - der db-Link-ID mysqli_fetch_array($result, MYSQLI_ASSOC) - das "I" Zwischenzeitlich hat mein Provider wieder PHP 7.1 freigeschaltet (siehe da, wenn man fragt, gibt es das doch noch) und das Backup von vor dem Umzug eingespielt - geht leider immer noch nicht. Sie waren aber so freundlich, mich auf die Sefrengo-Log-Datei hinzuweisen (ähm, selbst nicht dran gedacht), die nun folgende Fehlermeldung ausspuckt, wenn ich mich erfolglos am Backend anmelden will (die Session kann nicht erstellt werden, weil "form" statt einer Integer User-ID übergeben wird): QUELLTEXT MySql-Error:2020-02-27 (Thu) 20:22:44: error 1366 (Incorrect integer value: 'form' for column `db107560001`.`cms_sessions`.`user_id` at row 1) - Invalid SQL: insert into cms_sessions ( sid, name, val, changed, user_id) values ('8f72ca8a4a5502f8074afd821c8cafba', 'sefrengo', 'c2VmcmVuZ286JHR..(gekürzt)...ODM2NDcnOyA=', '20200227202244', 'form') MySql-Error:2020-02-27 (Thu) 20:22:44: error 1366 (Incorrect integer value: 'form' for column `db107560001`.`cms_sessions`.`user_id` at row 1) - Session: freeze() failed. Leider war meine Suche nach der richtigen Stelle im PHP-Code nicht erfolgreich, wo das denn jetzt falsch aufgerufen wird. Wo passiert der SQL Zugriff, in welcher Datei? Liegt das vielleicht an irgendwelchen anderen Änderungen auf dem Server? Der Provider schätzt die als nicht so relevant ein, aber hier die Beschreibung: http://www.artfiles.de/support/knowledgeba...try.html?id=152 Vielen Dank schonmal für die Reaktion und dass du dich damit beschäftigst! Gruß, Nils Hallo Nils, Ich habe das gerade mal getestet und unsere amyma Website auf PHP 7.2.28 umgestellt. Das läuft problemlos ! Mir scheint das es bei Dir ein Problem mit MySQL gibt, welche Version setzt Dein Provider ein? Hast Du die config.php ausgetauscht ? Da ist nämlich die Art des Datenbankzugriffs geändert worden? Gruss Harald Der Beitrag wurde von hman bearbeitet: Sat. 29. February 2020, 14:42 |
|
|
Sun. 1. March 2020, 00:10
Beitrag
#6
|
|
Member Gruppe: Members Beiträge: 35 Mitglied seit: 15.07.2006 Mitglieds-Nr.: 142 |
Ich habe das gerade mal getestet und unsere amyma Website auf PHP 7.2.28 umgestellt. Das läuft problemlos ! Mir scheint das es bei Dir ein Problem mit MySQL gibt, welche Version setzt Dein Provider ein? Hast Du die config.php ausgetauscht ? Da ist nämlich die Art des Datenbankzugriffs geändert worden? Hallo Harald, Backend läuft inzwischen (habe dies hier gefunden, funktioniert: https://forum.sefrengo.org/index.php?s=&...st&p=13764), nur die Umlaute sind noch ein Problem (hatte ich dich da falsch verstanden?). Der Content-Type wird da vom Server noch leer gesetzt, und auch .htaccess Änderungen bringen nichts. Bin gerade mit dem Provider am diskutieren, ob das ein Server-Konfig-Problem ist. Gruß Nils |
|
|
Mon. 2. March 2020, 12:10
Beitrag
#7
|
|
Advanced Member Gruppe: Members Beiträge: 64 Mitglied seit: 09.01.2007 Mitglieds-Nr.: 572 |
Hallo Harald, Backend läuft inzwischen (habe dies hier gefunden, funktioniert: https://forum.sefrengo.org/index.php?s=&...st&p=13764), nur die Umlaute sind noch ein Problem (hatte ich dich da falsch verstanden?). Der Content-Type wird da vom Server noch leer gesetzt, und auch .htaccess Änderungen bringen nichts. Bin gerade mit dem Provider am diskutieren, ob das ein Server-Konfig-Problem ist. Gruß Nils Hallo Nils, Hast Du das hier in den Layouts stehen ? <cms:lay type="head"/> Das setzt den Content Type und ein paar andere Einträge: <meta name="generator" content="Sefrengo / www.sefrengo.org" /> <base href="URL aus Einstellungen" /> <meta name="author" content="Autor von Seite in den Seiteneinstellungen" /> <meta name="description" content="Kurzbeschreibung aus Seiteneinstellungen " /> <meta name="keywords" content="Keywords aus Seiteneinstellungen" /> <meta name="robots" content="index, follow" /> <meta http-equiv="content-type" content="text/html; charset=utf-8" /> Wenn Du das gesetzt hast und es nicht ausgegeben wird, ist es ein Bug. Um den zu umgehen für einfach den Content Types per Hand ein. Gruss Harald |
|
|
Mon. 2. March 2020, 22:35
Beitrag
#8
|
|
Member Gruppe: Members Beiträge: 35 Mitglied seit: 15.07.2006 Mitglieds-Nr.: 142 |
Wenn Du das gesetzt hast und es nicht ausgegeben wird, ist es ein Bug. Um den zu umgehen für einfach den Content Types per Hand ein. Hi, irgendwie ist das komisch mit den Umlauten. Mein Provider ist derzeit noch nicht wirklich auf meine Content-Type Diskussion angesprungen, aber ich habe auch kein einheitliches Bild. Der Content-Type im Quelltext ist gesetzt, ich sehe eher Probleme mit dem vom Server gelieferten Content-Type (z.B. im Firefox Developer-Modus sichtbar) - der ist falsch, aber ob es da wirklich dran liegt, weiß ich nicht. Ich versuche mal meine Erkenntnisse aufzulisten: 1) Content-Types: - Startseite ( http://www.svg69.de ) hat einen leeren Content-Type vom Header, QUELLTEXT text/html; charset= . Im Quelltext steht QUELLTEXT <meta http-equiv="content-type" content="text/html; charset=utf-8" /> . In der .htaccess versuche ich derzeit noch wie folgt den Header zu beeinflussen (ändert aber nichts): QUELLTEXT AddCharset UTF-8 .php .html .xhtml - Unterseite ( http://www.svg69.de/gallery3 ) hat einen Content-Type vom Header QUELLTEXT text/html; charset=iso-8859-1 . Im Quelltext steht QUELLTEXT <meta http-equiv="content-type" content="text/html; charset=UTF-8" /> . In der .htaccess steht nichts zu Content-Headers. -> Warum passt das nicht zusammen?==> Der Server kann nicht generell falsch konfiguriert sein, wenn verschiedene Verzeichnisse mal richtig/mal falsch funktionieren. Aber warum läuft die Startseite falsch? 2) Umlaute Zeichenkodierung auf der Startseite: - Auf http://www.svg69.de gibt es verschiedene Umlaute, viele falsch, manche richtig. Ich habe mal mit Notepad++ geguckt, wie die Kodierungen falsch sind. - Die falsch dargestellten Umlaute werden bei der Konvertierung ANSI-->UTF-8 richtig dargestellt. Also würde eine mit ANSI dargestellte Seite in UTF-8 richtige Umlaute anzeigen. - Die derzeit richtig dargestellten Umlaute würden dann aber wieder falsch sein. Wo kommen zwei unterschiedliche Kodierungen her? Ist doch alles Datenbank, oder kommt irgendwas direkt aus (falsch kodierten) Dateien? 3) Datenbank Kodierung: - Die "Kollation" in phpmyadmin der Datenbank ist "utf8mb4_unicode_ci". Sollte eigentlich richtig sein, oder? Irgendwelche Ideen? Gruß Nils |
|
|
Vereinfachte Darstellung | Aktuelles Datum: 26.9.24 - 17:59 |