Beiträge der Kategorie TYPO3

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

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…

Geschrieben in TYPO3, TYPO3 v8 | Kommentare deaktiviert für Fluid f:comment-ViewHelper und Inline JavaScript

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)

Geschrieben in TYPO3 | Kommentare deaktiviert für Flux und Inhaltselemente in News

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

Ü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

Name von fe_user beim Speichern im Backend aus first_name und last_name setzen

Ich glaube mich daran zu erinnern, dass es mal in irgendeiner Registrierungsextension implementiert war. Man wünscht sich, dass der Name eines FE Benutzers (fe_user) sich automatisch aus Vor- und Nachname ergibt, andernfalls sind die Felder ja redundant.

Im Backend kann man mit einem Hook realisieren.

Erstmal muss man das Namensfeld des fe_user auf readOnly setzen, damit man es im BE nicht bearbeiten kann. Das geht am besten in Configuration/TCA/Overrides/fe_users.php der eigenen Extension:

$GLOBALS['TCA']['fe_users']['columns']['name']['config']['readOnly'] = 1;

Dann definiert man einen Hooks für das Backend-Formular: in ext_localconf.php folgendes einsetzen (My\Extension entsprechend ersetzen):

$GLOBALS ['TYPO3_CONF_VARS']['SC_OPTIONS']['t3lib/class.t3lib_tcemain.php']['processDatamapClass']['extkey'] = 'My\Extension\Hook\TceMain';

Dann im Ordner Classes/Hook der Extension die Datei TceMain.php erstellen und darin eine Funktion wie folgt definieren:

<?php
namespace My\Extension\Hook;
 
use TYPO3\CMS\Backend\Utility\BackendUtility;
 
class TceMain
{
 
    /**
     * @param $status
     * @param $table
     * @param $id
     * @param array $fieldArray
     * @param \TYPO3\CMS\Core\DataHandling\DataHandler $pObj
     */
    public function processDatamap_postProcessFieldArray($status, $table, $id, array &$fieldArray, \TYPO3\CMS\Core\DataHandling\DataHandler &$pObj)
    {
        if ($table == 'fe_users') {
            if (array_key_exists('first_name', $fieldArray) || array_key_exists('last_name', $fieldArray)) {
                $oldRow = BackendUtility::getRecord('fe_users', $id);
                $firstName = (array_key_exists('first_name', $fieldArray)) ? $fieldArray['first_name'] : $oldRow['first_name'];
                $lastName = (array_key_exists('last_name', $fieldArray)) ? $fieldArray['last_name'] : $oldRow['last_name'];
                $fieldArray['name'] = $firstName . ' ' . $lastName;
            }
        }
    }
 
}

Dabei wird beim Speichern des Datensatzes der Name automatisch aktualisiert, falls first_name oder last_name bearbeitet wurden. Diese Funktion funktioniert in beiden Fällen: wenn man nur einen Datensatz vollständig bearbeitet oder wenn man mehrere Datensätze gleichzeitig bearbeitet.

Tags: , ,

Geschrieben in TYPO3 | Kommentare deaktiviert für Name von fe_user beim Speichern im Backend aus first_name und last_name setzen

Landauswahl aus static_info_tables in Extension femanager

Für die Benutzerregistrierung nutze ich die Extension femanager, die sich hervorragend konfigurieren lässt.

Im Extension Manual ist beschrieben, wie man die static_info_tables Tabellen als Quelle für die Länderauswahl einsetzen kann. Das funktioniert erstmal nur im Frontend. Wenn man die Templates so anpasst, wie im Manual beschrieben, dann landet der 3-stellige Iso Code des Landes in der Datenbank.

Nun fände ich es auch schön, wenn die entsprechende Auswahl auch im Backend benutzt werden würde. Und so kann man es konfigurieren:

Als erstes muss das TCA der fe_users Tabelle entsprechend umkonfiguriert werden. Dazu in einer eigenen Extension entweder in ext_tables.php oder (besser) in Configuration/Tca/Overrides/fe_users.php folgenden Code einfügen. Damit wird die Länderauswahl mittels itemProcFunc erstellt. In diesem Fall kann man leider nicht einfach ‘foreign_table’ verwenden, da als Key automatisch die uid verwendet wird.

$GLOBALS['TCA']['fe_users']['columns']['country']['config'] = [
    'type' => 'select',
    'renderType' => 'selectSingle',
    'itemsProcFunc' => 'My\Extension\UserFunc\TcaProcFunc->staticInfoTablesItems',
    'maxitems' => 1
];

Dann legt man die Klasse TcaProcFunc in Classes/UserFunc an mit folgendem Inhalt:

<?php
namespace My\Extension\UserFunc;
 
use TYPO3\CMS\Extbase\Reflection\ObjectAccess;
 
class TcaProcFunc
{
 
    /**
     * @param array $config
     * @return array
     */
    public function staticInfoTablesItems($config)
    {
        $key = 'isoCodeA3';
        $value = 'shortNameLocal';
        $sortbyField = 'isoCodeA3';
        $sorting = 'asc';
 
        $objectManager = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance('TYPO3\CMS\Extbase\Object\ObjectManager');
        $countryRepository = $objectManager->get('SJBR\StaticInfoTables\Domain\Repository\CountryRepository');
 
        $countries = $countryRepository->findAllOrderedBy($sortbyField, $sorting);
        $countryList = [];
        $countryList[] = ["", ""];
        foreach ($countries as $country) {
            /** @var $country \SJBR\StaticInfoTables\Domain\Model\Country */
            $countryList[] = [ObjectAccess::getProperty($country, $value), ObjectAccess::getProperty($country, $key)];
        }
        $config['items'] = $countryList;
        return $config;
    }
 
}

Der Code der Function ist aus dem ViewHelper GetCountriesFromStaticInfoTablesViewHelper aus der Extension femanager geklaut 🙂

Tags: ,

Geschrieben in TYPO3 | Kommentare deaktiviert für Landauswahl aus static_info_tables in Extension femanager

Vorschau von Plugin-Einstellungen im Backend in TYPO3

Wenn man eingene Plugins implementiert und dabei mit Flexforms arbeitet, kann man bei einem eingesetzen Plugin im Backend nicht erkennen, welche Einstellungen im Flexform vorgenommen wurden. Es gibt in TYPO3 einen Hook, der es ermöglicht, sich in die Backend-Ansicht einzuklinken und diese Einstellungen dort auszugeben. Und so wird das implementiert:

Als erstes muss man den Hook registrieren in ext_localconf.php der eigenen Extension. Der Name der Klasse ist egal. Unter $pluginSignature gibt man den Namen des Plugin an, so wie man ihn registriert hat.

if (TYPO3_MODE === 'BE') {
    // Page module hook - show flexform settings in page module
    $extensionName = \TYPO3\CMS\Core\Utility\GeneralUtility::underscoredToUpperCamelCase($_EXTKEY);
    $pluginSignature = strtolower($extensionName) . '_pi';
    $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['cms/layout/class.tx_cms_layout.php']['list_type_Info'][$pluginSignature][$_EXTKEY] =
        'My\Extension\Hook\CmsLayout->getExtensionSummary';
}

Dann erstellt man die entsprechende Klasse. In meinem Fall die Klasse CmsLayout im Ordner Classes/Hook. Diese Klasse muss die Funktion getExtensionSummary haben, die als Parameter ein Array übergeben bekommt. Die Funktion gibt einen String zurück, der dann im Backend als Plugin-Zusammenfassung ausgegeben wird.

Dabei ist zu beachten, dass der Hook für alle Plugins aufgerufen wird, d.h. man muss selbst rausfinden, ob man sich in seinem Plugin befindet oder nicht.

Bei mir hat sich mittlerweile dieser Klassenaufbau etabliert:

namespace My\Extension\Hook;
class CmsLayout
{
    public function getExtensionSummary(array $params) {
        $result = null;
        if (strpos($params['row']['list_type'], 'myextension_') !== FALSE) {
            $pluginName = str_replace('myextension_', '', $params['row']['list_type']);
            if ($params['row']['pi_flexform'] != '') {
                $this->flexformData = \TYPO3\CMS\Core\Utility\GeneralUtility::xml2array($params['row']['pi_flexform']);
            }
            $methodName = 'bePreview' . ucfirst(GeneralUtility::underscoredToLowerCamelCase($pluginName));
            if (method_exists($this, $methodName)) {
                $result = $this->$methodName($params['row']);
            }
        }
        return $result;
    }
 
    protected function getFieldFromFlexform($key, $sheet = 'sDEF') {
        $flexform = $this->flexformData;
        if (isset($flexform['data'])) {
            $flexform = $flexform['data'];
            if (is_array($flexform) && is_array($flexform[$sheet]) && is_array($flexform[$sheet]['lDEF'])
                && is_array($flexform[$sheet]['lDEF'][$key]) && isset($flexform[$sheet]['lDEF'][$key]['vDEF'])
            ) {
                return $flexform[$sheet]['lDEF'][$key]['vDEF'];
            }
        }
 
        return NULL;
    }
 
    protected function bePreviewPi($row) {
        // whatever
        return '';
    }
}

In der Funktion getExtensionSummary werden die Flexform-Daten geparst, falls es sich um eines meiner Plugins handelt. Dann wird die Preview-Funktion aufgerufen, falls sie existiert. Damit spare ich mir if- oder switch-Abfragen.

Hinweis 8.5.: Ich habe mitbekommen, dass sich die Flexform-Definition in der TYPO3 Version 8 geändert hat. d.h. es müssten entsprechend Anpassungen an diesem Code vorgenommen werden.

Bug? Falsche Artikelauswahl auf der News-Seite

Ok, ich versuche mal mein Setup zu beschreiben.

Kategorien sehen ungefähr so aus:

  • Kategorie Eins
    • Subkategorie EinsEins
    • Subkategorie EinsZwei
  • Kategorie Zwe
    • Subkategorie ZweiEins
    • Subkategorie ZweiZwei
  • Kategorie Drei

Dann sind da natürlich News-Beiträge, die immer einer Hauptkategorie und (falls diese Unterkategorien hat) Unterkategorien zugewiesen sind. Pro Hauptkategorie gibt es jeweils eine Ausgabe-Seite, die in der Hauptspalte ein Plugin enthält, wo eingestellt ist, dass nur Beiträge einer Kategorie angezeigt werden. So weit passt alles.

Und auf einmal werden auf der Seite in Plugin, das eigentlich nur Beiträge der Kategorie “Kategorie Eins” und Unterkategorien anzeigen soll, auch Beiträge der Kategorie Zwei angezeigt. Ich habe alles überprüft: Ist die Zuordnung im Artikel richtig gesetzt? Ist das Plugin auf der Seite richtig konfiguriert? Sieht alles gut aus. Hab schon angefangen an meinem Verstand zu zweifeln und an einen mysteriösen Bug in News geglaubt.

Lösung: Damit nur Artikel einer bestimmten Kategorie ausgegeben werden, muss im News-Plugin in der Kategorieauswahl “Show items with selected categories” ausgewählt werden. Wenn man keine weiteren Einstellungen vornimmt, dann kann damit durch URL Parameter die Kategorieauswahl überschrieben werden. Wenn man RealURL verwendet, merkt man das nicht so schnell. Im RealURL Cache für diese Seite war nämlich ungefähr folgende URL eingetragen: seite/?tx_news_pi1[overwriteDemand][categories]=0 und die auch noch an erster Stelle. d.h. Wenn man die Seite aufruft, dann wird die sprechende URL so umgewandelt, dass die Kategorieauswahl aufgehoben wird.

Damit das nicht wieder passiert, kann man im News-Plugin das Überschreiben von Kategorien per URL deaktivieren: im Tab “Additional” unter “Disable override demand”.