TYPO3 und die responsiven Bilder

Programmcode

Da Mobilgeräte die immer bestimmendere Dominante in der Suchmaschinenoptimierung (SEO) sind, ist die Frage der optischen Darstellung und der damit einhergehenden Datenmenge relevant. Ein Bild, das 50 % der Breite einnimmt, ist gut geeignet, wenn der Browser 800 Pixel in der Breite aufweist. Auf einem Telefon mit kleinem Display verbraucht es jedoch zu viel Platz und die schlechte Darstellung kann sich in unzufriedenen Usern widerspiegeln.

Aufgrund eines aktuellen Kundenprojektes kam wieder die Frage nach responsiven Bildern und deren Machbarkeit auf.

Wenn es schnell gehen muss, griffen wir bisher immer zu folgender Option in Fluid:

<picture>
    <source media="(min-width: 1200px)" srcset="{f:uri.image(image: '{file}', treatIdAsReference: 'true', width: '{desktop.width}', height: '{desktop.height}')}" />
    <source media="(min-width: 768px)"  srcset="{f:uri.image(image: '{file}', treatIdAsReference: 'true', width: '{tablet.width}', height: '{tablet.height}')}" />
    <source media="(min-width: 300px)"  srcset="{f:uri.image(image: '{file}', treatIdAsReference: 'true', width: '{mobile.width}', height: '{mobile.height}')}" />
    <f:image image="{file}" width="{desktop.width}" height="{desktop.height}" />
</picture>

Das ist für den Datenverbrauch an sich ein guter Anfang, um verschiedene Auflösungen je nach Gerätetyp zur Verfügung zu stellen. Leider handelt es sich dabei immer noch um das gleiche Bild, welches immer gleich abgeschnitten wird. Daraus resultiert, dass Ausschnitte erzeugt werden, die unter Umständen essentielle Teile des Bildes wegschneiden. Das ist eher suboptimal, vor allem, weil andere CMS das augenscheinlich besser können.

Bei einem kühlen Bier haben Frank und ich darüber sinniert, was man tun kann, um wirklich responsive Bilder in TYPO3 haben zu können, das heißt, man kann pro Anzeigegerät unterschiedliche Ausschnitte des gleichen Bildes oder gar komplett andere Bilder anzeigen. Anforderungen gerade zum letzten Punkt gab es schon. Diese hatten wir dadurch gelöst, dass das entsprechende Bildelement exakt 3 Bilder in einer bestimmten Reihenfolge benötigt. Von Flexibilität keine Spur.

Das naheliegendste war, eine FileReference innerhalb der FileReference anzulegen. Technisch und theoretisch war uns klar, wie das auszusehen hat.

Wir haben dementsprechend ein neues Repository eröffnet und losgelegt. Während ich mich um die TCA-Konfiguration kümmerte, hat Frank über das Einbinden der Bilder sinniert. Unser erster Gedanke war, den FilesProcessor um einen weiteren Processor zu erweitern. Leider gibt der FilesProcessor diese Möglichkeit nicht her.

Mir kam der Gedanke, die Informationen über einen DatabaseQueryProcessor zu holen und dann in den FilesProcessor laufen zu lassen. Das klang anfangs logisch, aber auch diese Option musste verworfen werden.

Die Einbindung in die TCA verlief im Gegenzug dazu relativ reibungslos. Ich ergänzte zwei neue Datenbankfelder, eines für die Relation und eines für das CSS Media Query.

Dann erstellte ich eine neue Palette, welche ich der ImagePalette zuwies. Zur Vereinfachung habe ich alles so angepasst, dass selbst beim initialen Anlegen nur die benötigten Felder crop und media_query angezeigt werden. Die Attribute wie alternativer Text, Titel, Link und Beschreibung sind hier nicht von Nöten, da diese Informationen aus dem originalen Bild kommen.

Auch einen ersten Entwurf des möglichen Fluid habe ich erstellt. Anhand dieser Überlegungen sind wir dann auf die Lösung der Varianteneinbindung gekommen.

<picture>
    <f:for each="{file.variants}" as="variant">
        <source media="{variant.mediaWidth}" srcset="{f:uri.image(image: '{variant}', width: '', height: '')}">
    </f:for>
    <f:media alt="{file.alternative}" class="image-embed-item" file="{file}" height="{dimensions.height}" loading="{settings.media.lazyLoading}" style="width:auto;height:auto;" title="{file.title}" width="{dimensions.width}" />
</picture>

Frank hat entschieden, dass wir die FileReference systemweit überschreiben und somit die Möglichkeit bieten, selbst einzugreifen. Mit dieser Art haben wir dafür gesorgt, dass alles sauber funktioniert. Im Endresultat wurde nur eine kleine Änderung im Fluid noch vorgenommen:

<picture>
    <f:for each="{file.variants}" as="variant">
        <source media="{variant.properties.media_width}" srcset="{f:uri.image(image: '{variant}', width: '', height: '')}">
    </f:for>
    <f:media alt="{file.alternative}" class="image-embed-item" file="{file}" height="{dimensions.height}" loading="{settings.media.lazyLoading}" style="width:auto;height:auto;" title="{file.title}" width="{dimensions.width}" />
</picture>

Wir haben somit eine Möglichkeit geschaffen, über TYPO3-Bordmittel responsive Bilder einzubinden. Wenn man mehrere media_query-Varianten haben will, sind diese per pageTS-Konfiguration erweiterbar:

TCEFORM.sys_file_reference.media_width.addItems {
	(min-width: 200px): Very small device image
}

Die Extension ist wie immer hier zu finden: https://extensions.typo3.org/extension/responsive_picture

Die Dokumentation befindet sich hier:
https://docs.typo3.org/p/sudhaus7/responsive-picture/0.9/en-us/

Wir planen noch einen Modus in welchem nicht verwendete media-queries automatisch eingefügt werden, so dass man immer alle konfigurierten Varianten automatisch zur Verfügung hat.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.