Januar 2010:
101 - Endlich mal das mysql Collate "normalisieren"
Auf die Frage, wo denn der Unterschied zwischen
utf8_general_ci und utf8_unicode_ci
sei, bekam ich von Moreno Feltscher folgende Antwort:
Google wäre dein Freund gewesen: http://dev.mysql.com/doc/refman/5.1/de/charset-unicode-sets.html
Dort findet man irgendwo ganz unten im Text, daß utf8_general_ci
die schnellere (dafür weniger korrekt) Sortiermethode ist. Außer daß es soweiso der neue Standard von mysql und Typo3 ist, ist bei vielen Domains ein historisch gewachsenes Collate Wirrwar eigentlich tödlich.
102 - Warum man doch das Collate auf utf8 umbauen sollte
- Ergebnisse mit mnogosearch- So klappt das nun mal nicht, das sollte man korrigieren.
Die Wellen schlugen hoch bei den "Experten", als das Warum in der Newsliste angesprochen wurde und Manche meinten - bloß die Finger davon lassen.
Doch so einfach ist das nicht. Wir hatten aus langer Historie dieses "latin1_swedish_ci" über Jahre und es hatte (bei uns) funktioniert. Außerdem hatten wir nur MyISAM als Indexmaschine. Später kam mit neueren mysql Versionen InnoDB dazu und wurde sogleich mit "utf8_unicode_ci" eingerichtet. Das funktionierte leidlich, bis wir die indexed_search Suchmaschine ausprobiert hatten.
Dort tauchten in den Content Headern bei den Fundstellen (Treffern) sonderbare Sonderzeichen auf. Da diese Such-Geschwindigkeit aber nicht überzeugte, haben wir alles deinstalliert und uns auf die hochgelobte mnogosearch gestürzt. Dort war der Mischmasch eklatant und der Autor Dmitry riet zu einem "sauberen" Umgang mit einem !! universellen Zeichensatz.
Das Ganze macht wirklich Sinn.
So habe ich angefangen, meine beiden großen Webs umzubauen. Hier steht, wie ich es gmacht habe:
105 - Jan. 2010 - Eine Muster-Umstellung :
Korrigieren der Kollation von "latin1" auf "utf8_general" bedeute bei mir das Duplizieren der Datenbank "fernsehmuseum_info" nach "fernsehmuseum_2010".
Dazu ist der Shellzugriff mit putty erforderlich !!
108 - Die alte Datenbank dumpen:
Versuch 1:
(mysqldump -u"user" -p"passw" -hlocalhost --add-drop-table fernsehmuseum_info > /tmp/femuwi-info.sql)
erstes Ergebnis :
-rw-r--r-- 1 root root 23.582.355 9. Jan 21:21 femuwi-info.sql
Korrektur = Versuch 2:
Ich nehme aber die verbesserte Exportversion ohne !!!! Zeichensatzinfo (weil bereits mysql 4.0 oder höher !!) :
Die Kommandozeile (mit der --compatible Option) sieht jetzt so aus:
mysqldump -u"user" -p"passw" -hlocalhost --add-drop-table fernsehmuseum_info --compatible=mysql40 > /tmp/femuwi-info-neutral-utf.sql
verbessertes Ergebnis:
-rw-r--r-- 1 root root 25507117 9. Jan 21:26 femuwi-info-neutral-utf.sql
und jetzt mit "joe" oder "less" (bei uns unter Suse 11.1) überprüft, daß darin kein "latin1" String mehr gefunden wird!! also ist der Export File neutral.
110 - Diesen Dump in neue leere Datenbank einlesen:
mysql -u"user" -p"passw" -hlocalhost fernsehmuseum_2010 < /tmp/femuwi-info-neutral-utf.sql
Gleich mit phpmyadmin prüfen, ob die Umlaute korrekt angezeigt werden. Das ist natürlich nur der erste Grundtest, daß es überhaupt funktioniert hat. - bei uns stimmt es. Das reicht aber nicht !!!!!! Also aufpassen und ausgiebig überprüfen.
116 - jetzt noch 2 Ergänzungen von Hand in localconf.php
oder mit dem Install-Tool im Backend, das geht auch, ist aber für uns zu aufwendig.
forceCHarset = utf-8
und
SetDBinit = Set NAMES utf8;
hier das Semicolon am Ende nicht vergessen !!
So, es hat funktioniert mit ca. 1100 Seiten und 5600 Contentementen.
120 - Stolperfallen an allen Ecken
Auf der Homepage sind die Bilder weg und das Layout ist "zerrupft". Was ist das nun schon wieder ?
Es können in den html Templates vormalige Umlaute (sogar in den Kommentarzeilen !!! ) als "?" angezeigt werden und schon sind es keine Kommentare mehr und die Seite ist zerrupft wenn nicht sogar unsichtbar. - So war es bei mir.
Gehen Sie also Ihre html Templates in Ihrem Template Verzeichnis durch (bei uns wohnen die html Templates in fileadmin/templates/.
Da waren wirklich mehrere ehemalige deutsche Umlaute durch Fragezeichen substituiert und machten nur Ärger.
124 - der finale Test mit dem mnogo Indexer
Jetzt muß der mnogoserch Indexer nochmal laufen, bei uns werden mit phpmydamin alle Tabellen in der mnogosearch Datenbank geleert oder gelöscht, die Kollation muß auch auf utf8 kontrolliert bzw. korrigiert werden
und dann auf der Linux Commandozeile als user root
/usr/bin/php5 -q /vol2/www/www.fernsehmuseum.info/typo3/cli_dispatch.phpsh mnogosearch -v 3 -w
laufen lassen.
Es funktioniert.
www.fernsehmuseum.info/die-schnelle-suchseite.html
Hier jedenfalls fast.
130 - Gelerntes auf Web Nummer 2 anwenden
jetzt also Projekt Nummer 2 nach gleichem Schema umformen:
auslesen neutral !!
mysqldump -utypo3rootmaster -prdesqladmin191 -hlocalhost --add-drop-table dlt_lto_museen --compatible=mysql40 > /tmp/dlt_lto_museen-neutral-utf.sql
neue "Shadow"-Datenbank anlegen , dann Rechte zuweisen,
dann importieren
mysql -utypo3rootmaster -prdesqladmin191 -hlocalhost dlt_2010 < /tmp/dlt_lto_museen-neutral-utf.sql
es hatte funktioniert diesmal mit 1500 Seiten und 8500 Contenelementen
dann die Tabellen in der mngosearch Datenbank leere oder löschen. Die Kollation korrigieren
und dann
/usr/bin/php5 -q /vol2/www/www.useddlt.com/typo3/cli_dispatch.phpsh mnogosearch -v 3 -w
und warten und dann probieren.
134 - Probleme mit dem cag_pagebrowser
WICHTIG: in der cag_cagebrowser extension bei den statics im file constants (auch) die (ehemaligen) Umlaute reparieren (bei uns sind solche Schlüssel-Extensions immer global installiert).
und
im localconf.php diese Zeile wieder auskommentieren :
### $TYPO3_CONF_VARS['SYS']['UTF8filesystem'] = '1';
sonst geht der Pagebrowser nicht. Alles andere hatte dann funktioniert.
