Würde ich auch begrüßen. Nur ohne solche Hacks und fest integriert in die Extension
Würde ich auch begrüßen. Nur ohne solche Hacks und fest integriert in die Extension
Hallo darki,
danke für das Feedback. Die Variante von Adaptive-Images hatte ich mir früher schon mal angeschaut aber da dort zwingend Änderungen an der .htaccess notwendig sind und sich dieses Konzept nicht vernünftig als Contao-Extension umsetzen lässt, bin ich einen anderen Weg gegangen.
Bei deinen Anpassungen im zweiten Posting sehe ich auch Probleme. Da dort der Cookie im ersten Request gesetzt wird, werden damit beim ersten Aufruf einer Webseite noch keine Retina-Bilder angezeigt. Da aber der ersten Eindruck wichtig ist, möchte ich das schon erreichen. Ein anderes Problem ist, dass überall dort Template-Anpassungen notwendig sind, wo Bilder auftauchen können.
Mit den doppelten Laden der Bilder bei meiner jetzigen Variante hast du leider Recht. Dort bin ich noch nicht weitergekommen. Eigentlich wollte ich direkt nach den DomRead-Event eingreifen. Wenn ich dort aber per JS das (stark vereinfacht) mache:
Dann erhalte ich ein merkwürdiges Ergebnis. Das zurückgegeben Objekt/NodeList hat zwar laut Konsole verschiedene Elemente, jedoch trotzdem die Länge 0 :(Code:el = document.getElementsByClassName("at2x");
Ausgabe:Code:console.log(typeof(el));
console.log(el);
console.log(el.length);
Obwohl ich die Elemente zurückbekomme, hat das Objekt eine Länge von 0 und ich kann sie nicht ansprechen. Dadurch kann ich die Bilder nicht vor dem Laden austauschen. Wenn ich den Code jedoch erst nach DOMContentLoaded aufrufe, sieht alles gleich aus, bis auf e.length, welches korrekt 3 liefert. Dort wurden die nicht-Retina-Bilder aber schon geladen.Code:> object
> [<img src="…" class="at2x" …>,
<img src="…" class="at2x" …>,
<img src="…" class="at2x" …>]
> 0
Alles sehr merkwürdig. Ich werde mir das in den nächsten Tagen noch mal mal in Ruhe anschauen.
BTW: Insert-Tags werden durchaus schon in Artikeln ersetzt und damit meine Erweiterung überall funktioniert, brauche ich einen zusätzlichen Hook, siehe hier. Dort seid ihr alle gefragt, in dem Bug mitzuschreiben und Leo die Dringlichkeit mitzuteilen.
Gruß
Ich hab den vorherigen Code geupdatet und den Schritt wo ich $GLOBALS['TL_JAVASCRIPT'][]=".." auskommentiert hab rausgelassen, da dies nicht mal wirklich notwendig ist. Dadurch werden auch beim ersten Pageload die Retina-Bilder geladen (durch deine retina.js), ab dem zweiten Pageload ist der Cookie dann vorhanden, d.h. ab dem zweiten Pageload werden die Retina Bilder mit meiner Variante geladen. D.h. der Traffic wird zumindest für alle anderen Seiten mit Ausnahme der ersten Seite korrekt geladen, leider auch kein perfektes Ergebnis, aber immerhin perfomanter als ohne :)Zitat:
Bei deinen Anpassungen im zweiten Posting sehe ich auch Probleme. Da dort der Cookie im ersten Request gesetzt wird, werden damit beim ersten Aufruf einer Webseite noch keine Retina-Bilder angezeigt. Da aber der ersten Eindruck wichtig ist, möchte ich das schon erreichen.
Du kannst ja die src-url des Bildes in der Extension abfangen und zur Laufzeit ändern (ist es das was du mit dem Hook meintest?), mein Template ist nur als simples Testbeispiel angedacht gewesen um die Logik aufzuzeigen die in die Extension implementiert werden könnte. Vielleicht fällt uns ja noch irgendwann eine bessere Lösung ein, aber zumindest würde der Traffic / die Serverauslastung dadurch schon mal drastisch abnehmen.Zitat:
Ein anderes Problem ist, dass überall dort Template-Anpassungen notwendig sind, wo Bilder auftauchen können.
Wäre herrlich wenn es so leicht ginge xD :) aber dann hätten wir auch nicht diese vielen herrlichen millionen Diskussionen über DomReady, DomEvents & Co. im Web ;)Zitat:
Mit den doppelten Laden der Bilder bei meiner jetzigen Variante hast du leider Recht. Dort bin ich noch nicht weitergekommen. Eigentlich wollte ich direkt nach den DomRead-Event eingreifen. Wenn ich dort aber per JS das (stark vereinfacht) mache:
Deine Versuche oben funktionieren einfach schlichtweg deswegen nicht weil sie 1. Bereits zu spät ausgeführt werden (womit das Bild bereits geladen wird) oder 2. Weil du auf ein Element zugreifst das noch gar nicht richtig existiert (Problem ist Browserabhängig und jeder hat da auch noch so seine Vorlieben dazu xD).
Die Sache ist leider die,
1. DomReady wird viel zu spät ausgelöst und ist eine Performance-Langsame Sau xD
2. Direkte Script-Ausführungen, wie dein Beispiel, können keine Elemente manipulieren die noch gar nicht richtig geladen worden sind oder noch nicht existieren (du musst bedenken dass das Element erst ansprechbar ist wenn der Tag auch korrekt geschlossen wurde (dies bezieht auch ganze Gruppen von Elementen ein, also ".at2x", über JS eine Class-Selection zu machen getElementsByClassName("at2x") würde nur dann funktionieren wenn alle drei Elemente geschlossen worden sind), z.B. <div id="test"></div>, du kannst diesen DIV also nur dann über das DomRead-Event korrekt bearbeiten sobald </div> durch ist, selbiges gilt für <img>, dies ist aber riskant, da unterschiedliche Browser das Verhalten unterschiedlich interpretieren)
3. Andere DomEvents die schon früher zugreifen können sind leider auch noch zu spät dran und ein paar wenige Raritäten wiederum sind kaum in einem Browser implementiert oder fehlerhaft.
Die einzige mir bekannte Lösung ist Inline-Scripting, entweder das scriptTag befindet sich am Ende des Body's oder nach dem Element das manipuliert werden soll. Das wäre der überhaupt frühstmögliche Zugriff auf ein Element. Fraglich ist aber dennoch ob man dabei das Src-Attribut früh genug ändern kann bevor es einen Server-Request startet, ich habs zwar noch nicht ausprobiert, aber ich denke das wird wahrscheinlich Browserabhängig sein und in den meisten Fällen nicht so funktionieren wie man es sich vorstellt.
D.h. letzten Endes muss der korrekte Pfad eines Bildes anhand der Monitoreinstellugen direkt serverseitig ausgegeben werden. Leider kriegen es die Browser-Hersteller immer noch nicht auf die Reihe eine neue und standardisierte Header-Request Spezifikation herauszubringen damit wir auch mit serverseitigen Sprachen die Möglichkeit haben dort die Monitorauflösung, PixelDensity, etc. herzubekommen, das wäre ein absoluter Traum und würde uns all die blöde Arbeit abnehmen die wir damit verschwenden Probleme wie diese zu lösen, aber davon sind wir leider noch weit entfernt, da dies schon vor Jahren hätte passieren müssen, und es jetzt schon zu viele Browser-Versionen gibt in denen es nicht implementiert ist (es hätte genau dann eingeführt werden müssen als Screens mit einer höheren PixelDensity als 1 herausgekommen sind).
Die einzige andere Alternative die mir noch einfällt wäre mittels CSS3 Media Queries und dem <picture> Element (rein theoretisch und noch nicht getestet):
Eine gute Erklärung zu <picture> mit Media-Queries gibt es hier:Code:<picture alt="description">
<source src="picture.jpg">
<source src="picture@2x.jpg" media="min--moz-device-pixel-ratio: 1.5; -o-min-device-pixel-ratio: 3/2; -webkit-min-device-pixel-ratio: 1.5; min-device-pixel-ratio: 1.5; min-resolution: 1.5dppx;">
</picture>
http://css-tricks.com/which-responsi...hould-you-use/
Und hier eine Liste aller bisher vorhanden Alternativen / Möglichkeiten zu ResponsiveImages (die Konzepte sind aber ebenso verwendbar für unser @2x Problem):
https://docs.google.com/spreadsheet/...mdVI2OXc#gid=0
Davon hab ich noch nicht alle ausprobiert, aber vielleicht ist ja etwas dabei was uns weiterhilft. Ansonsten sind die Lösungen mit der .htaccess + Cookie leider die derzeitig einzigen die zuverlässig arbeiten.
[EDIT1:] Zu den drei Aufzählungen, das Element ist erst dann zugreifbar wenn der Tag auch geschlossen wurde, siehe Punkt 2.
[EDIT2:] Es gibt eine Möglichkeit den JS Cookie schon beim ersten Pagerequest zu setzen und über PHP abzufangen, allerdings kann das die Performance vom Server ein wenig schlauchen, daher ist das auch keine gute Variante: http://stackoverflow.com/questions/1...nswer-12684322
Viele Grüße
darki
Also wenn DomReady aufgerufen wird, obwohl die Elemente noch gar nicht geschlossen sind und damit der DOM-Baum ja noch nicht „ready“ ist, dann ist das irgendwie ziemlich großer Käse und das W3C sollte mal nachsitzen.
Ansonsten werde ich mal schauen, ob und wie ich deinen Ansatz in der Erweiterung einbauen und einen Mix aus JavaScript (für den ersten Zugriff) und serverseitiger Ersetzung für danach machen kann. Um es komplett für alle Elemente zu machen, brauche ich aber eben den schon angesprochenen Hook und auch ein wenig Unterstützung aus Community. Momentan gibt es bei Contao eben keinen Hook, der nach dem Ersetzen von Insert-Tags noch mal das Ändern der fertig gerenderten Seite erlaubt und damit lassen sich leider nicht alle Bilder ersetzen.
Gruß
Hab gerade gemerkt dass selbst bei AdaptiveImages in meinem Browser der Cookie manchmal nicht früh genug gesetzt wird xD Schrott ^^.
Da hab ich durch lauter Text-durchlesen etwas durcheinander gebracht xD Ich meinte nicht das DomReady Event (DomReady würde hier so oder so nicht funktionieren), sondern ein anderes, z.B. einen eigenen Parser der Schritt für Schritt den DOM überprüft bis das entsprechende Tag geschlossen wurde um darauf dann zuzugreifen (ein gutes Beispiel liefert dafür das YUI Framework mit dem Event "available", dieses wird sofort gestartet sobald das Element auch nur ansatzweise da ist, dafür gibt es aber Probleme im IE). Aber das ist wie gesagt alles andere als eine gute Lösung und somit abzuraten, da es hierbei unzählige Probleme gibt auf die man gefasst sein muss und auch kennen muss.
Ich hab allerdings etwas anderes entdeckt was das Problem lösen kann, du kannst statt dem regulären Code folgendes per PHP ausspucken lassen:
Und dann per JS die Bilddatei in den Platzhalter einfügen, das klappt deswegen weil alles was sich im <noscript> Tag befindet der Browser nicht ins DOM einfügt, aber dennoch über JS erreichbar ist. Ein Beispiel findest du hier: https://github.com/scottjehl/picturefillCode:<div data-picture data-alt="A giant stone face at The Bayon temple in Angkor Thom, Cambodia">
<div data-src="small.jpg"></div>
<div data-src="small.jpg" data-media="(min-device-pixel-ratio: 2.0)"></div>
<div data-src="medium.jpg" data-media="(min-width: 400px)"></div>
<div data-src="medium_x2.jpg" data-media="(min-width: 400px) and (min-device-pixel-ratio: 2.0)"></div>
<div data-src="large.jpg" data-media="(min-width: 800px)"></div>
<div data-src="large_x2.jpg" data-media="(min-width: 800px) and (min-device-pixel-ratio: 2.0)"></div>
<!-- Fallback content for non-JS browsers. Same img src as the initial, unqualified source element. -->
<noscript>
<img src="external/imgs/small.jpg" alt="A giant stone face at The Bayon temple in Angkor Thom, Cambodia">
</noscript>
</div>
[EDIT1:] Es hat sich herausgestellt das diese Möglichkeit ebenfalls wegfällt, da laut einem Google Mitarbeiter alle Image Dateien die sich innerhalb eines <noscript> Tags befinden nicht für SEO Zwecke beachtet oder sogar abgewertet werden :(
Ich hab mich mal die halbe Nacht durchgelesen, ne perfekte Lösung gibts immer noch nicht, man kann höchstens mit so vielen Fallbacks wie möglich arbeiten, diese hab ich versucht auszuarbeiten. Die Ausgabe der Bilder (inkl. Fallback) würde wie folgt aussehen.
Zuerst folgenden Code im Head Bereich des Dokuments (vor allen anderen JS Dateien) einsetzen:
Lösung 1:Code:<script>document.cookie='resolution='+Math.max(screen.width,screen.height)+("devicePixelRatio" in window ? ","+devicePixelRatio : ",1")+'; path=/';</script>
Standard Code, falls kein Cookie ermittelt werden konnte folgendes ausgeben:
Falls ein Cookie ermittelt werden konnte dann einfach den richtigen Dateipfad zum Bild anhand des Cookies ermitteln (photo.jpg oder photo@2x.jpg) und ausgeben:Code:<picture>
<source src="photo.jpg">
<source src="photo@2x.jpg" media="(min-device-pixel-ratio: 2.0)">
<img src="photo.jpg" alt="">
</picture>
Lösung 2:Code:<picture>
<source src="...">
<img src="..." alt="">
</picture>
Ohne Cookie:
Mit Cookie:Code:<img src="photo.jpg" srcset="photo.jpg, photo@2x.jpg 2x" alt="">
Die retina.js kann gelöscht werden.Code:<img src="..." alt="">
Im Standard Code (ohne Cookie) muss das <img> Tag aus dem Grund das kleinere Bild erhalten, weil es unzumutbar ist mobilen Usern mit einer langsamen Verbindung (z.B. wenn man unterwegs ist) zusätzlichen Traffic aufzubürgen (AdaptiveImages macht es nicht anders, es wird aber bereits an HTML5 Traffic/Network-Spezifikationen gearbeitet). Genau dieses Problem besteht aber derzeitig bei der retina.js Variante. Aber so weit kommt es ja zum Glück nicht einmal, denn durch den HTML5 Media Query nimmt er ohnehin das @2x Bild ohne etwas doppelt zu laden, sofern er HTML5 versteht (was wohl bei 99% der HighDensity Display Geräten der Fall ist, da diese neuen Geräte keinen IE6 oder IE7 draufhaben), nur falls aus irgendwelchem Grund auch immer dennoch nicht HTML5 (bzw. der MediaQuery) von diesen Geräten verstanden wird, dann wird auf das kleinere Bild zurückgegriffen falls kein Cookie gesetzt ist, sobald der Cookie dann aber gesetzt wurde funktioniert selbst bei dieser Minderheit dann wieder alles wie es sollte, soviel zum Fallback "html5 media query + cookie".
Der zweite Lösungansatz sieht auf den ersten Blick viel kürzer aus, hat aber auch seine entsprechenden Nachteile aus Programmierersicht, z.B. hat das srcset Attribut keine Möglichkeit komplexere MediaQueries aufzunehmen (z.B. zukünftige Traffic/Network-Specs), und es kann gleich viel viel unübersichtlicher werden wenn mehrere neue Bedingungen (Microsyntax) hinzukommen. Ebenso kann man zum Beispiel über JS nur schwerer neue Bedingungen hinzufügen.
D.h. html5 media query detection + cookie/js detection decken nahezu alle Fälle ab um die richtigen Bilder auszugeben und damit die Bilder nicht doppelt geladen werden.
Viele Grüße & gute Nacht
darki
Erst mal vielen Dank für deine Nachtschicht und deine Mühe! Ich werde es mir alles ganz genau anschauen. Mir fallen aber auch gleich ein paar Probleme auf: Das picture-Element gibt es doch soweit ich weiß noch gar nicht und es wird erst seit Ende letzen Jahren vom W3C ein Standard dafür ausgearbeitet. Sind die denn schon fertig? Das srcset-Attribut vom img-Element war doch der „Gegenentwurf“ von der WHATWG - ist das denn schon irgendwo festgeschrieben? Ich bin mir also nicht sicher, ob sich beides schon im produktiven Einsatz nutzen lässt.
Selbst wenn, gibt es zwei weitere Probleme:
1. Ich kann ja nicht einfach ein img-Tag mal eben gegen einen picture-Tag austauschen. Damit gehen ja alle Styleangaben krachen und müssen angepasst werden. Das muss auf jeden Fall gut überlegt sein. Gut vorstellen kann ich mir aber, dass ich in der Erweiterung Inhaltselemente wie Bild, Galerie oder das Bild vom CE Text per Option in ein picture-Tag umwandle und die entsprechenden Bilder zur Verfügung stelle. Das werde ich mir auf jeden Fall ganz genau anschauen.
2. Das ganze soll ja auch noch bei XHTML-Seiten funktionieren. Ich selbst betreue noch eine bildlastige XHTML-Seite, die ich nicht so schnell auf HTML5 umstellen werden und dort möchte ich auch hochauflösende Bilder.
Momentan scheint mir dein erster Ansatz mit Cookie und retina.js am einfachsten. Dort muss ich nur genau testen, wie Contao mit dem Cachen klar kommt, damit nicht Retina-Versionen im Cache landen und dann für andere Nutzer ausgegeben werden.
Gruß
Keine Ursache, helfe gerne :)
Beide Versionen sind erst noch als Dev Draft auf der W3C verfügbar und wurden Anfang / Mitte 2012 von der WHATWG und der W3C eingeführt, bzw. weiterentwickelt (http://www.peterkroener.de/die-responsive-images-story).Zitat:
Erst mal vielen Dank für deine Nachtschicht und deine Mühe! Ich werde es mir alles ganz genau anschauen. Mir fallen aber auch gleich ein paar Probleme auf: Das picture-Element gibt es doch soweit ich weiß noch gar nicht und es wird erst seit Ende letzen Jahren vom W3C ein Standard dafür ausgearbeitet. Sind die denn schon fertig? Das srcset-Attribut vom img-Element war doch der „Gegenentwurf“ von der WHATWG - ist das denn schon irgendwo festgeschrieben? Ich bin mir also nicht sicher, ob sich beides schon im produktiven Einsatz nutzen lässt.
Aber beide Varianten sind jetzt schon nutzbar, da sie abwärtskompatibel sind (mit Ausnahme von XHTML :/). Allerdings hast du Recht dass das W3C noch daran arbeitet und das diese leider erst sehr spät aufgenommen wurden, die WHATWG ist da schon etwas weiter (da neue Features ausprobieren einer deren Hauptaufgabe ist), allerdings gelten diese erst wenn sie von der W3C offiziell angenommen werden. In der W3C sind beide noch als "Dev Drafts" aufgeführt und somit noch nicht vollwertig implementiert. Einige Browser haben allerdings schon die Vorschläge implementiert (hängt aber leider ganz von den Browerherstellern ab, wann und wie sie diese implementiert haben oder noch werden, falls sie es bei gewissen Browsern noch nicht sind).
Falls das nicht geht dann kannst du die <img src="..." srcset="..." alt="..."> Variante verwenden, es wird lediglich nur ein neues Attribut hinzugefügt und es ist abwärtskompatibel.Zitat:
Erst mal vielen Dank für deine Nachtschicht und deine Mühe! Ich werde es mir alles ganz genau anschauen. Mir fallen aber auch gleich ein paar Probleme auf: Das picture-Element gibt es doch soweit ich weiß noch gar nicht und es wird erst seit Ende letzen Jahren vom W3C ein Standard dafür ausgearbeitet. Sind die denn schon fertig? Das srcset-Attribut vom img-Element war doch der „Gegenentwurf“ von der WHATWG - ist das denn schon irgendwo festgeschrieben? Ich bin mir also nicht sicher, ob sich beides schon im produktiven Einsatz nutzen lässt.
Selbst wenn, gibt es zwei weitere Probleme:
1. Ich kann ja nicht einfach ein img-Tag mal eben gegen einen picture-Tag austauschen. Damit gehen ja alle Styleangaben krachen und müssen angepasst werden. Das muss auf jeden Fall gut überlegt sein. Gut vorstellen kann ich mir aber, dass ich in der Erweiterung Inhaltselemente wie Bild, Galerie oder das Bild vom CE Text per Option in ein picture-Tag umwandle und die entsprechenden Bilder zur Verfügung stelle. Das werde ich mir auf jeden Fall ganz genau anschauen.
Das stellt in der Tat ein Problem dar, an XHTML hatte ich noch gar nicht gedacht :/ Da wäre diese Methode in der Tat nicht verwendbar, dort könnte man aber alternativ mit der <noscript> Variante arbeiten, auch wenn diese einen kleinen Nachteil hat, zumindest wäre das aber eine Übergangslösung. Wenn man es noch mehr absichern möchte, dann kann man die <noscript> Variante auch in der HTML5 Version als Fallback implementieren, der Code sollte dann aber nur ausgegeben werden falls das <picture> Tag oder das srcset nicht vom Browser unterstützt wird (Überprüfung wäre dann mühselig über den BrowserAgent realisierbar). Die Methoden stellen definitiv eine hohe Komplexität und Umsetzung dar, mittels genug Fallbacks wäre das aller meiste aber wie erwähnt abdeckbar.Zitat:
2. Das ganze soll ja auch noch bei XHTML-Seiten funktionieren. Ich selbst betreue noch eine bildlastige XHTML-Seite, die ich nicht so schnell auf HTML5 umstellen werden und dort möchte ich auch hochauflösende Bilder.
Eine gute Lösung zu finden ist viel komplexer als ich Anfangs dachte, zu verdanken haben wir es letzten Endes den Browserherstellern dass wir noch nichts haben (z.B. durch eine bessere Header-Request Spezifikation).
Gruß
darki
Also bei mir funktioniert die Erweiterung in Contao 3.0.3 nicht. Das zweite Bild wird zwar erzeugt in assets/images/1/..., aber im Frontend nicht ersetzt. Die Klasse "@2x" steht auch nicht beim Bild im Quelltext. Woran kann das liegen?
Ach, Fehler selbst gefunden. Das Bild ist über ein Modul eingebunden, dann funktioniert es nicht mehr :-(
Gäbe es auch eine Möglichkeit je nach Gerät einen Schalter (plus Erklärungstext) auf der Website zu platzieren, um die hochauflösenden Bilder erst damit zu aktivieren. Gerade bei bildlastigen Websites wäre man unterwegs (mit langsamerem Internet) nicht gezwungen die hochauflösenden Bilder herunterzuladen (evlt. mit einem einfachen Cookie). Oder habe ich diese Funktion überlesen?
Hi,
wollte die Erweiterung jetzt auch mal in ein aktuelles Projekt integrieren und erhalte promt eine Fehlermeldung, wenn ich den {{image::...}} Inserttag nutze.
Ich hab mir die Posts durchgelesen und inserttags scheinen Probleme zu machen.
Ich poste den Fehler dennoch, vielleicht kann man was machen:
PHP-Code:Fatal error: Call to a member function getImageHook() on a non-object ... on line 999
Welche Contao-Version und in welcher Datei tritt der Fehler auf? Ansonsten verweise immer noch hier rauf:
https://github.com/contao/core/issues/4291
Da bisher keiner weiter seinen Senf dort mit abgegeben hat, nehme ich an, dass es niemand weiter außer mir braucht.
Gruß
2.11.9Zitat:
Zitat von Babelfisch
In welcher Datei tritt denn der Fehler auf? Bei solchen Fehlermeldungen steht das im Normalfall mit dabei.
Auch ja, natürlich... :)Zitat:
Zitat von Babelfisch
In der Controller.php, Bereich wo der eigentliche getImage Hook durchlaufen wird.
Sent from my iphone using Tapatalk
Nach einigen probieren habe ich nun mit der Erweiterung aufgegeben,
es hakte hier und da (bei mir) noch.
Bin nun auf
http://retina-images.complexcompulsions.com/
umgestiegen, etwas mehr Aufwand mit background-size etc bei CSS Bilder,
aber die Erweiterung klappt super mit jeglichen Grafiken die ich einbinde.
@56mj1985
Wie löst du es, das die Erweiterung "Retina-Images" den richtigen Bild-Pfad zu den @2x Bilder bekommt, wenn der Pfad durch Contao so aussieht?:
http://domain.local/assets/images/9/image.jpg
Das Original Bild und das @2x liegt aber im "files" Ordner.
Diesen Fall hab ich auf meiner Webseite zum Glück nicht gehabt.
Tolle Idee die Erweiterung! Wie bringe ich die Erweiterung mit der Standardgalerie zum Laufen?
Es gibt ja bei der Großansicht keine Möglichkeit die Bildgröße anzugeben.
Gruß - Max
Bitte um kurzes Feedback ob die Erweiterung mit der Standardgalerie nun funktioniert oder nicht.
Wie gesagt kann man in der Standardgalerie bei der Vollansicht keine Bildgrößen angeben,
was so wie ich es verstanden habe jedoch grundlegend für diese Erweiterung ist.
Wenn keine Bildgröße angegeben wird, kann die Erweiterung nichts machen. Dann hängt es vom Ausgangsbild und den Einstellungen von Contao ab, ob das Bild trotzdem hochauflösend dargestellt wird.
Gruß
Hallo!
Erstmal Danke, dass es überhaupt eine Erweiterung gibt die Retina-Bilder bereitstellt!
Ich wollte es in unserem neusten Projekt für einen Fussball Club einbauen, aber bei mir funktioniert die Erweiterung nicht.
Oder ich mache etwas falsch, was wahrscheinlicher ist :D
Auf dieser Seite wäre das Mannschaftsbild gross genug, aber im Quelltext sehe ich nichts von "@2x".
Ausserdem habe ich bei dem Akkordeon den Toggle in beiden Grössen bereitgestellt und da nimmt er auch nicht die @2x Grafik.
http://beta.fcdavos.ch/junioren-c.html
Könnte mir irgendjemand sagen, was ich falsche mache? :)
Contao 3.1.1
Der Toggler (pfeil_hoch) ist per CSS-Hintergrundgrafik einbunden, muss da nicht die Hintergrundgröße angegeben werden?
Code:background-image: url("my-image.png");
-webkit-background-size: 20px 14px;
-moz-background-size: 20px 14px;
-o-background-size: 20px 14px;
background-size: 20px 14px;
Hallo zusammen,
ich habe die Erweiterung heute installiert, und habe den Eindruck, dass sie bei mir nicht funktioniert. Sprich, auf dem iPhone 4 (ist das einzige Gerät mit Retina Display das ich momentan zur Verfügung habe), werden nicht die hochauflösenden Fotos angezeigt, obwohl sie im Verzeichnis html/ vorhanden wären.
Ich habe bis anhin einige Grafiken (Logos, Symbole) auf der Seite in grösserer Auflösung bereit gestellt, und dann per css "verkleinert". Natürlich reklamiert deswegen der PageSpeed Test, was mir nicht so gefällt.
Was ich bisher gemacht habe:
Die Erweiterung installiert, Systemwartung ausgeführt, dann getestet, leider erfolglos, Browser und Servercache in Contao deaktiviert, Browsercache geleert, wieder getestet, wieder erfolglos (übrigens Contao 2.11.11)
was ich auch noch gemacht habe:
in der DateialleHTML-Code:/system/modules/retina_image/config/config.php
inPHP-Code:$GLOBALS['TL_JAVASCRIPT']
geändert. Gefällt mir zwar nicht, aber ich möchte Javascript gerne erst am Ende der Seite laden, und weiss momentan noch keinen besseren Weg. Das Script wird korrekt im Quelltext eingebunden, scheint aber trotzdem nicht zu funktionieren. Die Developer-Tools von Chrome zeigen mir keine JavaScript Fehlermeldung an.PHP-Code:$GLOBALS['TL_MOOTOOLS']
Habs natürlich auch mit der Originaldatei getestet. Erfolglos. Das iPhone zeigt einfach keine hochauflösenden Bilder.
Was mich auch verwirrt, ist, dass jetzt alle Bilder in dreifacher Ausführung in /html/ liegen.
Danke für jeden Hinweis!
lg Daniel
Ich werde mir das in den nächsten Tagen mal genauer anschauen. Habe ich schon festgestellt, dass seit einem der letzten Contao-Updates was hakt.
Gruß
Vielen Dank. Dann warte ich mal ab.
lg Daniel
Hi Babelfisch,
ich habe in Contao 3.1.1. das Problem, dass die Extension ein Bild nicht in der 2x-Variante anzeigt. Das Bild ist einem ce_text-Element angefügt. Der Artikel in dem dieses Element liegt wird per Modul in das Seitenlayout eingebunden. Wenn ich das ce_text-Element mit dem Bild ganz normal in einem Artikel auf einer Seite einbinde funktioniert es wie gewünscht.
Ich verwende die aktuellste Version der Extension.
Gruß
Stefan
Hallo Babelfisch
Danke für deine Erweiterung, macht einen guten Eindruck und ist genau das, was mir noch gefehlt hat. Allerdings bin ich (vermutlich) noch auf einen kleinen Bug gestossen: Ich verwende in meinem eigenen Contao3 Modul die Funktion \Image::get um die Bilder aus dem Backend für das Template in der Grösse anzupassen. Ich verwende folgende Einstellungen: Image::get($quelle, 289, 289, 'box'). Wenn jetzt als Input ein Bild ankommt, welches die doppelte Auflösung nur in der Breite aufweist, wird das Bild nicht in beiden Auflösungen gerechnet. Stelle ich beide Werte auf die halbe Auflösung der kurzen Kante, funktioniert es. Scheinbar wird bei 'box' (und nach einem kurzen Test auch bei 'proportional') die Orientierung des Bildes nicht mit beachtet bei der Auswertung, ob die Auflösung genügend ist. Meinst du das lässt sich noch realisieren?
Herzlich
Atreju
Hallo Babelfisch
Bin heute doch noch dazu gekommen deine Erweiterung etwas genauer an zu schauen. Das Problem mit der falschen Prüfung für den Modus 'box' und 'proportional' konnte ich mit einer erweiterten IF Abfrage lösen (nicht ausgiebig getestet):
Gleichzeitig ist mir noch ein Bug beim zusammenstellen des <img> tags aufgefallen. Da wurde mir nämlich immer ein quadratischer Wert für Breite und Höhe ausgegeben, statt die effektiven Kantenwerte des neuen Bildes. Auf Zeile 159 im RetinaImage.php ist der falsche Array Eintrag gesetztPHP-Code:if($mode == 'box' || $mode == 'proportional') {
if($arrSize[0] < $width*2 && $arrSize[1] < $height*2) {
return;
}
} elseif($arrSize[0] < $width*2 || $arrSize[1] < $height*2) {
return;
}
Und zu guter Letzt ist mir beim Server Umzug noch aufgefallen, dass die die Entwicklungsanleitung die ich selber Verwendet habe, für die .htaccess Datei in den "assets" eine (inzwischen) falsche oder zumindest nicht unbedingt überall funktionstüchtige Vorlage angibt. Bei deinem Modul hatte ich auf dem neuen Server das gleiche Problem. Contao und andere Module verwenden folgenden .htaccess Inhalt für den Modul>assets Ordner:PHP-Code:$strTag = str_replace('<img', '<img width="'.$imageSize[1].'"', $strTag);
// should be
$strTag = str_replace('<img', '<img width="'.$imageSize[0].'"', $strTag);
anstelle vonHTML-Code:<IfModule !mod_authz_core.c>
Order allow,deny
Allow from all
</IfModule>
<IfModule mod_authz_core.c>
Require all granted
</IfModule>
HTML-Code:order deny,allow
allow from all
Hoffe das hilft und wäre cool, wenn du das mal noch einbauen könntest.
Herzlich
Patric
Hallo Babelfisch
Und noch was wäre super: Mein Projekt hat sehr viele, grosse Bilder, was für Mobile-Benutzer ein rechter Datenkiller sein dürfte. Vielleicht wäre es sinnvoll dem Admin per Einstellungen per Checkbox die Möglichkeit zu geben Retina-Bilder für Mobile Geräte aus zu schalten (als alternative zu einem mobilen Layout). Ich konnte dies mit folgendem Code in Zeile 139 in RetinaImage.php lösen:
Der Insert-Tag müsste natürlich auch noch entsprechend angepasst werden...PHP-Code:// get user agent info
$userAgent = \Environment::get('agent');
if ($count == 0 && $userAgent->mobile != 1) {
$strTag = str_replace('<img', '<img class="at2x"', $strTag);
}
Herzlich
Atreju
Ich hatte noch keine Zeit das Problem genau zu suchen aber mit Contao 3.2.4 und 3.2.5 funktioniert retina_image nicht mehr. Die Bilder werden einfach doppelt so gross wiedergegeben, der Effekt der durch die Extension erfolgt bleibt weg.
Hallo.
danke für diese sehr nützliche Erweiterung!
1) Gibt es schon Neues bzgl. der Funktionalität mit 3.2.4 / 3.2.5 ?
2) Wie kann ich denn am besten testen, ob die Erweiterung greift und ein Bild bei Retinadisplay wirklich doppelt so groß ausgelilefert wird.
3) Sind die Funktionen dieser Erweiterungen kompatibel mit denen der Erweiterung [responsive_images] Erweiterung um Bilder für Mobilgeräte zu verkleinern
Danke & Grüße
Die Erweiterung funktioniert jetzt auch wieder unter Contao 3 richtig. Auch über InsertTags eingebunden Bilder oder andere Inhaltselemente mit Bilder werden jetzt berücksichtigt.
In der 1.3.0 habe ich eine – noch etwas experimentelle – einfach Unterstützung für SVG-Bilder (Scalable Vector Graphics) hinzugefügt. Das funktioniert nur für Contao 3 und sollte generell für alle Standard-Inhaltselemente mit Bilder funktionieren. In den Contao-Systemeinstellungen muss man dazu erst bei Unterstützte Bildformate und Erlaubte Upload-Dateitypen die Endung svg hinzufügen. Läd man danach ein SVG-Bild hoch und bindet es in einem Inhaltselement ein, wird es ohne weitere Änderungen auch im Frontend im IMG-Tag eingebunden, was in allen modernen Browsern funktionieren sollte. Eine Fallback-Lösung mit dem OBJECT-Tag ist nicht vorgesehen, ließe sich aber über ein angepasstes Template ce_image sicherlich realisieren.
Generell wäre dies auch schon so mit Contao direkt möglich, da jedoch die GD-Library unter PHP kein SVG kennt, funktioniert addImageToTemplate in der Controller.php nicht und macht eine Anpassung nötig.
Hey
Zuerst mal vielen Dank für die Erweiterung! :)
Leider habe ich einen Bug, der die Erweiterung relativ nutzlos macht.
Ich habe ein Bild (130x50 Pixel). Wenn ich nun die Erweiterung aktiviere und eine Retina-Version des Bildes wird der Code falsch angepasst und das Bild zu klein dargestellt.
Aus diesem Code:
wird dieser Code:Code:<img src="tl_files/bild.png" alt="Logo">
Die von der Erweiterung ergänzte width ist immer identisch mit der height. Korrekt wäre aber in diesem Fall:Code:<img width="50" height="50" class="at2x" src="tl_files/bild@2x.png" alt="Logo">
Wenn ich das im Firebug ändere, stimmt die Darstellung. Hat sich hier ein Fehler eingeschlichen? Nutze die neuste Contao-Version und das neuste retina_image.Code:<img width="130" height="50" class="at2x" src="tl_files/bild@2x.png" alt="Logo">
Liebe Grüsse
Big_Berny
Ja, da hat sich ein Fehler eingeschlichen. Bis zum Update kannst du dir erst mal so behelfen, dass du width und height im img-Tag selbst reinschreibst.
Gruß
Vielen Dank für die Info. Leider sind es ziemlich viele Bilder. Gibt es eine Version, die den Bug noch nicht aufweist und mit Contao 3.2 funktioniert?
Gerade gesehen, dass es in 1.3.1 bereits wieder funktioniert. Stark! :)
Liebe Grüsse
Hallo,
bei mir funktioniert die Erweiterung leider nach wie vor nicht.
Es wird keine Klasse "at2x" und auch keine entsprechenden Bilder im Cacheverzeichnis generiert.
http://www.semi-kolon.de/ (z.B: Logo liegt definitiv groß genug vor)
Hat jemand eine Idee woran es liegen könnte?
Danke & Grüße.
Die Erweiterung greift automatisch nur bei Bildern, die über ein Contao-Inhaltselement oder den Insert-Tag eingebunden werden und mindestens doppelt so groß sind, wie sie angezeigt werden sollen. Du hast bei dir fast alle Bilder direkt eingebunden, ohne das sie Contao (und damit meine Erweiterung) noch mal anfasst und damit kann das nichts werden. Dort, wo du Bilder über Contao einbindest, klappt es dagegen. Bspw. hier bei dem SEO-Foto.
Wie ich im ersten Post schon schrieb, müssen für Layout-Grafiken die @2x-Dateien manuell angelegt werden und ggf. die Klasse a2x im IMG-Tag gesetzt werden. Du musst also dein Logo semikolon_logo.jpg in der gewünschten Auflösung 225x63 haben und zusätzlich noch semikolon_logo@2x.jpg mit 450x126 Pixeln. Das Bild bindest du dann mit 225x63 Pixeln ein und retina_images sollte dafür sorgen, dass die Klasse a2x gesetzt wird. Wenn nicht, setzt du sie manuell für das Bild.
Zu deiner vorherigen Frage: Nein, ich denke nicht, dass sich retina_images mit responsitive_images verträgt. Dort werden sich die JavaScripte im Hintergrund sicherlich gegenseitig stören.
Gruß
Ah! Jetzt habe ich es verstanden! Super, vielen Dank für die Schnelle Antwort und ausführliche Erklärung!
