Aktualisierung functions.api.images.php
Verfasst: Fr 10. Jul 2020, 11:38
Liebe Gemeinde!
Seit einiger Zeit spiele ich mit dem Gedanken, einen Ersatz für die functions.api.images.php zu schaffen. Ich finde sie im Einsatz unhandlich und sehe darin, dass sie moderne Bildformate (webp) nicht unterstützt, einen großen Nachteil. Für die aktuelle Anforderung, dass ich ein Bild zum Beispiel in einem <picture>-Element in 5 Größen und sowohl als webp wie auch als jpg brauche, ist sie nicht gedacht.
Eigentlich schwebt mir eine Klasse vor, die mit dem Bild, das ich verwenden will, einmal initialisiert wird und die mir dann Bilder in beliebigen Größen und Datenformaten zur Verfügung stellt.
Die Idee, wie die functions.api.images.php Bilder cacht finde ich gut, was ich aber nicht verstehe ist die eingesetzte Cache Time, die eine Zeitangabe in Minuten erwartet. Erinnert sich jemand an den Sinn dessen? Es geht ja nicht um Speicherplatz. »Abgelaufene« Bilder im Cache werden ja nicht gelöscht, sie werden nur überschrieben, falls sie nach Ablauf der Cache-Zeit erneut angefragt werden.
Nach meinem Verständnis ist dieses Überschreiben aber nur dann sinnvoll, wenn das Originalbild geändert wurde (und dabei seinen Dateinamen beibehalten hat).
Und da wäre es meiner Meinung nach sinnvoller, in der Tabelle con_upl zu jedem Medium den Dateihash (md5_file($filename)) zu pflegen und den bei der Erstellung des Hash-Namens der Cachedatei mit einzubeziehen. Der müsste beim Upload der Bilder (und bei allen anderen Gelegenheiten, bei denen Bilder in die DB geschrieben werden) ermittelt und eingetragen werden.
Ein Nachteil ergäbe sich dann, wenn Dateien häufig durch namensgleiche Dateien überschrieben werden, dann liefe der Cache voll. Wäre aber hinnehmbar, denke ich.
Was meint ihr? Oder bietet Contenido längst eine Lösung für webp, die ich nur noch nicht kenne?
Grüße!
Bodil
Update: Ich stelle gerade fest, dass mit jedem Generieren des Hashs für die Cache-Datei ein md5_file() auf das Originalbild gemacht wird. Das löst mein Problem im Prinzip. Es klingt aber auch etwas inperformant, oder?
Das größte Bild im Upload-Bereich eines zufällig ausgewählten Kunden hat 450 kB. Den Hash zu erzeugen dauert 1,5 ms. Jedes mal?
Seit einiger Zeit spiele ich mit dem Gedanken, einen Ersatz für die functions.api.images.php zu schaffen. Ich finde sie im Einsatz unhandlich und sehe darin, dass sie moderne Bildformate (webp) nicht unterstützt, einen großen Nachteil. Für die aktuelle Anforderung, dass ich ein Bild zum Beispiel in einem <picture>-Element in 5 Größen und sowohl als webp wie auch als jpg brauche, ist sie nicht gedacht.
Eigentlich schwebt mir eine Klasse vor, die mit dem Bild, das ich verwenden will, einmal initialisiert wird und die mir dann Bilder in beliebigen Größen und Datenformaten zur Verfügung stellt.
Die Idee, wie die functions.api.images.php Bilder cacht finde ich gut, was ich aber nicht verstehe ist die eingesetzte Cache Time, die eine Zeitangabe in Minuten erwartet. Erinnert sich jemand an den Sinn dessen? Es geht ja nicht um Speicherplatz. »Abgelaufene« Bilder im Cache werden ja nicht gelöscht, sie werden nur überschrieben, falls sie nach Ablauf der Cache-Zeit erneut angefragt werden.
Nach meinem Verständnis ist dieses Überschreiben aber nur dann sinnvoll, wenn das Originalbild geändert wurde (und dabei seinen Dateinamen beibehalten hat).
Und da wäre es meiner Meinung nach sinnvoller, in der Tabelle con_upl zu jedem Medium den Dateihash (md5_file($filename)) zu pflegen und den bei der Erstellung des Hash-Namens der Cachedatei mit einzubeziehen. Der müsste beim Upload der Bilder (und bei allen anderen Gelegenheiten, bei denen Bilder in die DB geschrieben werden) ermittelt und eingetragen werden.
Ein Nachteil ergäbe sich dann, wenn Dateien häufig durch namensgleiche Dateien überschrieben werden, dann liefe der Cache voll. Wäre aber hinnehmbar, denke ich.
Was meint ihr? Oder bietet Contenido längst eine Lösung für webp, die ich nur noch nicht kenne?
Grüße!
Bodil
Update: Ich stelle gerade fest, dass mit jedem Generieren des Hashs für die Cache-Datei ein md5_file() auf das Originalbild gemacht wird. Das löst mein Problem im Prinzip. Es klingt aber auch etwas inperformant, oder?
Das größte Bild im Upload-Bereich eines zufällig ausgewählten Kunden hat 450 kB. Den Hash zu erzeugen dauert 1,5 ms. Jedes mal?