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.
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. Variations: Have getActiveBlockVariation fall back to default variation
WordPress 6.9 introduces a small change to active block variation detection.
To understand what that change looks like, recall that a block variation can include an isActive criterion that will be used to determine if a given block instance matches the variation.
The change concerns the case in which none of the isActive criteria of a block type’s variations match a given block instance. In this case, WordPress 6.9 will use the variation with the isDefault property set to true as fallback, if any.
Two limitations apply:
The variation with the isDefault property is only used as fallback if it doesn’t also include an isActive criterion, as that would mean that the variation did not match that criterion (and thus cannot be assumed to be active).
The fallback is only applied for the block and transform scopes but not to the inserter, as to not affect the block name displayed there.
In practice, the updated behavior should be consistent with users’ and developers’ expectations, as the isDefault variation is typically used to set a default block variation different from the “vanilla” block type.
Together with the improvements made to active block variation detection in WordPress 6.6 , this change allows block authors to express the criteria for active block detection in a very succinct and 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.-only manner. For an example, see how these principles were applied to rewrite Group block variations.
CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress.-data: Media Entity Deprecation
What is being deprecated?
In WordPress 6.9, the @wordpress/core-data package’s media entity is being deprecated. This entity is usually accessed through a range of APIs:
The getMedia and getMediaItems selectors or resolvers.
The saveMedia and deleteMedia actions.
The getEntityRecord, getEntityRecords and other selectors or resolvers when passed the 'root' and 'media' params (e.g. getEntityRecords( 'root', 'media' );).
The editEntityRecord, saveEntityRecord, deleteEntityRecord and other actions when passed the 'root' and 'media' params (e.g. deleteEntityRecord( 'root', 'media', 123)).
These 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. calls will continue to work in WordPress 6.9, but will now log a deprecation message that recommends switching to a different signature.
Why is this being deprecated?
The media entity was found to be duplicating another entity, attachment. This attachment entity is usually accessed through API calls like getEntityRecords( 'postType', 'attachment' );. These two entities both internally use the mediaREST APIREST APIThe REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. endpoint and return results for attachment post types.
The entity system maintains a cache of REST API data, and the two separate entity types result in two separate caches that might contain different states for the same data. If the caches become desynchonized, this can result in noticeable bugs where a user interface might show outdated data, or old data overwrites newer data when saved.
Various solutions for fixing this issue were explored, but the option that was found to be safest was to deprecate the media entity in favor of the attachment entity.
How to update your code to use the attachment entity
Replacing API calls
The following code snippet shows some examples of how to update your API calls:
wp.data.select( 'core' ).getMedia( 123 ); // now deprecated
wp.data.select( 'core' ).getEntityRecord( 'root', 'media', 123 ); // now deprecated
wp.data.select( 'core' ).getEntityRecord( 'postType', 'attachment', 123 ); // recommended update
wp.data.select( 'core' ).getMediaItems(); // now deprecated
wp.data.select( 'core' ).getEntityRecords( 'root', 'media' ); // now deprecated
wp.data.select( 'core' ).getEntityRecords( 'postType', 'attachment' ); // recommended update
wp.data.dispatch( 'core' ).saveMedia( 123, { // ... media data } ); // now deprecated
wp.data.dispatch( 'core' ).saveEntityRecord( 'root', 'media', 123, { // ... media data } ); // now deprecated
wp.data.dispatch( 'core' ).saveEntityRecord( 'postType', 'attachment', 123, { // ... media data } ); // recommended update
wp.data.dispatch( 'core' ).deleteMedia( 123 ); // now deprecated
wp.data.dispatch( 'core' ).deleteEntityRecord( 'root', 'media', 123 ); // now deprecated
wp.data.dispatch( 'core' ).deleteEntityRecord( 'postType', 'attachment', 123 ); // recommended update
Changes to the caption property when using the getEditedEntityRecord selector
When making an API call for the ‘edited’ version of an entity record (e.g. getEditedEntityRecord( 'root', 'media', 123 )), the core data package converts the caption property to a string:
caption: "My image's caption"
The attachment entity doesn’t perform the same processing, an API call like getEditedEntityRecord( 'postType', 'attachment', 123 ) returns the caption in its object form:
caption: {
raw: "My image's caption",
rendered: "My image's caption"
}
The caption.raw property corresponds to the string value that the media entity returns for the caption.
When switching to the ‘attachment’ entity, some code may need to be updated to account for this difference.
Block Editor: Support passing updater function to setAttributes
Starting from WordPress 6.9, the setAttribute prop passed to a block’s Edit component will now support an updater function as an argument.
The updater is a pure function; it takes only the current attributes as its argument and returns the updated attributes.
// Toggle a setting when the user clicks the button.
const toggleSetting = () =>
setAttributes( ( currentAttr ) => ( {
mySetting: ! currentAttr.mySetting,
} ) );
// Append item to the list.
const addListItem = ( newListItem ) =>
setAttributes( ( currentAttr ) => ( {
list: [ ...currentAttr.list, newListItem ],
} ) );
SelectControl: Moved class names to the component root
The SelectControl component’s class assignments have been adjusted for better consistency with other form components, such as TextControl. Both the default class name (components-select-control) and any custom class name passed via the className prop are now applied to the root element of the component, rather than to the internal element.
While this update does not alter the component’s behavior or visual design, custom CSSCSSCascading Style Sheets. that previously depended on the inner structure may need to be updated.
WordPress 6.9 adds support for registering custom social icons to the Social Icons block. With this update, developers can create plugins to define new services and SVGs, and expose them to both the editor and frontend through block variations and PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher filters. For styling, matching brand colors can be handled in CSS and loaded for both views.
