Oldperl hat geschrieben: ↑Di 20. Mär 2018, 19:37
Servus,
Moin!
Faar hat geschrieben: ↑Di 20. Mär 2018, 14:29
Man könnte hier eine Funktion nachbauen, die zusätzlich noch den Dateinamen anfügt, aber praktisch wird das schwer, weil das Cache System dann die Datei nicht erkennen kann.
Und warum sollte das das Cache-System nicht erkennen? Wenn ich an allen Stellen, einschließlich der Auswertung, einen Teil des gecachten Dateinamens im Klartext hinzufüge, so arbeitet das System damit genauso, als wenn es nur gehashte Namen wären.
Das Cache System ist da sehr simple und macht aus verschiedenen und zusammengesetzten Daten einen md5 String.
Wenn man nun aus SEO Gründen da einen Dateinamen anfügt, sieht das vielleicht so aus:
Oldperl_beim_Kaffee_BF3C3E76B1B0053FDE376A6749143ECC.jpg
Würde das Caching System nun nachschauen, ob da ein Bild schon im Cache liegt, würde es nach einem BF3C3E76B1B0053FDE376A6749143ECC.jpg suchen, aber nicht nach Oldperl_beim_Kaffee_BF3C3E76B1B0053FDE376A6749143ECC.jpg, und folglich nichts finden und das Originalbild neu cachen.
Folglich müsste das gesamte Bildcaching angepasst werden. Nur einen Namen anfügen genügt nicht.
Natürlich könnte man hier den Cache-Dateinamen wieder aufsplitten und nur den md5 Teil (BF3C3E76B1B0053FDE376A6749143ECC) wieder für die Cache Suche verwenden, dann passt das wieder ins Contenido Kontinuum.
Trotz alledem muss man am Code etwas machen.
Da es nur eine Funktion ist, kann man diese vielleicht einfach kopieren und anpassen und stattdessen im Modul verwenden.
Was natürlich nicht mehr bei Modulen geht, die alles in Core-Klassen abgekapselt haben, wie dem Teaser-Image.
Faar hat geschrieben: ↑Di 20. Mär 2018, 14:29
Das Caching macht ja nur dann Sinn, wenn sich Bilder ändern könnten, wie bei News oder so.
Aber wenn Bilder statisch und in richtiger Größe auf dem Verzeichnis liegen, braucht es kein Caching.
Da möchte ich widersprechen.
Das Caching macht beispielsweise auch Sinn um den Pfad der Originaldatei zu verschleiern.
Ja, da habe ich verallgemeinert, bin aber in Gedanken vom SEO ausgegangen.
Bei SEO wähle ich eine Bild-Datei sehr bewusst aus und forme mir den Bildnamen.
Beispiel "Kommutator":
https://www.google.de/search?client=fir ... I8kS4B9NUs
Ich möchte dann ja, dass dieses Orignal gefunden wird.
Das ist dann nicht mehr das Originalbild aus der Kamera, sondern das Original, das ich für SEO erschaffen habe.
Also meisten fachgerecht ausgewählt, skaliert und zugeschnitten.
Das soll 1 zu 1 so ins Internet, mit exakt dem Namen.
Natürlich sind da in der Mehrzahl die anderen Fälle, in denen es nur darum geht, ein hochgeladenes Bild für ein Teaser-Programm oder einer Galerie verkleinert darzustellen und nicht das 14 Megapixel Bild im Uploadverzeichnis.
Und die meinte sicher Ortwin.
Was Ortwin hier beschreibt, ist eine feine Sache auch für Daten, die nicht jeder herunter laden können soll, sondern z.B. nur eingeloggte User im "geschützen Frontend-Bereich" und dann auch vielleicht nur für eine bestimmte Zeit lang.
Nutze ich diesen nur zur Generierung des Caches und nicht als URL im Frontend, so kann der Besucher nur an die gecachten Dateien, und nicht an das Original ran. So kann ich zum Beispiel hochauflösende Originale herunter rechnen und anbieten, ohne das der Besucher die originale Datei herunterladen kann bzw. den Pfad dafür erhält. Ebenso kann ich damit meine Pfadstruktur für Suchmaschinen verschleiern. Es kommt also immer auf die Anwendung an.
Das Unterverzeichnis im Upload (mit den Originalen) wird dann einfach mit .htaccess gegen außen abgesperrt.
Ab Apache 2.4 sieht es etwas anders aus:
https://httpd.apache.org/docs/2.4/upgrading.html