In meinem Beispiel will ich in einem eigenen Modul einen Datepicker verwenden und das Feld leeren können. Weiterhin soll ein kleines CSS im Backend-Modul eingebunden werden.

Die Registrierung der Module hat sich in TYPO3 12 geändert: Backend module configuration. Was ich dort in dieser Anleitung nicht gefunden habe: wie man in einem Modul z.B. einen Datepicker verwenden kann oder eigene CSS-Stylesheets einbindet.

Konfigurationsdatei JavaScriptModules.php im Order Configuration der Extension erstellen. Darin werden die Abhängigkeiten definiert und der Pfad zu den verfügbaren JS-Dateien. Als key in den Import gibt man an, wie das Modul dann im Template geladen werden kann.

Configuration/JavaScriptModules.php

return [
    'dependencies' => [
        'backend',
        'core',
    ],
    'imports' => [
        '@myextension/module/' => 'EXT:my_extension/Resources/Public/JavaScript/',
    ],
];

In der JS-Datei steht folgendes (das habe ich aus einem Core-Modul kopiert). Statt MyModule sollte der Name des eigenen Moduls eingesetzt werden.

Resources/Public/JavaScript/backend-module.js

import DateTimePicker from "@typo3/backend/date-time-picker.js";
import "@typo3/backend/input/clearable.js";
class MyModule {
    constructor() {
        this.clearableElements = null, this.dateTimePickerElements = null, DocumentService.ready().then((() => {
            this.clearableElements = document.querySelectorAll(".t3js-clearable"), this.dateTimePickerElements = document.querySelectorAll(".t3js-datetimepicker"), this.initializeClearableElements(), this.initializeDateTimePickerElements()
        }))
    }
 
    initializeClearableElements() {
        this.clearableElements.forEach((e => e.clearable()))
    }
 
    initializeDateTimePickerElements() {
        this.dateTimePickerElements.forEach((e => DateTimePicker.initialize(e)))
    }
}
 
export default new MyModule;

Im Template des Moduls kommt nun folgendes in die content-section, im Kommentar steht der Namespace des ViewHelpers, das muss natürlich ins html-Tag. Dort wird nun der Pfad eingesetzt, den man oben in JavaScriptModules.php festgelegt hat. Unter includeCssFiles kann man auch CSS-Dateien angeben, die im Modul eingebunden werden.

<!-- xmlns:be="http://typo3.org/ns/TYPO3/CMS/Backend/ViewHelpers" -->
 
<f:be.pageRenderer
    includeJavaScriptModules="{
        0: '@myextension/module/backend-module.js'
    }"
 
    includeCssFiles="{
        0: '{f:uri.resource(path: \'Css/backend.css\')}'
    }"
/>

Sobald in einem Feld die entsprechenden Klassen gesetzt werden, wird dort ein Datepicker generiert:

<div class="input-group">
    <f:form.textfield id="filter_datefrom"
                      property="datefrom"
                      class="form-control t3js-datetimepicker t3js-clearable"
                      data="{date-type: 'date'}"
    />
    <label class="mb-0 btn btn-default" for="filter_datefrom">
        <core:icon identifier="actions-calendar" />
    </label>
</div>

Ich weiß nicht, ob es der einzige Weg ist, oder ob es andere/bessere Möglichkeiten gibt. Ich schaue mir immer an, wie das die Core-Module machen und übernehme es für meine Module. Ich freue mich über Feedback 🙂

In TYPO3 gibt es zwei Möglichkeiten settings oder allgemein Einstellungen für Plugins zu konfigurieren. Entweder man konfiguriert für die komplette Extension oder für einzelne Plugins. Da ich das nicht besser beschreiben kann, versuche ich es an einem Beispiel.

Angenommen, die Extension heißt my_extension und hat zwei Plugins pi1 und pi2. Die Konfiguration allgemein kann unter plugin.tx_myextension abgelegt werden und für die einzelnen Plugins unter plugin.tx_myextension_pi1 und plugin.tx_myextension_pi2. Die „allgemeine“ Konfiguration wird dabei an die Plugins vererbt.

plugin.tx_myextension.settings {
  var1 = Variable 1
}
 
plugin.tx_myextension_pi1.settings {
  var2 = Variable 2
}
 
plugin.tx_myextension_pi2.settings {
  var3 = Variable 3
}

Im ersten Plugin pi1 stehen damit in den Settings die Variablen var1 und var2 zur Verfügung, im Plugin pi2 die Variablen var1 und var3.

Was ist aber, wenn eine Variable entfernt werden soll? In diesem Fall funktioniert der > Operator leider nicht, da die Settings allgemein und Plugin als Array gemergt werden. Die Lösung ist das Wörtchen „__UNSET“, das ein entfernen des Schlüssels zur Folge hat.

plugin.tx_myextension_pi1.settings {
  var1 = __UNSET
}

Wie es der Titel schon sagt, nach einem Update auf TYPO3 12 hat der Mailversand nicht mehr funktioniert, Fehlermeldung

the rendering context of ViewHelper f:uri.page is missing a valid request object

Dank Websuche bin ich schnell auf diesen Eintrag bei stackoverflow gestoßen.

In meinem Fall war es geringfügig anders, ich nutze FluidEmail, dort kann es aber genauso verwendet werden:

/** @var FluidEmail $email */
$email = GeneralUtility::makeInstance(FluidEmail::class);
$email->setRequest($this->request);
$email->subject($subject);
$email->setTemplate($templateName);
$email->assignMultiple($variables);

Für ein Projekt, das ich übernommen habe, brauchen die Redakteure der Seite Zugriff auf TypoScript. Ich hätte es definitiv anders implementiert (Datensätze, Modul, etc.), mein Vorgänger hatte aber den Weg gewählt. Wenn also ein Benutzer Anpassungen am TypoScript vornehmen wollte, brauche er zwangsweise die Admin-Rechte. Seit TYPO3 10 gibt es noch die Abgrenzung zum System Maintainer, aber sobald ein Benutzer Admin-Rechte besitzt, können Sie nicht weiter eingeschränkt werden. „Mit großer Macht kommt große Verantwortung“ (Onkel Ben aus Spiderman) und ich traue den Redakteure nicht über den Weg mit Admin-Rechten. Also habe ich nach der Möglichkeit gesucht, das Modul und die Tabellen für die Redakteure freizugeben, damit sie wieder normale Redakteure sein können.

In TYPO3 11 hat das folgende gut funktioniert. Wahrscheinlich auch unter TYPO3 10.

1. Zugriffsrechte für Modul anpassen in my_extension/ext_tables.php
$GLOBALS['TBE_MODULES']['_configuration']['web_ts']['access'] = 'user,group';

2. Tabellen für Benutzer freigeben (dann tauchen sie in der Liste der erlaubten Tabellen auf) in my_extension/Configuration/TCA/Overrides/sys_template.php
$GLOBALS['TCA']['sys_template']['ctrl']['adminOnly'] = 0;

3. Benutzergruppe oder Benutzer bearbeiten und dort das Modul „Template“ und die Tabelle „sys_template“ erlauben.

In TYPO3 12 hat sich die Registrierung der Module geändert. Abgesehen davon gibt es nun mehrere Template-Module. Es ist natürlich auch ein Vorteil, denn die Redakteure brauchen sie ja nicht alle.

1. Event-Handler für die Modul-Konfiguration registrieren
Backend Module configuration

2. Event Listener implementieren

namespace Vendor\MyExtension\Backend\EventListener;
 
use TYPO3\CMS\Backend\Module\BeforeModuleCreationEvent;
 
final class ModuleEventListener
{
    public function __invoke(BeforeModuleCreationEvent $event): void
    {
        // Change module icon of page module
        $modules = ['web_ts', 'web_typoscript_recordsoverview', 'web_typoscript_infomodify'];
        if (in_array($event->getIdentifier(), $modules)) {
            $event->setConfigurationValue('access', 'user');
        }
    }
}

Es reicht an dieser Stelle nicht, nur web_ts aufzulisten. Die verfügbaren Module sind die Keys in vendor/typo3/cms-tstemplate/Configuration/Backend/Modules.php

3. Benutzergruppe oder Benutzer bearbeiten und dort die Module „Template“, gewünschte Submodule und die Tabelle „sys_template“ erlauben.