Hallo, ich habe gerade gesehen, dass der transient-ordner eine absurde Größe erreicht hat (14 GB) für eine eher kleine Seite. Ich hab' ein paar mp4-Dateien, die zum guten Teil dafür verantworltich sind. Einige Fragen dazu: 1. Kann ich den Ordnerinhalt löschen, ohne das es zu Problemen kommt? 2. Wie kann ich künftig verhindern, dass das voll-/überläuft (sporadisch über BE Maintenance-Modul bzw. wiederkehrend, ggf. über einen bestehenden Scheduler-Task)? Wäre toll, wenn jemand was dazu erklären könnte. Danke schon mal

transient-ordner / fal-tempfile

wini2

Hallo,
ich habe gerade gesehen, dass der transient-ordner eine absurde Größe erreicht hat (14 GB) für eine eher kleine Seite. Ich hab' ein paar mp4-Dateien, die zum guten Teil dafür verantworltich sind.
Einige Fragen dazu:

Kann ich den Ordnerinhalt löschen, ohne das es zu Problemen kommt?
Wie kann ich künftig verhindern, dass das voll-/überläuft (sporadisch über BE Maintenance-Modul bzw. wiederkehrend, ggf. über einen bestehenden Scheduler-Task)?

Wäre toll, wenn jemand was dazu erklären könnte.

Danke schon mal

Eric Harrer

Ich habe untersucht, wo im TYPO3-Core auf Environment::getVarPath() . '/transient/' zugegriffen wird.

Hier eine Übersicht aller Vorkommen in TYPO3 v13 mit Erklärung:

Package: typo3/cms-fluid
Datei: Classes/Command/SchemaCommand.php
Methode: execute

→ Erzeugt temporäre Schema-/Output-Dateien während des CLI-Laufs

Package: typo3/cms-core
Datei: Classes/Imaging/GraphicalFunctions.php
Methode: randomName

→ Erstellt eindeutige temporäre Dateinamen für Bildoperationen

Package: typo3/cms-core
Datei: Classes/Utility/GeneralUtility.php
Methode: tempnam

→ Legt leere Temp-Dateien in var/transient/ an (Suffix frei wählbar)

Package: typo3/cms-extensionmanager
Datei: Classes/Controller/ActionController.php
Methode: createZipFileFromExtension

→ Packt eine Extension temporär als ZIP in var/transient/

Package: typo3/cms-extensionmanager
Datei: Classes/Controller/UploadExtensionFileController.php
Methode: copyExtensionFolderToTempFolder

→ Kopiert Extension-Ordner temporär nach var/transient/ (Upload/Install-Prozess)

Package: typo3/cms-impexp
Datei: Classes/ImportExport.php
Methode: createTemporaryFolderName

→ Legt temporäre Ordner für Import-/Export-Dateien in var/transient/ an

Package: typo3/cms-install
Datei: Classes/Report/InstallStatusReport.php
Methode: getFileSystemStatus

→ Prüft Schreibrechte und Status von var/transient/

Package: typo3/cms-install
Datei: Classes/Service/CoreUpdateService.php
Methode: __construct

→ Nutzt var/transient/ für Update-Downloads und Entpacken

Package: typo3/cms-install
Datei: Classes/Service/EnableFileService.php
Methode: getTransientPath

→ Gibt den Pfad zu var/transient/ zurück

Package: typo3/cms-install
Datei: Classes/Service/EnableFileService.php
Methode: getInstallToolEnableFilePath

→ Ablage der temporären Datei ENABLE_INSTALL_TOOL

Package: typo3/cms-install
Datei: Classes/Service/LanguagePackService.php
Methode: languagePackDownload

→ Lädt Sprachpakete temporär herunter und entpackt sie in var/transient/

👉 Fazit: Der Core nutzt var/transient/ ausschließlich für temporäre Arbeitsdateien (z. B. Extension-ZIPs, Sprachpakete, Im-/Export, Bildverarbeitung). .mp4-Dateien entstehen dort nicht durch den Core, sondern stammen von Extensions oder Custom Code, die den Ordner zweckentfremden.

Das Verzeichnis kann daher grundsätzlich gefahrlos geleert werden. Vorher sollte man allerdings prüfen, welche Erweiterung die MP4-Dateien dort ablegt.

wini2

Eric Harrer
Hallo und vielen Dank für die Mühe. Ich hatte zwischenzeitlich den Ordner geleert - ohne nachteilige Konsequenzen festzustellen. Allerdings läuft der immer wieder voll. Meiner Vermutung nach, ist die tx_news (verwende 12.3.0) dafür verantworlich. Bei jedem Aufruf einer Detail-Seite werden pro verwendetem Bild 6 Dateien angelegt. Ich hab zwar das Template umgebaut, passiert aber auch beim Original.

Im Setup hab' ich fast nix geändert

			# media configuration
			media {
				image {
					lazyLoading = {$styles.content.image.lazyLoading}
					#maxWidht/Height durch eigene konfig verändert  -  muss leer sein
					#maxWidth = 282
maxWidth = 512
					#maxHeight =
maxHeight =


					# Get lightbox settings from fluid_styled_content
					lightbox {
			
enabled = 1
						#enabled = {$styles.content.textmedia.linkWrap.lightboxEnabled} 
						#class = {$styles.content.textmedia.linkWrap.lightboxCssClass}
#class = glightbox
class = lightbox
						#width = {$styles.content.textmedia.linkWrap.width}
						#height = {$styles.content.textmedia.linkWrap.height}
						#rel = lightbox[myImageSet]
rel = lightbox[myImageSet]


					}
				}

Mir fehlt die Idee, woran es liegen kann.

Ich verwende auch noch die sync-crop-areas-Ext. Die habe ich aber schon öfter in Kombination mit News eingesetzt, ohne dieses Problem zu haben.

Eric Harrer

wini2 Ich habe zum Nachvollziehen beide Extensions in TYPO3 v13 installiert und grundlegend konfiguriert.

Dazu habe ich einen News-Artikel angelegt, in dem sowohl ein MP4-Video als auch eine Bilddatei referenziert werden und den ich im Frontend in der Detailansicht aufgerufen habe. Für das Bild habe ich die Crop-Funktion genutzt, die dank EXT:sync_crop_areas auch über die konfigurierten cropVariants hinweg synchronisiert wurde (konfiguriert nach dieser Dokumentation).

Mit diesem Setup konnte ich allerdings nicht erreichen, dass etwas beim Aufruf der News-Detailansicht in das Verzeichnis var/transient geschrieben wird.

Bei der Durchsicht des Codes der News-Extension bin ich beim Begriff „transient“ nur auf das PHP-Attribut #[Transient] gestoßen. Dieses markiert eine Eigenschaft eines Extbase-Domain-Models als „vorübergehend“ im Sinne von „nicht persistiert“ (siehe Dokumentation). Das hat jedoch nichts mit Dateien im Verzeichnis var/transient zu tun.

In EXT:sync_crop_areas konnte ich den Begriff „transient“ gar nicht finden. Möglich ist aber, dass Core-Prozesse genutzt werden, die ihrerseits var/transient verwenden – das lässt sich nicht ohne Weiteres nachvollziehen.

Da es aktuell viele mögliche Einflussfaktoren gibt, würde ich empfehlen, die installierten Extensions, Templates und Konfigurationen schrittweise zu reduzieren, um einen kleinsten gemeinsamen Nenner zu finden, mit dem sich das Problem zuverlässig reproduzieren lässt. Auf diese Weise lässt sich die eigentliche Ursache vermutlich klarer eingrenzen.

wini2

Eric Harrer

Ganz heißen Dank für deine viele Arbeit.
Ich hatte ganz vergessen/es schon wieder verdrängt, dass ich die sitegeist / image-jack installierte habe (die webp gab's nicht für v13), um webp-support zu bekommen. Ich war nicht der erste, den es getroffen hat: https://github.com/sitegeist/image-jack/issues/15, die Änderung in Classes/Templates/AbstractTemplate.php
$this->imagePath = $this->storage->getFileForLocalProcessing($image, false);
könnte das Problem beseitigt haben. Leider gibt es noch keine gefixte Version im TER.
Seltsam ist nur, dass das scheinbar nur bei news auftritt!!?? Ich werde es im Auge behalten.

Eric Harrer

Ah interessant, danke dir für die Klarstellung.

Wenn hier der zweite Parameter ($writable) TRUE ist, dann ruft die Methode getFileForLocalProcessing die Methode copyFileToTemporaryPath auf, welche eine Kopie der Datei in einem temporären Verzeichnis aus der Methode getTemporaryPathForFile anlegt:

protected function getTemporaryPathForFile(string $fileIdentifier): string
{
    return GeneralUtility::tempnam('fal-tempfile-', '.' . PathUtility::pathinfo($fileIdentifier, PATHINFO_EXTENSION));
}

Hier kommt dann unsere bereits bekannte Methode GeneralUtility::tempnam() ins Spiel, welche auf var/transient referenziert.

wini2

Gern geschehen, bin kein Programmierer und verstehe leider nur wenig von dem, was du erklärst. Mit den webp-Ext. ist das schon ein Graus. Erst sah es so aus, als ob die eine nicht weiterentwickelt wird, dann die andere. Ich war schon happy, dass Wolfgang diese hier in seiner - schmerzlich vermissten, - donnerstäglichen twitch-Kaminrunde vorgestellt hatte und dachte, dass eine Agentur wie Sitegeist die angemessen pflegt.

Eric Harrer

wini2 Ich habe mich jetzt nicht im Detail damit befasst was die EXT:image_jack genau kann außer WebP-Kopien zu erzeugen aber braucht man denn überhaupt noch eine separate Extensions dafür in TYPO3 v13?

Der normale Bild-Prozessor des TYPO3 Cores unterstützt doch bereits die Umwandlung anderer Rastergrafikformate nach WebP/AVIF, so dass du die Umwandlung auch über dein Fluid Template auslösen könntest.

Beispiel mit Bootstrap-Breakpoints (Bild in ganzer Breite eines Bootstrap Containers):

<picture>
    <f:comment><!-- AVIF --></f:comment>
    <source
        srcset="{f:uri.image(image: file, maxWidth: 540, fileExtension: 'avif')} 540w,
                {f:uri.image(image: file, maxWidth: 720, fileExtension: 'avif')} 720w,
                {f:uri.image(image: file, maxWidth: 960, fileExtension: 'avif')} 960w,
                {f:uri.image(image: file, maxWidth: 1140, fileExtension: 'avif')} 1140w,
                {f:uri.image(image: file, maxWidth: 1320, fileExtension: 'avif')} 1320w"
        sizes="100vw"
        type="image/avif"
    />
    <f:comment><!-- WebP --></f:comment>
    <source
        srcset="{f:uri.image(image: file, maxWidth: 540, fileExtension: 'webp')} 540w,
                {f:uri.image(image: file, maxWidth: 720, fileExtension: 'webp')} 720w,
                {f:uri.image(image: file, maxWidth: 960, fileExtension: 'webp')} 960w,
                {f:uri.image(image: file, maxWidth: 1140, fileExtension: 'webp')} 1140w,
                {f:uri.image(image: file, maxWidth: 1320, fileExtension: 'webp')} 1320w"
        sizes="100vw"
        type="image/webp"
    />
    <f:comment><!-- Fallback --></f:comment>
    <f:image image="{file}" width="1320" alt="{file.alternative}" title="{file.title}" loading="lazy" decoding="async"/>
</picture>

Wenn du bereits ganz ohne Fallback auf andere Bildformate nurnoch WebP nutzen möchtest, dann könntest du beispielsweise diese Middleware nutzen, um WebP als Standard-Dateityp bei der Bildverarbeitung zu setzen.

wini2

Schon wieder mal - danke! Der Vorteil der webp-Ext. ist, soweit ich mich erinnere, dass man keine image-ausgaben in Templates anpassen muss und dass die Bilder automatisch konvertiert werden; d.h., Bilder müssen gar nicht erst als webp vorliegen; Redakteure müssen sie vor dem Hochladen nicht von jpeg, png oder was anderes konvertieren. Korrigiere mich, wenn ich mich irre: soweit mir bekannt, brauche ich webp schon für deinen Ansatz, damit die auch ausgegeben werden und den Fallback braucht man dann auch jedesmal - wird bei srcsets schnell unübersichtlich. Deinen Ansatz aus https://t3forum.net/d/872-webp-konvertierung-in-typo3-13-zentral-aktivieren/5 muss ich mir man in Ruhe in einer Testumgebung anschauen.

Eine kurze Vorstellung ist übrigens hier zu finden https://www.youtube.com/watch?v=yioCR-e4QQs so ab etwa 1h7min.

Eric Harrer

wini2 Man muss hier zwei Dinge klar voneinander trennen:

1) Bereitstellung moderner Bildformate (WebP/AVIF)
2) Bereitstellung optimierter Bildgrößen je nach Layout und Anzeigefläche

Zu 1): In TYPO3 v13 ist die Unterstützung für WebP und AVIF bereits im Core enthalten. Setze ich in Fluid z. B. das Attribut fileExtension="webp", wird automatisch eine WebP-Variante des Bildes erzeugt – zusätzliche Extensions sind dafür nicht erforderlich.

Zu 2): Die Definition verschiedener Bildgrößen ist weder durch den Core noch durch eine Extension automatisierbar, da dies immer vom jeweiligen Layout abhängt. Hier musst du selbst über srcset in Fluid passende Breakpoints hinterlegen. Auch EXT:image_jack nimmt dir das nicht ab.

Der Mehrwert von EXT:image_jack liegt vor allem darin, dass über den Accept-Header automatisch moderne Formate (WebP/AVIF) ausgeliefert werden – auch wenn im Markup nur ein einfaches <img src="bild.jpg"> steht.

Das ist der große Unterschied zum normalen TYPO3-Image-Processing, das nur dann alternative Formate erzeugt, wenn du sie explizit über bspw. f:uri.image anforderst. Für Bestandsprojekte ohne Template-Anpassungen kann das praktisch sein; wenn du dein Markup ohnehin anfasst, reicht der Core.

wini2

Eric Harrer
Danke für die Klarstellung. Dass ich mein srcset selbst erstellen/definieren muss, war mir klar, dass die Konvertierung automatisch stattfindet nicht (ich nehme an, wenn bei [SYS][mediafile_ext] eingetragen). Den Accept-Header habe ich bei Herumprobieren früher schon vermisst; ein Grund, weshalb ich die Ext. installiert habe. Ohne Ext. wird das wohl auch nicht gehen, wenn ich die htaccess anpasse, wie für die beiden extensions beschrieben?

Eric Harrer

Die Einstellung [SYS][mediafile_ext] legt lediglich fest, welche Dateiendungen TYPO3 grundsätzlich akzeptiert.

Die eigentliche Konvertierung erfolgt im Image-Processing:

Sobald du bei der Erzeugung einer Variante fileExtension="webp" oder fileExtension="avif" angibst – oder wenn TYPO3 intern mit dieser Endung arbeitet – wird die Datei im Processing-Cache (typischerweise fileadmin/_processed_/) erzeugt und von dort ausgeliefert. Zusätzliche Anpassungen in der .htaccess sind dafür nicht erforderlich.

Eine Auslieferung anhand des Accept-Headers unterstützt der Core nicht. Genau das übernimmt EXT:image_jack. Mit einer reinen .htaccess-Regel lässt sich dieses Verhalten nicht nachbilden, da TYPO3 die Varianten selbst generieren und verwalten muss.

Die Frage ist also, ob du überhaupt den Weg über den Accept-Header gehen möchtest oder ob dir der Core-Standard mit den genannten Einschränkungen ausreicht. Es wäre eine Abhängigkeit weniger in deiner Instanz.

wini2

Danke, sehr informativ. Bei neuen Projekten werde ich mir überlegen, ob ich die ext. noch einsetze. Für viele Fälle wird wahrsch. die von dir beschriebene Vorgehensweise ausreichend sein. Jedenfalls wären dann nicht 14 GB in 19.000 Dateien im transient-Ordner aufgelaufen. Jede Ext., die man nicht braucht, ist eine gute Ext. Wäre schön, wenn auch noch der Accept-Header in TYPO3 14 angepasst würde.

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