Many others just copy whatever method the latest default WordPress theme happens to be using. Several have created custom scripts to ease pain points. However, many have accepted it grudgingly. That has generally been an accepted practice in the theme author community over the years. Theme authors piggyback off existing functions for enqueueing a third-party stylesheet or a custom one with rules. It’s not a good-to-have item in our wishlist, it is a requirement in order to move forward.”Ĭurrently, no standard specifically relates to web fonts in WordPress. “Not having a web fonts API is a blocker at this point. “There are many improvements in Gutenberg that are in limbo, waiting for a web fonts API,” wrote Stathopolous in the ticket. This was a small sampling of the arguments in favor of including the API in core WordPress.
#Wordpress 5.9 features code
Four lines of code if they wanted to follow current core WordPress standards, at least on the front end. Technically, theme authors could do that with a single line of code if they wanted to. The appeal of the feature is not simply loading fonts.
The first iteration of the proposed API was more about setting down a foundation to build upon in future WordPress releases. Developers could also add custom providers outside of the two defaults. On the most basic level, the web fonts API would allow developers to register and load locally-hosted fonts or those from Google Fonts. However, his primary argument hinged on the practicality of why everything in the API was necessary, stating that prior replies had been “in principle” and seemed to be based on assumptions. Ozz listed several questions around the proposal, and several developers replied to each. However, several Gutenberg proposals rely on the existence of the API, such as allowing theme authors to define web fonts via their theme.json files. Both traditional and block themes, as well as plugins, could make use of the feature today. The web fonts API is not directly related to the block system.
This would be a sort of compromise between launching as a separate feature plugin and going into WordPress 5.9. The core WordPress proposal will likely be pushed into the Gutenberg plugin for further exploration. However, he pointed out the REST API being one exception that performed well enough to get ported into WordPress. “Suggesting this be done as a feature plugin is an elegant way to delay something for a few years,” said Ari Stathopoulos, one of the developers behind the API.
#Wordpress 5.9 features install
And, the average end-user would not install something specific to developers. Developers would not rely on them in production in most cases. One of the issues with testing feature plugins for APIs is that they are not often adopted, as others noted in the ticket. Unfortunately it’s too late for this now for 5.9.” Then it would have been possible to really test it in production, verify (or reject) the assumptions that were made while creating it, and make it into a really worthy addition to WordPress. We were chatting with and he suggested that ideally this should have been a feature plugin, and I agree. However I still cannot see how this would make WordPress better in the short and long run. “It is really well documented (thanks !). “Purely as code it looks good,” he wrote in the ticket. He stated that he did not think the proposal was ready for WordPress. However, it hit a standstill in the past few days.Īndrew Ozz, a lead WordPress developer, essentially halted the possibility of the new API landing in 5.9. The pull request had over 200 in-ticket messages, 93 commits, and code approval from two core committers. In recent months, the proposal picked up speed. Jono Alderson opened a ticket for the feature in February 2019.
The feature would standardize how theme and plugin developers load fonts and lay the groundwork for future user-facing features. After what seemed like a shoo-in for WordPress 5.9, a proposed web font API was put on hold.
0 kommentar(er)
