TYPO3@lisardo

Ziel ist die Erstellung einer Extension, die alle Features zur Mehrsprachigkeit bietet, die zur Ausstattung von TYPO3 gehören.

Die Datenbank-Struktur

Diese drei Felder müssen zusätzlich in der Extension in der »ext_tables.sql« angelegt werden:

Die »ext_tables.php« muss so erweitert werden:

Und das »columns«-Array in der »tca.php« ebenfalls:

Wichtig: Damit die Zuordnung der Sprach-Overlays funktioniert, muss oben bei »foreign_table« die korrekte Tabellenbezeichnung der Extension eingegeben werden, ebenso bei »foreign_table_where« – insgesamt also dreimal.

Damit die Redakteure später nicht nur Language-Overlay-Datensätze anlegen, sondern einen Datensatz direkt einer Sprache zuordnen können (um z. B. Datensätze in einer Fremsprache anlegen zu können, ohne dass es zuvor einen Datensatz in der Standardsprache gibt), muss auch noch das »types«-Array in der »tca.php« erweitert werden:

Damit erscheint im Backend ein DropDown-Menü mit einer Auswahl von allen definierten Alternativ-Sprachen sowie der Auswahl »Alle«.

Im Backend müsste jetzt alles richtig ausgegeben werden: Die Redakteure können neue Datensätze anlegen, diese einer oder allen Sprachen zuordnen, oder nachträglich Datensätze in der Standardsprache übersetzen. Also genauso wie bei den normalen Inhaltselementen.

Natürlich muss die Ausgabe im Frontend das entsprechend berücksichtigen

Ausgabe von sprachabhängigen Texten ins Template

Damit sind nicht die Inhalte aus den Datentabellen gemeint sondern zum Beispiel Überschriften oder Labels für Formularfelder, die ebenfalls den Sprachen angepasst werden müssen. Diese Texte werden zunächst in die »locallang.xml« im pi1-Ordner der Extension eingetragen:

Diese Datei muss in UTF-8 abgespeichert werden, sonst gibt es entweder eine leere Frontend-Seite oder eine Fehlermeldung, je nach TYPO3-Version. Sie darf weder HTML noch Entities enthalten. In der Regel wirds das nicht brauchen (da die Datei ja UTF-8 ist), aber falls doch, gibt es folgende Möglichkeiten:

Entitiy definieren:

Sieht komisch aus, funktioniert aber. Die nächste Möglichkeit ist wahrscheinlich einfacher:

HTML in »locallang.xml«

Jeder HTML-eintrag muss also mit

maskiert werden.

Ausgabe ins Frontend

Damit eine Ausgabe möglich wird, muss die »class.tx_meineExtension_pi1.php« erweitert werden:

Die Zeile $this->pi_loadLL(); lädt die notwendige Klasse.

Die eigentliche Ausgabe des Textes erfolgt so:

Die Optionen bedeuten:

• Name/Bezeichnung des Eintrags in der »locallang.xml«
• Defaultwert – in der Regel ein englischer Begriff, als Platzhalter, falls der Eintrag in der locallang.xml fehlt
• TRUE wenn der Wert durch htmlspecialchars() laufen soll

Daten aus den Datentabellen auslesen

Das erweist sich als das eigentliche Problem. Ich habe noch keine endgültige Lösung, aber die folgende funktioniert fürs erste.

1. Schritt: Daten aus der Tabelle holen. Dabei interessiert erstmal nur der WHERE-Teil des sql-Statements, der Rest dürfte klar sein:

Erläuterung: In der Defaultsprache wird »$this->cObj->enableFields()« aufgerufen, damit die versteckten Datensätze (und die gelöschten etc) nicht sichtbar werden. Bei den Alternativ-Sprachen entfällt das in diesem Schritt sondern folgt erst in einem weiteren. Die Zeile »’ AND (sys_language_uid ….« wählt alle Datensätze aus, die in »sys_language_uid« 0 (= Standardsprache) oder -1 (= alle Sprachen) stehen haben. Sie wählt aber auch alle Datensätze in der Alternativsprache aus, die keinen Eintrag in der Standardsprache haben.

Im nächsten Schritt werden die Sprach-Overlays geholt: die Felder des Datensatzes werden mit den Einträgen in der Alternativ-Sprache überschrieben:

Je nach Spracheinstellung werden dabei auch Einträge entfernt – also z. B. wenn sys_language_mode=strict eingestellt ist, werden alle nicht übesetzten Einträge entfernt.

Über GLOBALS[‘TSFE’]->fe_user kann man sich die gesamte Konfiguration der Frontenduser ausgeben lassen:

Ergebnis:

Dabei werden die Daten des eingeloggten Benutzers und seiner Benutzergruppe ausgegeben. Damit kann einfach überprüft werden, ob es sich um einen gültigen Benutzer handelt und ob er der richtigen Gruppe angehört.

In eigenen Extensions gibt es eine einfache Möglichkeit zu verhindern, dass beim Einbinden von Dateien für den Download – zum Beispiel aus einem Unterordner von fileadmin – diese Dateien nochmals in den /uploads/-Ordner kopiert werden. Dazu muss in der tca.php der internal_type von file auf file_refence umgestellt werden:

Dadurch wird nicht mehr der reine Dateiname in der Datenbank gespeichert sondern der komplette Pfad auf die Datei. Natürlich muss das bei der weiteren Verarbeitung der Datei auch entsprechend berücksichtigt werden.

Weiterführende Links

• Typo3 API Dokumentation – darin Stichwort internal_type.

Datenbankabfragen sollten in Extensions nie über die normalen SQL-Befehle erfolgen. Gründe:

• die globale Datenbank-Abstraktionsschicht DBAL wird eingbezogen; heisst, die Extension läuft automatisch auch mit anderen Datenbanken als MySQL
• die Verbindung zur Datenbank muss nicht eigens erstellt und beendet werden
• die INSERT-Queries führen automatisch ein FullQuote durch (die Mindest-Absicherung gegen SQL-Injection)
• die verfügbaren Befehle sind zum Teil einfach bequem …

Funktionen aufrufen

Die Klassen müssen nicht initialisiert werden, es reicht, sie über die GLOBALS aufzurufen:

Absicherung gegen SQL-Injection

Alle Eingaben, die vom Besucher der Website kommen (also über GET oder POST) müssen vorher abgesichert werden. Das betrifft vor allem die Befehle zum Einfügen in die Datenbank, ausserdem aber auch die Übernahme von Benutzerdaten in die where-Abschnitte der SQL-Abfragen. Auch hier sollten die Typo3-Funktionen benutzt werden, damit die Quotierung für jede Datenbank passend erfolgt. Folgende Funktionen stehen zur Verfügung:

Parameter

• string: Zeichenkette, die quotiert werden soll
• string: Tabellenname (daraus entnimmt DBAL die korrekte Quotierungstechnik)

Parameter

• array: eindimensionales oder assoziatives Array mit den Daten
• string: Tabellenname (daraus entnimmt DBAL die korrekte Quotierungstechnik)
• string/array: Liste oder Array von Schlüsseln, die nicht quotiert werden sollen. Nur bei assoziativen Datenarrays anwenden!

Parameter

• string: kommaseparierte Liste mit Werten, die Integer sein sollen

Parameter

• array: Array mit Werten, die Integer sein sollen

Datenbankabfragen

Parameter

• string: Liste der Felder oder * für alle Felder
• string: Tabelle(n). Es gelten die üblichen SQL-Regeln für Aliase
• string: WHERE-Klausel. Wie in SQL üblich. ACHTUNG: man muss alle GET / POST-Werte hier selbst qotieren! Verwenden Sie $this->fullQuoteStr() – siehe oben. Hier nicht Befehle wie GROUP oder LIMIT verwenden.
• string: Optionale GROUP-Anweisung
• string: Optionale ORDER BY-Anweisung
• string: Optionale LIMIT-Anweisung.

Parameter

• string: Tabelle
• array: Feldwerte als array mit key=>value Paaren. Die Werte werden intern quotiert. Typischerweise verwenden Sie ein Array “$insertFields” mit ‘fieldname’=>‘value’ und übergeben es als Argument.
• string/array: Liste oder Array von Schlüsseln, die nicht quotiert werden sollen; siehe ober bei fullQuoteArray()

Parameter

• string: Tabelle
• string: WHERE-Anweisung, typischerweise “uid=xx”. Achtung: Sie müssen alle GET- oder POST-Parameter hier selbst quoten – siehe oben.
• array: Feldwerte als array mit key=>value Paaren. Die Werte werden intern quotiert. Typischerweise verwenden Sie ein Array “$insertFields” mit ‘fieldname’=>‘value’ und übergeben es als Argument.
• string/array: Liste oder Array von Schlüsseln, die nicht quotiert werden sollen; siehe ober bei fullQuoteArray()

Parameter

• string Tabelle
• string WHERE-Anweisung, typischerweise “uid=xx”. Achtung: Sie müssen alle GET- oder POST-Parameter hier selbst quoten – siehe oben.

Spezielle Datenbank-Anweisungen

Die folgende Funktion eignet sich hervorragend zum Auswerten einer n-n Datenverbindung, wie sie zum Beispiel bei der Verwendung von Kategorien anfällt. Bedingung ist allerdings, dass die Verbindung mit einer m_m-Tabelle erfolgt und nicht über ein einzelnes Feld mit kommaseparierter ID-Liste.

Parameter

• string: Liste der Felder oder * für alle Felder
• string: Name der lokalen Tabelle
• string: Name der Relationalen m_m-Tabelle
• string: Name der fremden, verknüpften Tabelle
• string: WHERE-Klausel. Wie in SQL üblich. ACHTUNG: man muss alle GET / POST-Werte hier selbst qotieren! Verwenden Sie $this->fullQuoteStr() – siehe oben. Hier nicht Befehle wie GROUP oder LIMIT verwenden. Es muss ein ‘ AND ‘ eingefügt werden.
• string: Optionale GROUP-Anweisung
• string: Optionale ORDER BY-Anweisung
• string: Optionale LIMIT-Anweisung.

Achtung: Viele Feldnamen in Typo3 sind identisch (uid, pid, hidden etc.). Das kann bei der Auswertung zu Problemen führen, da die Felder nicht eindeutig sind! Es ist deshalb sinnvoll, imm select- und für die Tabellennamen mit Aliasen zu arbeiten:

Ein ganz besondere Funktion ist listQuery(): Sie ermöglicht eine einfache Behandlung von relationalen Verknüpfungen, die nicht über eine dritte m_m-Tabelle laufen sondern über Felder mit kommaseparierten Listen.

Das Problem derartiger Verknüpfungen ist, dass die Abfrage über LIKE laufen muss, und dabei zusätzlich unterschieden werden muss, auf welcher Seite des gewünschten Wertes das Komma folgt. Kern der Funktion ist diese Zeile:

Parameter

• string: Feldname, der die kommaseparierte Liste enthält
• string: Wert, der gefunden werden soll
• string: Tabelle, in der gesucht wird (für die korrekte Behandlung durch DBAL)

In die gleiche Richtung geht die folgende Funktion, die Srings für die LIKE-Abfrage korrekt für DBAL umsetzt:

WICHTIG: Es gibt eine hervorragende Abkürzung, um die wichtigen einschränkenden Felder in der WHERE-Abfrage automatisch einzuschließen: hidden, deleted, von/bis, Frontenduser etc. Die WHERE-Abrage muss einfach damit erweitert werden:

Also zum Beispiel in der exec_SelectQuery:

Noch drei weitere Funktionen werden öfter gebraucht:

Parameter

• pointer: Der Resultpointer einer vorher erfolgten SELECT-Abfrage.

Weiterführende Links

• Typo3 Dokumentation Darin suchen nach »t3lib_DB«.
• t3lib_DB Class Reference (Achtung: geht ausserhalb seines Framesets auf).

Achtung: Keine Gewähr: bei mir hat das folgende geklappt, aber es hängt stark von der Konfiguration von PhpMyAdmin ab! Das muss nämlich bereits korrekt auf utf-8 konfiguriert sein (was allerdings bei neuen Verisionen der Fall sein sollte). Siehe unten die beiden Links für eine Version, die sicherer funktioniert, aber leider Shell-Zugriff benötigt.

Ziel ist die Umstellung einer vorhandenen Installation in ISO-8859-1 nach utf-8. Dazu sind eine Reihe von Schritten nötig:

• mit PhpMyAdmin die Datenbank exportieren. PhpMyAdmin erstellt dabei standardmäßig eine Datei in utf-8; heisst, die Daten sind bereits konvertiert.
• neue DB anlegen und dabei darauf achten, dass die neue DB eine Collation von utf8_general_ci bekommt. Notfalls nachträglich in PhpMyAdmin in der Karteikarte »Operationen« umstellen.
• Die exportiere SQL-Datei in einem Editor öffnen und dort die Einträge “DEFAULT CHARSET=latin1” entfernen.Achtung: bei mir gab es ein Problem mit der Tabelle »tx_realurl_pathcache« – beim Import erhielt ich eine Fehlermeldung, dass der Schlüssel länger wäre als 1000 Zeichen, was nicht erlaubt ist. Das liegt an der Umstellung auf utf-8: durch die benötigten 2 – 3 Byte pro Zeichen wird der Schlüssel zu lang. Ich habe deshalb bei dieser Tabelle “DEFAULT CHARSET=latin1” gelassen.
• Danach die Datei mit PhpMyAdmin importieren. Wenn alles richtig eingestellt ist, werden die Daten jetzt als utf-8 eingelesen. Das kann kontrolliert werden mit einer kleinen PHP-Datei:

Den Output überprüfen, indem die Kodierung im Browser entsprechend umgestellt wird (oder denOutput mit einem HTML-Header erweitern und ein charset mitgeben). Entscheidend ist diese Zeile:

sie stellt nämlich die Collation der Verbindung auf utf-8 um, die sonst standardmäßig auf latin stehen würde. Jetzt müssten alle Seitennamen korrekt in utf-8 im Browser erscheinen und PhpMyAdmin müsste sie ebenfalls korrekt anzeigen. Ohne Umstellen der Verbindung würde PhpMyAdmin zwar korrekt utf-8 in die Datenbank schreiben, wir würden aber mit PHP immer noch latin auslesen.

Der Witz ist, dass jetzt wirklich diese Testdatei und PhpMyAdmin die korrekten Zeichen anzeigen müssen!

Allerdings klappt es in TYPO3 noch nicht. Nächster Schritt:

• Im Installtool muss bei [forceCharset] “utf-8” und bei [setDBInit] “set names utf8” eingetragen werden. Der erste Eintrag sorgt dafür, dass das Backend und die Frontendausgabe immer auf utf-8 eingestellt sind und die zweite Angabe stellt die Kollation der Datenbankverbindung auf utf-8. Insbesondere der zweite Eintrag ist nötig, sonst erhält TYPO3 durch die falsche Standardkollation der Verbindung (latin) doch keine utf-8-Daten.

Weiterführende Links

• UTF-8-Umstellung (Großen Dank an Oliver, der Tipp mit [setDBInit] war der entscheidende Hinweis nach einigen Stunden Suche).

• MySQL und TYPO3 auf UTF-8 umstellen

• MySQL: Zeichensatz-Grundlagen – Der ausführlichste Artikel zum Problem der Zeichensätze in MySQL. Köhntopp rät allerdings von einer Umstellung der gesamten Datenbank auf UTF-8 ab und begründet das auch überzeugend mit Speicher- und Performance-Vorteilen. Allerdings erfordert sein Ansatz sehr genaues Arbeiten – Definition von CHARSET und COLLATION auf Spaltenebene.

• UTF-8 für alle – der Artikel thematisiert einige Probleme der String-Verarbeitung in UTF-8 innerhalb von PHP. Ausführlicher in Handling UTF-8 with PHP