Zum Inhalt springen

Ich empfehle euch natürlich, die gut geschriebenen What's New Slides zu den einzelnen TYPO3 v10 Sprint Releases zu lesen. Weitere Details zu einer Änderung findet ihr dann im Changelog (und bald in der TYPO3-Dokumentation).

Das neue Dashboard

Wer von euch die Entwicklung um TYPO3 etwas verfolgt, wird bereits mitbekommen haben, dass mit Version 10 ein neues Backend-Modul eingeführt wird: Im Dashboard können wichtige Eckdaten zur TYPO3-Installation angezeigt werden. Für jeden Benutzer können mehrere Dashboards mit jeweils individuellen Widgets angelegt werden.

Es gibt einige Standard-Widgets im TYPO3-Kern, aber jede Extension kann eigene Widgets mitbringen.

Der Anfang also ist gemacht. Die Zahl der Widgets muss aber noch ausgebaut werden, damit ein echter Mehrwert entsteht. Potenzial hat das Dashboard auf alle Fälle.

Ein Beispiel für ein hilfreiches Widget wäre etwa eine Übersicht von Seiten, deren Inhalte schon länger nicht mehr bearbeitet wurden. Ein Redakteur könnte seine Seiten damit die Aktualität seiner Inhalte besser im Blick behalten.

In den nächsten Monaten werden viele neugierige Entwickler eigene Widgets im TER veröffentlichen. Hoffen wir, dass es nicht nur Wetter-Widgets sein werden. :)

Das TYPO3 Form Framework

In EXT:form hat sich wieder viel getan. Ich greife hier nur ein paar Details heraus – bitte beachtet vor allem die als Breaking markierten Änderungen im TYPO3 Changelog!

Darunter fällt z.B. die umbenannte Option translationFile. Sie schreibt sich zukünftig translationFiles (Mehrzahl). Grund dafür: bislang musste man bei der Option selbst auf die Array-Schreibweise im YAML wechseln, um eigene XLF-Dateien verwenden zu können. Nun ist diese schon voreingestellt und die mitgelieferten Sprachdateien besitzen den Array-Index 10.

Meine Extensions form_examples und form_distribution habe ich entsprechend aktualisiert. Für jede TYPO3-Version gibt es einen passenden Entwicklungs­zweig auf GitHub (u.a. verlinkt in der README-Datei).

Mehrere E-Mail-Empfänger einrichten

Eine Funktion, die schon oft von Integratoren angefragt wurde: ab sofort können mehrere Empfänger in den beiden E-Mail Finishern hinterlegt werden.

Bei bestehenden Form-Definitionen wird dadurch eine Migration notwendig. Diese Migration kann automatisch erfolgen, wenn ihr das Formular im Backend-Modul einmal öffnet und speichert. Im Changelog sind Beispiele der neuen Schreibweise zu finden.

Übersicht der aktuellen YAML Konfiguration

Während es zur Prüfung der angewendeten TypoScript-Konfiguration den TypoScript Object Browser gibt, stand für YAML-Konfigurationen nichts Vergleichbares zur Verfügung.

In TYPO3 v10 findet ihr unter SYSTEM>Konfiguration jetzt das Untermodul "Form: YAML Configuration". Hier könnt ihr prüfen, ob eure Formular-Konfiguration korrekt geladen und verwendet wird.

Ausgabe einzelner Formularwerte in Templates

Bislang war es in Formular-Templates nicht möglich, einzelne Werte direkt auszugeben. Man musste – sehr umständlich – alle Werte ausgeben und dann einzelne Identifier in Conditions abfangen. Das sah in der SummaryPage.html in etwa so aus:

<!-- bisherige Ausgabe einzelner Formular-Werte -->
<table class="table">
    <formvh:renderAllFormValues renderable="{page.rootForm}" as="formValue">
        <tr>
            <f:if condition="{formValue.value}">
                <f:then>
                    <f:if condition="{0: formValue.element.identifier} == {0: 'name'}">
                        <td>{formvh:translateElementProperty(element: formValue.element, property: 'label')}</td>
                        <td>{formValue.processedValue}</td>
                    </f:if>
                    <f:if condition="{0: formValue.element.identifier} == {0: 'subject'}">
                        <td>{formvh:translateElementProperty(element: formValue.element, property: 'label')}</td>
                        <td>{formValue.processedValue}</td>
                    </f:if>
                    <f:if condition="{0: formValue.element.identifier} == {0: 'email'}">
                        <td>{formvh:translateElementProperty(element: formValue.element, property: 'label')}</td>
                        <td>{formValue.processedValue}</td>
                    </f:if>
                    <f:if condition="{0: formValue.element.identifier} == {0: 'message'}">
                        <td>{formvh:translateElementProperty(element: formValue.element, property: 'label')}</td>
                        <td>{formValue.processedValue}</td>
                    </f:if>
                </f:then>
                <f:else>
                    -
                </f:else>
            </f:if>
        </tr>
    </formvh:renderAllFormValues>
</table>

In TYPO3 v10 wurde der neue Viewhelper <formvh:renderFormValue> für einzelne Werte ergänzt. Ein Beispiel aus dem Changelog-Eintrag:

<p>The following message was just sent by <b><formvh:renderFormValue renderable="{page.rootForm.elements.name}" as="formValue">{formValue.processedValue}</formvh:renderFormValue><b>:</p>

<blockquote>
   <formvh:renderFormValue renderable="{page.rootForm.elements.message}" as="formValue">
      {formValue.processedValue}
   </formvh:renderFormValue>
</blockquote>

Außerdem lassen sich die im Template verfügbaren Formular-Elemente zum Debugging nun als Array ausgeben:

<f:debug>{page.rootForm.elements}</f:debug>

Restrukturierung des YAML-Setups

Als das neue Form Framework eingeführt wurde, ging es wahrscheinlich nicht nur mir so: die YAML-Konfiguration war gewöhnungsbedürftig. Form-Definition, Form-Konfiguration, Form Manager, Form Editor – die ganzen Begrifflichkeiten mussten erst erlernt werden. Und die drei YAML-Dateien in EXT:form (BaseSetup.yaml, FormEditorSetup.yaml und FormEngineSetup.yaml) fand ich immer recht unübersichtlich. Inheritances und Mixins waren der Lesbarkeit nicht gerade förderlich.

In der neuen TYPO3-Version wurde die YAML-Konfiguration von EXT:form vollständig überarbeitet:

Die neue Struktur erscheint mir auf den ersten Blick wesentlich einfacher. Ich bin gespannt, wie sich das auf die tägliche Arbeit mit dem Form Framework auswirken wird.

Die Seitenverwaltung

Die mit TYPO3 v9 implementierte Seitenverwaltung wurde erweitert. Unter anderem wird nun für jede Seite mit der Eigenschaft is_siteroot automatisch eine config.yamlmit einer Standard-Konfiguration erstellt.

Der Website-Titel (sitetitle), der bislang im TypoScript-Template gepflegt werden konnte, kann nun ebenfalls in der Seitenkonfiguration gesetzt werden. Dies ist auch für jede Frontend-Sprache individuell möglich!

Verbesserungen beim Routing (sprechende URLs)

Wenn ihr URL-Segmente in Seiten nachträglich ändert, wurde das in TYPO3 v9 nicht auf Unterseiten angewendet – diese behielten den alten Pfad. Das sollte verhindern, dass plötzlich viele Seiten nicht mehr unter der zuvor bekannten URL aufrufbar sind.

In TYPO3 v10 wurde das Verhalten verbessert: jetzt ändern sich auch die URL-Segmente aller Unterseiten automatisch. Dabei werden auch direkt Weiterleitungen im Redirects-Modul angelegt, so dass die Seite für Besucher erreichbar bleibt. Der Redakteur wird bei der Änderung eines URL-Segments über diese automatischen Anpassungen informiert und kann diese bei Bedarf wieder rückgängig machen.

Das neue Verhalten könnt ihr in der Site Configuration individuell konfigurieren (Beispiel im Changelog).

Das Frontend-Login Plugin (felogin)

Die Core-Extension für den Frontend-Anmeldung war – bis einschließlich TYPO3 v9 – noch mit der alten PiBase-Bibliothek umgesetzt. Dementsprechend verwendete das Frontend-Template leider noch das alte, Marker-basierte Templating.

Mit TYPO3 v10 ist EXT:felogin nun endlich mit Extbase umgesetzt. Bestehende TYPO3-Installationen können vorerst die alte PiBase-Version weiterlaufen lassen, da dieses Plugin weiter in der Extension enthalten ist. Bei Neuinstallationen ist der neue Feature Toggle für die Extbase-Version aktiviert.

Ich betreue mehrere Websites mit Frontend-Login und freue mich ehrlich darauf, bald Login-Templates mit Fluid bauen zu können.

Der neue AssetCollector

Ein neues, sehr interessantes Konzept wurde in TYPO3 v10 ergänzt: der AssetCollector. Er erlaubt es euch, JavaScript und CSS in Fluid-Templates (oder in PHP) zu ergänzen. Das kann etwa hilfreich sein, wenn ihr für bestimmte Inhaltselemente zusätzlichen Code benötigt, den ihr nicht auf allen Unterseiten einbinden wollt.

Der AssetCollector sorgt beim Rendering der Seite dafür, dass identische Assets nur einmal ausgegeben werden. Zu diesem Zweck setzt ihr ein identifier Attribut im Viewhelper.

Der Code kann sowohl inline als auch als externe Datei eingebunden werden:

<f:asset.css identifier="specialElement" href="EXT:sitepackage/Resources/Public/Css/special-element.css" />

<f:asset.css identifier="specialWrapper">
   .wrapper--modifier { max-width: 1200px; }
</f:asset.css>

<f:asset.script identifier="specialElement" src="EXT:sitepackage/Resources/Public/JavaScript/special-element.js" />

<f:asset.script identifier="annoyingAlert">
   alert('Hello!!!11');
</f:asset.script>

Zudem könnt ihr steuern, an welcher Stelle das Asset ausgegeben werden soll: setzt ihr das optionale Attribut priority, wird das Asset im <head> gesetzt. Andernfalls wird es im <body> ergänzt.

Kleine Verbesserungen

  • Im Extension Manager gibt es jetzt wieder einen direkten Link zur jeweiligen Dokumentation.
  • Im Kontextmenü des Seitenbaums kann man nun auch "In Menüs verbergen" umschalten (zu finden unter "Weitere Optionen…").
  • Die TypoScript-Condition PIDupinRootline war bislang nicht für die Symfony Expression Language vorhanden. Dies hat sich in v10 nun geändert (Beispiel im Changelog).
  • TYPO3 unterstützt nun das native Lazy Loading von Bildern in Webbrowsern. In fluid_styled_content wird es voreingestellt verwendet. Über TypoScript kann der gewünschte Wert des neuen Bild-Attributs konfiguriert werden.
Zur News-Übersicht