Beiträge der Kategorie TYPO3 v9

Abschnittsnavigation (aka menu_section) mit Gridelements

Wenn man mit Gridelements und somit verschachtelten Inhaltselementen arbeitet, stellt man vielleicht irgendwann fest, dass die Sortierung nicht funktioniert, sobald in der Abschnittsnavigation anzuzeigende Inhaltselemente in Container (2-Spalten etc.) angeordnet werden. Beispiel (in Klammern ist die Position intern):

  • Container A (1)
    • Element A.1 (1)
    • Element A.2 (2)
  • Container B (2)
    • Element B.1 (1)
    • Element B.2 (2)

Je nachdem, in welcher Reihenfolge man die Elemente erstellt hat, kann z.B. folgende Abschnittsnavigation ausgegeben werden:

  • B.1
  • A.1
  • A.2
  • B.2

Ich habe z.B. folgende Lösung mit einem ViewHelper gefunden. Ich wollte jedoch eine Lösung, die auch für bereits vorhandene Inhaltselemente funktioniert und die unabhängig vom Template eingesetzt werden kann. So habe ich mich für einen DataProcessor entschieden.

Als erstes hole ich mir alle Inhaltselemente – unabhängig davon, ob sectionIndex gesetzt ist oder nicht. Dann hänge ich meinen eigenen DataProcessor ein.

tt_content.menu_section.dataProcessing.10.dataProcessing.20 {
    where >
}
tt_content.menu_section.dataProcessing.10.dataProcessing.30 = NP\MyExtension\DataProcessing\SectionProcessor

Im DataProcessor werden die Datensätze gefiltert, so dass nur die mit sectionIndex = 1 übrig bleiben. Weiterhin wird die Sortierung korrigiert und es wird neu sortiert. Beim neuen Sorting wird der Wert der Elemente, die direkt auf der Seite abgelegt sind, mit 10000 multipliziert. Falls das Element in einem Container liegt, dann wird die Sortierung auf den Sorting-Wert des Containers mal 10000 plus die eigene Sortierung gesetzt.

Den DataProcessor lege ich unter Classes\DataProcessing\SectionProcessor.php ab:

namespace NP\MyExtension\DataProcessing;
 
use TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer;
use TYPO3\CMS\Frontend\ContentObject\DataProcessorInterface;
 
class SectionProcessor implements DataProcessorInterface
{
 
    /**
     * Process content object data
     *
     * @param ContentObjectRenderer $cObj The data of the content element or page
     * @param array $contentObjectConfiguration The configuration of Content Object
     * @param array $processorConfiguration The configuration of this processor
     * @param array $processedData Key/value store of processed data (e.g. to be passed to a Fluid View)
     * @return array the processed data as key/value store
     */
    public function process(
        ContentObjectRenderer $cObj,
        array $contentObjectConfiguration,
        array $processorConfiguration,
        array $processedData
    ) {
        $processedContent = [];
        $sortMapping = [];
        foreach ($processedData['content'] as $content) {
            if ($content['data']['sectionIndex'] == 1) {
                $content['data']['sorting'] = $this->getRealSorting($content, $processedData['content']);
                $processedContent[] = $content;
            }
        }
        // debug($processedContent, 'processed content');
        usort($processedContent, [$this, 'sortContent']);
        $processedData['content'] = $processedContent;
        return $processedData;
    }
 
    /**
     * @param array $content
     * @param array $allElements
     */
    protected function getRealSorting($content, $allElements)
    {
        if ($content['data']['colPos'] != '-1') {
            return $content['data']['sorting'] * 10000;
        }
        $sorting = $content['data']['sorting'];
        foreach ($allElements as $element) {
            if ($element['data']['uid'] == $content['data']['tx_gridelements_container']) {
                $sorting += $element['data']['sorting'] * 10000;
            }
        }
        return $sorting;
    }
 
    /**
     * @param array $a
     * @param array $b
     * @return bool
     */
    protected function sortContent($a, $b)
    {
        return $a['data']['sorting'] > $b['data']['sorting'];
    }
}

Dieser Ansatz wird limitiert durch das Verschachtelungslevel der Elemente. Da könnte man diesen auf die schnelle implementierten Ansatz noch optimieren.

Geschrieben in gridelements, TYPO3, TYPO3 v9 | Kommentare deaktiviert für Abschnittsnavigation (aka menu_section) mit Gridelements

TYPO3 Meldung bei gesperrten Records im Backend

Ich arbeite ja fast immer in der englischen Version, daher ist mir dieser Fehler nicht aufgefallen. Wenn ein anderer Benutzer einen Datensatz (z.B. eine Seite) zum Bearbeiten geöffnet hat, dann wird im TYPO3 Seitenbaum eine Meldung angezeigt. Im Englischen lautet die Meldung wie folgt:
„The user ‚%s‘ began to edit this record %s ago.“ Dann wird der Benutzertyp und das Datum eingesetzt, passt soweit.

Ist das Backend auf deutsch eingestellt, sieht diese Meldung etwas komisch aus.

Die Anführungsstriche werden mit HTML-Entities dargestellt.

Die Suche im Netz gab diesen wertvollen Beitrag aus der TYPO3-Doku aus: https://docs.typo3.org/m/typo3/reference-coreapi/9.5/en-us/ApiOverview/Internationalization/ManagingTranslations.html

Die Übersetzungen fürs Backend können also in einer eigenen Extension überschrieben werden.

Das in die ext_localconf.php einer eigenen Extension:

$GLOBALS['TYPO3_CONF_VARS']['SYS']['locallangXMLOverride']['de']['EXT:core/Resources/Private/Language/locallang_core.xlf'][] = 'EXT:my_extension/Resources/Private/Language/de.locallang-core.xlf';

Dann unter dem angegebenen Pfad die xlf-Datei anlegen und folgendes rein:

<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<xliff version="1.0">
    <file source-language="en" datatype="plaintext" date="2013-03-09T18:44:59Z" product-name="examples">
        <header/>
        <body>
            <trans-unit id="labels.lockedRecord" resname="labels.lockedRecord" approved="yes">
                <source>The user '%s' began to edit this record %s ago.</source>
                <target state="translated">Der Benutzer '%s' hat mit der Bearbeitung dieses Datensatzes vor %s begonnen.</target>
            </trans-unit>
            <trans-unit id="labels.lockedRecord_content" resname="labels.lockedRecord_content" approved="yes">
                <source>The user '%s' began to edit content on this page %s ago.</source>
                <target state="translated">Der Benutzer '%s' hat mit der Bearbeitung dieser Seite vor %s begonnen.</target>
            </trans-unit>
            <trans-unit id="labels.lockedRecordUser" resname="labels.lockedRecordUser" approved="yes">
                <source>The %s '%s' began to edit this record %s ago.</source>
                <target state="translated">Der %s '%s' hat mit der Bearbeitung dieses Datensatzes vor %s begonnen.</target>
            </trans-unit>
            <trans-unit id="labels.lockedRecordUser_content" resname="labels.lockedRecordUser_content" approved="yes">
                <source>The %s '%s' began to edit content on this page %s ago.</source>
                <target state="translated">Der %s '%s' hat mit der Bearbeitung dieser Seite vor %s begonnen.</target>
            </trans-unit>
        </body>
    </file>
</xliff>

Klappt! Hab ich schon erwähnt, dass ich TYPO3 toll finde 😀

Geschrieben in TYPO3, TYPO3 v9 | Kommentare deaktiviert für TYPO3 Meldung bei gesperrten Records im Backend

TYPO3 auf ohne Composer umstellen

Ich persönlich arbeite mittlerweile sehr gerne mit Composer. Man kann schnell Extensions installieren/aktualisieren und TYPO3 aktualisieren. Bei jeden neuen Projekt arbeite ich mit Composer, außer es ist aus irgendwelchen Gründen doch nicht möglich – fehlende SSH Zugänge oder ähnliches. Manchmal kommt es vor, dass man eine mit Composer installierte TYPO3-Instanz von Composer wieder trennen muss.

Es ist eigentlich einfach – in der Datei vendor/typo3/cms-composer-installers/autoload-include.php nur den folgenden Abschnitt entfernen:

// TYPO3 is installed via composer. Flag this with a constant.
if (!defined('TYPO3_COMPOSER_MODE')) {
    define('TYPO3_COMPOSER_MODE', TRUE);
}

In meinem Fall hatte ich auch den crawler installiert. Nachdem ich den Abschnitt entfernt und alle Caches gelöscht hatte, wurde mein Backend nicht geladen mit der Fehlermeldung:

Warning: Uncaught TYPO3\CMS\Core\Error\Exception: PHP Warning: require([...]/public/typo3conf/ext/ crawler//Resources/Private/Php/ Libraries/vendor/autoload.php): failed to open stream: No such file or directory

In der ext_localconf.php der Extension crawler findet man folgendes:

if (!\TYPO3\CMS\Core\Core\Environment::isComposerMode()) {
require \TYPO3\CMS\Core\Utility\ExtensionManagementUtility::extPath('crawler') . '/Resources/Private/Php/Libraries/vendor/autoload.php';
}

Der angegebene Pfad existiert aber nicht. Ein Ticket beim Crawler-Issue-Tracker und ein paar Stunden später ist die Lösung eigentlich banal: Extension crawler aus dem TER neu installieren. Sobald man das tut, dann werden die erforderlichen Pakete (die bei der Installation per Composer in vendor installiert werden) unter dem entsprechenden Pfad abgelegt.

Geschrieben in TYPO3, TYPO3 v9 | Kommentare deaktiviert für TYPO3 auf ohne Composer umstellen

TYPO3 9 – Twitter-/Facebook Meta-Angaben mit Fallback auf Standardfelder

In TYPO3 9 gibt nach der Installation der Core-Extenson seo in den Seiteneigenschaften Felder, um Meta-Informationen für Facebook und Twitter zu hinterlegen. Diese Informationen werden im Quellcode ausgegeben, wenn man die Felder entsprechend ausgefüllt hat. Nun möchte man nicht explizit immer diese Informationen angeben müssen, vor allem weil der Facebook-/Twitter-Beschreibungstext wahrscheinlich eh identisch ist mit dem Beschreibungstext der Seite. Und die Bilder können automatisch aus dem Feld media generiert werden, wenn es denn befüllt ist.

Mit dem folgenden TypoScript lassen sich Beschreibung und Seitentitel in die Facebook-/Twitter-Meta-Angaben der Seite schreiben. Sobald die „richtigen“ Felder ausgefüllt werden, dann werden die Angaben daraus ausgegeben.

page.meta {
    og:title.cObject = TEXT
    og:title.cObject {
        field = title
    }
 
    og:description.cObject = TEXT
    og:description.cObject {
        field = description
        # data = levelfield:-1 , description, slide
    }
 
    og:image.cObject = IMG_RESOURCE
    og:image.cObject.file {
        import.data = levelmedia:-1, slide
        treatIdAsReference = 1
        import.listNum = 0
        maxW = 1200
        cropVariant = default
    }
    og:image.cObject.stdWrap.dataWrap = {getIndpEnv:TYPO3_REQUEST_HOST}/
}

Damit es mit dem Levelfield Slide funktioniert, müssen die Felder in addRootLineFields aufgenommen werden. Das kann entweder „global“ in der LocalConfiguration.php gemacht werden oder die Extension fügt diese der vorhandenen Liste hinzu.

In meinem Beispiel habe ich weiterehin Crop Varianten für das Media-Feld der Seite definiert und greife auf diese zu. Wenn das nicht gewünscht ist, dann die Zeile mit cropVariants = default einfach weglassen.

Geschrieben in TYPO3, TYPO3 v9 | Kommentare deaktiviert für TYPO3 9 – Twitter-/Facebook Meta-Angaben mit Fallback auf Standardfelder

Lösung für Bilder im Flexform ohne Alternative-Feld

Für ein Custom Content Element kann in einem Feld Überschrift und ein Text eingegeben werden und ein Bild verknüpfte werden. Die Felder sind alle im Flexform definiert und der Kunde bemängelte (zurecht), dass die Möglichkeit zur Eingabe des Alternative Text beim Bild fehle. Kurz gesucht und einen Eintrag im Bezug auf TYPO3 6 gefunden, der unter TYPO3 9 immer noch funktioniert.

So wird das Bild im Flexform definiert:

<image>
    <TCEforms>
        <label>Bild</label>
        <config>
            <type>inline</type>
            <maxitems>1</maxitems>
            <minitems>1</minitems>
            <foreign_table>sys_file_reference</foreign_table>
            <foreign_table_field>tablenames</foreign_table_field>
            <foreign_label>uid_local</foreign_label>
            <foreign_sortby>sorting_foreign</foreign_sortby>
            <foreign_selector>uid_local</foreign_selector>
            <foreign_selector_fieldTcaOverride type="array">
                <config>
                    <appearance>
                        <elementBrowserType>file</elementBrowserType>
                        <elementBrowserAllowed>jpg,png</elementBrowserAllowed>
                    </appearance>
                </config>
            </foreign_selector_fieldTcaOverride>
            <foreign_match_fields type="array">
                <fieldname>image</fieldname>
            </foreign_match_fields>
            <appearance type="array">
                <newRecordLinkAddTitle>1</newRecordLinkAddTitle>
                <headerThumbnail>
                    <field>uid_local</field>
                    <height>64</height>
                    <width>64</width>
                </headerThumbnail>
            </appearance>
        </config>
    </TCEforms>
</image>

Und folgenden Block muss man einfügen, damit das alt-Feld angezeigt wird:

<image>
    <TCEforms>
        <label>Bild</label>
        <config>
            [...]
            <foreign_types type="array">
                <numIndex index="2">
                    <showitem>title,description,alternative</showitem>
                </numIndex>
            </foreign_types>
            [...]
        </config>
    </TCEforms>
</image>

Das war der Artikel, den ich gefunden habe: https://typo3-english.typo3.narkive.com/0GGddVxh/typo3-6-0-using-fal-image-in-a-flexform-as-an-element

Grundsätzlich würde ich davon abraten, Bilder im Flexform zu referenzieren. Gerade in diesem Fall, wenn die Felder wie Überschrift, Text und Bild bereits in der Tabelle vorhanden sind, wäre es deutlich einfacher gewesen, zwar ein neues Inhaltselement zu definieren, jedoch die vorhandenen Felder zu nutzen. Es hat diverse Vorteile: man kann das Element in Typ Text „konvertieren“, ohne die Inhalte zu verlieren und die Inhalte können besser gefunden werden. Das Projekt habe ich von einem anderen Entwickler übernommen und das Element wird bereits häufig genutzt, so dass ein Umbau nicht mehr so einfach ist.

Geschrieben in TYPO3, TYPO3 v8, TYPO3 v9 | Kommentare deaktiviert für Lösung für Bilder im Flexform ohne Alternative-Feld

404 Fehlerseite beim Routing nach Update auf 9.5.20

Für ein selbst-geschriebenes Plugin hatte ich eine funktioniere Routing-Konfiguration umgesetzt. Die Extension ist so eine Art news, aber deutlich abgespeckt. Da die Beiträge alle ein Datum haben, gibt es eine einfache Datumsnavigation. Nach einem Update auf TYPO3 9.5.20 funktionierten die Detail-Links weiterhin, die Links der Datumsnavigation lieferten einen 404-Fehler – Seite nicht gefunden.

Die funktonierende Konfiguration sah so aus.

routeEnhancers:
  Magazine:
    type: Extbase
    extension: MyMagazine
    limitToPages:
      - 18
      - 65
    plugin: Magazine
    defaultController: 'Article::list'
    defaults:
      date-month: ''
      date-year: ''
    routes:
      -
        routePath: '/{article-title}'
        _controller: 'Article::show'
        _arguments:
          article-title: article
      -
        routePath: '/{date-year}-{date-month}'
        _controller: 'Article::list'
        _arguments:
          date-month: overwriteDemand/month
          date-year: overwriteDemand/year
        requirements:
          date-month: \d+
          date-year: \d+
    aspects:
      article-title:
        type: PersistedAliasMapper
        tableName: tx_mymagazine_domain_model_article
        routeFieldName: path_segment
      date-month:
        type: StaticRangeMapper
        start: '01'
        end: '12'
      date-year:
        type: StaticRangeMapper
        start: '2000'
        end: '2030'

Nach dem Update und dem 404-Fehler beim Aufruf der Ansicht mit Jahr-Monat-Parametern hatte ich lange gesucht, unterschiedliches ausprobiert, mich durch den Quellcode gehangelt, es half alles nichts. Ich hatte mich bei der Konfiguration nach der Dokumentation von news gerichtet (Hut ab vor Georg Ringer und dieser Extension). Da ist der Block requirements in dem jeweiligen routePath-Block definiert. Die aktuellste Dokumentation des Core sieht da etwas anders aus: der requirements-Block steht dort an der gleichen Ebene wie aspects und routes. Die Lösung meines Problems war die Angabe von genauen Requirements auf der gleichen Ebene wie routes und aspects, sicherheitshalber habe ich noch einen neuen Konfigurationsabschnitt angelegt (DateMenu).

  DateMenu:
    type: Extbase
    extension: MyMagazine
    limitToPages:
        - 18
    plugin: Magazine
    defaultController: 'Article::list'
    defaults:
      date-month: ''
      date-year: ''
    routes:
      - routePath: '/{date-year}-{date-month}'
        _controller: 'Article::list'
        _arguments:
          date-month: overwriteDemand/month
          date-year: overwriteDemand/year
    requirements:
      date-month: '[0-9]{2}'
      date-year: '[0-9]{4}'
    aspects:
      date-month:
        type: StaticRangeMapper
        start: '01'
        end: '12'
      date-year:
        type: StaticRangeMapper
        start: '2000'
        end: '2030'

Die nicht mehr funktionierende Konfiguration ist wahrscheinlich auf diesen BUGFIX zurückzuführen – es ist jedoch nur eine Vermutung…

Geschrieben in TYPO3, TYPO3 v9 | Kommentare deaktiviert für 404 Fehlerseite beim Routing nach Update auf 9.5.20

TYPO3 Extension und Composer-Packages ohne Composer

Ich bin schon verwöhnt, seit ich Composer nutze. Da gibt es dann andere Problemchen, aber zumindest braucht man sich keine Gedanken um Abhängigkeiten zu machen. Extension per Composer installieren, notwendige Pakete werden geladen – fertig! Gelegentlich kommt es vor, dass auf einem Kunden-Server Composer nicht installiert werden darf oder der Kunde es nicht wünscht. Ich knirsche dann ein bisschen mit den Zähnen und arbeite so wie früher – „classic way“, wie es auf get.typo3.org so schön heißt.

Aktuell habe ich genau so einen Fall. Ich habe eine Extension installiert, die folgende Pakete benötigt:

"geocoder-php/google-maps-provider": "^4.4",
"php-http/guzzle6-adapter": "^1.0",
"php-http/message": "^1.7",
"geocoder-php/nominatim-provider": "^5.1"

Zunächst habe ich angefangen, mit alle Pakete aus den jeweiligen Git-Repos herunterzuladen, die dann wiederum andere Pakete brauchten etc. So hangelte ich mich von Paket zu Paket. Die Dateien der Pakete müssten natürlich nicht nur da sein, sondern auch eingebunden werden. Am Anfang hatte ich jede Datei einzeln mit require eingebunden – da wird man ja bekloppt! Es wurde mir composer-file-loader empfohlen. Es löst zwar das Problem, dass man die Dateien nicht alle einzeln aufführen muss, aber ein Paket benötigt das andere und sich an den Abhängigkeiten entlanghangeln muss man ja selbst.

Etwas später in einer ruhigen Minute hatte ich die Idee: Ich kann auf dem Server kein Composer nutzen, aber ich kann LOKAL Composer nutzen, um mir die notwendigen Pakete zu laden.

Ich habe eine TYPO3 Extension erstellt, die nur aus ext_localconf.php, ext_emconf.php und composer.json besteht. In die composer.json habe ich die benötigten Pakete aufgelistet:

{
    "name": "myvendor/myextension",
    "type": "typo3-cms-extension",
    "description": "Externe Pakete, da sie nicht per Composer installiert werden können",
    "license": "GPL-2.0+",
    "require": {
        "geocoder-php/google-maps-provider": "^4.4",
        "php-http/guzzle6-adapter": "^1.0",
        "php-http/message": "^1.7",
        "geocoder-php/nominatim-provider": "^5.1"
    },
    "config": {
        "vendor-dir": "vendor"
    }
}

Dann auf der Konsole in dem Extension-Ordner composer install laufen lassen. Nicht nur, dass mir composer alle Pakete mit den Abhängigkeiten lädt, er erstellt auch eine autoload.php, die ich einbinden kann. Somit steht in meiner ext_localconf.php nur noch das:

require_once(\TYPO3\CMS\Core\Utility\GeneralUtility::getFileAbsFileName('EXT:myextension/vendor/autoload.php'));

Da merkt man doch wieder, wie schön Arbeiten mit Composer ist…

Plugins in GridElement scheinbar ohne Flexform-Settings

Falls jemand so wie ich einige Stunden (ok, ich übertreibe etwas) an diesem Problem verzweifeln sollte. Ich habe eine 3-spaltiges GridElement, das ich gemäß der aktuellsten Vorgabe mit dem DataProcessor umgesetzt habe. Übrigens ist die Dokumentation an dieser Stelle falsch.

Dort heißt es:

This is the default TypoScript setting provided while including the special Gridelements w/DataProcessing setup in your TS template editor:

lib.gridelements.defaultGridSetup =< lib.contentElement
lib.gridelements.defaultGridSetup {
[...]

Das Objekt lib.gridelements.defaultGridSetup gibt es nicht. Es wird tt_content.gridelements_pi1 hinzugefügt, der Rest der Angaben in der Dokumentation stimmt soweit.

Nun hatte ich also in einer Spalte ein Plugin mit ein paar Einstellungen, die über ein Flexform vorgenommen werden. In der "normalen" Content-Spalte funktioniert alles - meine Einstellungen werden im Frontend entsprechend ausgewertet. In einer Spalte in diesem GridElement hingegeben nicht - ich bekam in meinem Fall gar keine Ausgabe. Zum Glück bin ich zufällig über einen Issue gestolpert. Das Problem ist, dass der GridChildrenProcessor in Standardfall das Feld pi_flexform der Kinder parst und dabei in ein Array umwandelt. Wenn man die Inhalte der Spalte wie folgt ausgibt, dann wird die Eingabe im Feld pi_flexform nochmal verarbeitet.


Da es ja kein String mit XML-Inhalten, sondern ein Array ist, werden die Settings nicht ausgelesen und im Frontend nicht intepretiert. Das liegt an der Einstellung resolveChildFlexformData, die per default 1 ist. In diesem Issue wird vorgeschlagen, den Wert von resolveChildFlexformData per Default auf 0 zu setzen. Um breaking changes zu vermeiden, wird entschieden, diesen Wert wie vorher zu belassen, d.h. auf 1.

In meinem Fall ist die Lösung somit, diese Einstellung auf 0 zu setzen.

tt_content.gridelements_pi1.dataProcessing.10.default.options.resolveChildFlexFormData = 0

Gridelement auf Daten vom Parent zugreifen

In einer TYPO3 9 Installation mit Gridelements habe ich ein extrem flexibeles Accordion-Element erstellt. Es gibt dabei ein Gridelement „Accordion-Container“, das als Container für alle zusammengehörigen Accordion-Inhaltselemente dienen soll. Weiterhin gibt es ein „Accordion-Content“ – damit können mehrere Inhaltselemente gruppiert werden. Der Container ist notwendig, um das Accordion-typische Verhalten zu realisieren: man klickt ein Element zum Öffnen an und alle anderen schließen sich. Die klickbare Überschrift wird im Accordion-Content-Element hinterlegt. Im Accordion-Container können Einstellungen wie Farbe und Verhalten für das gesamte Accordion vorgenommen werden.

Und das ist genau das Problem. Sobald ich mich im Context des Accordion-Content befinde, kenne ich die Einstellungen wie Farbe und Verhalten nicht mehr – die sind ja im Container (aka Parent) hinterlegt.

Die neueste Version von Gridelements nutzt DataProcessing, also beschloss ich einen DataProcessor einzusetzen, um an die Daten des übergeordneten Elements ranzukommen:

tt_content.gridelements_pi1.dataProcessing {
    20 = TYPO3\CMS\Frontend\DataProcessing\DatabaseQueryProcessor
    20 {
        if.equals.field = tx_gridelements_backend_layout
        if.value = accordion-content
        table = tt_content
        pidInList.field = pid
        where = uid=###uid### AND deleted=0 AND hidden=0
        markers.uid.field = tx_gridelements_container
        as = parent
 
        dataProcessing {
            10 = Vendor\MyExtension\DataProcessing\FlexformDataProcessor
            10 {
                as = flexform_data
            }
        }
    }
}

Die Implementierung des FlexformDataProcessor habe ich bereits in einem anderen Beitrag beschrieben.

Nachdem ich das implementiert hatte, fiel mir ein, dass ich mein Problem bestimmt auch mit variable.set aus dem Fluid ViewHelper-Set lösen könnte – und siehe da, das geht auch.

Femanager – Profil bearbeiten und das Passwort Problem

Bei einem aktuellen Projekt arbeite ich mit Femanager für die Frontend-Benutzer-Verwaltung und bin dabei auf einige Schwierigkeiten gestoßen, die ich mit einem Workaround umschiffen konnte. Die Benutzer-Registrierung funktioniert sehr gut, die Probleme entstehen im Profil-Bearbeiten-Formular.

Das Standard-Template für Profil bearbeiten (Edit) im Femanager ist relativ einfach: Falls im Backend Felder ausgewählt sind, dann gebe für jedes Feld das Partial aus, ansonsten alle Felder. In meinem Fall ist das Profil bearbeiten Formular etwas komplexer aufgebaut: zweispaltig, Felder teilweise gruppiert.

Zuerst hatte ich das Passwort im Formular drin, hatte jedoch die Passwort-Validierung aus der Konfiguration entfernt und die Einstellung keepPasswordIfEmpty gesetzt. Es kommt eine Fehlermeldung von der Passwort-Hash-Funktion (Femanager Issue).

Ok, also Passwort aus dem Formular entfernt. Dann eine neue Seite erstellt, auf der Profil-Bearbeiten-Plugin platziert und dort nur das Passwort als Feld ausgewählt, weiterhin alle anderen Felder per Konfiguration als der Validierung entfernt. Die clientseitige Validierung hat auch rumgezickt, also habe ich sie auch deaktiviert (zumindest auf der Seite). Mit dieser Konfiguration kann das Passwort auf einer separaten Seite geändert werden.

plugin.tx_femanager.settings {
    edit.validation {
        _enable.client = 0
        password.required = 1
        password_repeat.required = 1
        lastName >
        firstName >
        username >
        email >
        address >
        zip >
        usergroup >
        city >
        country >
        jobState >
        subject >
    }
}

Obwohl ich das Passwort aus dem Template entfernt habe und die Validierung des Passworts aus dem Konfiguration, wird die Passwort-Validierung trotzdem aufgerufen. Schuld daran ist die folgende Zeile im PasswordValidator:

public function isValid($user)
{
    $this->init();
 
    // if password fields are not active or if keep function active
    if (!$this->passwordFieldsAdded() || $this->keepPasswordIfEmpty()) {
        return true;
    }
 
    $password = $user->getPassword();
    $passwordRepeat = isset($this->piVars['password_repeat']) ? $this->piVars['password_repeat'] : '';
 
    if ($password !== $passwordRepeat) {
        $this->addError('validationErrorPasswordRepeat', 'password');
        return false;
    }
 
    return true;
}

Die Funktion passwordFieldsAdded liefert dann true, wenn das Passwort-Feld im Flexform explizit hinzugefügt wurde oder gar kein Feld, was aus der Sicht der Extension bedeutet, dass das Passwort-Feld ja sichtbar ist. Ich habe ja schon erwähnt, dass durch das etwas komplexere Formular die Variante die Felder alle einzeln auszuwählen für mich nicht in Frage kommt. Ich muss also alle Felder ausgeben, durch die Konfiguration der Extension jedoch vorgaukeln, dass das Passwort-Feld nicht gewählt ist. Als Lösung habe ich in der TypoScript-Konfiguration eine neue Einstellung hinzugefügt showAll, die ich dann im Template abfrage. Damit kann ich im Flexform z.B. das Feld ‚firstname‘ auswählen und es werden trotzdem alle Felder angezeigt. Auf der Passwort-Bearbeiten-Seite muss ich den Wert auf 0 setzen, damit nur das Passwort-Feld ausgegeben wird.

Das Edit-Template sieht verkürzt so aus:

<f:if condition="{settings.edit.showAll}">
    <f:then>
        ALLE FELDER AUSGEBEN
    </f:then>
    <f:else>
        <f:for each="{femanager:misc.explode(string:'{settings.edit.fields}')}" as="field">
            <f:render partial="Fields/{femanager:misc.upper(string:'{field}')}" arguments="{_all}" />
        </f:for>
        <f:render partial="Fields/SubmitUpdate" arguments="{_all}" />
    </f:else>
</f:if>

Es ist leider die beste Lösung für das Problem, die mir gerade einfällt. Bin gespannt, ob mir es bald um die Ohren fliegt…

Geschrieben in TYPO3, TYPO3 v9 | Kommentare deaktiviert für Femanager – Profil bearbeiten und das Passwort Problem