Beiträge getaggt mit typo3

Fluid Select mit Objekten in Hierarchie darstellen

Folgendes Datenmodell: Objekte vom Typ ‚Items‘ und Kategorien. Eine Kategorie hat eigentlich nur einen Titel, kann aber über das Feld ‚parent‘ einer anderen Kategorie als Kind zugewiesen werden, so dass eine Art Baum entsteht. So ist z.B. in Kategorie A.1 ist Kategorie A als Parent gesetzt.

- A
-- A.1
-- A.2
--- A.2.I
--- A.2.II
-- A.3
- B

Nun will ich in einem Select-Feld die Kategorien ausgeben, dabei würde ich gerne den vollen Pfad zur Kategorie im Select ausgeben und nicht nur den Titel der Kategorie. So würde dann die Auswahl im Select-Feld so aussehen:

A
A > A.1
A > A.2
A > A.2.I
[...]

Und das ist meine (wie ich finde elegante) Lösung: das Select-Feld in Fluid wird dann so definitert:

<f:form.select property="category" options="{categories}" prependOptionLabel="Bitte wählen" prependOptionValue="" optionLabelField="titlePath"/>

Die Eigenschaft titlePath exisitert in der Kategorie natürlich nicht, aber Fluid bedient sich da des Getters, also muss nur der entsprechende Getter definiert werden. In dem Getter ruft man dann die gleiche Funktion vom Parent auf. That’s it!

/**
 * @return string
 */
public function getTitlePath() {
    if($this->parent == null) {
        return $this->title;
    }
    return $this->parent->getTitlePath().' - '.$this->getTitle();
}

Fluid Formular für neues Objekt mit Select und leerer Option

Ich implementiere gerade eine Extension mit (vereinfacht) folgendem Aufbau: Objekte vom Typ ‚Items‘ können jeweils einer Kategorie zugeordnet werden. Die Kategorien sind wiederum in der Datenbank als Datensätze hinterlegt. So etwas kommt häufig vor, das beliebteste Beispiel ist wahrscheinlich ein Blog-Eintrag und die dazugehörige Kategorie.

Erstellt man diese Extension z.B. über den Extension Builder und lässt sich eine new/create-Action anlegen, kann man im Frontend nun auch Objekte vom Typ ‚Item‘ anlegen. Nun hatte ich folgende Hürde zu meistern: das Feld Kategorie ist ein Pflichtfeld, trotzdem soll in der Kategorieauswahl im Frontend eine zusätzliche leere Option angezeigt werden. Da höre ich schon den Schrei der Empörung: „Warum brauchst du eine leere Option? Das Feld ist doch ein Pflichtfeld!“. Weil dann der Benutzer gezwungen ist, sich für eine Option bewusst zu entscheiden und nicht einfach die erste Option angenommen wird.

Eine leere Option im Formular dranzuhängen ist einfach:

<f:form.select property="category" options="{categories}" prependOptionLabel="Bitte wählen" prependOptionValue="" optionLabelField="title" />

Im Model das Feld als Pflichtfeld deklarieren:

/**
 * @var \MY\MyExtension\Domain\Model\Category
 * @validate NotEmpty
 */
protected $category = null;

Wenn man nun das Formular im Frontend testet, passiert folgendes: beim Absenden des Formulars ohne etwas auszuwählen gibt es eine Exception: Exception while property mapping at property path "": PHP Catchable Fatal Error: Argument 1 passed to MY\MyExtension\Domain\Model\Item::setCategory() must be an instance of MY\MyExtension\Domain\Model\Category, null given. Das erwartete Verhalten wäre aber, dass der Validator greift und eine Fehlermeldung ausgibt.

Die Lösung ist das Setzen eines Default-Wertes im Setter:

/**
 * Sets the category
 *
 * @param \MY\MyExtension\Domain\Model\Category $category
 * @return void
 */
public function setCategory(\MY\MyExtension\Domain\Model\Category $category = null)
{
    $this->category = $category;
}

TYPO3 7.6. Indexed Search – Ausgabe optimieren

Lange habe ich mich nicht an die zweite Implementierung der Indexed Search rangetraut. Der Hinweis „experimental“ lädt auch nicht gerade ein, das Plugin einzusetzen. Mittlerweile ist das „experimental“ dem „Extbase/Fluid based“ gewichen und suggeriert, dass es nun stabil sei. Die Vorteile von dem Plugin gegenüber dem Original liegen auf der Hand – endlich saubere Templates! Wenn ich nur daran denke, welche Konfiguration und CSS-Gefrickel teilweise vonnöten war, um das gewünschte Layout des Designers mit dem alten Plugin umzusetzen. Nun soll es damit ja vorbei sein. Wenn es doch so einfach wäre.

Neu in TYPO3 ist, dass man nicht alle Templates überschreiben muss, sondern einen Template-Order angeben kann, in dem man einige der Dateien ablegt und der Rest wird als Fallback aus der Extension geholt. Das funktioniert in Indexed Search nicht so gut, dazu hatte ich ja schonmal was geschrieben: Templates Indexed Search überschreiben. Die Konfiguration muss wie folgt angepasst werden, damit man in den Konstanten den Pfad zu den überschreibenden Dateien angeben kann.

plugin.tx_indexedsearch {
	view {
		templateRootPath >
		templateRootPaths {
			0 = EXT:indexed_search/Resources/Private/Templates/
			1 = {$plugin.tx_indexedsearch.view.templateRootPath}
		}
 
		partialRootPath >
		partialRootPaths {
			0 = EXT:indexed_search/Resources/Private/Partials/
			1 = {$plugin.tx_indexedsearch.view.partialRootPath}
		}
	}
}

So weit so gut. Nächstes Problem – der Suchbegriff wird in der Anzeige der Suchtreffer nicht hervorgehoben. Natürlich könnte man es dann auch mit einem ViewHelper lösen, ABER der Mechanismus zum Hervorheben des Suchbegriffs sorgt auch dafür, dass der relevante Abschnitt der Zusammenfassung in der Trefferliste angezeigt wird. Soll heißen: Wenn der Suchbegriff unten auf der Seite gefunden wird, ich aber die ersten 200 Zeichen des Textes bekomme, dann bringt mir der ViewHelper auch nichts.

Nachdem ich Google mehrfach bemüht habe, um nur ansatzweise jemanden mit dem gleichen Problem zu finden, wurde ich doch fündig auf Stackoverflow. Im Indexed Search Controller ist in Zeile 452 folgendes zu finden:

$resultData['description'] = $this->makeDescription(
    $row,
    (bool)!($this->searchData['extResume'] && !$headerOnly),
    $this->settings['results.']['summaryCropAfter']
);

Damit der Suchbegriff hervorgehoben wird, muss der zweite Parameter false sein. Ich habe über diese Stelle meditiert, um zu verstehen, was diese Abfrage macht und in welchem Fall sie mal false ist. Aller Einstellungen zum Trotz ist es nie der Fall. Interessanterweise wird der Suchbegriff hervorgehoben, wenn ich bei gleichen Konfiguration das Classic-Plugin für die Ausgabe nutze. Verrückt, oder?

Lösung: XCLASS! Extbase-Style geht das so: in ext_localconf.php die Klasse angeben, die den Controller überschreibt.

$GLOBALS['TYPO3_CONF_VARS']['SYS']['Objects']['TYPO3\\CMS\\IndexedSearch\\Controller\\SearchController'] = array(
    'className' => 'NP\\MyExtension\\Controller\\SearchController'
);

Dann im eigenen Controller die Funktion compileSingleResultRow übernehmen und überschreiben:

$resultData['description'] = $this->makeDescription(
    $row,
    false,
    $this->settings['results.']['summaryCropAfter']
);

Yeah, der Suchbegriff wird hervorgehoben. Damit das auch gut aussieht, muss man im Template die Description als RTE parsen:

<f:format.html>{row.description}</f:format.html>

Nächstes Problem: Falls der Suchbegriff in einem Link vorkommt, dann ist der Link schrott. Beispiel: Auf der gesuchten Seite exisitert der Link http://www.test.de, der Suchbegriff ist test. Die Funktion zum Hervorheben wrappt den Suchbegriff in einen Tag (span mit Klasse dran, egal), Ergebnis: http://www.<span class=“…“>test</span>.de. Bei der Ausgabe geht der RTE Parser dahin, aha, ein Link und macht folgendes: <a href=“http://www.“>http://www.</a><span class=“…“>test</span>.de. Es entsteht ein völlig verkrüppelter Link. Bis ich rausgefunden habe, dass es der RTE macht, waren 3 Tassen Kaffee verbraucht. Lösung: <f:format.raw>{row.description}</f:format.raw> statt dem RTE Parser.

Wenn jemand weiß, wie das alles weniger kompliziert gemacht werden kann, ich bin gerne für Vorschläge offen.

Templates Indexed Search (Extbase & Fluid) überschreiben

In der Indexed Search (Extbase & Fluid) sollte es (theoretisch) möglich sein, einen eigenen Pfad zu den Templates anzugeben. Aber so hat es bei mir nicht geklappt:

Folgendes in Konstanten:

plugin.tx_indexedsearch {
	view {
		templateRootPath = EXT:my_extension/Resources/Private/Templates/
		partialRootPath = EXT:my_extension/Resources/Private/Partials/
	}
}

Obwohl der Pfad richtig war und der Wert richtig ins Setup übernommen wurde, zeigte die Angabe keine Wirkung. Meine Vermutung war, dass es mit der neuen Template-Vererbung zu tun hat.

Folgende Angabe im Setup löst das Problem:

plugin.tx_indexedsearch {
	view {
		templateRootPath >
		templateRootPaths {
			0 = EXT:indexed_search/Resources/Private/Templates/
			1 = {$plugin.tx_indexedsearch.view.templateRootPath}
		}
 
		partialRootPath >
		partialRootPaths {
			0 = EXT:indexed_search/Resources/Private/Partials/
			1 = {$plugin.tx_indexedsearch.view.partialRootPath}
		}
	}
}

Erfolgserlebnis

Nach jahrelanger Arbeit mit TYPO3 habe ich heute endlich verstanden, wie die Syntax für die Types und Palettendefinition im TCA sich zusammensetzt. Das tolle an TYPO3 ist, dass man das Backend sehr gut customizen kann. Man kann Felder beliebig anornden, gruppieren, umbenennen etc. Natürlich habe ich schonmal Formulare für neue Backend-Elemente konfiguriert, aber bisher meist das TCA vom Extension Builder erstellen lassen und dann nur noch geringfügig angepasst. Heute habe ich endlich verstanden, wie man Paletten unabhängig von Feldern definieren kann:
Das in types: --palette--;Datum;dates
Und das in palettes: 'dates' => array('showitem' => 'begin_date, begin_time, --linebreak--, end_date, end_time', 'canNotCollapse' => '1'),
Wie man Tabs definiert, wusste ich vorher auch schon
--div--;Registrierung, registration_date
Heute hats nochmal richtig Klick gemacht – nun steht absolut umwerfenden Backend-Formularen nichts mehr im Weg.

Bild aus Media als Hintergrundbild ausgeben (FAL)

Vor langer Zeit hatte ich mal einen Beitrag geschrieben, wie man das verknüpfte Bild aus dem Feld ‚media‘ einer Seite als Hintergrundbild ausgeben kann.

Seit TYPO3 6.0 werden die Bilder nicht in den Upload-Ordner hochgeladen, sondern referenziert. Dafür reicht aber eine zusätzliche Zeile im Code. Dieser Schnipsel kann im Template-Setup verwendet werden:

10 = IMG_RESOURCE
10 {
	file.import = uploads/media/
	file.import.data = levelmedia:-1, slide
	file.import.listNum = 0
	file.treatIdAsReference = 1
	stdWrap.wrap = <div id="visual" style="background-image: url(|)">
}

News Latest wird von Archive Menu beeinflusst

Ich habe auf einer Seite gleichzeitig die tt_news-Plugins List, Archive Menu (AMENU) und Latest eingebaut und dabei festgestellt, dass die Latest-Darstellung ebenfalls von der Auswahl im AMENU beeinflusst wird. Natürlich liegt es daran, dass im Code von tt_news keine große Unterscheidung gemacht wird zwischen List und Latest. Dieses Verhalten ist natürlich nicht immer gewüscht, so habe ich im Forum auf typo3.net einen Beitrag von 2006 gefunden, auf dem jemand genau das gleiche Problem hat, wie ich jetzt.
Die Funktion getSelectConf in der tt_news-Hauptklasse bastelt einfach die Where-Bedingungen für die Abfrage zusammen. Es wird gleich für List und Latest zusammengebaut. Eine Möglichkeit ist in der Klasse rumzupfuschen, was ich aber nicht gerne mache. Wer es doch machen möchte, braucht vor allen Ergänzungen des $selectConf[‚where‘], die archivedate oder datetime enthalten einfach die folgende If-Abfrage zu ergänzen:

if($this->theCode != 'LATEST') {

Eine elegantere Möglichkeit ist der selectConfHook, allerdings wird dieser erst aufgerufen, wenn alles zusammengebaut wurde. Um einen Hook zu nutzen, schreibt man erstmal eine eigene kleine Extension, Name ist egal. Dann registriert man den Hook in der ext_localconf.php:

$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['tt_news']['selectConfHook'][] = 
	'EXT:my_extension/class.myextension.php:user_myextension_hook';

Dann legt man eine Datei mit dem Namen class.myextension.php im Extension-Ordner an und darin die Klasse user_myextension_hook mit einer einzigen Funktion. Dieser Funktion wird das übergeordnete Objekt übergeben und die selectConf, die man dann manipulieren kann. Der einzige Weg, der mir einfallen ist, ist mit preg_replace. Mit diesem Code werden für Latest alle Zeitabhängigen Abfragen aus der selectConf rausgefiltert.

function processSelectConfHook($pObject, $selectConf) {
	if($pObject->theCode == 'LATEST') {
		$selectConf['where'] = preg_replace('/tt_news.archivedate.*?AND/i', '', $selectConf['where']);
		$selectConf['where'] = preg_replace('/tt_news.datetime.*?AND/i', '', $selectConf['where']);
		$selectConf['where'] = str_replace('((', '', $selectConf['where']);
	} 
	return $selectConf;
}

Tags: ,

Geschrieben in TYPO3 | Kommentare deaktiviert für News Latest wird von Archive Menu beeinflusst

Überschriften im RTE umbenennen

Die Überschriften in TYPO3 umzubenennen, so dass die Bezeichnungen für den Redakteur sprechender sind, ist recht einfach. Dazu braucht man folgenden Schnipsel im User oder Page-TS Config:

TCEFORM.tt_content.header_layout {
	altLabels.1 = H1: groß und blau
	altLabels.2 = H2: groß und schwarz
	altLabels.3 = H3: mittel und blau
	altLabels.4 = H4: mittel und grau
}

Natürlich wäre es schön, wenn die Überschriften im RTE auch die entsprechenden Bezeichnungen hätten, dazu einfach folgendes in die RTE Konfiguration rein und schon klappts (allerdings seit TYPO3 4.3).

RTE.default {
...
	buttons.formatblock.items {
		h1.label = H1: groß und blau
		h2.label = H2: groß und schwarz
		h3.label = H3: mittel und blau
		h4.label = H4: mittel und grau
	}
...

Tags: ,

Geschrieben in TYPO3 | Kommentare deaktiviert für Überschriften im RTE umbenennen

Untertitel der Seite in TypoScript ausgeben mit Fallback auf Titel

Über einer Navigation in der linken Spalte soll der Titel der übergeordneten Seite aus Level 1 dargestellt werden. Da im Web keine Silbentrennung existiert, habe ich mir gedacht, dass das Wort inklusive Silbentrennung in den subtitle geschrieben wird. Wenn das Feld subtitle befüllt ist, dann soll statt titel der Inhalt von subtitle ausgegeben werden. Hier ist mein TypoScript:

lib.navigation.sub = COA
lib.navigation.sub.10 = TEXT
lib.navigation.sub.10 {
	data = levelfield: 1, title
	wrap = <h3>|</h3>
	override.required = 1
	override.data = levelfield: 1, subtitle
}

Tags: ,

Geschrieben in TYPO3 | Kommentare deaktiviert für Untertitel der Seite in TypoScript ausgeben mit Fallback auf Titel

Mühsame Installation von TYPO3 auf Localhost

Ich hatte die letzten zwei Mal schwierigkeiten die neueste TYPO3 Version 4.5.x auf Localhost (XAMPP) zu installieren. In XAMPP ist der Datenbank-User, der bereits eingerichtet ist root ohne Passwort. Solange man lokal arbeitet ist es ja auch in Ordnung. Im Install-Tool kann man das Feld Passwort nicht einfach frei lassen, da es erforderlich ist. Also überspringe ich den 1-2-3-Modus und will die Datenbankzugangsdaten selbst in localconf.php eingeben. Das funktioniert aber auch nicht – TYPO3 Install Tool meldet noch immer „Keine Verbindung zur Datenbank“. Ich versuche einen neuen Datenbank-Benutzer über phpMyAdmin anzulegen – mit Passwort – und trage die Daten dann in localconf.php ein. Immer noch kein Erfolg. Nachdem ich schließlich den Datenbank-Namen in die Konfigurationsdatei geschrieben habe und eine Fehlermeldung auftauchte „ADONewConnection: Unable to load database driver“, hatte ich zumindest eine Fehlermeldung, nach der ich Suchen konnte.

Meine Recherche ergab, dass die Fehlermeldung auftaucht, wenn die Extensions adodb und dbal installiert sind, aber nicht korrekt konfiguriert sind (Quelle jweiland.net). Da es aber eine ganz neue TYPO3 Installation ist, konnte ich noch keine Extensions manuell aktivieren, also ist das wohl die Standardkonfiguration. Um die Extensions zu deaktivieren, habe ich in der localconf.php in der Extension Liste (extList) den Eintrag dbal entfernt. Und siehe da, es funktioniert sofort und die Verbindung zur Datenbank steht.