0
Your Cart
No products in the cart.

Sarah Gooding
The WordPress 6.4 release squad has decided to punt the planned Font Library feature to 6.5 after core maintainers found major gaps in the Font APIs that cannot be resolved in time for the upcoming release.
“I am currently reviewing the font APIs PR,” WordPress REST API co-maintainer Jonny Harris said. “I must say, I am very worried about the PR in its current state. The code simply doesn’t follow the WP core code style and doesn’t feel WordPress.” He listed a number of problems he found with the feature:
“With time very limited in this release, it feels like actioning the above, feel like it is going too hard to achieve in this release,” Harris said.
“I think this feature needs some more time to bake.”
Harris said none of the REST API maintainers were involved in the early stages of the Font Library feature and they are currently “playing catch up.” The team was attempting to patch the existing design, but Harris said if a redesign of the API is planned, he would like to understand the requirements for the feature before drawing up a design.
Punting a flagship feature is never an easy decision, but it’s far more preferable than shipping poorly designed API’s that don’t allow users to modify and disable the feature to fit their needs.
“No is temporary but yes is forever,” WordPress core committer Aaron Jorbin said. “Once the code is merged into core for release, it’s something that needs to be maintained for our extenders forever. To me, the concerns I see being raised about how people will extend the feature are enough to punt the feature.”
The Font Library feature was put forward late in the release cycle, landing in Gutenberg 16.7 last week, with very little time for testing.
“Features have landed after beta 1 in the past,” WordPress core committer Jonathan Desrosiers said. “But my preference is to not land something with this much outstanding feedback. We’d be making last minute changes and merging for public release with very little actual testing. Sure, everyone here would test as best they can. But ‘in the wild’ WordPress testing is much different and always uncovers some strange use cases or issues that we can’t foresee.”
Contributors briefly considered delaying the release date to allow the feature more time but the consensus was for punting to 6.5, with the decision anchored in WordPress’ philosophy of “deadlines are not arbitrary.”
“Changing a scheduled release date to leave room for finalizing a feature—no matter its priority—should not be considered,” WordPress core committer Joe McGill said. “This would not be the first time that we really hoped to have a feature shipped in a release but delayed it to the next release. It seems to me that a lot of effort has gone into preparing this feature for release and the consensus is that folks need more time to get it into a state that is ready to ship in a major WordPress release, which I know is disappointing, but also speaks to the care and quality folks want to ensure we put into these releases. If it’s not ready, it’s not ready. Let’s delay it — meanwhile we are still getting valuable user feedback via the Gutenberg plugin, which is a good thing.”
WordPress 6.4 release lead Josepha Haden Chomphosy made the difficult decision to punt the feature based on contributor feedback. The removal of the Font Library does not affect other key features anticipated to land in the release. Jessica Lyschik, 6.4 default theme co-lead, confirmed the Font Library isn’t a requirement for Twenty Twenty-Four. The theme will ship with preselected fonts that get loaded from the theme assets, just like previous default themes.
WordPress 6.4 Beta 3 is scheduled for October 10, 2023. This will be the last scheduled beta before RC1.
Slow the whole process down! Leave more time between WP releases, and yes, delay features until they are in good shape and ready to go. We users struggle to keep up as it is.
I honestly disagree, font management is a huge issue. The only ones that won’t this be consumer-friendly and end users like consumers be ready to manage fonts with ease, are the devs/coders. The devs/coders want everything to be complicated, so that only their theme/solution/plugin can work. They don’t want easy-of-use as that will make them redundant. WordPress will keep its marketshare and become more user friendly only if features like these become mainstream. The purpose of the CMS is to serve consumers, not devs/coders. This is not Linux, we don’t live to serve the platform, the platform live to serve the consumers! If devs/coders can make money along the way, fine, however they should not stop and hinder the progress when they feel threatened and their business models.
To me, the original post read as though the management system would be difficult to implement, without we users being able to adjust as needed—that did not sound so great. I do agree that it must be universal enough to work with all/most themes, plug-ins, etc., block and classic alike as much as possible (IDK how different block and classic are in terms of something like font management working for both; I could imagine that being difficult).
All themes/plugins have complicated solutions for font management. If managed by the core, this would make many themes/plugins obsolete and that’s what devs/coders don’t want and that’s for the interest of the end user/consumer. The consumers must be put FIRST! Otherwise Wix/Squarespace and others would eat our lunch!
I don’t know any devs that don’t font management in core. Sounds to me like you are just assuming a lot.
Having this functionality only available for Block Themes seems like it was poorly thought out from the very beginning. Functionality like this could have benefited the whole WordPress community instead of just a very small minority that are currently using Block Themes.
Don’t slow any progress and processes, closed source and read-web solutions like Wix, Squarespace & other are eating the marketshare, people jump out of the ship. WordPress must be focused on the consumers, not on coders/devs/techies. Serve the consumers! Implement redesigns, new features, make things simple & streamlined! Put the dev baggage on the backend, think for consumers FIRST!
Hmm, good point—though as one of those end users, I do find the constant updating a bit stressful, especially with a new version of WordPress—will all my plug-ins continue to work? What moved, what new stuff do I need to do now? etc. If a new feature is not fully tested—or at least as much as possible before public release—it can complicate things further.
IDK, just an amateur here, doing my best to maintain 4 WP sites.
WordPress should be focussing on ALL the community, not ignore any part of it. What you are saying is that. Let’s focus on the community and not just one small loud section.
WordPress should focus on the customer/consumer, we are not a cult to focus on self-centered to create a system in order to serve the system. The end goal of the CMS is to do the job and be the best solution on the market. If we continue that road of slowing down progress, Wix/Squarespace and other closed-sourced hosted solutions would eat our launch.
I do think we must put consumers/customers FIRST!
The feature should not be rushed to land without a clear API that can be used in visual editors other than Gutenberg.
I built my own plugin that is available on the WP repository named “Yabe Webfont”.
Enter your email address to subscribe to this blog and receive notifications of new posts by email.


WordPress Tavern is a website about all things WordPress. We cover news and events, write plugin and theme reviews, and talk about key issues within the WordPress ecosystem…
© All Rights Reserved. Powered by WordPress, hosted by Pressable

source