Fehlermeldungen in Fluid / Extbase Formularen

Folgendes Setup: Model mit Validatoren bei einigen Properties und ein Formular, um ein neues Objekt dieses Typs anzulegen.

Das Formular kann wie folgt definiert werden:

<f:form action="create" object="{my}" objectName="my" method="post">
    <f:render partial="Form/AllErrors" arguments="{_all}" />
    <label for="foo" class="">Label</label>
    <div class="formWrap">
        <f:form.textfield property="foo" id="foo" />
    </div>
</f:form>

Sobald man für das Formular object und objectName definiert, kann man mit dem Attribut property in den Feldern arbeiten, dabei wird der Wert falls vorhanden automatisch ausgefüllt. Wenn nun während der Validierung Fehler auftreten, dann werden in diesem Beispiel die Fehler ALLE ausgegeben mit dem folgenden Partial:

<f:form.validationResults>
    <f:if condition="{validationResults.flattenedErrors}">
        <div class="errors">
            <f:for each="{validationResults.flattenedErrors}" as="errors" key="propertyPath">
                <ul>
                    <f:for each="{errors}" as="error">
                        <li>{propertyPath}: <span>{error}</span></li>
                    </f:for>
                </ul>
            </f:for>
        </div>
    </f:if>
</f:form.validationResults>

Es wäre natürlich schöner, wenn die Fehlermeldung am Feld dran stehen würde und nicht irgendwo am Anfand des Formulars. Man kann dem Tag f:form.validationResults durch das Argument for mitteilen, für welche Property man die Fehler haben möchte. Und so sieht das geänderte Formular nun so aus:

<f:form action="create" object="{my}" objectName="my" method="post">
    <label for="foo">Label</label>
    <div class="formWrap">
        <f:form.textfield property="foo" id="foo" />
        <f:form.validationResults for="my.foo">
            <f:render partial="Form/FormFieldError"
                      arguments="{validationResults: validationResults}"/>
        </f:form.validationResults>
    </div>
</f:form>

Das Partial dazu sieht so aus:

<f:if condition="{validationResults.errors}">
    <f:for each="{validationResults.errors}" as="error">
        <div class="error-note">
            <small class="has-error">{error.message}</small>
        </div>
    </f:for>
</f:if>

In meinem Fall sollte zusätzlich eine Klasse beim Label gesetzt werden, wenn es zu Validierungsfehlern kommt. Der validationResults ViewHelper ist aber keine Condition, man kann ihn auch nicht inline mit der Klasse “füttern”. Der validationResults ViewHelper setzt nur die Fehler für die entsprechende Property in den Template Variable Container und gibt danach die Kinder aus. Die Kinder können dann auf die entsprende Variable zugreifen, also ein bisschen wie f:alias oder f:map. Und so sieht der Formular-Code am Ende aus:

<f:form action="create" object="{my}" objectName="my" method="post">
    <f:form.validationResults for="my.foo">
        <label for="form-customer_id"
               class="{f:if(condition: validationResults.errors, then: 'has-error')}">Label</label>
        <div class="formWrap">
            <f:form.textfield property="foo" id="foo" />
            <f:render partial="Form/FormFieldError"
                      arguments="{validationResults: validationResults}"/>
        </div>
    </f:form.validationResults>
</f:form>

I love TYPO3

Auf dem Camp (Bericht hier) hatte Jochen Weiland aufgefordert, mehr über TYPO3 zu schreiben. Der Aufhänger für diese Aufforderung war: er berichtete über Kommentare von TYPO3-Außenseitern der Art “TYPO3 ist doch schon tot”. Tja, totgeglaubte leben länger.

Ich arbeite mit TYPO3 seit Version 3.7, das ist finsteres Mittelalter. Bereits im Informatik-Studium mit viel C, C++ und Java habe ich Gefallen an PHP und MySQL gefunden. Wir haben damals Informix SQL gelernt und als ein Kommilitone MySQL erwähnte, war der Kommentar des Professors “die halten sich nicht lange”. Tja, siehe oben. PHP war damals rein funktionsbasiert, wahrscheinlich sah ich das Potential schon damals – ähm. Für meine Diplomarbeit schrieb ich eine Web-Applikation mit dem frisch erschienenen PHP 5 – es gab Klassen. OOP! Irgendwann gegen Ende des Studiums erzählte mir ein Kommilitone von einem verrückten Dänen, der im Keller ein CMS geschrieben hat und das sei richtig geil. Als ich ein paar Monate später eine Seite umsetzen musste, wo der Kunde seine Inhalte selbst bearbeiten kann, fiel mir dieses Gespräch wieder ein und so lernte ich TYPO3 kennen.

Jahre vergingen, ich habe mich mal mehr, mal weniger mit TYPO3 beschäftigt. Nach einer TYPO3 Agentur wechselte ich zu einer Agentur, die kein TYPO3 anbot und vermisste es nach einiger Zeit. TYPO3 krebste lange in der Version 4 herum, weil die Version 5 ja was neues werden sollte. Nach außen sah das so aus, als würde es da nicht voran gehen. Das Backend war nach wie vor altbacken, andere CMS spossen aus dem Boden (WordPress, Contao), dagegen sah TYPO3 alt aus. Da durfte ich mir anhören “TYPO3 wird nicht mehr lange geben” und wurde irgendwie traurig.

Dann kam Version 6 – Namespaces, Extbase und Fluid – endlich! Seitdem gibt es regelmäßig Releases, Updates, neue Technologien werden eingebaut und TYPO3 macht mehr Spaß denn je. Was ist an TYPO3 liebe, ist die Flexibilität bei sauberer Datenbank-Struktur und hoher Code-Qualität. Ok, es gibt im Core nach wie vor ein paar dunkle Ecken, die immer noch eingestaubt und gruselig sind. Dafür ist der aufgeräumte Rest genial. Ich bin überzeugt, dass es nichts gibt, was man mit TYPO3 nicht umsetzen könnte. Gelegentlich schaue ich über den Tellerrand – ich habe schonmal mit anderen CMS (Drupal, WordPress, Contao) und Frameworks (CakePHP, Laravel) gearbeitet, um dann mit einem guten Gefühl weiter mit TYPO3 arbeiten zu können.

Ja, die Einstiegshürde ist hoch – TypoScript. Gut, wo ist denn bitte keine Einstiegshürde? Ich gehe doch auch nicht zur Fahrschule, setze mich ans Steuer und kann fahren? Für viele Dinge im Leben muss man lernen, Erfahrung sammeln, manchmal Frustrationen aufbauen, um voran zu kommen. TYPO3 hat den Vorteil, dass es gut dokumentiert ist und dass es eine Community gibt, die einem helfen kann. Beispiele gibt es wie Sand am Meer und Google hilft ja auch weiter, damals im finsteren Mittelalter war das noch anders.

Dann höre ich manchmal, TYPO3 ist zu kompliziert für Redakteure. Meine Antwort: das System ist falsch eingerichtet. TYPO3 hat ein geniales Benutzermanagement mit einer differenzierten Rechteverwaltung. d.h. nicht TYPO3 ist Schuld, es ist nur falsch konfiguriert. Ich kann verstehen, dass Frau Müller überfordert ist, wenn Sie 80 Buttons hat, die sie klicken kann und eine Menüleiste, bei der sie scrollen muss. Da ist es die Aufgabe des Entwicklers/Integrators TYPO3 entsprechend einzurichten und Frau Müller nur die 5 Buttons und 2 Menüpunkte zu geben, die sie braucht.

Und zum Schluß – seit einigen Jahren gibt es die TYPO3 Zertifizierung. Welches andere CMS hat das bitte? “The TYPO3 certification program is a global standard for TYPO3 knowledge”[1]. Wenn man also mit einem TYPO3 zertifizierten Entwickler zusammen arbeitet, dann ist zumindest sicher gestellt, dass er die API kennt. Da ich die Prüfung abgelegt habe, weiß ich, dass sie nicht ohne ist und dass ich trotz jahrelanger TYPO3 Erfahrung noch einiges lernen musste.

So, genug geschwärmt – wieder an die Arbeit. Mit TYPO3 natürlich 😉

[1] https://typo3.org/certification/

TYPO3 Camp Rhein-Ruhr 2019

An diesem Wochenende fand das TYPO3 Camp Rhein-Ruhr statt. Ich war zum 4. oder 5. Mal dort und fand es mal wieder toll. Zunächst mal ist es schön, wenn man bekannte Gesichter wieder trifft oder jemanden persönlich kennenlernt, von dem man bisher nur gelesen oder mit dem man nur geschrieben hat. Die Auswahl an Talks ist phantastisch – am Samstag wurde in 6 Räumen von 12 bis 19 Uhr stündlich vorgetragen, vorgestellt oder diskutiert. Abends ab 19 Uhr dann “Get together” (wie das so schön neudeutsch heißt) und gegen 9 dann Whisky-Tasting. Ja, richtig – Whisky. Kein Billigfusel mit Cola. Ich gestehe, dass ich bei meinem ersten Camp-Besuch damals überhaupt auf den Geschmack von Whisky gekommen bin. Man braucht nur den richtigen Einstieg, etwas Hintergrundinformationen und Möglichkeiten, verschiedene Whiskys zu probieren. Mittlerweile freue ich mich Monate im Voraus auf das nächste Camp und Whisky.

Sehr gut fand ich dieses Jahr die Möglichkeit, statt T-Shirt den Betrag zu spenden. Der Betrag aller T-Shirt-Spenden wurde noch erhöht und geht an eine Organistion, die Kita-Kinder mit frischem, regionalem Essen versorgt.

Die Sponsoren hatten auch echt geniale Goodies beigelegt: ein Flachmann mit “flush cashes” Aufdruck. Wir haben beim Informatik-Studium damals beim Trinken auch immer gewitzelt, dass wir die “Caches flushen” oder “Format C:”. Man konnte sich auch ein Lego-Männchen (in meinem Fall Lego-Weibchen) zusammenbasteln – mit TYPO3 Logo auf der Brust. Ich bin ja eh etwas Lego-verrückt…

Die Talks waren fast alle für Developer – gut für mich. Helmut lieferte eine Einführung in Composer und ich dufte ihn danach mit ein paar Fragen löchern. Ich nutze Composer in (allen) meinen Projekten, und es schmerzt fast, wenn es nicht zur Verfügung steht. Weiterhin habe ich mir vorgenommen nach dem Camp, Rector PHP und Webpack Encore auszuprobieren – beides vorgestellt von Sebastian Schreiber.

Rector PHP ist ein Tool, dass automatische Code-Updates ermöglicht. Dabei kann der Code semantisch korrigiert und auf fehlenden/veraltete Funktionen überprüft werden. Um im TYPO3 Umfeld zu bleiben – früher t3lib_div, wurde es dann zu GeneralUtility. Oder: bei ViewHelpern konnte man noch in Version 7 die Argumente der Funktion render übergeben. Ab Version 9 ist das Registrieren der Argumente in registerArguments Pflicht. Rector PHP kann den Code entsprechend umschreiben!

Andere Talks (Depencancy Injection, Quo vadis Extbase) geben einen Überblick darüber, was sich ändert in TYPO3 in den nächsten Versionen und worauf man achten sollte – hilfreich auf jeden Fall.

Und so fuhr ich gestern nach Hause, mein Kopf voller neuer und interessanter Informationen und freue mich ab jetzt wieder auf das Camp nächstes Jahr. Und Whisky 😉

TYPO3 Fluid-Templates und PhpStorm

Manchmal hab ich folgendes Problemchen: ich möchte z.B. falls Bedingung X eintrifft einen öffnenden Tag ausgeben und bei Bedingung Y einen schließenden Tag. PhpStorm fängt dann an, die Tags zu korrigieren, damit das Template aus seiner Sicht eine gültige Struktur hat. Ich habe bei meinem TYPO3-Kollegen Thomas Deuling einen einfachen Trick gesehen, wie man PhpStorm austricksen kann. Man schreibt die Tags einfach in !
Hier ein Beispiel für ein Media/Gallery Partial:

<html xmlns:f="http://typo3.org/ns/TYPO3/CMS/Fluid/ViewHelpers"
      xmlns:ce="http://typo3.org/ns/TYPO3/CMS/FluidStyledContent/ViewHelpers" data-namespace-typo3-fluid="true">
<f:if condition="{gallery.rows}">
    <f:for each="{gallery.rows}" as="row">
        <f:if condition="{gallery.rows -> f:count()} > 1">
            <f:format.raw value="<div class='row'>"/>
        </f:if>
        <f:for each="{row.columns}" as="column">
            <f:if condition="{row.columns -> f:count()} > 1">
                <f:format.raw value="<div class='col'>"/>
            </f:if>
            <f:if condition="{column.media}">
                <f:render partial="Media/Type"
                          arguments="{file: column.media, dimensions: column.dimensions, data: data, settings: settings}"/>
            </f:if>
            <f:if condition="{row.columns -> f:count()} > 1">
                <f:format.raw value="</div>"/>
            </f:if>
        </f:for>
        <f:if condition="{gallery.rows -> f:count()} > 1">
            <f:format.raw value="</div>"/>
        </f:if>
    </f:for>
</f:if>
</html>

Es hat den kleinen Nachteil, dass man selbst den Code etwas schlechter lesen kann, aber wenigstens stimmt die Struktur und PhpStorm versucht nicht die Tags zu korrigieren.

Vorschau von Bildern aus Page Media im Backend

Es hat mich ein wenig gewundert, dass es keine Extension gibt, die das anbietet. Ich nutze das Feld “Media” unter Resources in den Seiteneingenschaften bei fast allen Projekten. Und gestern ist mir eingefallen, dass es ja eigentlich cool wäre, wenn man das eingepflegte Bild auch im Backend sehen könnte. In der TYPO3 Facebook-Gruppe hat die Nachfrage nach einer Extension nicht zum gewünschten Ergebnis geführt. Also beschloss ich (auch zu Übungszwecken) eine solche Extension selbst zu schreiben. Hier mein Kochrezept und Ergebnis.

Als erstes erstellt man einen Extensionordner mit einer ext_emconf.php. Meine Extension heißt übrigens np_pageresourcepreview.

In TYPO3 gibt es ja mittlerweile Hooks für so ziemlich alles. So auch einen um die Seite im Backend zu rendern. Man registrierert den Hook aus der neuen Extension in ext_localconf.php.

<?php
defined('TYPO3_MODE') || die('Access denied.');
 
if (TYPO3_MODE === 'BE') {
 
    // Hook into the page module
    $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['cms/layout/db_layout.php']['drawHeaderHook'][$_EXTKEY] =
        \Npostnik\NpPageresourcepreview\Hook\PageHook::class . '->render';
}

Im Ordner Classes/Hook erstellt man eine Datei PageHook.php und schreibt folgendes rein:

<?php
namespace Npostnik\NpPageresourcepreview\Hook;
 
use TYPO3\CMS\Backend\Controller\PageLayoutController;
use TYPO3\CMS\Core\Utility\GeneralUtility;
use TYPO3\CMS\Fluid\View\StandaloneView;
 
class PageHook
{
 
    /**
     * @var StandaloneView
     */
    protected $view;
 
    public function render(array $params, PageLayoutController $parentObject)
    {
        $pageinfo = $parentObject->pageinfo;
        if($pageinfo['media'] == 0) {
            return '';
        }
        $fileRepository = GeneralUtility::makeInstance(\TYPO3\CMS\Core\Resource\FileRepository::class);
        $fileObjects = $fileRepository->findByRelation('pages', 'media', $pageinfo['uid']);
 
        //load partial paths info from typoscript
        $this->view = GeneralUtility::makeInstance(StandaloneView::class);
        $this->view->setFormat('html');
 
        $resourcesPath = 'EXT:np_pageresourcepreview/Resources/';
        $this->view->setTemplatePathAndFilename($resourcesPath . 'Private/Templates/PageHook.html');
        $this->view->assign('files', $fileObjects);
        $this->view->assign('page', $parentObject->pageinfo);
        return $this->view->render();
    }
 
}

Und schließlich erstellt man im Ordner Resources/Private/Templates die Datei PageHook.html mit folgendem Inhalt:

<f:if condition="{page}">
    <f:for each="{files}" as="file">
        <f:image image="{file}" maxHeight="300" />
    </f:for>
</f:if>

Das ist schon alles. Installieren und feddich.

Datepicker im TYPO3 Backend

Eigentlich ist es total simpel, ich bin jedoch fast verzweifelt. Im Template braucht man folgenden Schnipsel:

<f:form.textfield type="datetime" property="timeRestriction" id="timeRestriction" class="form-control t3js-datetimepicker t3js-clearable" data="{date-type:'datetime',date-offset:'0'}" />
<span class="input-group-btn">
	<label class="btn btn-default" for="timeRestriction">
		<span class="fa fa-calendar"></span>
	</label>
</span>

Dann (da war mein Fehler) muss man im Controller das JavaScript für den Datepicker aktivieren:

    /**
     * Set up the doc header properly here
     *
     * @param ViewInterface $view
     */
    protected function initializeView(ViewInterface $view)
    {
        $pageRenderer = $this->view->getModuleTemplate()->getPageRenderer();
        $pageRenderer->loadRequireJsModule('TYPO3/CMS/Backend/DateTimePicker');
    }

Formhandler Vorbelegung der Felder aus Attributen der Seite

Der Formhandler gilt als veraltet, schade eigentlich. Zum Glück hat sich Phorax dessen angenommen und stellt in einem Fork einen zu TYPO3 8 kompatiblen Formhandler bereit.

In meinem aktuellen Projekt sollen Auswahlfelder in einem Formular vorbelegt werden. Dabei kann der Redakteur im Backend in den Eigenschaften der Seite einstellen, was vorausgewählt werden soll.

Ich habe die Seite um die notwendigen Felder erweitert. In der Formhandler-Konfiguration kann mittels TypoScript auf diese Werte zugegriffen werden, um die Felder vorzubelegen.

plugin.Tx_Formhandler.settings.predef.myform {
 
    preProcessors {
        1.class = PreProcessor\LoadDB
        1.config {
            1 {
                meinfeld1.mapping = tx_myext_field1_preselect
                meinfeld2.mapping = tx_myext_field2_preselect
            }
 
            select {
                table = pages
                where.data = page:uid
                where.intval = 1
                where.wrap = uid=|
            }
        }
    }
}

TYPO3 Order by Uid List in Repository

Ich habe ein Flexform mit einem Feld, in dem man Datensätze auswählen kann, die man berücksichtigen möchte. Nun sollen diese Datensätze in der Reihenfolge selektiert werden, die man im Flexform gewählt hat. Wie das Flexform zu konfigurieren ist, spare ich mir hier. Die Abfrage im Repository ist jedoch interessant. Theoretisch war es früher möglich (vor Doctrine) mit einem ORDER BY FIND_IN_SET die Elemente direkt in der richtigen Reihenfolge aus der Datenbank zu holen. Vielleicht geht es doch immer noch irgendwie (immerhin habe ich es geschafft, Elemente zufällig zu sortieren), in meinem Beispiel soll es eine PHP Funktion tun.

Und das ist mein Code: kurz und fein, wie ich finde.

public function findByUidOrdered($uidList = [])
{
    $query = $this->createQuery();
    if(count($uidList) > 0) {
        $query->matching($query->in('uid', $uidList));
    }
    $result = $query->execute()->toArray();
    usort($result, function($a, $b) use ($uidList) {
        $aIndex = array_search($a->getUid(), $uidList);
        $bIndex = array_search($b->getUid(), $uidList);
        return ($aIndex < $bIndex) ? -1 : 1;
    });
    return $result;
}

Funktioniert wunderbar in TYPO3 8.7.

Geschrieben in TYPO3, TYPO3 v8 | Kommentare deaktiviert für TYPO3 Order by Uid List in Repository

TYPO3 Order by Random im Repository

Oder auch: Datensätze in zufälliger Reihenfolge ausgeben

Es kommt schonmal vor, dass man Datensätze aus dem Repository in zufälliger Reihenfolge ausgeben möchte. In meinem Fall habe ich Kundenzitate und möchte sie gerne zufällig sortiert in einem Slider ausgeben. Meine Recherche ergab, dass ORDER BY RAND() nicht geht seit Doctrine in TYPO3 eingezogen ist, diverse Links zu Diskussionen hier und da. Ich bin stur: es muss doch gehen. Da habe ich diesen Forumsbeitrag entdeckt, wo jemand es mit TypoScript hinbekommen hat, in TYPO3 8 wohlgemerkt. Da TypoScript ja auch von Doctrine verarbeitet wird, geht es also doch, man muss nur etwas um die Ecke denken.

Meine Lösung sieht wie folgt aus: Query mit Doctrine zusammenbauen, zusätzliches Feld einfügen das einen Zufallswert enthält und nachdem sortiert wird, Ergebnisse holen und mit dem DataMapper in Objekte transformieren.

use TYPO3\CMS\Core\Database\ConnectionPool;
use TYPO3\CMS\Core\Database\Query\Restriction\FrontendRestrictionContainer;
use TYPO3\CMS\Core\Utility\GeneralUtility;
use TYPO3\CMS\Extbase\Persistence\Generic\Mapper\DataMapper;
/**
 * @param int $limit
 */
public function findRandom($limit)
{
    $queryBuilder = GeneralUtility::makeInstance(ConnectionPool::class)->getQueryBuilderForTable($this->getTableName());
    $queryBuilder->setRestrictions(GeneralUtility::makeInstance(FrontendRestrictionContainer::class));
    $records = $queryBuilder
        ->select('*')
        ->addSelectLiteral('rand() AS random_sort')
        ->from($this->getTableName())
        ->orderBy('random_sort')
        ->setMaxResults($limit)
        ->execute()
        ->fetchAll();
    $dataMapper = GeneralUtility::makeInstance(DataMapper::class);
    $result = $dataMapper->map($this->objectType, $records);
    return $result;
}
 
/**
 * Return the current tablename
 *
 * @return string
 */
protected function getTableName()
{
    $dataMapper = GeneralUtility::makeInstance(DataMapper::class);
    $tableName = $dataMapper->getDataMap($this->objectType)->getTableName();
    return $tableName;
}

Funktionert wunderbar in TYPO3 8.7.

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.

Geschrieben in TYPO3, TYPO3 v8 | Kommentare deaktiviert für TYPO3 E-Mail-Adressen in JsonView verschlüsseln