fluidcontent_elements

Fluid Inhalt: Kernelemente

Ein Ersatz für EXT:css_styled_content 100% powered by Fluid und Flux Forms.

Was bewirkt es?

Genau wie EXT:css_styled_content fügt diese Erweiterung Rendering-Anweisungen für Datensätze aus tt_content hinzu. Aber anstatt TypoScript zur Manipulation des Renderings zu verwenden, wird jedem Inhaltselementtyp eine Fluid-Vorlage zugewiesen und vollständig in Fluid gerendert.

Wie installiere ich es?

1. Deaktivieren Sie die Erweiterung "CSS-gestylter Inhalt" (css_styled_content). Du kannst css_styled_content und fluidcontent_elements nicht gleichzeitig verwenden!
2. Laden Sie die Erweiterung herunter und installieren Sie sie.
3. Kopieren oder integrieren Sie die Datei AdditionalConfiguration.php aus EXT:fluidcontent_elements/Build/AdditionalConfiguration.php in typo3conf/AdditionalConfiguration.php - oder verwenden Sie das Extension Manager Upgrade-Skript für fluidcontent_elements, das dies für Sie erledigt.
4. Laden Sie die statische TypoScript-Vorlage, um die Konfigurationsoptionen hinzuzufügen, die die CSS-Klassennamen definieren, die Sie für Container-HTML-Elemente festlegen können, die Standard-H-Größe und mehr.

Warum es verwenden?

Flexibler geht es nicht, wenn es um individuell gestaltete TYPO3 CMS-Seiten geht. Sie können beliebig viele eingebaute Inhaltselemente durch eigene Fluid-Vorlagen ersetzen. Sie können einstellen, welche Vorlagen auf einzelnen Unterseiten verwendet werden (mit TypoScript können Sie View-Pfade überschreiben). Sie können Vorlagenpfad-Overlays verwenden, wie Sie es von EXT:view kennen. Anstatt entweder ein FlexForm oder TCA/DB-Spalten hinzuzufügen, können Sie einfach eine Flux-Formulardefinition in die Vorlagendatei einfügen und beliebig viele Felder hinzufügen, die Sie zur Steuerung des Renderings verwenden möchten.

Sie können sogar eine beliebige Anzahl dieser eingebauten Inhaltselementtypen in eine Flux Provider-Erweiterung werfen und (statisches) TypoScript-Setup hinzufügen, damit diese Erweiterung zuerst Ihre Vorlagenpfade verwendet, mit Rückgriff auf die enthaltenen Vorlagen.

Ist es schneller als css_styled_content?

Ziemlich viel, ja. Erste Messungen ergaben eine Geschwindigkeitssteigerung von 400% für zwischengespeicherte Seiten, nur weil es etwa 10% des zu ladenden TypoScript gibt (wohlgemerkt, TypoScript wird tatsächlich auch auf zwischengespeicherte Seiten geladen und macht oft mehr als 50% der gesamten Frontend-Ladezeiten von zwischengespeicherten Seiten aus). Also ja, es ist auf zwischengespeicherten Seiten viel schneller. Aber es kann etwas langsamer sein, wenn Sie den gecachten Inhalt erzeugen und wenn Sie das Caching absichtlich deaktivieren. Man gewinnt einiges, man verliert einiges.

Beispiele

Eingebaute Vorlagendateien befinden sich unter Ressourcen/Private/Vorlagen/CoreContent - sie alle teilen sich eine Layoutdatei und verwenden eine Teilvorlage, um einen gemeinsamen Header zu rendern (entspricht lib.stdheader in EXT:css_styled_content). Die einzelnen Plugins werden in ext_localconf.php konfiguriert (ein Plugin pro Content-Typ, das jedem möglichen CType-Wert entspricht) und ein kleines bisschen TypoScript wird verwendet, um ein sehr einfaches tt_content.*-Array zu erstellen, das benötigt wird, um etwas zu rendern. Dies ist zusammen mit den bereits bekannten Template-Pfaddefinitionen - und allen benutzerdefinierten Einstellungen, die Sie hinzufügen und damit in Templates zur Verfügung stellen - das einzige TypoScript, das von dieser Erweiterung benötigt wird. Die Ansichtsdefinitionen sind genau so, wie Sie es von jedem Extbase Plugin kennen.

Im Wesentlichen handelt es sich um ein Extbase Plugin, das das TypoScript-basierte Rendering von EXT:css_styled_content ersetzt und Flux nutzt, um es extrem einfach zu machen, genau die richtigen Felder zu konfigurieren, die Sie verwenden möchten, um das Aussehen Ihrer Inhalte zu konfigurieren.

Dies ist sehr wahrscheinlich eine der einfachsten Erweiterungen, die Sie je benutzt haben, und alles basiert auf Konventionen von Flux, Extbase und Fluid, um Ihnen ein Höchstmaß an Flexibilität zu bieten.

Es gibt drei Hauptwege, um eigene Inhaltselementvorlagen zu erstellen, die die zentralen Inhaltselementvorlagen ersetzen. Jeder hat einen ganz spezifischen Anwendungsfall - Ihre Verantwortung als Extension-Entwickler bzw. Integrator besteht darin, den richtigen auszuwählen, damit sich Ihre Vorlagensammlung perfekt integrieren lässt.

Konzept

Gestaltende FluidcontentElements ermöglicht in der Reihenfolge der Einfachheit drei Ebenen der Inhaltsnutzung:

1. Ersetzen eines oder mehrerer Inhaltselementtypen durch benutzerdefinierte Fluid-Vorlagen.
2. Bereitstellung weiterer Variationen jedes Inhaltselementtyps, z.B. "Textelemente" aus mehreren Erweiterungen, z.B. Anpassung an verschiedene CSS-Frameworks, die standardmäßig verwendet werden können.
3. Wenn Sie zusätzliche Versionen jeder Variation des Typs Inhaltselement anbieten, z.B. wenn ein Twitter Bootstrap Textelement ausgewählt wird, können Sie eine Version bereitstellen, die <p class="lead"></p> verwendet und die Textwarnung usw. unterstützt. CSS-Klassen.

Der erste Ansatz ist der, den Sie aus jedem Fluid-Kontext in TYPO3 kennen.

Der zweite Ansatz lässt sich anhand der Tatsache erklären, dass die Erweiterung fluidbootstraptheme nur zusätzliche Inhaltselemente zu den bereits integrierten Inhaltselementen von TYPO3 hinzufügt. Dies ermöglicht es, auch neue Variationen von Kerninhaltselementen hinzuzufügen, ohne die Standardelemente zu ersetzen.

Der dritte Ansatz kann als eine Möglichkeit angesehen werden, jede hinzugefügte Variante zu versionieren: z.B. das Kopieren vorhandener Elemente in eine Legacy-Vorlage, wenn Sie Änderungen vornehmen, das Ausprobieren neuer Versionen Ihres Inhalts, ohne die aktuellen zu ersetzen, oder einfach das Unterteilen einer Variante eines Inhaltselements in mehrere spezialisierte "Rendering-Versionen" wie im obigen Beispiel der Twitter Bootstrap-Erweiterung.

Eine detailliertere Beschreibung folgt in diesen Kapiteln.

Konzept: Überlagerung und Überlagerung

Anwendungsfall: zwingende Überschreibung bestehender Vorlagen, um immer eigene Vorlagen zu verwenden

Dies ist die replace-them-all oder replace-a-couple Strategie, die inzwischen sehr bekannt ist - es genügt zu schreiben, dass Sie einen alternativen templateRootPath etc. für Gestaltende FluidcontentElements konfigurieren können, und dass dann jede Template-Datei in diesem anderen Pfad existieren muss. Oder, weniger bekannt, aber Ihnen hoffentlich vertraut, der "Overlay"-Ansatz, der z.B. von EXT:view und EXT:fluidpages implementiert wurde, mit dem Sie eine (oder beliebig viele) Vorlagendateien ersetzen können, anstatt sie alle ersetzen zu müssen.

Sie können dieses Konzept verwenden, um ein völlig neues "Paket" von Kerninhalten zu erstellen, das mit Ihren benutzerdefinierten Vorlagen gerendert wird. Sie können "Overlays" verwenden, wenn Sie nicht alle Vorlagendateien kopieren möchten.

Konzept: Varianten

Anwendungsfall: Die Erweiterung xyz möchte einen alternativen "Text" oder eine andere Art von Kerninhaltselement einbinden, das Editoren verwenden können, zusätzlich zu den Kernelementen, die in den in TypoScript konfigurierten Standard- oder überschriebenen Vorlagenpfaden vorhanden sind.

Beachten Sie das Teil "zusätzlich zum Teil" sorgfältig. Aus diesem Grund wird dieses Konzept als "Varianten" und nicht als "Ersatz" bezeichnet. Verwenden Sie dieses Konzept, wenn Sie nicht bestehende Vorlagen ersetzen wollen, sondern alternative (Varianten-)Vorlagen zur Verfügung stellen, die ebenfalls verwendet werden können. Mit dem Überschreiben des Vorlagenpfades oder Überlagerungen erhalten Sie als Ergebnis eine "Variante" (diejenige, die Sie überschreiben oder überlagern). Mit diesem Konzept erhalten Sie zwei "Varianten" - die grundlegende (potenziell überlagerte oder überlagerte) und Ihre zusätzliche.

Das Variantenkonzept bedeutet einfach, dass Sie eine beliebige Anzahl von Varianten jedes Inhaltstyps hinzufügen können, die jeweils durch eine Erweiterung bereitgestellt werden. Um Gestaltende FluidcontentElements über Ihre Varianten zu informieren, fügen Sie diesen Code hinzu:

// ext_tables.php
$GLOBALS['TYPO3_CONF_VARS']['Gestaltende.FluidcontentElements']['variants']['text']['text'][] ='myextensionkey';
$GLOBALS['TYPO3_CONF_VARS']['Gestaltende.FluidcontentElements']['variants']['image']['image'][] ='myextensionkey';

Oder wenn Ihre Erweiterung Namensräume verwendet und einen Herstellernamen enthält:

// ext_tables.php
$GLOBALS['TYPO3_CONF_VARS']['Gestaltende.FluidcontentElements']['variants']['text']['text'][] ='VendorName.ExtensionName';
$GLOBALS['TYPO3_CONF_VARS']['Gestaltende.FluidcontentElements']['variants']['image']['image'][] ='VendorName.ExtensionName';

Wenn sie angezeigt wird, sucht die Variantenauswahlbox standardmäßig nach einem LLL-Label in:

EXT:myextensionkey/Ressourcen/Private/Language/locallang.xlf:fluidcontent_elements.variantLabel

Sie können auch manuell ein Label und ein optionales Symbol für Ihre Variante auswählen, indem Sie eine leicht erweiterte Registrierung verwenden:

$GLOBALS['TYPO3_CONF_VARS']['Gestaltende.FluidcontentElements']['variants']['text']['text'][] = array(

    myextensionkey',
    // Das erste Array-Element muss der Erweiterungsschlüssel sein, je nach Bedarf mit oder ohne Anbieter

    LLL:EXT:myextensionkey/Resources/Private/Language/locallang.xlf:my_custom_label',
    // eine vollständige LLL-Datei- und -Label-Referenz, die auf das gewünschte Label zeigt

    ErweiterungManagementUtility::extRelPath('myextensionkey') . icon.png'
    // oder ein anderer Dateiname, oder ein Pfad (NB: siteroot-relative!) - oder NULL für kein Symbol.
);

Erstellen Sie dann die Vorlagendateien:

<!-- EXT:myextensionkey/Resource/Private/Templates/CoreContent/Text.html -->
Der Text: {record.bodytext}

<!-- EXT:myextensionkey/Resource/Private/Templates/CoreContent/Image.html -->
Meine eigenen Bilder:
<!-- einige benutzerdefinierte Renderings von Bildern -->

Damit wären insgesamt zwei Varianten der Inhaltselemente Text und Bild CType möglich: Die immer vorhandene, erste Option "Standard", die "nein danke, nur der Standardtyp in dem von der TS konfigurierten Template-Pfad, bitte" bedeutet, und Ihre neu hinzugefügte Variante - die durch den Erweiterungsschlüssel identifiziert wird, zu dem sie gehört.

Die Auswahl einer Variante bei der Bearbeitung von Text- oder Bildelementen führt dazu, dass Gestaltende FluidcontentElements die Variantenvorlage aus Ihrer Erweiterung anstelle derjenigen rendern, die an der in TypoScript konfigurierten Standard-Templatzierung vorhanden ist.

Hinweis: Wenn Sie in diesem Beispiel das TypoScript ändern, das templateRootPath etc. für myextensionkey setzt, wird Gestaltende FluidcontentElements an dieser anderen Stelle nach den zu Ihrer Variante gehörenden Vorlagendateien suchen!

Sie können weder benutzerdefinierte Vorlagendateinamen für Ihre Varianten noch einen benutzerdefinierten Speicherort auswählen - sie müssen sich im CoreContent Vorlagenordner befinden und müssen in UpperCamelCase entsprechend dem von ihnen abgedeckten CT-Typ benannt sein: Text.html, Image.html, Uploads.html etc.

Hinweis: Die Vorlagendateien müssen vorhanden sein, sonst wird Ihre Variante ignoriert!

Konzept: Versionen

Anwendungsfall: Sie haben bereits eine "Variante" eines Elements, aber Sie sollten nun mehr "Versionen" des Elements bereitstellen, mit einem von zwei Zwecken: 1) die es ermöglicht, neue Elementdesigns in einem einzigen Inhaltselement zu testen und/oder 2) logische Versionen Ihrer "Variante" zu erstellen, die nur ausgewählt werden können, wenn Ihr "Variantentyp" ausgewählt ist.

Da dieses Konzept nur für Sie gilt, wenn Sie Varianten verwenden, müssen Sie zunächst eine Variante für jede Art von Element registrieren, die Sie benötigen:

// ext_tables.php
$GLOBALS['TYPO3_CONF_VARS']['Gestaltende.FluidcontentElements']['variants']['text']['text'][] ='myextensionkey';

Oder wenn Ihre Erweiterung Namensräume verwendet und einen Herstellernamen enthält:

// ext_tables.php
$GLOBALS['TYPO3_CONF_VARS']['Gestaltende.FluidcontentElements']['variants']['text']['text'][] ='VendorName.ExtensionName';

<!-- EXT:myextensionkey/Resource/Private/Templates/CoreContent/Text.html -->
Die Basisversion: {record.bodytext}

Dann, um weitere Versionen des Inhaltselements "text" bereitzustellen:

<!-- EXT:myextensionkey/Resource/Private/Templates/CoreContent/Text/Truncated.html -->
Die gekürzte Version: {record.bodytext -> f:format.crop(maxCharacters: 100)}}

<!-- EXT:myextensionkey/Resource/Private/Templates/CoreContent/Text/Raw.html -->
Die Rohfassung: {record.bodytext -> f:format.raw()}}

Und so weiter. Das sind natürlich sehr einfache Beispiele - es geht nicht darum, jeden möglichen Anwendungsfall zu dokumentieren, sondern Sie zu inspirieren, diese Konzepte zur Erreichung Ihres spezifischen Ziels einzusetzen. Denken Sie daran: Sie können sogar Flux-Formularfelder in Teilvorlagen einfügen und diese einfach aus allen Versionen rendern, damit Versionen ein oder mehrere Flux-Formularfelder gemeinsam nutzen können. Dasselbe ist mit Flux-Formularen etc. möglich.

Hinweis: Obwohl das gleiche Verhalten wie bei "Versionen" in den meisten Fällen auch durch Flux-Formulareinstellungen wie einen Selektor erreicht werden kann, der zwischen dem Rendern von beschnittenen, rohen, html-formatierten usw. Texten und der Verwendung von Bedingungen in der Vorlage selbst wechselt, können Sie mit "Versionen" jedoch viel an Templatekomplexität sparen und Legacy-Elemente einbeziehen, die nur dann berührt werden, wenn diese bestimmte Version ausgewählt wird. Ähnlich wie die verschiedenen Versionen des statischen TypoScript css_styled_content verwendet, um eine einfache Kompatibilität zu gewährleisten.

Eingebaute Inhaltselementtypen

• Header.html
• Text.html
• Bild.html
• Bullets.html
• Uploads.html
• Tabelle.html
• Media.html
• Menü.html
• Shortcut.html
• Div.html
• Html.html (yep, html-dot-html, so....)
• Standard.html

Besonderer Hinweis zum Inhaltstyp Textpic (Text mit Bildern)

Wie Sie vielleicht schon bemerkt haben, gibt es für den TYPO3-Kerninhaltstyp Textpic (Text mit Bildern) kein Template. Der Grund dafür ist so einfach wie überzeugend: Dieser spezielle Content-Element-Typ erfordert eine übermäßige Anzahl von Einstellungen und Rendering-Anweisungen, um nur die häufigsten Anwendungsfälle zu bedienen. Dies zeigt sich auch im TypoScript-Setup, das mit CSS Style Content ausgeliefert wird - das Setup, das zur Verwaltung der Positionierung und des Flusses von Bildern und Texten benötigt wird, ist so umfangreich, dass man auf den meisten Seiten nur einen Bruchteil der Einstellungen verwendet.

Daher wurde beschlossen, einfach keine Vorlage für diesen Content-Typ zu liefern, um die unvermeidliche Explosion der Komplexität, die sich bei CSS Style Content ereignete, zu vermeiden.

Unsere alternative Empfehlung ist es, Containerelemente zu erstellen, die die Struktur steuern, in die Sie dann reguläre Text- und Bildelemente einfügen. Das Ergebnis sind mehr Elemente, aber eine viel klarere Trennung der Typen (was z.B. im Rahmen der Standortsuche mit Facetten des Inhaltstyps nützlich ist). Sie können natürlich auch einen Schritt weiter gehen und Ihre eigenen benutzerdefinierten Elemente erstellen, die Ihre eigenen benutzerdefinierten Felder verwenden, um den Text und die Bilder zu definieren, die Sie vollständig benutzerdefiniert darstellen.

Pläne für zukünftige Verbesserungen

1. Fertigstellung des Basissatzes der enthaltenen Vorlagen, um ein Rendering in Fallback-Qualität zu erstellen
2. Einführung einer Asset-Konfigurationsintegration (möglicherweise Nutzung von LESS/SASS, um Flux-Formularwerte für die Verwendung in kompiliertem CSS zu erfassen)
3. Versuche, die Welt zu erobern. Wie jeden zweiten Abend, Pinky.