TYPO3 E-Mail-Adressen in JsonView verschlüsseln

Ich leistete Support bei einem Projekt (d.h. ich hatte es nicht selbst programmiert) und hatte mit einer Ansprechpartner-Liste zu tun, die mit Ajax (JSON-Format) nachgeladen wurde. Bei dieser Site sollte die TYPO3 E-Mail-Adressverschlüsselung aktiviert werden. Für die Ansprechpartner-Liste war ein Controller geschrieben, der die Ansprechparter aus dem Repository holte und ins JSON-Format umwandelte, ein Fluid-Template wurde nicht benutzt. Als ich die E-Mail-Adressverschlüsselung aktiviert hatte (hier nur ein Beispiel), griff sie an der Stelle nicht und die E-Mail-Adressen wurden unverschlüsselt ausgeliefert.

config.spamProtectEmailAddresses = 2
config.spamProtectEmailAddresses_atSubst = (at)

Da ich nicht viel umbauen wollte, hatte ich die E-Mail-Adresserschlüsselung in den Controller implementiert. Wenn man sich den Fluid EmailViewHelper naschaut, dann ist die entscheidende Zeile eigentlich folgende:

list($linkHref, $linkText) = $GLOBALS['TSFE']->cObj->getMailTo($email, '');

Da ich letztens über die JsonView gelesen hatte, ließ mir die Aufgabe keine Ruhe. Wie könnte man die JsonView verwenden und dabei die in TYPO3 eingestellte E-Mail-Adressverschlüsselung beibehalten?

Ich habe eine kleine Demo-Extension, in der ich Personen-Datensätze verwalte mit Name, Email und noch ein paar weiteren Feldern. Im AjaxController aktiviere ich die JsonView und konfiguriere sie. In der Konfiguration gebe ich 2 Felder an, die nicht in der Datenbank existieren. Dann füge ich dem Model getter-Funktionen für diese zwei Felder hinzu.

Controller

class AjaxController extends \TYPO3\CMS\Extbase\Mvc\Controller\ActionController
{
 
    protected $defaultViewObjectName = JsonView::class;
 
    /**
     *
     */
    public function personListAction()
    {
        $jsonViewConfiguration = [
            'persons' => [
                '_descendAll' => [
                    '_exclude' => ['pid'],
                    '_only' => ['name', 'email', 'emailHref', 'emailText']
                ]
            ]
        ];
        $personRepository = $this->objectManager->get(PersonRepository::class);
        $persons = $personRepository->findAll();
        $this->view->setVariablesToRender(['persons']);
        $this->view->setConfiguration($jsonViewConfiguration);
        $this->view->assign('persons', $persons);
    }
}

Model

class Person extends \TYPO3\CMS\Extbase\DomainObject\AbstractEntity
{
    [...]
    /**
     * @return string
     */
    public function getEmailHref()
    {
        list($linkHref, $linkText) = $GLOBALS['TSFE']->cObj->getMailTo($this->email, '');
        return $linkHref;
    }
 
    /**
     * @return string
     */
    public function getEmailText()
    {
        list($linkHref, $linkText) = $GLOBALS['TSFE']->cObj->getMailTo($this->email, '');
        return $linkText;
    }
}

JSON Output

[
{
"email": "bruce@wayne-enterprises.com",
"emailHref": "javascript:linkTo_UnCryptMailto('ocknvq,dtwegBycapg\\/gpvgtrtkugu0eqo');",
"emailText": "bruce(at)wayne-enterprises.com",
"name": "Bruce Wayne"
},
[...]

Wirklich glücklich bin ich mit dieser Lösung nicht. Ich habe das Gefühl, dass ich Darstellungslogik, die eigentlich in den View gehört, im Model unterbringe. Mir würde es besser gefallen, wenn man Prozessoren für Objekte definieren könnte. Leider gibt die Konfiguration des JsonView das im Moment nicht her.

Fluid f:comment-ViewHelper und Inline JavaScript

In Vorbereitung auf die TYPO3 Developer Prüfung schaue ich mir gerade vieles in TYPO3 genauer an. So wie im Moment die Standard Fluid-ViewHelper. Dabei bin ich beim f:comment ViewHelper hängen geblieben. Die Dokumentation beschreibt da einen Fall, denn ich so nicht reproduzieren konnte. Mein TYPO3 8.7.19 verhält sich so:

Inhalte gewrappt in f:comment werden nicht ausgegeben – weder im Quellcode, noch sichtbar.

<f:comment>
    <p>Wrapped in f:comment: Anzahl Einträge {data -> f:count()} </p>
</f:comment>

Inhalte gewrappt in CDATa werden ebenfalls nicht ausgegeben. Das ist der Dokumentation noch anders beschrieben.

<![CDATA[<p>Wrapped in CDATA: Anzahl Einträge {data -> f:count()} </p>]]>

Es gibt allerdings einen neuen ViewHelper f:format.cdata, der Inhalt bei der Ausgabe in CDATA wrappt. Eigentlich toll.

<f:format.cdata><p>Wrapped in f:format.cdata: Anzahl Einträge {data -> f:count()} </p></f:format.cdata>

Problem dabei ist, dass dann folgendes im Quellcode ausgegeben wird:

<![CDATA[<p>Wrapped in f:format.cdata: Anzahl Einträge 10 </p>]]>

Der Browser (in meinem Fall Chrome) stellt auf der Seite ]]> dar. Wünschenswert wäre, dass auf der Seite gar keine Ausgabe erfolgt. Ich habe mich noch nie ausführlich mit CDATA beschäftigt, weiß daher nicht, ob es an f:format.cdata oder meinem Browser liegt.

Und nun zum nächsten Problemchen: Inline JavaScript. Ich hatte etwas recherchiert und die Vorschläge, wie man Fluid vom Parsen von Inline-JavaScript abhält, beziehen sich alle auf Wrappen in CDATA. Was ja eben nicht funktioniert. Also f:format.cdata ViewHelper benutzen:

<script type="text/javascript">
    <f:format.cdata>
        function sayHello() {
            alert("hello world");
        }
        sayHello();
    </f:format.cdata>
</script>

Allerdings wirft der obige Code einen JavaScript-Fehler. Der Browser stört sich an dem < am Beginn von CDATA. Eine funktionierende Lösung sieht damit so aus:

<script type="text/javascript">
    //<f:format.cdata>
        function sayHello() {
            alert("hello world");
        }
        sayHello();
    //</f:format.cdata>
</script>

Gibt es denn eine Möglichkeit, einen Block auszugeben, den aber von Fluid nicht parsen zu lassen? Wofür könnte man es brauchen? Ich werde weiter schauen…

Eigene Fehlermeldungen für Extbase-Validatoren

(Custom error message for extbase validators)

Da ich auf die schnelle nichts gefunden habe und es mir selbst zusammengereimt hab, schreibe ich es hier besser auf. Um die Standard-Fehlermeldungen der Extbase-Validatoren zu ändern, schreibt man folgendes ins Setup:

config.tx_extbase._LOCAL_LANG.default {
    validator.notempty.null = This is a custom error message 1
    validator.notempty.empty = This is a custom error message 2
}

Damit werden die Fehlermeldungen global für die Sprache geändert. Den Key (validator.notempty.null) findet man im Validator:

class NotEmptyValidator extends AbstractValidator
{
	protected $acceptsEmptyValues = false;
 
	public function isValid($value)
	{
		if ($value === null) {
			$this->addError(
				$this->translateErrorMessage(
					'validator.notempty.null',
					'extbase'
				), 1221560910);

Flux und Inhaltselemente in News

In der Extension “News” gibt es ein schönes Feature. Dabei können News-Beiträge mit Inhaltselementen beliebig erweitert werden. In meinem aktuellen Projekt wurde die Seite mit Flux umgesetzt und dafür wurden alle Standard-Inhaltselemente per TSconfig deaktiviert. Damit man die “normalen” Text-Elemente in den News verwenden kann, muss man im TSconfig der News-Storage-Seite folgendes hinterlegen:

# reset remove items
TCEFORM.tt_content.CType.removeItems = html
# allow only text
TCEFORM.tt_content.CType.keepItems = text

Wichtig ist zunächst die removeItems zurückzusetzen (removeItems = black list). Diese Einstellung überschreibt andernfalls alles andere. Mit keepItems können Elemente angegeben werden, die stehen bleiben, während der Rest entfernt wird. (keepItems = white list)

Laravel – erster Eindruck

Soeben bin ich fast fertig mit einer Applikation, mit der ich Playlisten für meine Les Mills Kurse erstellen kann. Ich habe mich entschieden, die Applikation in Laravel zu schreiben, weil es spannend ist, mal was neues kennenzulernen (Laravel ist beliebste PHP-Framework im Moment) und weil ich TYPO3 dafür zu viel fand.

Als Einstieg in Laravel habe ich mir “Laravel From Scratch” Tutorials angeschaut. Die Videos fand ich echt gut, auch wenn der Entwickler verdammt schnell tippt und Fenster wechselt. Ich musste immer wieder mal stoppen und sortieren, wo er gerade ist. Mir hat gut gefallen, dass er ziemlich schnell eine Ausgabe erzeugt, auch wenn es nicht immer der eleganteste Weg ist. In den späteren Tutorials passt er es auch an und zeigt einen besseren Weg. z.b. werden am Anfang die Ausgaben direkt in die Routing-Datei geschrieben. Später erzeugt er auch View, Models und Controller.

Etwas verwirrend an Laravel finde ich die Migrations. Zum einen das Wording, zum anderen, dass man Felder nicht nach dem Erstellen der Tabelle hinzufügen kann. Wenn ich also bereits eine Tabelle angelegt und befüllt habe, brauche ich eine neue Migration, die ein Feld zu der Tabelle hinzufügt. Alternativ kann ich durch Rollback meine Tabelle löschen, die Migration anpassen und neu erstellen.

Gut gefällt mir das Routing. Gerade dann, wenn man mit Route::resource() automatisch Routen mit einem Controller verknüpfen kann. Zusammen mit CRUD kann man so schnell Funktionen fürs Erstellen und Bearbeiten implementieren. Ebenfalls positiv finde ich Blade-Templates. Mein Lieblings-Templating-Framework ist nach wie vor Flow, mein Horror ist Smarty. Blade ist ein guter Kompromiss zwischen “sieht aus wie HTML” und “PHP verwendenen in Templates”. In den Tutorials schreibt Jeffrey seine Formulare mit <form ...> in die Templates. Dann fand ich einige Beispiele mit Form::open, was mir natürlich besser gefällt. Seit Laravel 5.5 ist der Form-Helper ausgelagert worden. Nachdem ich das herausgefunden hatte, schrieben sich die Formulare noch schneller. Wenn man das Prinzip mit den View-Helpern verstanden hat, kann man relativ schnell eigene implementieren. So brauchte ich z.B. einen View-Helper, der mir aus meinem Rating (1 bis 5) Sternchen malt. Wäre auch mit einem Include gegangen, ist aber so noch eleganter.

Ebenfalls gut lassen sich Relationen abbilden. Mit hasMany, belongsTo kann man die Verknüpfungen zwischen Models definieren. Ebenfalls eine gute Idee sind die Scopes. Man definiert im Model einen Scope mit einer Einschränkung und kann im Controller oder von einem anderen Model auf den Scope zugreifen. So habe ich in meiner Applikation Scopes für Tracks definiert (Standard mit bonus=0 und Bonus mit bonus=1) und kann die Tracks in der Release-Einzelansicht in zwei verschiedenen Bereichen ausgeben.

Der Vorteil eines gut durchdachten Frameworks ist, dass man relativ schnell eine funktionierende Applikation bekommt. Auch wenn ich mich erst seit 2 Wochen mit Laravel beschäftige, habe ich meine Plan umsetzen können und die Applikation funktioniert hervorragend. Fazit: TYPO3 bleibt nach wie vor mein Steckenpferd, Laravel hat mir jedoch gut gefallen und ich könnte mir vorstellen, mich bei Bedarf da weiter einzuarbeiten.

LesMixer – Playlists für LesMills Kurse

Schon von ca. einem Jahr hatte ich die Idee zu einer (für mich sinnvollen) Anwendung. Als Hobby unterrichte ich Kurse im Fitnessstudio: BODYPUMP und BODYCOMBAT. Beides sind Fitnessprogramme von Les Mills. Das besondere: sie sind vorchoreografiert. Alle 3 Monate gibt es eine neue Release (neue Musik und neue Bewegungen), diese lerne ich dann und unterrichte sie. Nach ca. 6 bis 8 Wochen sorge ich für Abwechslung in den Kursen, in dem ich “mixe”, d.h. ich ersetze Tracks aus dem aktuellen Programm durch ältere Tracks. Beim Austauschen den Tracks gibt es einiges zu beachten, da der programmtypische Stundenablauf beibehalten werden soll. Jeder Track hat eine Funktion. So ist bei BODYPUMP der 2.Track immer Squats (d.h. es werden die Beine trainiert). Beim Austauschen des Tracks kann ich dann nur einen Squat-Track aus einer älteren Release verwenden. Dann sollten die ausgetauschten Lieder gemeinsam auch musikalisch Kontraste bilden und die Länge aller Lieder sollte zusammen eine bestimmte Zeit nicht überschreiten.

Bis vor kurzem mixte ich “manuell”. Ich überlegte mir, welche Lieder ich machen könnte, hörte kurz rein (klickte mich vorher durch Ordner) und überprüfte die Gesamtlänge der Auswahl. Also dachte ich mir, da kann ich doch eine kleine Anwendung schreiben, die mir die Liedauswahl erleichtert. Zunächst braucht man eine Datenbasis: ich muss bisherige Releases einpflegen können. Danach wäre es noch praktisch, diese Daten durchsuchen zu können: nach Künstler, Musiktitel oder Bewegungen.

Ich hätte es auch in TYPO3 implementieren können. Manchmal möchte ich meinen Horizont erweitern und ein neues Framework oder eine neue Anwendung kennenlernen. Das geht am besten mit Learning-by-Doing. Von einigen habe ich schon gehört, wie toll Laravel ist und wollte es selbst ausprobieren. Nachdem ich mir einen kurzen Überblick über Laravel verschafft habe (Video-Tutorials), ging es an die Umsetzung meiner Applikation names “LesMixer”.

Um mir die Datenpflege zu erleichtern, habe ich einige sinnvolle Funktionen eingebaut. Da ich die Musik in Ordner abgelegt hatte, konnte ich automatisch beim Auswählen eines Programms und einer Release die Mp3-Dateien im Ordner einlesen und zur Auswahl anbieten. Sobald eine Datei ausgewählt wird, werden Künstler, Titel und Länge (Mp3-Metadaten) und in die entsprechenden Felder eingesetzt. d.h. Tracks für eine neue Release einzupflegen ist denkbar einfach. Sobald die Tracks eingepflegt sind, kann man sie direkt in der Applikation abspielen. Die Suche oben durchsucht Künstler und Track-Titel.

Eine Playlist (Mix) zu erstellen, ist einfach. Sobald man ein Programm ausgewählt hat, werden die Tracktypen gelistet (der Ablauf ist ja immer gleich) und man kann für jeden Tracktyp einen konkreten Track auswählen. Irgendwann möchte ich diesen Vorgang automatisieren. Da ich ein Rating eingebaut habe, könnte ich mir vorstellen, in Zukunft eine Playlist generieren zu lassen unter Berücksichtigung bestimmter Einschränkungen.

Pagination Widget im Backend anpassen

Ich habe ein Modul implementiert, in dem bestimmte Datensätze gelistet werden. Über der Auflistung hatte ich einen Filter für die Datensätze implementiert und für die Paginierung das Fluid BE-Pagination Widget verwendet. Nun musste ich erstaunt feststellen, dass das BE-Paginate-Widget (be.widget.paginate) keine weiteren Argumente mitschleppen kann und es auch nicht konfigurierbar ist. Das bedeutet: beim Blättern gehen die Einstellungen aus dem Filter verloren.

Ich habe es hinbekommen mit einem eigenen ViewHelper und einem eigenen Template fürs Pagination-Widget.

(mehr …)

Tags: ,

Geschrieben in TYPO3 | Kommentare deaktiviert für Pagination Widget im Backend anpassen

Magnific Popup: springen von fix positioniertem Content

Wenn man Maginific-Popup zum Vergrößern von Bilder einsetzt, dann springen die fix positionierten Elemente beim Öffnen des Popups. Warum? Magnific Popup entfernt das Overflow Attribut des html-Elements und fügt stattdessen ein margin-right hinzu, das der Breite der Scrollbalken entspricht. Das schaltet das Scrolling der Seite aus. Ein Problem stellen die fix positionierten Elemente dar: sie springen leicht beim Öffnen des Popups. Wenn man bei fix positionierten Elementen diese entweder von rechts ausrichtet oder die Breite auf 100% setzt, dann ändert sich beim Öffnen des Popups die gesamte Breite der Seite, da die Scrollbalken entfernt werden. Die fix positionierten Elemente sind vom margin-right im html-Element wenig beeidruckt.

Lösung: Magnific Popup bietet viele Callbacks, die man nutzen kann, um die fixe Positionierung der Elemente zu korrigieren.

var magnificpopupSettings = {
        callbacks: {
            beforeOpen: function () {
                if($('nav.top-bar').css('position') == 'fixed') {
                    $('nav.top-bar').css('margin-right', '17px');
                    $('#top-link').css('margin-right', '17px');
                }
            },
            afterClose: function() {
                if($('nav.top-bar').css('position') == 'fixed') {
                    $('nav.top-bar').css('margin-right', '');
                    $('#top-link').css('margin-right', '');
                }
            }
        }
    };
};

Diskussion zum Thema: Jumping background

Geschrieben in javascript | Kommentare deaktiviert für Magnific Popup: springen von fix positioniertem Content

Übersetzung bestimmte Sprache im Fluid Template ausgeben (LocalizationUtility)

Für mein aktuelles Projekt sollte es etwas abgefahrenes sein: In einem Template sollen nebeneinander ein Wort in Sprache 1 und dann das gleiche Wort in Sprache 2 ausgegeben werden. Problem ist, das der <f:translate key="" /> ViewHelper immer nur mit der aktuellen Sprache arbeitet. Mein Ansatz ist also einen eigenen ViewHelper zu schreiben. Nun ruft der TranslateViewHelper (in einer statischen Funktion) die LocalizationUtility auf und diese liefert die Übersetzung. d.h. ich werde wohl auch eine eigene LocalizationUtility brauchen.

Mein ViewHelper soll in der Verwendung so aussehen: <my:translate key="lang[fr]:years" />
Ich kann/möchte kein weiteres Argument an den ViewHelper dranhängen, weil mein TranslateViewHelper dann nicht mehr von zum Teil statischen Core-TranslateViewHelper ableiten kann. Und der $key wird eh durchgereicht, also nutze ich den Key, um meine Sprache zu definieren.

Eigenen TranslateViewHelper implementieren, der “meine” LocalizationUtility nutzt

namespace My\Extension\ViewHelper;
use My\Extension\Utility\LocalizationUtility;
class TranslateViewHelper extends \TYPO3\CMS\Fluid\ViewHelpers\TranslateViewHelper
{
    protected static function translate($id, $extensionName, $arguments)
    {
        return LocalizationUtility::translate($id, $extensionName, $arguments);
    }
}

Dann muss “nur” noch die LocalizationUtility angepasst werden. In der translate-Funktion wird der $key geparst und falls er einen Hinweis auf eine konkrete Sprache enthält, wird diese in $overrideLanguageKey gesetzt. Wichtig ist keine der anderen Variablen zu ändern, denn sobald ich sie für ein Label ändere, gilt die Änderung für alle folgenden Labels. Später überprüfe ich, ob $overrideLanguageKey gesetzt ist, lade die Übersetzungen und liefere die angeforderte Übersetzung zurück. Das ist nicht der komplette Code, sondern nur die relevanten Auszüge.

<?php
namespace My\Extension\Utility;
class LocalizationUtility extends \TYPO3\CMS\Extbase\Utility\LocalizationUtility
{
    /**
     * @var string
     */
    protected static $overrideLanguageKey = '';
 
    /**
     * Returns the localized label of the LOCAL_LANG key, $key.
     *
     * @param string $key The key from the LOCAL_LANG array for which to return the value.
     * @param string $extensionName The name of the extension
     * @param array $arguments the arguments of the extension, being passed over to vsprintf
     * @return string|NULL The value from LOCAL_LANG or NULL if no translation was found.
     */
    public static function translate($key, $extensionName, $arguments = null)
    {
        if (GeneralUtility::isFirstPartOfStr($key, 'lang[')) {
            preg_match('#^lang\[(.*?)\]\:(.*?)$#', $key, $matches);
            // set key
            $key = $matches[2];
            self::$overrideLanguageKey = $matches[1];
        }
        [...]
            self::initializeLocalization($extensionName);
            /* NEW */
            $languageKey = self::$languageKey;
            if(self::$overrideLanguageKey) {
                self::initializeLocalizationFor($extensionName, self::$overrideLanguageKey);
                $languageKey = self::$overrideLanguageKey;
            }
            // The "from" charset of csConv() is only set for strings from TypoScript via _LOCAL_LANG
            if (!empty(self::$LOCAL_LANG[$extensionName][$languageKey][$key][0]['target'])
                || isset(self::$LOCAL_LANG_UNSET[$extensionName][$languageKey][$key])
            ) {
                // Local language translation for key exists
                $value = self::$LOCAL_LANG[$extensionName][$languageKey][$key][0]['target'];
            } elseif (!empty(self::$alternativeLanguageKeys)) {
            [...]
    }
 
    /**
     * @param string $extensionName
     * @param string $languageKey
     * @return void
     */
    protected static function initializeLocalizationFor($extensionName, $languageKey)
    {
        $locallangPathAndFilename = 'EXT:' . GeneralUtility::camelCaseToLowerCaseUnderscored($extensionName) . '/' . self::$locallangPath . 'locallang.xlf';
        $renderCharset = TYPO3_MODE === 'FE' ? self::getTypoScriptFrontendController()->renderCharset : self::getLanguageService()->charSet;
 
        /** @var $languageFactory LocalizationFactory */
        $languageFactory = GeneralUtility::makeInstance(LocalizationFactory::class);
 
        self::$LOCAL_LANG[$extensionName] = $languageFactory->getParsedData($locallangPathAndFilename, $languageKey, $renderCharset);
    }
}

Im Template können schließlich beide TranslateViewHelper nebeneinander verwendet werden:

<f:translate key="years" />
<my:translate key="lang[fr]:years" />

Tags: ,

Geschrieben in TYPO3 | Kommentare deaktiviert für Übersetzung bestimmte Sprache im Fluid Template ausgeben (LocalizationUtility)

Hook-Implementierung für Linkhandler

Heute habe ich die Extension linkhandler (allerdings die neue Version) konfiguriert, damit die Redakteure in der Site auf Artikel und weitere von mir programmierte Dateitypen verlinken können. Die Konfiguration des Linkhandler in TsConfig ist sehr gut beschrieben, so ich mir hier die Konfiguration spare. Was allerdings gefehlt hat, war ein Beispiel für den beschriebenen Hook. Ich habe in dem Code unten jeweils Dummy-Namespaces und Extension-Namen eingesetzt, der Code funktioniert, muss aber modifiziert werden.

Damit man z.B. Links zu eigenen Datensätzen erstellen kann, braucht man ein wenig TsConfig:

TCEMAIN.linkHandler.tx_extension_myrecord {
    handler = Cobweb\Linkhandler\RecordLinkHandler
    label = Mein Datentyp
    configuration { ... }
    scanBefore = page
}

In ext_localconf.php wird der Hook registriert:

$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['linkhandler']['generateLink'][] = \My\Extension\Hooks\LinkhandlerParameterProcessor::class;

Dann erstellt man im Ordner Classes/Hooks der eigenen Extension die Datei LinkhandlerParameterProcessor.php mit folgendem Inhalt:

<?php
namespace My\Extension\Hooks;
 
use Cobweb\Linkhandler\ProcessLinkParametersInterface;
 
class LinkhandlerParameterProcessor implements ProcessLinkParametersInterface
{
 
    /**
     * @param \Cobweb\Linkhandler\TypolinkHandler $linkHandler Back-reference to the calling object
     * @return void
     */
    public function process($linkHandler) {
        $configurationKey = $linkHandler->getConfigurationKey();
        if($configurationKey == 'tx_extension_myrecord.') {
            $record = $linkHandler->getRecord();
            $additionalParams = '&tx_extension_test[parent]='.$record['parent'];
            $additionalParams.= '&tx_extension_test[record]='.$record['uid'];
            $additionalParams.= '&tx_extension_test[controller]=Test';
            $typolinkConf = $linkHandler->getTypolinkConfiguration();
            $typolinkConf['additionalParams'] = $additionalParams;
            $typolinkConf['title'] = $record['title'];
            $linkHandler->setTypolinkConfiguration($typolinkConf);
        }
    }
 
}

Mit $linkHandler->getConfigurationKey() kommt man an der Configuration Key – nämlich den, den man vorher im TsConfig verwendet hat. Es gibt einige Funktionen im LinkHandler wie getTableName() oder getLinkParameters(), von denen scheinbar keine verwendet wird. Somit bleibt nur der Weg über die Typolink Konfiguration: mit getTypolinkConfiguration() auslesen und mit setTypolinkConfiguration() wieder setzen.

In meinem Fall habe ich den Hook benötigt, weil ich an den Link nicht nur die UID des Datensatzes hängen musste, sondern auch noch einen weiteren Parameter aus dem Datensatz.

Nachtrag: Ich habe erst später festgestellt, das ich mein Problem auch komplett mit TypoScript lösen kann. Na ja, vielleicht hilft ja das Beispiel jemandem

plugin.tx_linkhandler {
    tx_extension_myrecord {
        typolink {
            title = {field:title}
            title.insertData = 1
            parameter = 74
            additionalParams = &tx_extension_test[parent]={field:parent}&tx_extension_test[record]={field:uid}&tx_extension_test[controller]=Test
            additionalParams.insertData = 1
            useCacheHash = 1
        }
    }
}

Tags: ,

Geschrieben in TYPO3 | Kommentare deaktiviert für Hook-Implementierung für Linkhandler