Experimental APIs in WordPress Core have largely been tamed

Last year’s proposal to stop merging experimental APIs from Gutenberg to WordPress Core is now mostly implemented.

To recap: Due to JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. technical limitations, the recurring merge of the GutenbergGutenberg The 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/ pluginPlugin A 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 to WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. led to a premature release of many experimental APIs.

After a long discussion and discovery process, Gutenberg introduced a distinction between Plugin-only APIs and Private APIs.

Plugin-only APIs 

Plugin-only APIs are like early access feature previews that require community feedback to mature. They are only released as a part of the Gutenberg plugin and not merged into WordPress core. It’s implemented as follows:

// Using IS_GUTENBERG_PLUGIN allows Webpack to exclude this
// export from WordPress core:
if ( process.env.IS_GUTENBERG_PLUGIN ) {
  export { pluginOnlyAPI } from './api';
}

Private APIs 

Private APIs are internal. They are merged into WordPress core, but cannot be accessed by extenders in plugins or themes. Only the code inside the blockBlock Block 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 can access the private APIs using the dedicated utilities – please review the coding guidelines to find out more.

Aftermath 

The goal of taming new experimental APIs has largely been achieved. Thanks to the recent coordinated effort to use the private APIs, only two new ones made it into WordPress 6.2. In contrast, previous WordPress releases introduced 14, 20, and even 40 new experimental APIs. Two is phenomenal 🎉 The remaining follow-up work is being tracked separately in GitHub issue #47786

Regarding the stabilization of the existing experimental APIs, a case-by-case assessment of the several hundred experimental APIs in WordPress core will be necessary. WordPress 6.2 addressed a few such exports, and the rest will likely be gradually addressed in future releases. Some may get stabilized, others may get deprecated, and others may stay indefinitely. The upcoming WordPress Community Summit may provide some answers, as the issue of deprecating JavaScript APIs has been proposed as a discussion topic.

Many thanks to everyone for the productive discussions and efforts. The outcome of this effort is a testament to the commitment of the WordPress community to maintain high-quality software.

Props to the following editors and reviewers of this post: @gziolo @ndiego @cbringmann @mcsf @akirk @peterwilsoncc @priethor

#core, #gutenberg, #proposal