Umlaute in Dateinamen bei WB 2.6.5

[ruebenwurzel]

Hallo,

Leider konnten wir ein altes Problem mit der falschen Konvertierung von Umlauten auch in WB 2.6.5 noch nicht lösen. Für die Konvertierung der Dateinamen ist die Datei convert.php im framework Verzeichnis zuständig. Für die deutschen Umlaute gibt es im Anhang eine gefixte Version, die diesen Fehler beseitigt. Die Datei funktioniert aber nur, wenn auch der charset auf ISO-8859-1 eingestellt ist. (in den erweiterten Optionen von WB)

Installationsanleit ung convert.php:
- Download der Datei convert.zip
- Entpacken zu convert.php
- per ftp in das framework Verzeichnis hochladen und die bestehende Datei überschreiben

Die geänderte convert.php konvertiert nur Seitennamen, die nach der Installation der geänderten Datei angelegt werden. Bereits bestehende Seitennamen mit falschen Namen werden nicht geändert. Diese können nur manuell geändert werden. Dazu sind folgende Schritte notwendig

nachträgliches ändern von Dateinamen:
- per phpmyadmin in der Datenbank den Dateinamen ändern ("gE4stebuch" zu "gaestebuch")
- im pages Verzeichnis den Dateinamen entsprechend anpassen ("gE4stebuch.php" zu "gaestebuch.php")

Edit:
Umlaute in Texten

Aus den nachfolgenden Beiträgen ist zu entnehmen, dass es anscheinend auch Probleme mit Umlauten in Texten geben kann. Hier nochmals eine kurze Zusammenfassung:

1. Wenn in der Datenbank die Umlaute so gespeichert werden wie sie geschrieben sind ( z.b. "ü" ist als "ü" gespeichert), werden diese sowohl im Adminbereich als auch auf der Homepage nur dann richtig dargestellt wenn der charset auf "iso 8859-1" eingestellt ist. (HTMLArea speichert standardmäßig die Umlaute so wie sie geschrieben sind)

2. Wenn in der Datenbank die Umlaute in Htmlschreibweise gespeichert sind ( z.b. "ü" ist als "ü" gespeichert), werden diese sowohl im admin Bereich als auch auf der Homepage auch dann richtig angezeigt wenn alternativ der charset auf "utf8" eingestellt ist. (FCKEDitor wandelt standardmäßig alle Umlaute beim speichern automatisch in HTMLCode um)

Viel Spaß

Matthias

[onliner45]

Hallo Matthias,

danke, für die neue convert.php - habe gerade wie beschrieben installiert, neue Seite (Täst) wird auch in der Seitenansicht richtig angezeigt, jedoch auf der Adminebene kommen die Umlaute nicht mit.

Sehe ich mir die Seite "Täst" im ftp an - ebenfalls nicht mit mit ae sondern "tC3A4st.php" was könnte  ich besser machen?

LG Martin

[ruebenwurzel]

Hallo,

hast du schon mal versucht den charset von utf8 auf iso-8859-1 einzustellen?

Matthias

[Waldschwein]

@onliner45: Genau das Problem hatte ich heute auch- bis ich in phpMyAdmin unter /settings das charset eben von utf-8 auf iso-8859-1 gestellt habe. Es kann sein, dass du- um es nachträglich richtig darzustellen- dann eben die Umlaute bearbeiten musst.

[onliner45]

jap,

ich habe die Einstellungen geändert und es läuft - auch die Umlaute in den Texten habe ich geändert - das Problem ist nur, bei einer bestehenden Seite alles kompl. zu überprüfen und ggf. zu ändern.

[ruebenwurzel]

Hallo,

@waldschein

in phpMyAdmin unter /settings das charset eben von utf-8 auf iso-8859-1

Eigentlich stellt man den Charset in den erweiterten Optionen von WB ein. Ein Bearbeiten der Datenbank ist nicht notwendig.

@onliner45

auch die Umlaute in den Texten habe ich geändert - das Problem ist nur, bei einer bestehenden Seite alles kompl. zu überprüfen und ggf. zu ändern.

Das wundert mich ein bisschen, dass man hier etwas ändern muss. Wie waren die Umlaute denn vorher in der Datenbank gespeichert? (Kann man am besten über das Sourcecode Fenster des WYSIWYG Editors sehen.). Sie sollten entweder als "ü" oder als "ü" in der Datenbank stehen. Bei allen Testseiten die wir hatten gab es keinerlei Probleme mit den Umlauten. Wir haben auch an diesem Teil in WB überhaupt nix verändert, so dass ich jetzt doch erstaunt bin, dass es hier Probleme gibt.

Matthias

Edit:
Also habe nochmal ein bisserl experimentiert.

Wenn ihr HTMLArea als WYSIWYG Editor einsetzt speichert dieser alle Umlaute so wie sie geschrieben sind in der Datenbank. ("ü" wird als "ü" gespeichert). Dies kann sowohl in in WB admin als auch auf der Homepage nur angezeigt werden wenn bei beiden charset iso-8859-1 eingetragen ist.

Wenn ihr FCKEditor einsetzt (was ich dringend empfehle) dann werden die Umlaute in HTML code gespeichert ("ü" wird zu "ü"). Bei dieser Art werden die Seiten auch richtig angezeigt wenn man als charset utf8 (der internationaler Standard ist) eingestellt hat.

Das Umschreiben der Umlaute in der Datenbank geschieht automatisch, wenn man FCKEDitor als Standardeditor einrichtet und all Seiten einmal ohne sonstige Änderungen mit FCKEditor gespeichert hat.

Nachteil: Die Such in WB kann momentan die html codes noch nicht zuordnen. Wenn man also im Text Umlaute hat und nach diesen Worten suchen will (z.b. Überschrift) wird dies nicht gefunden, da die Suche in der Datenbank sucht und dort halt "Überschrift" gespeichert ist. Aber das Problem is bekannt und wird spätestens bei WB 2.7 behoben sein.

[Waldschwein]

Vielleicht hat es mit dem erweiterten News-Modul zu tun bzw. mit der einen Datei, die Umlaut-Probleme beim Bearbeiten von News-Seiten behob?
Ich kenn mich da nicht gerade aus, ob es Auswirkungen auf das sonstige WB hat.

[ruebenwurzel]

@waldschwein

Vielleicht hat es mit dem erweiterten News-Modul zu tun

1. Das hat nix mit dem erweiterten news modul zu tun
2. Wenn du das erweiterte Newsmodul einsetzt, darfst du die kompletten Dateien des Newsmoduls nicht mit den geänderten Dateien von WB 2.6.5 überschreiben (siehe entsprechenden Hinweis auf der addons Seite dort wo es das erweiterte News Modul gibt). Falls du die Dateien überschrieben hast, ist dein newsmodul nicht mehr lauffähig. Ich rate dir dringend die Dateien des erweiterten Moduls wieder auf den Server zu laden. Das gleich gilt übrigends für das formmodul. Du hast durch das Überschreiben keine Nachteile, da alle Änderungen die im normalen News modul gemacht worden sind bereits seit einiger Zeit schon in dem erweiterten Modul enthalten sind.

Manchmal frage ich mich, warum wir Hinweise bei den Modulen dazuschreiben und diese sogar noch mit roten Ausrufezeichen versehen, wenn sich dann doch keiner dran hält. 

Matthias

[Waldschwein]

Nicht aufregen, ruebenwurzel- ich hatte doch gar kein erweitertes News-Modul. 
Ich hatte nur mit dem Standard-Newsmodul Probleme mit Umlauten, daher habe ich mir die geänderte Version geholt, hier aus dem Forum (war nur eine Datei, entweder von dir oder von kweitzel).
Aber natürlich habe ich den Modul-Ordner beim Überschreiben bzw. Updaten von WebsiteBaker 2.6.4 NICHT angetastet. 
Wie gesagt- war nur eine Vermutung (denn irgendwelche Änderungen könnte ja auch ein Modul auf die Datenbank haben...)
 

[free0815]

Danke für die neue convert.php!

 

[Marc Geldon]

Besteht eine Möglichkeit das sich diese "korrekte" convert.php in WB 2.6.6 wiederfindet?


LG,

Marc

[ruebenwurzel]

Hallo,

leider ist diese convert.php nur für deutsche Umlaute funktionsfähig. Kyrillisch, Hebräisch, Griechisch ... kann damit nicht konvertiert werden. Bin mir aber ziemlich sicher, dass wir in WB 2.6.6 eine Lösung gefunden haben werden.

Matthias

[Schnetty]

Aumann, seit heute morgen bekomme ich im Adminbereich bei verschiedenen Klicks (mal auf speichern, mal nur weil ich nen Menüpunkt anklicke) diese Fehlermeldung:

Fatal error: Maximum execution time of 2 seconds exceeded in f:\srv\www\htdocs\web2345\www\wb\include\phplib\template.inc on line 500

Was kann das wohl sein? Liegt das am Hoster?

Greets
Schnetty

PS. Ebenfalls Thanx für die convert.php  und auch für die Links

[Macros]

Aumann, seit heute morgen bekomme ich im Adminbereich bei verschiedenen Klicks (mal auf speichern, mal nur weil ich nen Menüpunkt anklicke) diese Fehlermeldung:

Fatal error: Maximum execution time of 2 seconds exceeded in f:\srv\www\htdocs\web2345\www\wb\include\phplib\template.inc on line 500

Was kann das wohl sein? Liegt das am Hoster?

Hi,
ja das liegt am Hoster, wenn es denn einer ist, der hat die Ausführungszeit für PHP Scripte auf 2 Sekunden gestellt, normal sind 30 ...

aber wenn man schon unter Windows hostet, warum dann nicht mit dem IIS?

Gruss

[fotoMP]

Hallo @alle,
die Umlaute funktionieren jetzt. Aber die Ordner bekommen jetzt einen anderen Namen?
"fachgeschaefte" nach Update "fachgeschE4fte" obwohl alle unterseiten von
Fachgeschäfte sind?

3 Seiten sthen unter "fachgeschaefte" die neue Seite nach Update  unter ""fachgeschE4fte"?

Gruß

fotoMP

[Schnetty]

Hi,
ja das liegt am Hoster, wenn es denn einer ist,

Ja es ist einer - aber was für einer 

[ruebenwurzel]

@fotoMP

Bitte lies die erste post hier im thread und benutze die dort angehängte convert.php und ISO-8859-1, dann wird aus dem Seitennamen "Fachgeschäfte" die Datei "fachgeschaefte.php".

In diesem Post findest du auch die Anleitung, wie man Dateinamen nachträglich von "fachgeschE4fte" in "fachgeschaefte" umwandelt.

Bitte erst lesen dann posten 

Danke

Matthias

[fotoMP]

@Matthias

sorry hatte Probleme mit dem Uploade!?

Ich werde mich bessern..

fotoMP

[Pittiplatsch]

hallo

irrgendwie gehts bei mir net

ich habe alle seiten gelöscht und eine Seite angelegt die ich " Über uns " genannt habe.

Ergebniss: pages/tF6E4st/DCber-uns.php

im browser und so wird sie auch gespeichert.

Unter den erweiterten Optionen ist auch charset auf ISO-8859-1 eingestellt

[ruebenwurzel]

@Pittiplatsch

bist du sicher, dass du die convert.php ausgetauscht hast, so wie ich es im ersten thread empfohlen habe?

Matthias

[Pittiplatsch]

japp
100%tig Matthias

Er legt mir die Verzeichnisse und die Dateien nicht convertiert ab.

[ruebenwurzel]

@Pittiplatsch

Ja was denn, kapiers jetzt nicht ganz. Du hast dich an die Anweisungen aus dem ersten Thread gehalten, es ist garantiert sicher, dass du die geänderte convert.php einsetzt, charset ist auf ISO-8859-1 eingestellt. Wenn du das alles gemacht hast werden neue Seiten richtig formatiert abgelegt. Garantiert, ansonsten hast du was falsch gemacht.

Wie du in ersten thread sicherlich auch gelesen hast (man ist eindeutig im Vorteil wenn man lesen kann) werden bereits bestehende Dateinamen durch die Änderung nicht convertiert, sondern nur neue die man nach den genannten Änderungen anlegt. Oder solltest du das vielleicht doch überlesen haben??

Matthias

[Pittiplatsch]

hallo Matthias,

lesen kann ich noch und das was dort steht hab ich auch gemacht.

nur leider nicht mit dem gewünschten ergebniss.

Folgendes habe ich gemacht:

convert runtergeladen und die alte mit der neuen ersetzt.
dann unter optionen charset wie beschrieben ausgewählt, war aber auch schon so eingestellt.

dann alle bestehenden Seiten gelöscht.

dann neue Seite angelegt.

Ergebniss = keine änderung eingetreten.


Gruß

micha

[albatros]

Hallo Mathias,

vielen Dank für die convert. Funktioniert alles tadellos, aber...

eine Frage habe ich noch:

Was muss ich wo einstellen, damit die Suchfunktion auch Worte mit Umlauten findet?

Wie immer, herzlichen Dank im Voraus!!!

Gruß

Uwe (albatros)

Edit: Ist das http://forum.websitebaker.org/index.php/topic,3842.0.html schon die Lösung? (Bei Joomla wird es auch so gelöst)

[ruebenwurzel]

@albatros
leider ist dies dir schlechteste Lösung für die Suche, da damit die richtige html schreibweise wieder ausgehebelt wird. Dass Joomla das so macht wundert mich nicht, ich denke aber WB sollte hier besser sein und in der nächsten Version auch richtig convertierte Umlaute in der suche erkennen können.

@pittiplatsch
aber irgendeinen Fehler machst du. Sonst würde es funktionieren. Wenn du die convert.php.txt runterlädst, wird die gleich in deinem Browser angezeigt, oder hast du nur die Möglichkeit sie auf der Fesplatte zu speichern. Nimm auf jeden Fall die zweite Möglichkeit. Oder Versuchs gleich über die rechte Maustaste mit Ziel Speichern unter, dann umbenennen, dann ins richtige Verzeichnis hochladen. Keine Ahnung was du treibst, aber irgend etwas machst du jedenfalls falsch.

Matthias