Sprachvariablen werden nicht alle erkannt

[ruebenwurzel]

Hallo,

habe gerade mal die WB 2.10.1-dev Rev. 24 von der Project Seite getestet. mit den neuen Sprachdateien werden folgende Variablen im Backend irgendwie nicht erkannt:

Module -> Erweitert -> Admin Optionen: MESSAGE[ADDON_RELOAD]
Optionen: MESSAGE[SETTINGS_MODE_SWITCH_WARNING]

Ansonsten Sieht das Ganze richtig gut aus 

Matthias

[jacobi22]

du bist der erste, der diese geheimen Worte (WB 2.10.1-dev Rev. 24) erwähnt - nu ist es raus....  ich dacht, es soll eine Überraschung sein.

[dbs]

Moin, da werden die Tage immer wieder mal weitere Dateien hochgespielt.
Im Moment lohnt SVN Aktualisierung noch nicht wirklich.
Kann aber nicht mehr allzulange dauern.

[ruebenwurzel]

Hallo,

@jacobi
wusste nicht, dass der öffentliche Zugang zur Project-Seite Geheim ist.  . Wollte keine Geheimnisse kundtun, sorry.

@dbs
Teste ab und an mal alles in meiner Testumgebung was sich da auf der Project-Seite so tut. Hab gesehen, dass hier die letzten Wochen wieder ein bisschen Fahrt aufgenommen wurde, find ich super. Warte gespannt darauf, was sonst noch so alles kommt. 

Matthias

[jacobi22]

Der Eindruck drängte sich nahezu auf und mit der Meinung steh ich sicher nicht alleine. Ich zitiere mal aus einer Mail an mich:

Auch was Websítebaker angeht, habe ich schon längere Zeit kein gutes Gefühl - da tut sich - zumindestens in der Öffentlichkeit - nicht mehr viel.

So oder ähnlich häufig in meinem Postfach. Mittlerweile werden es weniger Nachfragen. Die meisten haben schon gewechselt.

[dbs]

Was WebsiteBaker angeht wird hinter den Kulissen viel gemacht.
Die Nachfolgeversion von 2.10 ist kurz vor öffentlichen Tests.
Was tatsächlich fehlt sind Ankündigungen zwischendurch.

Wer woanders hingeht, ist selbst schuld. Ich sehe keinen Grund dafür.

[DarkViper]

[…] werden folgende Variablen im Backend irgendwie nicht erkannt:
Module -> Erweitert -> Admin Optionen: MESSAGE[ADDON_RELOAD]
Optionen: MESSAGE[SETTINGS_MODE_SWITCH_WARNING]

da gibt es eine einfache Lösung dazu:
Im Template die Sprachvariable
$MESSAGE['ADDON']['RELOAD']
auf
$MESSAGE['ADDON_RELOAD']
ändern... und dann klappt das wieder.
Grund dafür ist der Umstand, dass ich bereits vor 7!!! Jahren die Sprachvariablen mit mehreren Ebenen auf 'deprecated' gesetzt und kommuniziert!! habe und diese ab der neuen Version schlicht nicht mehr unterstützt werden.  Es sind auch noch einzelne 'alte' Variablen im Core enthalten, die wir aber bis zur Veröffentlichung hoffentlich alle gefunden und ausgetauscht haben.
(Die Meldung dazu kam das erste Mal 2010 in der Deprecated-Liste und dann im Februar 2012 nochmals)

Es sind zwischenzeitlich einige Dinge aus der Liste erledigt worden. Die Beschreibungen dazu kommen dann mit der Ankündigung der neuen Version. Während der Entwicklung gibt es nur die Commit-Meldungen im SVN. Um jeden kleinen Commit im Forum zu diskutieren, fehlt mir schlichtweg die Zeit. Zumal die meisten von mir gegebenen Hinweise in der Vergangenheit schlichtweg ignoriert wurden... also verschenkter Aufwand waren.
Nur ein kleines Beispiel:  Ich habe 2014 zum wiederholten Mal die Meldung " frontend::prepocess() : this method is without functionality 2012/08/27"  veröffentlicht und auch diverse Leute explizit darauf hingewiesen, dass die Methode seit 2012!!! keinerlei Code mehr enthält.
Die letzten Wochen beschweren sich diese Leute hier, weil sie eine Fehlermeldung im Logfile bekommen, wenn sie diese Methode in ihren neuesten Projekten aufrufen...  Wozu zur Hö*** mach ich eigentlich noch überhaut irgendwas bekannt???

Manuela

[jacobi22]

Die Nachfolgeversion von 2.10 ist kurz vor öffentlichen Tests.
Was tatsächlich fehlt sind Ankündigungen zwischendurch.

das alte Problem, aber eben auch eine Folge davon, wenn man Leute blockiert, die sich engagiert haben

Wer woanders hingeht, ist selbst schuld. Ich sehe keinen Grund dafür.

Du mußt das aus Sicht des einfachen Users sehen und ich meine da nicht eine Agentur, die  x WB-Projekte betreut, sondern den, der wirklich nur ein einfaches WB-Projekt für sich hat, mit 10, 20 oder auch hundert Unterseiten, womöglich alles auch etwas älter. Ich bekomme ja immernoch Anfragen zum Umstieg von WB 2.6.5 auf was Neueres.
Diese Leute bekommen schon allein wegen PHP und MySQL irgendwann Probleme und sei es nur eine Notice.
Dann schaut man hier rein, liest sich durch die diversen Upgrade-Anweisungen und kommt zum Schluß, das es die einfachste Methode ist, WB mit neuester Version neu aufzusetzen und Inhalte per Copy&Paste zu übernehmen.
Wenn ich sowieso neu aufsetzen muß, schau ich doch mal, wie es mit der Entwicklung aussieht, hier und woanders und da schaut es mit Informationen hier eher düster aus.
Ich gehe mit dir absolut konform, das es in technischer Hinsicht absolut keinen Grund zum wechseln gibt, da ist WB besser aufgestellt als jeder der Forks, es weiß nur niemand. Die Ausrichtung auf UTF8 / UTF8_mb4 ist m.E. absolut richtig und zukunftsorientiert, stellt aber dennoch den einen oder anderen User vor Probleme, weil es für ihn über all die Jahre kein Thema war. Typisches Beispiel aus aktuellen Postings: der portugisische User, der vorher UTF8_mb4 benutzte und nun mit "Zwangs-UTF8" Pobleme hat. Nach Erscheinen der WB 2.10.0 habe ich pro Woche ~3 Domains von Usern repariert / konvertiert, mittlerweile kommen da keine Anfragen mehr. Man geht zum Fork, weil es da noch problemlos möglich ist, latin1 zu verwenden - bis irgendwann der Provider einen Riegel vorschiebt (und das kommt mit Sicherheit in naher zukunft).
Diese UTF8-Geschichte wurde hier von offizieller Seite in keinster Weise kommuniziert, warum wurde das gemacht, kann man vielleicht Hilfe anbieten usw. Und da kommunizieren andere Systeme eben ganz anders. Ich habe mir in den letzten Monaten viele Systeme angesehen, in einige bin ich auch tiefer eingestiegen. Wie sieht es da mit Forum oder Support aus? Wie sieht es mit Terminangaben aus, Updatezyklen usw. Wie ist der Stand der Erweiterungen? Wie schnell wird reagiert, wenn Probleme oder Verbesserungsvorsch läge auftauchen? Wie ist die Meinung der User darüber, vorallem der mit weniger Postings? Und egal, wo du bist, die Informationspolitik war überall besser.

Ein CMS wurde als Bedienoberfläche für Leute ohne Informatikkenntniss e gemacht und viele User haben diese auch nicht. Sie dann auf den Weg zu schicken, sich UTF8-Zeichen zusammen zu suchen, um ein search&replace zu machen in einer Situation, wo man eh unsicher ist, das Projekt möglicherweise gerad nicht läuft wegen diverser Fehlermeldungen und die Gefahr besteht, das gesamte Projekt zu verlieren, wenn man bei der Konvertierung, dem Ex- und Import einen Fehler macht, das war definitiv ein "ungünstiger" Weg
Und wenn man dann nichts über eine mögliche Weiterentwicklung und deren Zeitpläne erfährt, ist der Entschluß zum Wechseln schnell gefaßt und auch verständlich.
Das jemand (Agentur oder nicht) der 100 Webseiten betreut, länger "bei der Stange" bleibt als ein Einzeluser, sollte einleuchtend sein, macht man so etwas in den allermeisten Fällen dann doch wohl auf eigene Rechnung.

[ruebenwurzel]

Hallo,

@Dark Viper
ich gehe davon aus, dass in den von WB offiziell zur Verfügung gestellten Dateien die von Euch selbst erstellten Vorgaben auch umgesetzt sind. 

In dem obigen Fall hab ich mir das mal angeschaut, find aber ums verrecken nicht heraus, warum der Text nicht ausgegeben wird.

Code: [Select]

wb/templates/DefaultTheme/templates/addons.htt Zeile76
{MESSAGE_RELOAD_ADDONS}

Code: [Select]

wb/admin/addons/index.php Zeile 70
'MESSAGE_RELOAD_ADDONS' => $MESSAGE['ADDON']['RELOAD']

Code: [Select]

wb/languages/old.format.inc.php Zeile 145
$MESSAGE['ADDON']['RELOAD']  = 'MESSAGE[ADDON_RELOAD]'

Code: [Select]

wb/languages/DE.php Zeile 123
$MESSAGE['ADDON_RELOAD'] = 'Abgleich der Datenbank mit den Informationen aus den Addon-Dateien (z.B. nach FTP Upload).';
Es scheint alles in Ordnung zu sein. Geht aber halt dennoch nicht.

Schaut es euch bitte nochmal an.

Gruß
Matthias

[Luisehahne]

Guten Morgen,

erstmal vielen Dank für die Meldung. Ist intern für das nächste WB Paket gefixt. Sicherlich kann man erwarten, dass keine Sprachvariablen mit mehreren Ebenen im WB Kern  mehr vorkommen sollten. Auch wir sind nur Menschen, deswegen sind wir auf eure Meldungen angewiesen.
Aus diesem Grunde werden zur besseren Auffindung durch die old.format.inc.php noch im Kern vorhandene Sprachvariablen mit mehreren Ebenen zum Fixen als Klartext angezeigt.

Dietmar

[ruebenwurzel]

Hallo,

hab mir jetzt die index.php files in den diversen Unterordnern von wb/admin mal angeschaut. Dort gibt es nach erstem groben drüberschauen noch in folgenden Dateien noch Sprachvariablen mit mehrfachenen Ebenen:

admin/addons
admin/settings
admin/templates

Matthias

[jacobi22]

nur informatorisch für den Fall, das jemand irgendwo Sprachvariablen korrigiert / ersetzt / für sich anpasst: es ist zwingend erforderlich, nach jeder Änderung an Sprachdateien des Cores und auch aller Addons, den Sprach-Cache zu löschen
Entweder in Info-fenster über den Link Clear Translate Cache oder manuell über den Datei-Explorer im Ordner temp / cache alle Dateien löschen

[jacobi22]

hab mir jetzt die index.php files in den diversen Unterordnern von wb/admin mal angeschaut. Dort gibt es nach erstem groben drüberschauen noch in folgenden Dateien noch Sprachvariablen mit mehrfachenen Ebenen:

mit Verlaub, ich finde allein im admin-Ordner ~50 solcher Beispiele, hab nur nach 3-4 Kombinationen gesucht, vielleicht werden es auch 100, wenn man mal alles durchsucht

Am Ende jeder Zeile hier die Fehler und Zeichennummer der einzelen Meldung

Found 16 matches of $MESSAGE['PAGES'] in 9 files.   
admin   
pages   
add.php 
$admin->print_error($MESSAGE['PAGES']['PAGE_EXISTS']);      [position 141:25]   
$admin->print_success($MESSAGE['PAGES']['ADDED'], ADMIN_URL.'/pages/modify.php?page_id='.$page_id);      [position 252:23]   
index.php    'INTRO_LINK' => $MESSAGE['PAGES']['INTRO_LINK'],      [position 597:49]
 
intro2.php   
    $admin->print_success($MESSAGE['PAGES']['INTRO_SAVED']);      [position 47:27]   
    $admin->print_error($MESSAGE['PAGES']['INTRO_NOT_WRITABLE']);      [position 50:25]   

modify.php  'LAST_MODIFIED' => $MESSAGE['PAGES']['LAST_MODIFIED'],      [position 85:32]
 
move_down.php   
        $admin->print_success($MESSAGE['PAGES']['REORDERED']);      [position 48:31]   
        $admin->print_error($MESSAGE['PAGES']['CANNOT_REORDER']);      [position 50:29]
 
move_up.php   
        $admin->print_success($MESSAGE['PAGES']['REORDERED']);      [position 48:31]   
        $admin->print_error($MESSAGE['PAGES']['CANNOT_REORDER']);      [position 50:29]   

restore.php  
    $admin->print_error($MESSAGE['PAGES']['NOT_FOUND']);      [position 45:25]   
    $admin->print_error($MESSAGE['PAGES']['INSUFFICIENT_PERMIS SIONS']);      [position 58:25]   
    $admin->print_success($MESSAGE['PAGES']['RESTORED']);      [position 95:27]   

sections.php   
                        'LAST_MODIFIED' => $MESSAGE['PAGES']['LAST_MODIFIED'],      [position 273:44]   
trash.php  
                    <a href="javascript: confirm_link('<?php echo $MESSAGE['PAGES']['DELETE_CONFIRM']; ?>?', '<?php echo ADMIN_URL; ?>/pages/delete.php?page_id=<?php echo $page['page_id']; ?>');" title="<?php echo $TEXT['DELETE']; ?>">      [position 187:67]   
<br />< <a href="<?php echo ADMIN_URL; ?>/pages/index.php"><?php echo $MESSAGE['PAGES']['RETURN_TO_PAGES']; ?></a>      [position 275:71]   

[ruebenwurzel]

[…] werden folgende Variablen im Backend irgendwie nicht erkannt:
Module -> Erweitert -> Admin Optionen: MESSAGE[ADDON_RELOAD]
Optionen: MESSAGE[SETTINGS_MODE_SWITCH_WARNING]

...  Es sind auch noch einzelne 'alte' Variablen im Core enthalten, die wir aber bis zur Veröffentlichung hoffentlich alle gefunden und ausgetauscht haben. ...


Manuela

Na dann viel Spass beim Suchen der "einzelnen alten Variablen"

Matthias

P.S.
Schon mal im Forum gefragt, ob euch jemand bei dieser Fleißaufgabe unterstützen kann, oder wollt ihr das auch alleine machen? 

[DarkViper]

Waren im gesamten Core + Standardmodule noch 30 Vorkommen in 17 Dateien.
Alle suchen und ersetzen hat knapp 5 Minuten gedauert (ein Hoch auf Netbeans und seine Regex-Suche)
Das jemand schriftlich zu erklären, hätte deutlich länger gedauert...

[DarkViper]

Ich denke, ich sollte ein klein wenig über Zeichensatzcodierun g  schreiben, vielleicht hilft es dabei die hier auftretenden Probleme leichter zu verstehen.

Wir haben für WB selbst ab der neuen Version den PHP-Code mehr oder weniger zwangsweise auf UTF-8 umgestellt.
Damit sind wir jedoch nur der dringenden Empfehlung der PHP-Group gefolgt, die mit PHP-7  UTF8 als default-Zeichensatz festgelegt hat.
Auch die mySQL - Datenbank läuft bei uns jetzt primär auf UTF-8mb4 (was bei mySQL demnächst Standard wird).

Da es bis dato bei WebsiteBaker noch keinerlei Vorgaben oder Regeln in Bezug auf Zeichensätze und Datenbankanbindung gab, jeder die Einstellungen nach persönlichem Gusto wählen und ändern konnte, bzw. vom Provider in unterschiedlichster Konfiguration geliefert bekam, war es vorhersehbar, dass es bei diesen Umstellungen Zeichensatzprobleme der unterschiedlichsten Art geben würde. Eine allgemeingültige Anleitung war da kaum zu erstellen.  Zumal auch Anleitungen leider meistens erst dann gelesen werden, wenn die ersten, eigenen Versuche "in die Hose gingen" und die Daten endgültig verwurstelt sind. 
Diese Umstellungen, mitsamt ihren Problemen, wären jedoch  auf jeden Fall erforderlich gewesen. Wenn nicht jetzt, dann spätestens in der nächsten Version. Das ganze Zeichensatzproblem wäre nur zeitlich etwas verschoben worden.

Noch ein paar Informationen zu Zeichensätzen, die vorwiegend Programmierer interessieren dürften:

Der offizielle UTF-8 Standard, der auch in PHP gilt, deklariert UTF-8 als Multibyte Zeichensatz, der 1-4 Bytes umfassen kann. Also für PHP alles im grünen Bereich.
Das Problem liegt bei mySQL. Als hier damals UTF-8 eingeführt wurde, hat man den maximalen Umfang auf die max. 3 Bytes der Basic Multilingual Plane (BMP) beschränkt. Quasi ein UTF-8(mb3). Mit Aufkommen der neuen Zeichen (z.B. Emojis etc), die das 4.Byte benötigen, war mySQL gezwungen, sich anzupassen. Es wurde jedoch nicht das bisherige UTF8 auf die genormten 1-4 Byte erweitert, sondern ein zusätzlicher Zeichensatz UTF8_MB4 eingeführt, der grundsätzlich 4 Byte lang ist. Der Codierungsalgorithm us von UTF8 und UTF8MB4 ist absolut identisch.
Da PHP von Haus aus ja 4-Byte UTF8 unterstützt, kann es sowohl utf8 als auch utf8mb4 von der Datenbank lesen und verarbeiten.
Umgekehrt ist das schon kritischer: Wird ein 4-Byte UTF8 Zeichen an mySQL gesendet und dieses ist auf 'normal' utf8(mb3) eingestellt, geht das 4.Byte verloren. Läuft die mySQL mit utf8mb4, so ist alles völlig in Ordnung.
Soll eine neue Tabelle angelegt werden, so muss der höhere Speicherbedarf für UTF8MB4 berücksichtigt werden (4 Byte je Zeichen anstatt durchschnittlich 2-3 Byte je Zeichen bei UTF8). Das muss auch beim Anlegen von Indizes auf Textfelder berücksichtigt werden.

Codierungsbeispiele:
UTF-8-Codetabelle

	Z		Ä
HTML-Entitie	Z		Ä		𝌆
ASCII	[0x5A]	01011010	---	---	---	---
Latin1	[0x5A]	01011010	[0xC4]	11000100	---	---
Unicode (Code position)	[0x5A] U+005A	01011010	[0xC4] U+00C4	11000100	[0x01 0xD3 0x06] U+1D306	00000001 11010011 00000110
UTF8(PHP)	[0xC3 0x9A]	11000001 10011010	[0xC3 0x84]	11000011 10000100	[0xF0 0x9D 0x8C 0x86]	11110000 10011101 10001100 10000110
UTF8(mySQL)	[0xC3 0x9A]	11000001 10011010	[0xC3 0x84]	11000011 10000100	[0xF0 0x9D 0x8C]	11110000 10011101 10001100 (Fehler)
UTF8MB4	[0xC3 0x9A]	11000001 10011010	[0xC3 0x84]	11000011 10000100	0xF0 0x9D 0x8C 0x86	11110000 10011101 10001100 10000110

Man sieht hier auch deutlich den Speicherverbrauch der einzelnen Codierungsarten. Ungeachtet dessen sind jedoch die neuesten Versionen von mySQL bereits soweit optimiert, dass manche Aktionen mit UTF8MB4 schon schneller ablaufen als mit UTF-8. 

Manuela