Schrift von Google Fonts laden

Zunächst müssen wir wissen, welche Schriftarten (Fonts) und Auszeichnungen (fett, kursiv…) benötigt werden. Manchmal kommt jedes Schriftgewicht als einzelne Datei, häufiger ist jedoch eine Datei mit einem „Variablen Font“ das alle Schriftgewichte enthält. Manchmal kommtn die kursiven Schriften in ein einer extra Datei. Den Hinweis auf „kursiv“ erkennt ihr meist am Zusatz „italic“ im Dateinamen. Diese Schriften laden wir dann bei Google Fonts wie folgt herunter:

Geht auf https://fonts.google.com/ und tippt euere Schrift in das Suchfeld ein, Klickt die entspechende Schrift und und klickt oben auf „Download Family“. Ein Beispiel für Open Sans seht ihr im Bild. Rechts braucht ihr nichts auszuwählen oder kopieren. Wir brachen nur die Datei(en) aus dem Download, der nach dem Klick auf „Download Familiy“ erfolgt sein sollte.

Die .Zip wird ausgepackt und wir haben jetzt so eine Struktur (siehe Bild)

Wollen wir also „Open Sans“ verwenden genügen uns die beiden .ttf Dateien. Die eine ist für alle regulären (geraden) Schriftgewichte (von dünn bis extrafett) und die mit dem „italic“ im Dateinamen enthält alle Schriftgewichte noch mal in kursiv. (Theoretisch kann der Browser auch aus einer regulären Schrift ein kursive Schrift machen, lass das aber nicht deinen Grafiker hören. Das sieht dann nämlich nur kursiv aus, ist aber nicht das was der Schriftdesigner sich unter kursiv vorgestellt hat.)

WordPress auf die Schriftdatei vorbereiten

Von Haus aus kennt WordPress eine Reihe von Dateitypen anhand der Dateiendungen. Alles andere lässt WordPress dich aus „Sicherheitsgründen“ nicht hochladen. Ein Versuch über „Medien“ und „Datei hochladen“ würde genauso scheitern wie der Versuch schon jetzt im Divi-Builder die Schrift einzubinden. Die Fehlermeldung „Du bist leider nicht berechtigt, diesen Dateityp hochzuladen.“ erscheint in diesem Fall.

Wir müssen also WordPress beibringen, dass eine .ttf Datei nicht gefährlich und sogar gewünscht ist. Dazu nutzte ich ein Plugin „WP Add Mime Type“ https://de.wordpress.org/plugins/wp-add-mime-types/ Mit „Mime Types“ wird beschrieben welche Dateiendung welchen Dateityp bedeutet. Einmal installiert und aktiviert haben wir jetzt unter „Einstellungen“ /  „Mime type Settings“ unser Tool. Oben stehen schon einige Mime-Types die WordPress bereits kennt und ganz unten ist ein großes Eingeabefeld „Add Values“. Hier gebe ich immer ttf = font/ttf  ein und drücke unten auf „save“.  Die „Security Options“ über dem Eingabefeld habe ich so gelassen wie sie waren, sonst gibt es doch noch Probleme z. B. beim Upload. Bei mir sind alle Haken aus. Ist das erledigt kann mit dem Hochladen der Schriften begonnen werden. Das Plugin muss so lange aktiviert bleiben, bis alle Schriften hochgeladen wurden.

Hochladen der Schriften (Google Fonts) in DIVI

Jetzt gehen wir auf eine beliebige Divi-Seite die einen Textblock enthält und aktivieren den Divi-Editor (Divi-Builder). Danach gehen wir in die Einstellungen des Textblocks (=Zahnrad-Symbol) und dort auf den Tab „Design“. Hier im Bereich „Text“ auf „Schriftart“ klicken – die Schriftauswahl erscheint als Dropdown. Nun klicken wir auf den Button „Hochladen“ der in der Auswahlbox angezeigt wird. (siehe Bilder).   

In der Dropdown Box auf den Button „Hochladen“ klicken.

Jetzt erscheint diese Dialogbox „Hochladen Schriftart“ Lasst euch von der wirren Übersetzung nicht irritieren, hoffentlich kommt hiee bald mal eine Korrektur.

Oben in das Feld gehört jetzt der Schriftname hinein. Ich ergänze hier um „Regular“ um es von den Kursivschriftarten abzugrenzen. Ausserdem schreibe ich „lokal“ dahinter. Das in zwar unkonventionell, aber ich sehe dann immer gleich woran ich bin. Danach auf den Button „Datei auswählen“ drücken und die .ttf-Datei (nicht die .zip) hochladen. 

Es sieht zwar anders aus, aber das System lasst nur eine Datei zu. Falls ihr keine variable Schriftdatei habt, müsst ihr den Prozess mit jeder Schrift wiederholen. Für diesen Fall gibt es unten die Checkbox „Alle“, die dann – sobald man den Haken entfernt – umschaltet und die Checkboxen für die einelnen Schriftgewichte (Fontweight) freigibt. 

Der Text den ihr oben eingebt, dient dazu später den richtigen Font auszuwählen. Kryptische Bezeichnungen, die ihr euch nicht merken könnt helfen hier nicht weiter. Jetzt ist nur noch wichtig auf „Hochladen“ zu drücken – das wars. Wir wiederholen das mit der Fontdatei für kursive Schrift oder mit allen Einzelfonts.

Einschub aus der Praxis: DIVI Google Fonts lokal einbinden

Kleiner Einschub aus meiner Praxis: Ich habe festgestellt, dass manchmal bei den variablen Fontdateien ich die einzelnen Schriftgewichte nicht vernünftig ansteuern kann. Also mit dem Wahlkonopf „fett, normal, dünn…“ der unter der gewählten Schriftart steht. Der Support konnte das bisher nicht vernünftig beantworten. Wenn ihr den Fall auch haben solltet: Ich lade in dem Fall dann doch noch die einzelnen Schriftgewichte-Dateien hoch – die sind in der geladenen Schrift – Zipdatei meist im Unterordner „static“.

Lokalen eingebundenen Google Font auswählen

So, das Hochladen wäre erledigt. Jetzt gibt es zwei Optionen. 

1. Will ich Schiften eher automatisch und allgemein vergeben, wählen wir in allen Textboxen – so auch hier – nur „Default“ als Schrift aus. Die Schrift wird dann von der Voreinstellung im Customzier übernommen. (ich erkläre gleich wie das geht). Nachdem auf der Seite alle Texte auf „Default“ stehen, bitte speichern und den Editor verlassen.
2. Will ich jede Textbox einzeln mit dem passenden Font versehen, dann bitte jetzt in allen Textblöcken die jeweils gewünschte Schriftart aus den eben hochgeladenen auswählen. Jetzt speichern und den Builder verlassen.

Abschließend für beide Schritte im Theme Cusomizer die lokalen Schriftarten voreinstellen. Dort stellen wir unter „Allgemeine Einstellungen“ / „Typografie“ je eine Schriftart für Überschriften (=Kopfzeile) und die Schriftart den ganzen Rest (=Hauptschriftart) aus. Jetzt klicken wir oben auf „Veröffentlichen“ und verlassen den Customzier über das „X“ oben links. 

Google Fonts deaktivieren

Ist das erledigt, können wir Google Fonts grundsätzlich abschalten. Das machen wir im Menü „Divi / Theme-Optionen“ im ersten Reiter „Allgemeines“ finden wir den Schalter „Google Schriftarten verwenden“ den wir ausschalten. (Der Screenshot zeigt den ausgeschalteten Zustand)

Ab sofort sind keine externen Google Fonts mehr verfügbar, wenn wir Schriften in den Designeinstellungen auswählen. Technisch läuft das Divi-Theme jetzt auf lokalen Fonts, also so wie wir uns das für den Datenschutz wünschen. Es ist aber ratsam, alle Seiten noch mal zu prüfen, und zu schauen, wo jetzt eine Schrift nicht wie gewünscht aussieht. Dort haben wir ggf. noch eine falsche Schrift eingestellt.

Viel Erfolg mit euerer Webseite. Fragen und Anregungen einfach in die Kommentare schreiben.

Über mich 

Ich bin Günther A. Biebl und gebe WordPress-Seminare, erstelle Webseiten und unterstütze euch gerne mit euerer WordPress Webseite. Bei Fragen einfach melden.

Der Beitrag Google Fonts im Divi Theme lokal einbinden erschien zuerst auf Collaborato Training.

Damit das Problem nicht offensichtlich vor allen Besuchern der Webseite passiert, wäre es klasse, solche Probleme frühzeitig zu erkennen und Ausfälle zu vermeiden, richtig? Es gibt ja schon seit gut zwei Jahren die Funktion „Website-Zustand“ in WordPress die uns zu Updates, entfernen nicht genutzter Plugins und Themes, update der PHP-Version und dergleichen ermahnt. (Im Backend unter dem Menüpunkt „Werkzeuge“ zu finden) Das ist natürlich eine gute Sache. Aber es gibt da noch ein System das nicht so offensichtlich ist: Fehlermeldungen bzw. Warnungen des Browsers oder Webservers. 

Offensichtliche und verdeckte Probleme

Manche Probleme auf der Webseite sind offensichtlich – da stimmt was nicht, da sieht was komisch aus oder da ist eine Funktion kaputt, klar. Da hilft häufig ein Blick in die Fehlerconsole des Browsers. (Ich spreche nicht von 404 oder 500er-Fehlermeldungen im Browser, sondern „niedrigschwelligeren“ Meldungen.) In Chrome oder Firefox am Desktop ist das einfach: Rechte Maustaste im Browserfenster drücken, „Untersuchen“ anklicken und auf den Reiter „Console“ gehen. Jetzt die Seite neu laden oder den fraglichen Prozess auf der Seite durchführen und es sollte eine verwertbares Ergebnis kommen: Eine Fehlermeldung oder eine Warnung. (Dabei ist der Eintrag in Chrome: „DevTools failed to load source map“ zu ignorieren, der kommt so gut wie immer.)

Soweit, so gut. Aber was ist jetzt, wenn ein Fehler auftritt, wenn ich gar nicht dabei bin? Ein Nutzer ein Formular ausfüllt und im Prinzip zwar alles läuft, aber im Hintergrund ein paar „rote Fahnen“ gehisst werden, die sagen sollen, dass hier was nicht ganz korrekt ist? Es wäre doch gut, das früh zu erkennen, noch bevor wichtige Daten verloren gehen oder Funktionen unbrauchbar werden. In meinem Beispiel (unten) wären das Anmeldedaten für meinen Newsletter oder sogar die Anmeldung für meine WordPress Seminare.

WordPress Ausfall vermeiden: Logfiles auswerten

Für solche Fälle gibt es in der IT die Logfiles. Das sind separate Dateien, in die die Software alle Meldungen des laufenden Prozesses schreibt. Natürlich macht es keinen Sinn, diese Meldungen jedem Besucher der Webseite um die Ohren zu hauen und wirre Meldungen auszuspucken. Das ist der Grund warum ein normaler Besucher üblicherweise von so etwas verschont bleibt. Im Standardfall ist die Logfile-Generierung in WordPress sogar deaktiviert.

Es gibt die Möglichkeit, das reine generieren des Logfiles direkt in der wp-config.php zu aktivieren und dort eine Datei für die Speicherung anzugeben. Das hat den Nachteil, dass ich in diese Datei auch gelegentlich reinschauen muss. Ich weiss nicht wie das bei Euch ist, aber ich würde das vergessen. Ich bin ja meistens im Backend unterwegs und nicht auf Dateiebene.

Lösung per Plugin „Error Log Monitor“

Die Lösung dafür ist ein Plugin: „Error Log Monitor“ von Janis Elsts (https://de.wordpress.org/plugins/error-log-monitor/). Nach der Installation und Aktivierung, mochte es mich für Newsletter und Tracking gewinnen, was ich mit „Skip“ überspringen kann, oder per „Allow & Continue“ erlaube.

Danach befinden wir uns in der Liste der aktivierten Plugins und werden oben aber darauf hingewiesen, dass wir das Error Log Monitor Plugin noch konfigurieren müssen. Um es einfach zu haben, hier auf „Use Recommended Settings“ drücken. (Über „Manual Configuration“ gibt es mehr Einstellmöglichkeiten. Unter anderem kann man einstellen, wo das Logfile auf dem Server liegen soll. Das ist aus Sicherheitsgründen gar nicht schlecht, ich bleibe hier aber bei der einfachen Lösung. Die Anleitung liefert das Plugin auf englisch mit sobald man auf den Knopf drückt. Und: Falls Ihr jetzt „Recommended“ gedrückt habe und zu „Manual“ wollt: Einfach im Backend noch mal auf den Menüpunkt „Plugins“ klicken)

Etwas Code dann doch

Nach dem Klick auf „Use Recommended Settings“ fordert es den Nutzer auf, ein paar Zeilen Code in die wp-config.php einzutragen und ggf. einen Eintrag anzupassen. Das geht am besten über einen FTP-Zugang. (Web-FTP im Backend des Providers oder z.B. die kostenlose Software „Filezilla“ mit den Zugangsdaten des Providers. (Aus Sicherheitsgründen empfehle ich euch bevor es weitergeht, ein Backup anzulegen – Veränderungen im Dateisystem können euer WordPress lahm legen und wir wollen ja Ausfälle vermeiden. Ein Option ist hier beschrieben: Backup per Updraft Plus)

Seid ihr per FTP eingeloggt, navigiert in das WordPress-Hauptverzeichnis, kopiert euch die wp-config.php auf den lokalen Computer (Bei Filezilla wird die Datei von der Server-Seite auf die andere mit dem lokalen Dateisystem gezogen.) Legt bitte zusätzlich eine Backup-Kopie der wp-config.php an, die unberührt bleibt, sollte was sein (Ausser ihr habt jetzt tatsächlich ein Backup, dann wäre das doppelt 😊). Jetzt öffnet ihr die lokale Datei in einem geeigneten* Editor. 

Bearbeiten der wp-config.php

*Mit „geeignet“ ist keinesfalls Word oder ähnliches gemeint. Gemeint ist ein reiner Text-Editor oder auch ein Code-Editor. Also: MS-Editor (=Notepad unter Windows) oder Textedit (auf Mac). Oder wahlweise als Extraprogramme zum kostenlosen download: BB-Edit (Mac) oder Notepad++ (Windows). Jetzt kopiert Ihr den Code, den das Plugin vorsieht, an das Ende der Datei und speichert die veränderte Datei ab.

Eine Leerzeile darüber ist OK, dann wird es übersichtlicher. Für den Fall dass euch Fehlermeldungen und Warnungen nicht reichen, kann auch noch die Zeile „define( ‚WP_DEBUG‘, false );“ auf define( ‚WP_DEBUG‘, true ); gesetzt werden. Dann wird das Log aber schnell voll. Das macht für mich nur Sinn, wenn ich grade auf der Suche nach einem Fehler bin – für meine Frühwarnfunktion lasse ich das aber aus, also auf „false“. Sonst bekomme ich so viele Meldungen, dass die wirklichen Fehler unter den Meldungen begraben werden, befürchte ich. (Obwohl ich grade sehe, dass bei den Konfigurations-Einstellungen es eine Filteroption gibt, falls ihr die testet, lasst mir einen Kommentar da.)

Bitte keine weiteren Änderungen ohne Knowhow vornehmen – hier reagiert WordPress empfindlich. Danach wird die wp-config.php wieder hochgeladen und damit die bestehende Datei überschrieben und im Plugin (WordPress-Backend) der Vorgang bestätigt. (Button „Done“ anklicken“)

Hat alles geklappt, nimmt das Programm seine Arbeit auf. Es ist gibt jetzt eine neue Anzeige auf der Backend-Seite “Dashboard“ die zunächst leer ist – und idealerweise leer bleibt. Weitere Konfigurationen können über dieses Dashboard-Widget vorgenommen werden. Dazu mit der Maus über die Kopfzeile des Widgets fahren und „Konfigurieren“ anklicken.

Es gibt eine Funktion sich die Einträge über Mail senden zu lassen – die bei mir aber nicht funktioniert.

Meine Erfahrung damit: Es wurde beim Test recht schnell klar, dass das Plugin, das die Mailadresse über das Anmeldeformular für Seminare an die Newsletter-Software weitergibt ein Problem hat. Und das, obwohl alles (noch) sauber ankommt und funktioniert. Um welches Modul es sich handelt, war an dem Pfad zur problematischen Datei zu erkennen der in der Fehlermeldung angegeben ist. Daraufhin habe ich auch gesehen, dass für das Plugin seit 1 Jahr kein Update mehr herausgebracht wurde. Einen Fehlerreport habe ich an den Autor über die Plugin-Support-Seite auf WordPress.org zwar gesendet, dort gibt es aber seit einiger Zeit kaum noch Rückmeldungen. Sprich: Früher oder später muss ich das Plugin ersetzen. Was sich gut trifft, denn ich wollte ja ohnehin ein Veranstaltungsplugin ausprobieren.

Letzte Worte zum Thema „Sicherheit“: Neben diesem Tool gibt es zusätzlich für Sicherheitslücken das sehr gute Sicherheitsplugin „iThemes Security“ das Sicherheitslücken frühzeitig anzeigt und inzwischen auch in der kostenlosen Version einen automatischen Scan auf und 2-Faktor Anmeldung anbietet.

Über mich

Ich bin Günther A. Biebl und gebe WordPress-Seminare und unterstütze Unternehmen dabei Ihre WordPress Webseite selbst zu erstellen und eigenständig zu publizieren. Bei Fragen einfach melden.

Headerbild: von Rudy and Peter Skitterians auf Pixabay

Der Beitrag WordPress Ausfälle vermeiden – ein Frühwarnsystem erschien zuerst auf Collaborato Training.

Meine Meinung – keine Rechtsberatung – ist: Wenn keine persönlichen Daten (dazu gehört die IP-Adresse) der Besucher aufgezeichnet werden und auch kein Cookie gesetzt wird, gibt es hier keine Notwendigkeit per Popup darauf hinzuweisen. Alles was man macht, ist zu zählen wie oft die Webseiten an (anonyme) Besucher ausgeliefert werden.

Bisher habe ich als WordPress Besucherstatistik-Tool Statify empfohlen. Das Plugin ist recht simpel, kann aber auch (zu) wenig. Über das Tool von Verona Labs habe ich auch schon gesprochen – das ist aber etwas zu neugierig. Für den Fall gibt es jetzt Koko Analytics. Die Statistik ist fundierter und man kann auf einzelne Tage herunter brechen. Der Nachteil, wenn man ohne Cookies trackt ist, dass man „wiederkehrende Besucher“ nicht erfassen kann. Das System kann sich ja die Besucher dann nicht merken.

Die Installation und Konfiguration ist supersimpel (Bild unten, klicken vergrößert das Bild):

Oben erstmal die eigenen Nutzerrollen ausschließen. Das ist wichtig, sonst zählt man sich immer selbst mit. Cookies ausschalten, klar. Dann noch Berichtszeitraum einstellen und ab wann gelöscht wird – 30 Monate sollten reichen.

Ab sofort finden sich dann die WordPress Besucherstatistik unter „Einstellungen / Analytics“. Probiert es einfach mal aus. Neben den Überblick über Besucher und Seitenaufrufe gibt es auch eine Übersicht über die Anzahl der einzelnen Seitenaufrufe. Auch die Herkunft der Besucher wird unter „Verweise“ angegeben.

Viel Erfolg!

Headerfoto: Lukas via Pexels

Der Beitrag WordPress Besucherstatistik mit Koko Analytics – ohne Popup und Cookies erschien zuerst auf Collaborato Training.