The WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
Found a bugbugA bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.?Create a ticket in the bug tracker.
The theme.jsonJSONJSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. version is incremented whenever a breaking change would need to be made to the APIAPIAn API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways.. This allows consumers to opt-in to the breaking change by updating the version. Older theme.json versions will always be supported in the latest versions of WordPress.
Updating to version 3 is recommended when your minimum supported WordPress version reaches 6.6. See theme.json version 3 frequently asked questions for more information on when to update. Then check out the theme.json reference for migrationMigrationMoving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. instructions when you are ready to update.
Breaking changes in version 3
Starting with theme.json version 3 the default behavior for using the same slugs as the default fontSizes and spacingSizes presets has been changed to match how other theme.json presets work: from always overriding the default presets to requiring defaultFontSizes or defaultSpacingSizes to be false in order to override the default presets.
Default font sizes
settings.typography.defaultFontSizes is a new option in theme.json v3. It controls whether the coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. provided default settings.typography.fontSizes presets are shown and used.
The default fontSizes presets’ slugs are: small, medium, large, and x-large.
When defaultFontSizes is true it will show the default font sizes in the editor and prevent the theme from creating presets using the default slugs.
When defaultFontSizes is false it will hide the default font sizes in the editor and allow the theme to use the default slugs.
For blockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. themes defaultFontSizes is true by default. This is consistent with how other default* options work such as settings.color.defaultPalette.
For classic themes there is a new theme support default-font-sizes which is also true by default. However, unlike block themes, it is set to false when editor-font-sizes theme support is defined.
In theme.json v2, the default font sizes were only shown when theme sizes were not defined. A theme providing font sizes with the same slugs as the defaults would always override the defaults.
To keep behavior similar to v2 with a v3 theme.json:
If you do not have any fontSizes defined, defaultFontSizes can be left out or set to true.
If you have some fontSizes defined, set defaultFontSizes to false.
settings.spacing.defaultSpacingSizes is a new option in theme.json v3. It controls whether the core provided default settings.spacing.spacingSizes presets are shown and used.
The default spacingSizes presets’ slugs are: 20, 30, 40, 50, 60, 70, and 80.
When defaultSpacingSizes is true it will show the default spacing sizes in the editor and prevent the theme from creating presets using the default slugs.
When defaultSpacingSizes is false it will hide the default spacing sizes in the editor and allow the theme to use the default slugs.
defaultSpacingSizes is true by default. This is consistent with how other default* options work such as settings.color.defaultPalette.
For classic themes there is a new theme support default-spacing-sizes which is also true by default. However, unlike block themes, it is set to false when editor-spacing-sizes theme support is defined.
In theme.json v2, the default spacing sizes were only shown when theme sizes were not defined. A theme providing spacing sizes with the same slugs as the defaults would always override the defaults.
Furthermore, there are two settings that can be used to set theme level spacing sizes: spacingSizes and spacingScale. With theme.json v3, presets from both will be merged together and sorted numerically by slug. Presets defined in spacingSizes will override those generated by spacingScale if the slugs match.
In theme.json v2, setting both spacingSizesandspacingScale would only use the values from spacingSizes.
To keep behavior similar to v2 with a v3 theme.json:
If you do not have any spacingSizes presets or spacingScale config defined, defaultSpacingSizes can be left out or set to true.
If you disabled default spacing sizes by setting spacingScale to { "steps": 0 }, remove the spacingScale config and set defaultSpacingSizes to false.
If you defined only one of either spacingScale or spacingSizes for your presets, set defaultSpacingSizes to false.
If you defined both spacingScale and spacingSizes, remove the spacingSizes config and set defaultSpacingSizes to false.
WordPress 6.6 includes some changes affecting both the social link and social links blocks.
HTMLHTMLHyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. changes when using a social linksblockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. inside a Navigation Block
As of WordPress 6.6, the social links block will be wrapped in a list item (litagtagA directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.)) when used in the navigation block. This change fixed an issue where the navigation block produced invalidinvalidA resolution on the bug tracker (and generally common in software development, sometimes also notabug) that indicates the ticket is not a bug, is a support request, or is generally invalid. HTML (the social links block’s ul was nested directly under the navigation block’s ul).
This may affect some themes that depend on the exact nesting of the HTML elements, for example using a selector like .wp-block-navigation__container > .wp-block-social-links.
Here are some examples of how the HTML has changed:
Example of navigation block and social links markup before WordPress 6.6
As of WordPress 6.6, the social link block will no longer output the components-button class name on its button element within the block editor.
Themes targeting this class name for editor styles should use the existing wp-block-social-link-anchor class instead.
It’s expected that most themes will be doing this already, so for most no change will be required.
Why was this class name present?
The class name was a side-effect of using the ButtonReactReactReact is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/. component from the @wordpress/components package (which can also be referenced as wp.components.Button) within the social link block’s implementation.
Why is this being changed?
The components from @wordpress/components are intended for use in the editor’s general interface and have a lot of opinionated CSSCSSCascading Style Sheets., while the on-canvas part of a block is intended to be styled by a theme and should have minimal CSS.
Updates made to styles in the @wordpress/components can have unintended side-effects for the block’s appearance, and can also raise or lower the specificity of the styles above or below what a theme implementer might expect. The change to the block’s implementation leads to more stable and predictable css specificity.
There’s no guarantee the styles from @wordpress/components will continue to work in the iframed editor canvas, some CSS variable references in the styles were already not working as expected.
The styles that were previously added to the social link block contravene the CSS guidelines used by developers on the WordPress project.
WordPress automatically loads multiple options with a single query on each page request in order to be more efficient—a technique called “autoloading”. Prior to [57920], developers could control whether their option should be autoloaded by passing either "yes"/true or "no"/false to the third parameter of add_option() or update_option(). However, the decision to make that parameter optional, with a default value of "yes" has led to many options being loaded on every page unnecessarily (see #42441).
Autoloading a large amount of data that is not used negatively impacts website performance, particularly when an option containing a large amount of data is not used.
[57920] introduces several changes to the Options APIAPIAn API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. to optimize autoloading behavior.
Changes to the options API
To support this optimization for autoloading behavior, and to create a way to apply further optimizations going forward, the following changes to the Options API have been made.
New default $autoload value
The default value for the $autoload parameter of add_option() and update_option() is being changed from "yes" to null, to allow WordPress to differentiate between an option with an autoload value that is explicitly set, and one where it can dynamically determine whether an option should be autoloaded. As a result, there are now three recommended values for the autoload parameter:
true: always autoload; Use this when an option should load on every page to avoid an additional DB query.
false: never autoload; Use this when an option is rarely used to avoid wasted data being loaded on every page.
null: maybe autoload; Allow the autoload value to be dynamically determined. By default, WordPress will still autoload options using the default value unless they contain large values (described below).
For backwards compatibility, the previous values of "yes" and "no" are still supported and mapped to true and false, respectively.
Updated database autoload values
Previously, all options were stored in the database with an autoload value of either “yes” or “no”. Starting with this change, the autoload value for newly updated options will now be one of the following values:
‘on’: Added with an explicit true value and MUST be autoloaded (needed on EVERY page).
‘off‘:‘ Added with an explicit false value and MUST not be autoloaded (e.g. only used on a single adminadmin(and super admin) page) .
‘auto’: Added without an explicit value and will rely on WP default autoloading behavior. In WordPress 6.6 these SHOULD autoload, but the default may change in the future.
‘auto-on’: Added with a dynamically set to true value and SHOULD be autoloaded.
‘auto-off’: Added with a dynamically set to false value and SHOULD NOT be autoloaded.
No upgrade routine is planned for this change, so previously added options will still be stored with “yes” or “no” values, which will be treated like “on” and “off”, respectively. If you have implemented any custom SQL to read or write autoload values, you should update them to use the new values.
Newly introduced public functions and filters
Several new functions and filters are available to make working with the new autoload values easier.
New Function
wp_autoload_values_to_autoload() – Returns all database values that should be autoloaded. Defaults to an array containing 'yes', 'on', 'auto-on', and 'auto'.
New Filters
wp_autoload_values_to_autoload – Edit the list of autoload values stored in the database values that should be autoloaded. At this time, the filterFilterFilters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. only allows values to be removed.
wp_default_autoload_value – Determine the default autoload value for an option where no explicit value is passed. Return a boolean false value to disable autoloading.
wp_max_autoloaded_option_size – Modify the size threshold above which options will not be autoloaded by default. Defaults to 150000, i.e., 150k bytes.
Disabling autoload for large options
To address the issue of autoloading excessively large options, when an option is added via add_option() or an option’s value is changed via update_option(), WordPress will now dynamically disable the autoload behavior by checking the size of the value before updating the database. For any options that do not explicitly pass true to the $autoload parameter, a value that is greater than 150k bytes will no longer be set to autoload.
Preparing for this update
To prepare for this update, developers should update calls to add_option() and update_option() in their code to explicitly set an autoload value using the new preferred true or false values in order to control the autoload behavior for your options. Otherwise, continue using the default value to allow for autoload optimizations to be dynamically applied.
Ensuring a large option is still autoloaded
If you need to ensure a specific large option is autoloaded after this change and cannot directly change the code where that option is saved, you can make use of the new wp_default_autoload_value filter.
Note: Do this with care, and only for options that are needed on every page.
If you want to change the size threshold for when options should no longer be autoloaded, you can use the new wp_max_autoloaded_option_size filter. Increasing this value is not recommended, as it could lead to slower performance.
add_filter( 'wp_max_autoloaded_option_size', 'my_max_autoload_option_size' );
function my_max_autoload_option_size( $size ) {
// Reduce the threshold for large sizes to 100K (Default is 150K).
return 100000;
}
Auditing your site for large options
WordPress 6.6 will include a new Site Health check, which will display a critical issue that says “Autoloaded options could affect performance” if the total size of your autoloaded options exceeds 800 KB.
To audit your site for large options that are currently being autoloaded, you can run an enhanced version of this same Site Health check by installing the Performance Lab plugin from the WordPress Performance Team. Once activated, the pluginPluginA plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party will add additional information to the Site Health check so you can review and disable any options that do not need to be autoloaded in the Site Health check.
Other changes to the Options API in WordPress 6.6
Introduce wp_prime_network_option_caches() to load multiple networknetwork(versus site, blog) options with a single database request (#61053)
Prime transient and transient timeout options in the transient and site transient APIs (#61193, #61053)
Update default autoload values used in coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. (#61045)
Add 'label' argument to register_setting() (#61023)
WordPress 6.6 includes improvements to how a block variation is detected as active for a given blockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. via the variation’s isActive property. This property can be either a function (that compares block and variation attributes), or a string[] shorthand that specifies which of the variation’s attributes to consider when comparing them to the block’s. The following changes affect only the string[] shorthand, which is now generally recommended over the function version.
Dot notation
Block variations can now use dot notation for “object paths” to specify “nested” attributes in their isActive property. For example, if a block’s query attribute is an object, it is now possible to use the following shorthand notation for isActive to determine if a variation is active based on the query object’s postType property:
If multiple variations have an isActive string array property that matches a given block, getActiveBlockVariation() will now return the one with the highest specificity. For example, take two variations of the same block, one with
Now if a block instance has attributes textColor: vivid-red and backgroundColor: cyan-bluish-gray, both variations’ isActive criterion will match that block instance. In this case, the specificity of each match will be calculated as the length of each isActive array, and the matching variation with the highest specificity will be returned — in this example, the second one.
Comparison of objects
If an isActive array item is an object, it was previously compared by reference. This has been fixed such that a block is considered to match a variation if it contains all the properties that the variation specifies for that object and if the properties have the same values. For example, the following variation
as the orderBy property that’s specified by the variation is missing.
Comparison of RichText
Finally, rich-text attributes are now compared correctly when used in a block variation’s isActive array. For example:
<pre class="wp-block-syntaxhighlighter-code">attributes: {
content: 'This is a <strong>warning</strong> message.',
},
isActive: [ 'content' ]</pre>
Conclusion
We hope that these improvements will make developers’ lives easier when working with block variations. They’re also meant to lay the foundations for some other enhancements we’re planning to make to block variations during the next cycle (e.g., automatically added class names for variations, or variation aliases).
The grid layout type for blocks has been in core since 6.3 but 6.6 adds some new features to it:
Toggle between grid modes
Adding grid layout to a block.json without specifying any further attributes, like so:
"layout": {
"default": {
"type": "grid"
}
}
will now by default display a toggle in the blockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience.sidebarSidebarA sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. layout section, allowing users to toggle between “Auto” and “Manual” modes:
It is still possible to configure the block to default to “Manual” mode and add a specific column count, by using the columnCount attribute:
Blocks that opt into grid layout can also allow their child blocks to span across multiple grid columns and/or rows. This can be enabled with the allowSizingOnChildren attribute:
WordPress 6.6 unified the different slots and extensibility APIs between the post and site editors. PluginPluginA plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party authors do not need to integrate their extensions twice (once using wp.editPost and once using wp.editSite). Instead, the following slots are now available under the wp.editor global variable (@wordpress/editor package or wp-editor script handle).
The above script registers a panel in the document sidebarSidebarA sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. for all post types in both the post and site editor. The script can be enqueued in PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher with the right script dependencies:
The wp.editPost and wp.editSite slots will continue to work without changes, but the old slot locations will be deprecated. To avoid triggering console warnings, you can support both the new and old slots at the same time.
To support previous versions in the example above, the Slot import must be updated as shown in the following code:
Once you are ready to make WP 6.6 the minimum required version for your plugin, you should be able to drop the fallbacks and restore the initial code.
Limiting your extensions per post types
It is important to note that when switching from editPost or editSite slots to editor, your plugin will now load and render in both contexts.
Both editors (post and site editors) have the possibility to render and edit pages, templates, patterns… This means that most plugins probably need to load in both contexts. But you might not want to load your plugin for templates, patterns, or you may only want load your plugin for pages but not posts…
To perform these checks, plugin authors have access to a range of selectors in the coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress./editor data store that allow them to hide or disable their behavior/UIUIUser interface as they wish.
Some extensions might only make sense to publicly viewable post types (post types that render in the frontend). You can use the postType’s viewable property to check for this.
Or you can use the name of the post type to only render for a limited set of post types.
Let’s update the initial example to only render the slot for publicly viewable post types:
// my-file.js
import { registerPlugin } from '@wordpress/plugins';
import { PluginDocumentSettingPanel, store as editorStore } from '@wordpress/editor';
import { store as coreStore } from '@wordpress/core-data';
const PluginDocumentSettingPanelDemo = () => {
const isViewable = useSelect( ( select ) => {
const postTypeName = select( editorStore ).getCurrentPostType();
const postTypeObject = select( coreStore ).getPostType( postTypeName );
return postTypeObject?.viewable;
}, [] );
// If the post type is not viewable, do not render my plugin.
if ( ! isViewable ) {
return null;
}
return (
Custom Panel Contents
);
}
registerPlugin( 'plugin-document-setting-panel-demo', {
render: PluginDocumentSettingPanelDemo,
icon: 'palmtree',
} );
WordPress 6.6 will ship with version 18.3 of the React library, which is identical to 18.2 but adds warnings for deprecations and other changes to help developers prepare for the ReactReactReact is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/. 19 upgrade once it becomes stable.
It’s recommended to stop using the deprecated features to ensure better compatibility with React 19 when it ships with WordPress. Keeping deprecations unchecked may lead to bugs or unintended behavior in your plugins. Addressing them is important to ensure smooth and reliable functionality.
Removed: defaultProps for function components
When searching the pluginPluginA plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party and theme repo for the use of deprecations in React 19, this one was found to be common.
React 19 will remove defaultProps for function components in favor of ES6 default parameters. This change can cause unexpected side effects when a component relies on default values provided by defaultProps.
// Before.
function Welcome( { text } ) {
return <p>{ text }</p>;
}
Welcome.defaultProps = {
text: 'Howdy!',
};
// After.
function Welcome( { text = 'Howdy!' } ) {
return <p>{ text }</p>;
}
Please refer to the official React 19 upgrade guide for a full list of deprecations and changes.
WordPress 6.6 introduces the possibility for developers to use the new React JSX transform that was first released in ReactReactReact is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/. 17.
How to use the new JSX in WordPress 6.6
Your build scripts need to apply the following changes in the built files:
Add the react-jsx-runtime to your script dependencies.
Use ReactJSXRuntime.jsx global as the output of your JSX calls.
In general, this is not something you do manually in your code base. Instead, you’ll use a build tool. The @wordpress/scripts, @wordpress/babel-preset-default and @wordpress/dependency-extraction-webpack-plugin npm packages have been upgraded to apply these transformations automatically.
Build Tools Compatibility and upgrade path
If you’re using the JSX syntax in your code base, and as long as you don’t update your dev dependencies (including @wordpress/scripts, @wordpress/babel-preset-default or @wordpress/dependency-extraction-webpack-plugin), you will continue to use the old JSX transform. This will allow your pluginPluginA plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party and built files to be compatible with WordPress 6.5, earlier versions and WordPress 6.6 as well.
When you’re ready to make WordPress 6.6 the minimum supported version of your plugin, you can update the following dependencies to use the new JSX transform.
@wordpress/scripts from version 28.
@wordpress/babel-preset-default from version 8.
@wordpress/dependency-extraction-webpack-plugin from version 6.
Going forward
The new JSX transform comes with performance improvements and optimization.
Note that the React team will deprecate the old JSX transform in the upcoming React v19 release (currently in RC).
Support for PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher 7.0 and 7.1 will be dropped in WordPress 6.6, scheduled for release in July 2024. The new minimum supported version of PHP will be 7.2.24. The recommended version of PHP remains at 7.4 or greater.
WordPress currently supports PHP version 7.0 or greater. The minimum supported version was last adjusted in WordPress 6.3 in August 2023, and since then usage of PHP 7.0 and 7.1 has dropped to a combined 2.45% of monitored WordPress installations as of April 2024.
There’s no concrete usage percentage that a PHP version must fall below before support in WordPress is dropped, but historically the project maintainers have used 5% as the baseline. Now that usage of PHP 7.0 and 7.1 combined is well below that at 2.45%, the process to increase the minimum supported PHP version in this release can move forward.
The benefits to increasing the minimum supported PHP version manifest over time and in multiple places, including within the pluginPluginA plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party and theme ecosystem, within the long term perception of the WordPress project, within developer relations, and over time within the WordPress codebase and its developer tooling.
WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. is compatible with PHP 8.0 and 8.1 with exceptions. Support for PHP 8.2 and PHP 8.3 is considered betaBetaA pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. since WordPress 6.4. Please see the PHP Compatibility and WordPress Versions page in the handbook for full information.
What about security support?
Sites that are running PHP 7.0 or 7.1 will remain on the 6.5 branchbranchA directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch". of WordPress which will continue receiving security updates as it does currently. The current security policy is to support WordPress versions 4.1 and greater.
What about the GutenbergGutenbergThe Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ plugin?
The Gutenberg plugin, which is used for development of the blockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor, has a separate release schedule from WordPress core and officially supports the two most recent releases of WordPress. The Gutenberg development team will likely also increase the minimum supported version of PHP to 7.2 in time for WordPress 6.6. See this issue on the Gutenberg repo for when this was last changed in WordPress 6.3.
Going forward
There are no plans to bump the minimum supported PHP version on a schedule. The core team will continue to monitor usage of PHP versions and work with the hosting team to encourage users and hosting companies to upgrade their versions of PHP as swiftly as possible. The 5% usage baseline will continue to be used for the foreseeable future.
This post has been superseded by the post WordPress 6.5 release delayed 1 week, in which it’s announced fonts will be uploaded to the fonts sub-directory of the uploads folder.
The Font Library, a new feature of WordPress 6.5, will allow users of blockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor themes to upload and customize their site’s fonts. You can learn about the full set of Font Library features in the #dev-note.
As fonts are a new first-class object, there has been some discussion around where to store the associated files while accounting for different file systems used by WordPress sites. The particular challenge has been for file systems that do not allow for the writing of files outside the uploads directory (See Gutenberg#59417 and Gutenberg#59699).
To account for such file systems, it was originally decided to natively fallback to the uploads directory natively in WordPress CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress..
Revised approach to font file storage
Exploratory work on supporting a fallback directory natively has demonstrated that this approach would lead to a high risk of bugs. Therefore, the original decision is being modified and the new approach will be:
WordPress Core will by default only attempt to store font files in the wp-content/fonts directory,
For file systems unable to write to or persistently store files in the new directory it is recommended to install the pluginPluginA plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-partyFonts to Uploads to store the files in the under existing uploads directory, in wp-content/uploads/fonts
Developers wishing to modify the directory without using a plugin can use the font_dirfilterFilterFilters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output.documented in the announcement post.
Props @mmaattiiaass and other contributors for working on the exploratory pull request.
You must be logged in to post a comment.