Roboto (local) oder Google Fonts?

Hallo Manfred,

am zuverlässigsten lässt sich das direkt im Browser nachvollziehen, das kannst du auch selbst in zwei Minuten prüfen:

1. Öffne deine Seite im Browser, dann Rechtsklick > Seitenquelltext anzeigen (oder Strg+U), und such dort mit Strg+F nach "fonts.googleapis" oder "fonts.gstatic". Findest du einen Treffer, hast du die Bestätigung.
2. Noch zuverlässiger: Öffne die Entwicklertools (F12), Reiter Netzwerkanalyse, lade die Seite neu und filtere nach "google" oder "font". Taucht dort eine tatsächliche Verbindung zu googleapis.com oder gstatic.com auf, werden Google Fonts live nachgeladen, unabhängig davon, was in den Template-Einstellungen steht.

Die häufigsten Ursachen, falls du fündig wirst:

• Dein Cache (Joomla System-Cache, eventuell auch beim Hoster oder einem CDN) liefert noch eine alte, zwischengespeicherte Version der Seite aus, von vor der Umstellung. Einmal komplett leeren.
• Falls du mehrere Template-Stile für unterschiedliche Menüpunkte nutzt, wurde die Umstellung auf lokal vielleicht nur bei einem Stil vorgenommen, nicht bei allen. Lohnt sich, jeden Stil einzeln zu prüfen.
• Die Template-Einstellung betrifft nur die Typografie des Templates selbst. Module, Plugins oder Komponenten, zum Beispiel Slider, Kontaktformulare oder Icon-Bibliotheken wie Material Icons, binden ihre Schriftarten oft komplett unabhängig davon ein und können eigenständig Google Fonts nachladen.
• Falls noch altes, benutzerdefiniertes CSS mit einem @import url(https://fonts.googleapis.com/...) von vor der Umstellung existiert, bleibt das bestehen, bis es manuell entfernt wird.

Am besten postest du kurz, was die Netzwerkanalyse anzeigt, dann lässt sich das gezielt eingrenzen.

Zitat von bemerkenswelt

Manche meinen entdeckt zu haben, dass auf unserer Website Google Fonts benutzt werden.

Das wird angezeigt:

Also erstmal Caches leeren. Ansonsten das hier:

Vielleicht hilfreich:

Thema

Google Fonts und Fontawesome lokal einbinden

Da in letzter Zeit vermehrt Anfragen zum lokalen Einbinden von Google Fonts auftreten, habe ich diese kleine Anleitung geschrieben.



Joomla:

Zum Einbinden von Google Fonts nutzt ihr dieses Plugin:

https://github.com/JoomTools/plg_system_jtaldef

Hier bitte das aktuellste Release herunterladen:







Nicht vergessen: Plugin aktivieren und in der Reihenfolge als letztes einstellen:







Lest dazu auch die Anleitung!



Astroid-Framework:


Erstellt im folgenden Pfad den Ordner /fonts :…

Elwood

28. Oktober 2022 um 16:07

Hallo Manfred,

deine Screenshots zeigen es ziemlich eindeutig, und die Cookie-Checker liegen leider nicht falsch. Die gute Nachricht zuerst: Roboto selbst läuft sauber lokal, fonts-local_roboto.min.css und Roboto-Regular.woff2 kommen direkt von deiner eigenen Domain, deine Template-Einstellung funktioniert also wie gewünscht.

Der eigentliche Google-Fonts-Aufruf kommt von ganz woanders: In beiden Netzwerk-Mitschnitten taucht fonts.googleapis.com mit icon?family=Material+Icons auf, initiiert von accessibility.min.js. Das ist das Barrierefreiheits-Widget, das unten links auf deiner Seite als blaues Rollstuhl-Symbol zu sehen ist. Dieses Widget lädt für seine eigene Bedienoberfläche unabhängig von deinen Template-Einstellungen die Google Material Icons nach, das hat mit Roboto oder deiner Template-Konfiguration gar nichts zu tun.

Um das zu beheben, würde ich dir empfehlen, in den Einstellungen dieses Barrierefreiheits-Widgets nachzuschauen, ob sich Icons dort lokal statt über Google laden lassen. Falls das nicht angeboten wird, müsstest du entweder auf ein anderes Widget wechseln oder die Icon-Schrift selbst lokal einbinden.

Hallo Manfred,

deine Verwirrung ist total nachvollziehbar, aber so ist Joomla technisch aufgebaut: Die Template-Einstellung "Roboto (local)" steuert nur, welche Schriftart das Template selbst für seine eigene Typografie lädt. Andere Erweiterungen, wie hier das Barrierefreiheits-Widget, laufen davon komplett unabhängig und entscheiden jeweils für sich selbst, ob sie extern nachladen. Es gibt leider keinen zentralen Schalter in Joomla, der das für alle Erweiterungen gleichzeitig unterbindet.

Genau deshalb ist Elwoods Tipp mit plg_system_jtaldef hier wahrscheinlich dein bester Weg, und zwar ein deutlich verlässlicherer als die manuellen Anleitungen, an denen du bisher gescheitert bist. Das Plugin arbeitet nämlich nicht an einer einzelnen Stelle, sondern durchsucht automatisch den kompletten, fertig gerenderten Seitencode nach Google-Fonts und Font-Awesome-Aufrufen, lädt diese selbst herunter und ersetzt die Verweise dann durch lokale Kopien. Das erfasst also auch Aufrufe von Erweiterungen wie deinem Barrierefreiheits-Widget, ohne dass du dort manuell etwas umstellen musst. Installier es wie in Elwoods verlinkter Anleitung beschrieben, aktivieren nicht vergessen, und in der Plugin-Reihenfolge ganz ans Ende stellen, damit es wirklich den fertigen Seitencode zu sehen bekommt.

Brauchst du nicht. Kannst es im Plugin ändern:

Das mit dem Widget rauswerfen ist eine völlig legitime, pragmatische Lösung, wenn es dir ohnehin nicht wichtig ist.

Zu deiner Frage: Ehrlich gesagt, nein, eine hundertprozentige Garantie gibt es ohne Weiteres nicht, jede Erweiterung könnte grundsätzlich eigenständig extern nachladen. Genau deshalb bleibt jtaldef trotzdem einen Blick wert, auch unabhängig vom jetzigen Fall: Es prüft nicht eine einzelne Erweiterung, sondern den kompletten, fertig gerenderten Seitencode, egal von welcher Erweiterung er stammt, und ersetzt gefundene Google-Fonts und Fon-Awesome-Aufrufe automatisch durch lokale Kopien. Das würde dich also auch bei zukünftigen Erweiterungen absichern, ohne dass du jedes Mal einzeln nachschauen musst.

Ganz vollständig ist das aber auch nicht, jtaldef deckt gezielt Google-Fonts und Font-Awesome ab, nicht jede denkbare Art von externem Nachladen, etwa andere Tracking-Skripte. Ein gelegentlicher Blick in die Netzwerkanalyse nach dem Hinzufügen neuer Erweiterungen bleibt also weiterhin eine sinnvolle Gewohnheit. 😉

Stelle es auf 'Emojis verwenden'. Caches leeren.

Dann sollte GF nicht mehr aufgerufen werden.

Deine Überlegung mit der Standardnähe ist absolut nachvollziehbar, gerade bei einer Vereinsseite mit wechselnden Betreuern zählt das mehr als die technisch elegantere Lösung. Von daher würde ich für euren Fall auch eher zu Elwoods zweitem Vorschlag raten: Die eingebaute Umstellung auf Emojis bleibt komplett innerhalb des vorhandenen Widgets, ganz ohne zusätzliches Plugin, das passt besser zu dem Ziel, möglichst nah an der Grundausstattung zu bleiben.

Meinen jtaldef-Tipp würde ich eher als Option im Hinterkopf behalten, falls ihr später mal weitere Erweiterungen einsetzt, die selbst externe Schriften nachladen, dann greift die eingebaute Einstellung des Barrierefreiheits-Widgets natürlich nicht.

Du kannst auch ein anders Symbol lokal einbinden.

Dieses als Beispiel:

Accessibility Icon PNG and SVG Vector Free Download

Accessibility Icon PNG and SVG free use any commercial projects no attribution required.

uxwing.com

Dazu das Icon herunterladen, in z.B. /images.

Dann diesen Code in die user.css

._access-icon { background-color: #ffffff !important; color: #232946 !important; font-family: Arial !important; font-size: 0 !important; transform: none !important; content: url(/j6/images/accessibility-icon.png);  padding: 5px; }

(Pfad entsprechend anpassen).

Dann würde es so aussehen:

Zitat von bemerkenswelt

Das wäre aber schon wieder ein neuer, nicht wirklich nötiger Eintrag in der user.css

Nötig ist er schon, wenn du das Logo verändern willst.

Ich sehe da jetzt keine Probleme. Ist aber natürlich deine Entscheidung.

Wollte nur eine Lösungsmöglichkeit aufzeigen.

Zitat von bemerkenswelt

Danke.
Das wäre aber schon wieder ein neuer, nicht wirklich nötiger Eintrag in der user.css

Gerade für eine individuelle Gestaltung der Website ist doch die user.css "zuständig".

Christian

Edit: mir gefallen die Grafiken bei den Bedienhinweisen auch nicht, dafür ist es dgsvo konform.

Nur mal ein Beispiel: Bei einer meiner Seiten hat die lokale CSS-Datei mehr als 1.000 Zeilen!