Snippet Deployment & Betrieb
Wenn typo3temp geleert wird
typo3temp/ ist ein Cache-Verzeichnis. Der TYPO3-Core erklärt es ausdrücklich für wegwerfbar — und manche Hoster leeren es bei jedem automatischen Update. t3sbootstrap holt einen Teil der Dateien von allein zurück, den anderen nicht.
Wen das betrifft: nicht jede Installation. Bleibt typo3temp/ bei Updates erhalten, ist hier nichts einzurichten. Spielt dein Hoster Updates dagegen automatisch ein, entscheidet er auch darüber, ob der Ordner das überlebt — und ein leerer Ordner ist dort kein Fehler, sondern erlaubtes Verhalten, also auch kein Grund zu reklamieren.
Was von selbst zurückkommt und was nicht
Unter typo3temp/assets/t3sbootstrap/ liegen zwei verschiedene Arten von Dateien: Ableitungen aus der Datenbank und Downloads aus dem Netz. Nur die erste Gruppe kann sich selbst wiederherstellen.
| Verzeichnis | Inhalt | Kommt von selbst zurück? |
|---|---|---|
TypoScript/ | t3sbconstants, t3sbsetup | Ja beim nächsten Frontend-Aufruf, aus dem Konfigurations-Datensatz |
T3SB-SCSS/ | custom-variables-<uid>.scss, custom-<uid>.scss | Ja sofern in der Konfiguration gefüllt |
css/ | kompiliertes CSS | Ja folgt aus dem SCSS |
T3SB-CSS/, T3SB-JS/ | heruntergeladenes CSS und JS, lokale Google Fonts | Nein Download |
T3SB-Bootstrap/ | Bootstrap-Quellen aus dem Release-Zip | Nein Download |
Der Grund für die Trennung: ein Frontend-Aufruf darf nicht auf einen Download warten. Die Middleware, die die fehlenden Dateien nachschreibt, läuft bei jedem Request — sie liest dafür einen Datensatz aus der Datenbank, greift aber bewusst nicht ins Netz.
Muss der Task wiederkehrend laufen?
In den meisten Installationen nicht. In der Anleitung zur Erstinstallation steht, der Task sei einmalig auszuführen — und dabei bleibt es, solange typo3temp/ erhalten bleibt. Nur wenn der Ordner verschwindet, muss etwas nachkommen, und auch dann hängt es davon ab, wer das Update auslöst:
| Situation | Was nötig ist |
|---|---|
der Normalfall | Nichts. Ein Lauf bei der Einrichtung genügt — kein Scheduler-Task, kein Deployment-Schritt. |
Eigenes Deployment das | Die Befehle hinter das Update hängen, zusammen mit dem Cache-Leeren. Auch hier kein wiederkehrender Task — du kennst den Zeitpunkt ja. |
Automatische Updates beim Hoster nur dieser Fall | Hier wird der wiederkehrende Scheduler-Task nötig: T3SB CDN to local als wiederkehrende Aufgabe im Planer. Weil der Zeitpunkt des Updates nicht bekannt ist, gibt es keine Stelle, an die sich der Befehl sonst hängen ließe. |
Die Befehle:
vendor/bin/typo3 t3sbootstrap:cdnToLocal
vendor/bin/typo3 t3sbootstrap:customScss <Rootseiten-ID>Bis 5.3.57 lädt der Task bei jedem Lauf neu herunter, er prüft nicht, ob die Dateien schon vorhanden sind — einmal täglich ist deshalb unkritisch, stündlich wäre unnötiger Netzverkehr. Ab 5.3.58 gibt es dafür --if-needed, siehe den nächsten Abschnitt. Voraussetzung ist in allen Fällen, dass der Webserver ausgehende HTTPS-Verbindungen aufbauen darf — nicht der Browser des Redakteurs. Erreichbar sein müssen github.com (Bootstrap-Quellen), cdn.jsdelivr.net, cdnjs.cloudflare.com, unpkg.com, code.jquery.com, bootswatch.com und, bei lokal gehosteten Google Fonts, gwfh.mranftl.com. Details zu den erzeugten Dateien und zur Sicherung: Eigenes SCSS sichern und übertragen.
Mit oder ohne --if-needed?
ab 5.3.58 Beide Kommandos nehmen die Option --if-needed. Sie steigen damit sofort wieder aus, wenn alle Dateien vorhanden sind und sich an der Konfiguration nichts geändert hat. Wann du sie setzt, ist eine Regel, und die reicht:
Der Befehl steht in einem Zeitplan Planer-Aufgabe oder Cronjob | mit--if-needed |
Du tippst ihn selbst weil etwas nicht stimmt | ohne |
Der Grund ist in beide Richtungen derselbe: ein Zeitplan läuft blind und oft — der braucht die Bremse. Von Hand tippst du den Befehl, weil etwas fehlt — dann soll er auch laden und nicht mit „Nothing to do“ aussteigen. Für cdnToLocal ist mit der Option ein Takt von 15 Minuten unkritisch.
In der Planer-Aufgabe Konsolenbefehl ausführen ist das ein Ankreuzfeld, keine Eingabe — TYPO3 liest die Optionen aus dem Kommando und zeigt sie als Felder an. Im Cronjob hängt sie hinten an:
*/15 * * * * cd /pfad/zum/projekt && vendor/bin/typo3 t3sbootstrap:cdnToLocal --if-neededEinmal im Monat ohne die Option. Angaben wie swiper: 12 oder jarallax: 2 sind gleitend — das CDN löst sie beim Abruf auf die neueste 12.x beziehungsweise 2.x auf. Für --if-needed sieht die Einstellung „12“ dabei immer unverändert aus, neue Unterversionen kommen also nur bei einem bedingungslosen Lauf an.
Die ruhigere Variante: beim CDN bleiben
Lokale Auslieferung ist in einer Umgebung, die typo3temp/ regelmäßig leert, der aufwendigere Weg. Bleibt Enable CDN in den Site Settings aktiv, werden Bootstrap, jQuery & Co. direkt vom CDN geladen — dann gibt es nichts, was verloren gehen könnte, und der Task entfällt vollständig.
| Lokal | CDN | |
|---|---|---|
| Nach dem Leeren von typo3temp | Task nötig | nichts zu tun |
| Datenschutz | keine Drittanbieter-Verbindung | Verbindung zum CDN beim Seitenaufruf |
| Ausgehendes HTTPS am Server | nötig (für den Task) | nicht nötig |
Die Entscheidung hängt also nicht an der Technik, sondern am Datenschutz: wer keine Verbindung zu einem Drittanbieter-CDN möchte, braucht die lokalen Dateien — und muss sie dort, wo der Hoster automatisch aktualisiert, wiederkehrend holen lassen.
Woran du es merkst
Fehlen die lokalen Dateien, verwirft TYPO3 die Einträge aus includeCSS und includeJS ohne Fehlermeldung und schreibt das Ergebnis in den Page-Cache. Die Seite wird also ausgeliefert, nur unformatiert — kein Fehler im Log, kein Hinweis im Frontend.
Das Backend-Modul T3SB Config weist darauf hin, wenn lokale Auslieferung konfiguriert ist und die Dateien fehlen. Dieser Hinweis ist nach einem automatischen Update die erste Stelle, an der man nachsieht.
Voraussetzungen
Alles auf dieser Seite gilt ab Version 5.3.50. Erst dort sind die erzeugten Dateien nach typo3temp/ gezogen, und erst dort gibt es das automatische Nachschreiben von TypoScript und SCSS.
Bis einschließlich 5.3.48 lagen sie in EXT:t3sb_package/Resources/Public/. Ein geleertes typo3temp/ konnte ihnen dort nichts anhaben — dafür traf sie jedes composer update, das dieses Paket ersetzt. Zurück kamen sie damals nur durch Speichern des Konfigurations-Datensatzes oder durch die Kommandos, von selbst gar nichts.
Wer also beschreibt, dass „auf einmal alles weg“ ist, sollte zuerst die Version prüfen — der Auslöser ist ein anderer: vor 5.3.50 ein composer update, ab 5.3.50 ein geleertes typo3temp/. Und erst ab 5.3.50 kommen TypoScript und SCSS von selbst zurück, die Downloads weiterhin nicht.
Siehe auch: Installation — die Reihenfolge bei der Erstinstallation, und Datenbank & CLI — alle Konsolenbefehle der Extension.