Die WordPress-Webfonts-API ist da

Der Weg zu einer Webfonts-API in WordPress war für Entwickler eine Achterbahn der Gefühle. Nachdem es von der WordPress 5.9-Version entfernt wurde, wurde es in das Gutenberg-Projekt verschoben, wo es zusammen mit verwandten Funktionen erstellt werden konnte, die darauf angewiesen waren.

Die API wurde in das Gutenberg-Plugin integriert und sollte in Version 12.8 landen. Themenautoren, die es testen möchten, können die Dev-Version des Plugins klonen oder die nächtliche Version von Gutenberg Times herunterladen.

Jono Alderson eröffnete im Februar 2019 das ursprüngliche Ticket für eine Webfonts-API. Es dauerte jedoch bis Ende 2021, bis es eine Menge Unterstützung und Entwicklung erhielt. Nach den meisten Berichten sah die API bereit aus, um mit WordPress 5.9 ausgeliefert zu werden. Es wurde jedoch von Andrew Ozz, einem der führenden WordPress-Entwickler, auf Eis gelegt.

Es war keine populäre Entscheidung, aber es war vielleicht die beste Richtung. Die API war eingeschränkt, da sie noch keine theme.json Unterstützung hatte. Nur über PHP verfügbar zu sein, bedeutete, dass Theme-Autoren meistens das getan hätten, was sie immer getan haben – ihre eigene Lösung einzuführen. Dies war nicht der Hinderungsgrund für die Enthüllung, aber es wird wahrscheinlich der häufigste Anwendungsfall der API sein.

Während viele wollten, dass dieses Feature in WordPress 5.9 landet, haben die zusätzlichen Monate Zeit gegeben, sich zu einer saubereren API zu entwickeln, die sich in die Website- und Inhaltseditoren integriert.

Theme-Autoren können jetzt Schriftartdefinitionen zusammen mit ihren entsprechenden Familien in theme.json Dateien definieren, und WordPress lädt automatisch das erforderliche @font-face CSS im Editor und im Frontend. Ich habe das ausgiebig getestet und bin auf keine Probleme gestoßen.

Der potenzielle Nachteil ist, dass die Funktion nur mit Unterstützung für einen lokalen Anbieter geliefert wird, was bedeutet, dass Schriftarten mit dem Thema gebündelt werden müssen. Ein Google Fonts-Anbieter war Teil der ursprünglichen Implementierung, wurde aber später entfernt.

Ozz geht in einem früheren Ticket auf weitere Details ein, aber seine Empfehlung war, die Unterstützung von Google Fonts vorerst einzustellen:

Fügen Sie vorerst nur Unterstützung für lokale Schriftarten hinzu. Wenn WordPress beschließt, später Unterstützung für das Google CDN einzubeziehen, muss die Implementierung Web-Datenschutzgesetze und -beschränkungen berücksichtigen und mit einer eventuellen User Consent API usw. verknüpft werden.

In Verbindung stehender Artikel: Deutsches Gericht verhängt Geldstrafe für Website-Besitzer wegen Verstoßes gegen die DSGVO durch Verwendung von von Google gehosteten Schriftarten

Ari Stathopoulos, einer der Entwickler hinter der Webfonts-API, erklärte, dass das Bündeln einer Lösung im Kern, die die Fontdateien direkt auf den Server schreibt, die Privatsphäre verbessern würde:

Anstatt sie zu entfernen, könnten wir sie vielleicht richtig implementieren und lokal gehostete Webfonts erzwingen, um die Leistung und den Datenschutz zu verbessern? Auf diese Weise würden wir mit gutem Beispiel vorangehen und eine deutliche Verbesserung der Leistung und des Datenschutzes im WP-Ökosystem sehen, da Themen und Plugins, die derzeit Google-Schriftarten, Adobe-Schriftarten und so weiter verwenden, damit beginnen werden, die API zu übernehmen.

Im Moment sieht es so aus, als würden lokale Schriftarten offiziell unterstützt, aber Autoren von Designs und Plugins müssen benutzerdefinierte Anbieter registrieren. Eine Befürchtung beim Weglassen der Google Fonts-Unterstützung ist, dass es viele konkurrierende Lösungen in freier Wildbahn gibt, anstatt einen soliden Anbieter, auf den sich alle verlassen können. Je mehr Entwickler ihre eigenen Räder bauen, desto wahrscheinlicher werden unterschiedliche Implementierungen mit Fehlern oder Sicherheitsproblemen ausgeliefert.

Automattic hat bereits einen Draft-Patch für einen Google-Anbieter für Jetpack. Angenommen, das wird in das Plugin gezogen, wird es zweifellos mit einem Thema in der Zukunft kollidieren, das seine eigene google -Anbieter-ID registriert.

Nur die Unterstützung lokaler Schriftarten könnte auch zu größeren Theme-Download-Größen führen. Für viele Themen sollte dies kein Problem sein. Ein, zwei oder drei Schriftpakete sind sinnvoll. Wenn jedoch globale Stilvariationen populär werden, könnten wir Themen sehen, die Dutzende von Schriftarten liefern, um mehrere vorgefertigte Designs abzudecken. Das führt schnell zu aufgeblähten Themendateien, und in Kombination mit genügend Bildern können Themenautoren die 10-MB-Grenze für die Übermittlung an das Verzeichnis erreichen. Das fühlt sich ein bisschen wie das Problem von morgen an, aber es ist etwas, woran man schon heute denken sollte.

Es gibt noch einige Probleme, die rund um die API gelöst werden müssen. Wenn Sie es jedoch so früh im Veröffentlichungszyklus von WordPress 6.0 durchziehen, haben alle Zeit, es zu testen und zu verbessern.

Testen von gebündelten Schriftarten

Es gibt zwei Methoden zum Registrieren von Webfonts bei WordPress. Für Themenautoren besteht die einfachste Lösung darin, sie über ihre theme.json Dateien zu definieren. Dies ist die Methode, die ich im Folgenden behandeln werde, da die Datei seit WordPress 5.8 Standard ist. Es gibt ein PHP-Beispiel im Pull-Request-Ticket.

Die theme.json Schlüssel und -Werte entsprechen größtenteils der CSS- @font-face Regel. Themenautoren sollten es auffrischen, wenn es eine Weile her ist, seit sie es verwendet haben.

Zum Testen habe ich drei Webfonts über mein Design registriert, und der folgende Screenshot zeigt sie in Aktion im Editor:

Webschriften sollten unter settings.typography.fontFamily als Teil einer bestimmten Schriftfamiliendefinition registriert werden. Das Folgende ist eine Kopie des Codes, den ich in einem meiner Themen mit der Cabin-Schriftart teste:

 { "settings": { "typography": { "fontFamilies": [ { "fontFamily": "\"Cabin\", sans-serif", "slug": "primary", "name": "Primary", "fontFace": [ { "fontFamily": "Cabin", "fontWeight": "400 700", "fontStyle": "normal", "src": [ "file:./public/fonts/cabin/Cabin-VariableFont_wdth,wght.ttf" ] }, { "fontFamily": "Cabin", "fontWeight": "400 700", "fontStyle": "italic", "src": [ "file:./public/fonts/cabin/Cabin-Italic-VariableFont_wdth,wght.ttf" ] } ] } ] } } }

Beachten Sie, dass file:./public/fonts/*.ttf relativ zum Themenordner ist. Theme-Autoren müssen dies an ihre Theme-Struktur anpassen.