TYPO3@lisardo

Mit dem Extensionbuilder können Datenbank-Relationen für Extbase-Extensions leicht angelegt werden. Das wirklich schöne Interface hat aber zumindest in meinem Fall dazu geführt, dass ich mich anfangs nicht darum gekümmert habe, was genau denn dabei passiert. Und dann stand ich plötzlich vor dem Problem, dass die 1:n-Relation doch bitte ohne IRRE funktionieren soll. Das Problem ist an sich leicht zu lösen, aber eben nicht mehr allein über den Extensionbuilder. 

Worin liegt das Problem? 

Model A (Location) soll eine 1:n-Verbindung erhalten zu Model B (Image). Ziel ist die Präsentation von Orten mit Adresse, Beschreibung und beliebig vielen Bilder. Wird die Relation über den Extensionmanager angelegt (was sehr einfach geht), dann bekomme ich im Location-Datensatz im Backend ein IRRE-Feld für die Bilder. Soweit wunderbar einfach für den Redakteur, wenn es sich um ein paar Bilder handelt. Was aber, wenn es mehrere hundert Bilder sind? IRRE mit hunderten von Datensätzen macht keinen Spaß. 

Nun liegt der Gedanke nahe, einfach anders herum zu gehen: Wir legen einfach eine n:1-Verbindung von Model B (Image) zu Model A (Location) an. Im Backend ist das Ergebnis perfekt: Im Location-Datensatz sind die IRRE-Relationen zu den Bildern weg, während jetzt ein DropDown im Image-Datensatz erscheint, in dem die Location ausgewählt werden kann. Aber leider wird jetzt das Objekt auch anders herum gemappt: Model A (Location) enthält keinen Bezug mehr zu Modul B (Image) und die Locationliste zeigt somit keine Bilder mehr. Dagegen funktioniert es jetzt anders herum: die Bildliste enthält jetzt die Locations, was ich nicht brauche. 

Was ich erreichen will: 

Das Backend soll sich verhalten wie oben beschrieben, es soll also ein DropDown in den Bilderdatensätzen erscheinen, in dem ich die Location auswähle. Im Extensionbuilder erhalte ich das über eine n:1-Relation in Model B (Image). Für die Frontendausgabe brauche ich jedoch eine Liste der Locations mit den Bildern, was ich bekomme, wenn ich im Extensionbuilder eine 1:n-Relation in Model A (Locations) anlege. 

Wie bekomme ich das aufeinander? 

Datenbank

ich lege in der Datenbank zwei Felder an: in der Location-Tabelle das Feld "images" und in der Image-Tabelle das Feld "locations". Beide bekommen int(11) als Format. 

TCA

Im TCA der Location-Tabelle erstelle ich eine Definition für das Feld "images" in dieser Art: 

'type' => 'inline'
'foreign_table' => '….…._image',
'foreign_field' => 'locations',

damit erhalte ich das IRRE-Feld im Location-Datensatz. Im TCA der Image-Tabelle wird das Feld "locations" so definiert: 

'type' => 'select',
'foreign_table' => 'tx_camplist_domain_model_location',

wobei ich als Typ angeben kann, was ich benötige, hier ein Select, also je nach den weiteren Definitionen entweder ein Auswahlfeld oder ein DropDown. 

Objektmapping in beiden Models

Beide Models erweitere ich nun um die Objekt-Attribute $images im Location-Model (die Kommentare nicht vergessen!) und $locations im Image-Model. Dazu natürlich in beiden Models die passenden Getter und Setter ergänzen. 

Abschluss

Man kann jetzt im Backend die Bilder auf zwei Arten hinzufügen: entweder direkt als Datensatz und dort die Location in einem Dropdown auswählen, oder über IRRE im Location-Datensatz. Wenn ich die IRRE-Felder im Location-Datensatz verstecken will, so lösche ich im TCA der Location-Tabelle unter "types.1.showitem" den Eintrag "images". 

Es ist prinzipiell möglich, den RTE in Flexforms – und damit auch in FCEs – zu konfigurieren. Wie das geht, wird  im Wiki auf typo3.org beschrieben, oder in der API-Dokumentation (nach »defaultExtras« suchen). Mit diesem Eintrag in den defaultExtras wird der RTE z. B. beschränkt auf fett, kursiv und Links:

Oder vielmehr sollte ... es funktioniert nämlich nicht mehr. Es gibt einen Bug-Report dazu, dem auch ein Patch für die Core-Klasse class.t3lib_tceforms beiliegt. Nach dem Einspielen des Patch funktioniert es wieder. 

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.