Pojawił się interfejs API czcionek internetowych WordPress

Podróż w kierunku interfejsu API czcionek internetowych w WordPressie była dla programistów kolejką górską. Po usunięciu z wersji WordPress 5.9 został przeniesiony do projektu Gutenberg, gdzie można go było budować wraz z powiązanymi funkcjami, które na nim opierały.

API zostało połączone z wtyczką Gutenberg i powinno trafić do wersji 12.8. Autorzy motywów, którzy chcą ją przetestować, mogą sklonować wersję deweloperską wtyczki lub pobrać wersję wieczorową z Gutenberg Times.

Jono Alderson otworzył oryginalny bilet do interfejsu API czcionek internetowych w lutym 2019 r. Jednak dopiero pod koniec 2021 r. zyskał on masę wsparcia i rozwoju. Na większości kont API wyglądało na gotowe do wysyłki z WordPress 5.9. Zostało to jednak wstrzymane przez Andrew Ozza, jednego z wiodących programistów WordPressa.

Nie była to popularna decyzja, ale być może był to najlepszy kierunek. Interfejs API był ograniczony, ponieważ nie miał jeszcze obsługi theme.json . Dostępność tylko za pośrednictwem PHP oznaczała, że ​​autorzy motywów robiliby to, co zawsze — wdrażali własne rozwiązanie. To nie była przeszkoda w jego ujawnieniu, ale prawdopodobnie będzie to najczęstszy przypadek użycia interfejsu API.

Chociaż wielu chciało, aby ta funkcja pojawiła się w WordPressie 5.9, dodatkowe miesiące dały czas na ewolucję w czystszy interfejs API, który integruje się z edytorami witryny i treści.

Autorzy motywów mogą teraz definiować definicje czcionek wraz z odpowiadającymi im rodzinami w plikach theme.json , a WordPress automatycznie załaduje niezbędny kod CSS @font-face w edytorze i na interfejsie użytkownika. Przetestowałem to dokładnie i nie napotkałem żadnych problemów.

Potencjalną wadą jest to, że funkcja jest dostarczana tylko z obsługą lokalnego dostawcy, co oznacza, że ​​czcionki muszą być dołączone do motywu. Dostawca Google Fonts był częścią pierwotnej implementacji, ale został później usunięty.

Ozz omawia dalsze szczegóły we wcześniejszym zgłoszeniu, ale jego zaleceniem było na razie porzucić obsługę czcionek Google:

Na razie dodaj obsługę tylko lokalnych czcionek. Jeśli WordPress zdecyduje się na późniejsze wsparcie dla Google CDN, implementacja będzie musiała wziąć pod uwagę przepisy i ograniczenia dotyczące prywatności w sieci i będzie powiązana z ewentualnym interfejsem API zgody użytkownika itp.

Powiązany artykuł: Właściciel strony internetowej zajmującej się grzywnami sądowymi w Niemczech za naruszenie RODO za pomocą czcionek hostowanych przez Google

Ari Stathopoulos, jeden z twórców interfejsu API czcionek internetowych, wyjaśnił, że dołączenie rozwiązania w rdzeniu, które zapisuje pliki czcionek bezpośrednio na serwerze, poprawiłoby prywatność:

Zamiast go usuwać, może moglibyśmy je odpowiednio wdrożyć, wymuszając lokalnie hostowane czcionki internetowe, aby poprawić wydajność i prywatność? W ten sposób dalibyśmy dobry przykład i zobaczylibyśmy znaczną poprawę wydajności i prywatności w ekosystemie WP, ponieważ motywy i wtyczki, które obecnie używają czcionek Google, czcionek Adobe i innych, zaczną przyjmować interfejs API.

Na razie wygląda na to, że lokalne czcionki są oficjalnie obsługiwane, ale autorzy motywów i wtyczek muszą zarejestrować niestandardowych dostawców. Jednym z obaw związanych z pominięciem obsługi czcionek Google jest to, że zamiast jednego solidnego dostawcy, na którym każdy może polegać, pojawi się wiele konkurencyjnych rozwiązań. Im więcej programistów buduje własne koła, tym bardziej prawdopodobne jest, że różne implementacje będą zawierały błędy lub problemy z bezpieczeństwem.

Automattic ma już wersję roboczą poprawki dla dostawcy Google dla Jetpack. Zakładając, że zostanie wciągnięty do wtyczki, niewątpliwie będzie to kolidować z motywem, który rejestruje własny identyfikator dostawcy google .

Tylko obsługa lokalnych czcionek może również powodować większe rozmiary pobieranych motywów. W przypadku wielu tematów nie powinno to stanowić problemu. Jeden, dwa lub trzy pakiety czcionek są rozsądne. Jeśli jednak globalne odmiany stylów staną się popularne, możemy zobaczyć motywy, które zawierają dziesiątki czcionek, które obejmują wiele gotowych projektów. To szybko doprowadzi do rozdętych plików motywów, a w połączeniu z wystarczającą liczbą obrazów autorzy motywów mogą osiągnąć limit 10 MB na przesłanie do katalogu. To trochę jak problem jutra, ale warto zacząć myśleć o tym dzisiaj.

Nadal istnieje kilka problemów, które należy rozwiązać w związku z API. Jednak przeforsowanie tego na wczesnym etapie cyklu wydawniczego WordPressa 6.0 da każdemu czas na przetestowanie i ulepszenie go.

Testowanie dołączonych czcionek

Istnieją dwie metody rejestrowania czcionek internetowych w WordPress. Dla autorów motywów najprostszym rozwiązaniem jest zdefiniowanie ich za pomocą ich plików theme.json . Jest to metoda, którą omówię poniżej, ponieważ plik jest standardem od WordPress 5.8. W bilecie żądania ściągnięcia znajduje się przykład PHP.

Klucze i wartości theme.json w większości odpowiadają regule CSS @font-face . Autorzy motywów powinni go odświeżyć, jeśli minęło trochę czasu, odkąd go używali.

Do testowania zarejestrowałem trzy czcionki internetowe za pomocą mojego motywu, a poniższy zrzut ekranu pokazuje je w akcji w edytorze:

Czcionki internetowe należy zarejestrować w pliku settings.typography.fontFamily jako część określonej definicji rodziny czcionek. Poniżej znajduje się kopia kodu, który testuję w jednym z moich motywów przy użyciu czcionki Cabin:

 { "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" ] } ] } ] } } }

Zauważ, że file:./public/fonts/*.ttf jest powiązany z folderem motywu. Autorzy motywów muszą to dostosować, aby pasowały do ​​ich struktury motywów.