"Früher" ging das ja nur per TypoScript, aber seit einiger Zeit gibt es ja auch die beiden ViewHelper `` und ``. Wie bindet ihr aktuell für die normalen Page-Templates CSS und JS ein? Und wo seht ihr Vor-/Nachteile beider Methoden?

Wie bindet ihr CSS und JavaScript in Page-Templates ein?

Wolfgang Wagner

"Früher" ging das ja nur per TypoScript, aber seit einiger Zeit gibt es ja auch die beiden ViewHelper <f:asset.css> und <f:asset.script>.
Wie bindet ihr aktuell für die normalen Page-Templates CSS und JS ein? Und wo seht ihr Vor-/Nachteile beider Methoden?

M4ND0

Ich würde sagen, beide Methoden haben Vor- und Nachteile.

Nutzt man die TypoScript-Variante und Compression und Concatinierung kommt zum Schluss eine CSS/JS Datei heraus. Das führt aber meist bei GooglePageSpeed dazu, dass zu viel ungenutztes CSS/JS geladen wird und dies führt dann meist zum „Punktabzug“.

Nutzt man die Assets-Variante, hat man im Endeffekt den Vorteil, dass wirklich, wenn man es richtig anstellt, nur das CSS/JS auf der Seite geladen wird, welches auch wirklich notwendig ist. Aber bei dieser Variante habe ich leider noch keine Möglichkeit gefunden, dass zum Schluss nur eine CSS/JS Datei im Quellcode eingebunden wird. Sondern pro Datensatz, wo die CSS/JS Datei in der FLUID HTML Datei eingebunden ist, wird eine CSS/JS Datei eingebunden.

So ist zumindest meine Sicht und Erfahrung der Dinge 😀

Wolfgang Wagner

Ja, so verhält sich das. Wobei die Einbindung von mehreren Dateien ja kein Problem mehr ist seit http/2.

wini2

TypoScript-Einbindung bietet sich sicher für scripte an, die überall benutzt werden, f:asset.script für spezielle Sachen - ist i.d.R. sicher besser zu kontrollieren und effizienter, wenn nicht feststeht, wo sie gebraucht werden (also statt TyposScript setup mit Conditons). Hin und wieder habe ich schon Probleme in Partials gehabt, bei denen das js mit f:asset.script partout nicht ausgegeben wurde. Ich bin mir nicht sicher, ob der Viewhelper nicht nur im Template oder Layout funktioniert - also nicht im Partial. In den 'Spezialfällen', habe ich einfach <script – ohne f:asset. im Partial verwendet, das funktioniert zuverlässig.

Ach ja, wäre toll, wenn es im Core sowas gäbe, was Helmut Hackbarth in seiner (fast) allmächtigen t3sbootstrap-ext hat - da kann man js und css als CE einbinden, d.h. im BE schreiben und auf der jeweiligen Seite ausgeben. Dateien kann man auch einbinden. Super Sache.

Wolfgang Wagner

wini2 Ich kenne die Lösung von Helmut nicht, aber sowas kann unter Umständen ne ganz schöne Sicherheitslücke sein, und sollte niemals normalen Redakteuren ermöglicht werden.

Ansonsten sollten die f:asset VH auch in Partials funktionieren.

Steffen

wini2 Moin, ich bin da auch bei wini2‘s Ansatz. In TS binde ich alles ein was generell gebraucht wird. Was ich partiell benötige dann per Asset Viewhelper.

wini2

Wolfgang Wagner
In t3sbs wird das über eine Partials/Contents/Layout/Assets.html gemacht und sieht ganz einfach aus:

<f:comment><!-- Custom CSS --></f:comment>
<f:if condition="{data.tx_t3sbootstrap_css}">
	<f:asset.css identifier="customCss_{data.uid}">
{data.tx_t3sbootstrap_css -> f:format.raw()}
	</f:asset.css>
</f:if>
<f:comment><!-- Custom JS --></f:comment>
<f:if condition="{data.tx_t3sbootstrap_js}">
	<f:asset.script identifier="customJs_{data.uid}">
{data.tx_t3sbootstrap_js -> f:format.raw()}
	</f:asset.script>
</f:if>

Der Code wird in einer t3sbootstrap-js/css-Datei ausgegeben, die auch von t3sbs selbst genutzt wird (mit uid als identifier). lässt sich also auch gut nachvollziehen.

Der Zugriff auf das CE lässt sich so konifgurieren, wie man es von anderen kennt - also für die BE-Benutzergruppe Redaktion-Praktikaten unbedingt voller Zugriff ;-)

Andreas Hirsch

Spannendes Thema. 🙂 Ich arbeite sehr gerne mit dem Bootstrap-Package und dem darin enthaltenen SCSS Compiler. Das verträgt sich allerdings überhaupt nicht mit dem Asset-ViewHelper und natürlich auch nicht mit den Content Blocks (wo das CSS auch über VH eingebunden wird).
Da bin ich auch noch auf der Suche nach einem Konzept, das auf der einen Seite eine zentrale Konfiguration von grundlegenden Dingen, wie Farben, Typographie etc. in den SiteSettings ermöglicht und auf der anderen Seite möglichst modular ist und möglichst nur das nötige CSS für die jeweilige Seite ausliefert.

Markus Hofmann

Ich versuche mittlerweile, nur noch per asset ViewHelper einzubinden, weil ich damit auch preloads klarer definieren kann. Da wir CSS und JS in der Pipeline bauen, können wir das Thema Kompression dort auch direkt machen, was den Vorteil hat, dass die gzipped Files schon direkt mit geliefert werden und TYPO3 das nicht machen muss.
Einziges Issue dabei: Die GET-Parameter Versionierung fehlt und das Ausspielen von aktualisiertem CSS/JS bei gleichzeitigem Caching von 1 Monat/ 1 Jahr ist bisher ungelöst.

Unterstütze das Forum

Hilf mit, den Community Hub für TYPO3 werbefrei zu halten und die Betriebskosten zu decken. Werde Official Community Hub Supporter für nur 5 Euro im Monat (zzgl. USt) und erhalte ein exklusives Supporter-Badge. Jeder Beitrag zählt!

Jetzt Supporter werden

Impressum - Datenschutz - Kontakt - Netiquette - RSS