Editor: Unified Extensibility APIs in 6.6

WordPress 6.6 unified the different slots and extensibility APIs between the post and site editors. 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 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).

• PluginDocumentSettingPanel
• PluginSidebarMoreMenuItem
• PluginSidebar
• PluginPostStatusInfo
• PluginMoreMenuItem
• PluginBlockSettingsMenuItem
• PluginDocumentSettingPanel
• PluginPostPublishPanel
• PluginPrePublishPanel

Example

// my-file.js
import { registerPlugin } from '@wordpress/plugins';
import { PluginDocumentSettingPanel } from '@wordpress/editor';

const PluginDocumentSettingPanelDemo = () => (
  
     Custom Panel Contents
   
);

registerPlugin( 'plugin-document-setting-panel-demo', {
  render: PluginDocumentSettingPanelDemo,
  icon: 'palmtree',
} );

The above script registers a panel in the document sidebarSidebar A 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 PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher with the right script dependencies:

function example_enqueue_editor_assets() {
  wp_enqueue_script(
    'example-plugin',
    plugins_url( 'my-built-file.js', __FILE__ ),
    array( 'wp-editor', 'wp-plugins' ),
    1
  );
}

add_action( 'enqueue_block_editor_assets', example_enqueue_editor_assets );

Supporting multiple WordPress versions

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:

// my-script.js
const PluginDocumentSettingPanel = wp.editor?.PluginDocumentSettingPanel ?? ( wp.editPost?.PluginDocumentSettingPanel ?? wp.editSite?.PluginDocumentSettingPanel );

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 coreCore Core 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/UIUI User 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',
} );

Thank you @ndiego @jeherve for contributing to and testing this post and @juanmaguitar for proofreading.

#6-6, #dev-note, #dev-notes, #dev-notes-6-6