WordPress 6.4's Font Library feature has been postponed to the 6.5 release. Users can expect to see this new feature in the upcoming update.
The core maintainers of WordPress 6.4 have discovered significant gaps in the Font APIs that cannot be fixed in time for the next release, hence the release team has chosen to push back the planned Font Library feature to WordPress 6.5.
Jonny Harris, a co-maintainer of the WordPress REST API, stated that he is now reviewing the typeface APIs PR. I have to admit that given the PR's current situation, I am somewhat concerned. The code just doesn't feel like WordPress and doesn't adhere to the WP core coding style. He enumerated some issues he discovered with the feature:
According to WordPress core committer Aaron Jorbin, "yes is forever, but no is temporary." The code must be continuously maintained for our extenders after it is integrated into core for release. The concerns I see expressed over how users would expand the feature, in my opinion, are sufficient to terminate it.
WordPress core committer Jonathan Desrosiers stated that features have already been released after beta 1. However, I would prefer not to land something that receives this much positive response. With less actual testing, we would be making last-minute adjustments and merging for public release. Yes, everyone in this room would do their best to test. However, WordPress testing in the real world is very different and frequently reveals peculiar use cases or problems that we weren't able to anticipate.
WordPress core committer Joe McGill stated that rescheduling a release date to accommodate the completion of a feature, regardless of its priority, should not be taken into consideration. We had previously really wanted to ship a feature in a release, but we had to postpone it until the following release. Although it is disappointing, it also shows how much care and attention to detail people want to make sure we put into these releases. It seems to me that a lot of work has gone into getting this feature ready for release, and the general consensus is that people need more time to get it into a state that is ready to ship in a major WordPress release. It isn't ready if it isn't. Let's postpone that for now.
Lead for the release of WordPress 6.4 Based on contributions, Josepha Haden Chomphosy took the tough choice to punt the feature. Other significant features that are planned for the release are unaffected by the Font Library's absence. Jessica Lyschik, co-lead of the 6.4 default theme, verified that Twenty Twenty-Four does not require the Font Library. As with previous default themes, the theme comes with pre-selected fonts that load from the theme assets.
October 10, 2023 is when WordPress 6.4 Beta 3 is expected to launch. Before RC1, this will be the final beta that is scheduled.
Since font management is such a problem, I sincerely disagree. Developers and programmers are the only ones who won't find this user-friendly and end users capable of easily managing fonts. The developers/coders want everything to be intricate so that their theme, plugin, or solution is the only one that functions. They oppose ease of use because they believe it will render them obsolete. Only until capabilities like this become commonplace will WordPress maintain its market dominance and grow more user-friendly. The CMS is designed to help users, not developers or programmers. This isn't Linux; the platform exists to service the users, not the other way around! Developers and programmers should not halt and obstruct progress when they feel threatened; if they can profit along the way, that's great.
The original message gave me the impression that the management system would be challenging to use and that we users would not be able to make necessary adjustments. That did not sound very good. I agree that it needs to be sufficiently universal to function with the majority of themes, plug-ins, and other programs, both block and classic, to the greatest extent feasible (I'm not sure how different block and classic are in terms of font management working for both; I could picture it being problematic).
WordPress ought to concentrate on the entire community rather than just a portion of it. That's what you're saying. Let's keep the community in mind rather than simply one boisterous group.
WordPress should have the customer/consumer at its center; we are not a religion that prioritizes self-interest in building a system that serves the system. The CMS wants to be the best available option and complete the task at hand. Our launch would be stifled by Wix/Squarespace and other hosted alternatives that are closed-sourced if we keep going down that path.
0 Comments