CONTENIDO Forum

Hallo,

nach dem Login in ein frisch installiertes 4.8.20 fehlt der 1. Submenüeintrag (siehe Scrennshot).
Gruß aus Franken

Ortwin

Mit welcher PHP-Version tritt das Problem auf?
Betrifft dieses Phänomen auch andere Tabs, die einen Umlaut in der Übersetzung haben?

Ja es sind alle Submenüs mit Umlauten betroffen.

Gruß aus Franken

Ortwin

Tritt das Problem auch mit einer 4.8.19 Installation auf?

Keine Ahnung, da hab ich aber auch gerade keine Zeit zum Ausprobieren, zumal die 4.8.20 offensichtlich noch weitere Encoding-Probleme auch bei der DB zu haben scheint. Ich musste hier aber weiter machen, der Kunde wartet, und hab nun halt meine 4.8er Version genommen. Falls ich die Tage mal Zeit habe installiere ich vielleicht nochmal eine blanke 4.8.19.

Gruß aus Franken

Ortwin

Hallo,

genau dieses Phenomän ist mir auch vor kurzem bei ALLEN 4.8.20er Versionen aufgefallen. Immer der erste Eintrag im Submenü "Übersicht" ist unbeschriftet, wie beim 1. Post auf dem Screenshot zu sehen. Hat mich ein Kunde darauf aufmerksam gemacht. Dummerweiße habe ich schon einige Installationen auf die .20er Version geupdatet..

Gibt es hier schon eine Lösung? Am besten eine neue Version.

Grüße Alex

/edit: Gerade eben habe ich wieder ein Update auf die 20 durchgeführt - und siehe da: Das erste Mal wird "Übersicht" auch angezeigt. Bei dieser Installation war vorher kein Mod-Rewrite installiert. Bei allen anderen schon. Kann es damit zusammen hängen??

Ich habe diese Probleme nicht bei 4.8.20.
PHP ist 5.2.17 und MySQL 5.5.x

Modrewrite war allerdings auch nicht installiert, hab ich erst bei der 4.8.20 gemacht.
Aber ob es damit zusammenhängen soll, weil die Menüeinträge sind ja intern im Backend?
Ich vermute da auch eher was mit PHP und einem Fehler in der Codierungs-Behandlung im Programm, denn wenn da was spinnt, gibts einfach keine Ausgabe und keine Fehlermeldung (hatte ich gerade neulich so einen Fall im eigenen Modul).
In meinem Fall war es so, dass die Ausgabe-Seite ein UTF-8 Dokument war und in der Datenbank aber Latin-1 (swedish-Standard) als Kollation eingestellt und die Zeichen auch Latin-1 waren.
Dadurch erschienen die ominösen Fragezeichen in der dunklen Raute oder Kreis.
Beim Test mit verschiedenen Zeichencodierungen und Behandlungen mit PHP ist auch ab und zu einfach gar nichts erschienen, also das ganze Wort nicht, ohne Fehlermeldung.
Das würde fast zu obigem Problem passen.

Die Lösung war und ist (hinterher) simpel: Ich lasse die Datenbank einfach bei Latin-1 swedish und wandle danach den aus der Datenbank geholten Text in UTF-8 um und schon funktioniert es und ein ü in der Datenbank wird auch als ü in der Webseite angezeigt.
Vielleicht fehlt in den anderen PHP-Installationen die Zeichenbehandlung, wie z.B. Multibyte (mb_) ?

Wahrscheinlich muss ich dann bei Formular-Eingaben auf einem UTF-8 Dokument auch dafür sorgen, dass die Zeichen vor der Datenbank-Speicherung in ISO-8859-1 codiert werden, sonst stehen in der Tabelle die Hiroglyphen.
Der Hintergrund für den Umstand ist der, dass ich die Daten in der Datenbank im Reintext lesen und bearbeiten können muss und phpmyadmin als auch andere Datenbank-Client-Programme kein UTF-8 speichern.
Würde ich eine UTF-8 Text-Zelle über phpmyadmin bearbeiten, dann stünden dort danach Latin1 Zeichen drin und schlimmstenfalls noch gemischt, also Supergau

Hört sich alles vernünftig an. Allerdings, was muss ich jetzt wo ändern? O:-)

Gibt es hierzu schon was Neues?

Ja, ich habe heute eine 4.8.11 auf 4.8.20 geupdatet und da traten diese Fehler nicht auf.
PHP ist 5.2.11 und Mysql ist 5.5

Ich verwende in dieser Seite auch kein UTF-8, sondern nur das schöne ISO 8859-1

Edit: Nur die Seite benützt lediglich ISO 8859-1 aber die Datenbank ist durchgehend (!) auf utf8_general_ci eingestellt.

Habe jetzt auch noch ein bisschen geforscht und gesehen, dass in der lang_de_DE.xml das encoding auf ISO-8859-1, wenn ich es allerdings auf UTF-8 umstellen bekam ich im Backend einen Fehler bei den Einträgen. Dann habe ich wieder zurückgestellt auf ISO-8859-1 und habe die Umlaute in der Datei wieder angepasst und siehe da die Umlaute waren jetzt auch im Backend OK. Dann habe ich die Datei wieder editiert und das encoding noch mal auf UTF-8 geändert und jetzt kam auch kein Fehler im Backend mehr.

Schertle hat geschrieben:Habe jetzt auch noch ein bisschen geforscht und gesehen, dass in der lang_de_DE.xml das encoding auf ISO-8859-1, ...

Vielleicht lag's daran:
Bei UTF-8 muss nicht nur das encoding utf-8 als Hinweis lauten sondern auch das Dokument selbst in utf-8 abgespeichert sein.
Es kann manchmal (oder oft so) sein, dass Umlaute und andere Zeichen ursrpünglich in anderem Charaktercode waren oder noch sind, diese muss man dann im Editor, womit das utf-8 Dokument geöffnet wurde, ersetzen (also z.B. alle ä,ö,ü,ß nochmal nachtragen im utf-8 Dokument und wieder als utf-8 abspeichern).
Manche Editoren können nur im ANSI oder utf-8 Format speichern und manche wandeln die bestehenden Zeichen nicht richtig um.

Faar hat geschrieben:Manche Editoren können nur im ANSI oder utf-8 Format speichern und manche wandeln die bestehenden Zeichen nicht richtig um.

Notepad++ kann alle Formate und dazwischen auch konvertieren.

Gruß
Zuschauer

Zuschauer hat geschrieben:Notepad++ kann alle Formate und dazwischen auch konvertieren.

PSPad kann das auch.
Eine Softwareauswahl ist aber schon etwas Offtopic. Zumal das viele gängige Code-Editoren heute können oder per Plugin dafür erweiterbar sind.

Gruß aus Franken

Ortwin

Hallo Leo,


Habe die Datei "contenido/xml/lang_de_DE.xml" im Editor geöffnet. Editor auf UTF-8 gestellt. Gespeichert. Fertig.

Jetzt stehe ich den Menüpunkt Übersicht wieder.

Gruß sarronsarron