Gutenberg 编辑后管理包实战指南：深入解析 @wordpress/edit-post 与文章编辑器 UI 扩展-二趣网

Gutenberg 编辑后管理包实战指南：深入解析 @wordpress/edit-post 与文章编辑器 UI 扩展

【免费下载链接】gutenbergThe Block Editor project for WordPress and beyond. Plugin is available from the official repository.项目地址: https://gitcode.com/GitHub_Trending/gu/gutenberg

@wordpress/edit-post是 WordPress Gutenberg 项目中负责"文章编辑"场景的专属模块——它承载了经典文章编辑器（Post Editor）的初始化、布局与 UI 扩展能力。本文将带你完整掌握它的安装方式、initializeEditor初始化流程、core/edit-post数据仓库（store），以及如何借助registerPlugin与PluginSidebar等组件在编辑器内落地自定义侧边栏和设置面板。

读完本文，你将能够：理解@wordpress/edit-post与@wordpress/editor的职责划分与迁移关系；掌握wp.editPost全局对象与脚本依赖的注册方法；基于插件 API 从零搭建一个读写post_meta的侧边栏插件，并了解各扩展点组件（PluginDocumentSettingPanel、PluginBlockSettingsMenuItem、PluginMoreMenuItem等）的完整参数与适用场景。

本文以仓库中 packages/edit-post/README.md 为骨架，结合其源码、@wordpress/plugins与@wordpress/editor包文档以及仓库内实战教程整理而成。

一、Edit Post 模块是什么

@wordpress/edit-post是 Gutenberg monorepo（当前工作目录即仓库根目录）中的一个独立包，官方定位为"Edit Post Module for WordPress"，即专门面向 WordPress 文章编辑页面（post.php下的块编辑器）的模块。它不负责抽象的编辑器内核，而是把"编辑一篇文章"这一具体业务场景组装起来：初始化编辑器实例、配置编辑器偏好（preferences）、注册核心块、管理侧边栏与 Meta Box 等。

其 package.json 中记录的版本为8.55.0，依赖了大量同仓库包：@wordpress/editor、@wordpress/block-editor、@wordpress/block-library、@wordpress/plugins、@wordpress/data、@wordpress/components、@wordpress/preferences等，整体呈现"薄壳 + 组装"的架构。

需要注意 README 中的一句关键声明：

This package is meant to be used only with WordPress core. Feel free to use it in your own project but please keep in mind that it might never get fully documented.

也就是说，该包主要面向 WordPress 核心使用；虽然允许在自有项目中使用，但其文档与 API 稳定度并不像@wordpress/editor那样有完整保障。对插件开发者而言，推荐直接使用@wordpress/editor暴露的组件与数据 store，这与本包自身的演进方向一致（见下文"废弃迁移"章节）。

与 @wordpress/editor 的职责划分

在 Gutenberg 中，职责被刻意分层：

@wordpress/editor：抽象"WordPress 文章"概念，提供块解析、文章加载与保存、PluginSidebar等所有扩展组件，不关心具体渲染在哪个 WordPress 屏幕中；
@wordpress/edit-post：在@wordpress/editor之上做文章编辑场景的组装与入口初始化，通过 src/index.jsx 对外暴露initializeEditor、store以及一组对@wordpress/editor组件的（现已废弃的）再导出。

二、安装与运行前提

在支持 npm 的 JavaScript 项目中，按 README 安装：

npm install @wordpress/edit-post

安装后，包入口按环境区分：CommonJS 环境使用build/index.cjs，ESM 环境使用build-module/index.mjs（见 package.json 的exports字段）。

ES2015+ 运行环境要求：该包默认你的代码运行在支持 ES2015+ 语法与 API 的环境。如果目标环境对这类语言特性支持有限或完全不支持，需要在代码中引入@wordpress/babel-preset-default附带的 polyfill。

脚本依赖与全局对象：当你在 WordPress 中通过wp_enqueue_script引入脚本时，若声明wp-edit-post作为脚本依赖，则该包导出的组件会暴露在全局变量wp.editPost上。这是 README 中明确给出的集成方式：

They can be found in the global variablewp.editPostwhen definingwp-edit-postas a script dependency.

由于该包面向 WordPress core，实际在 WordPress 页面里通常不需要手动入队wp-edit-post脚本——核心已加载。插件开发者更常用的是wp.editor（来自@wordpress/editor）与wp.plugins（来自@wordpress/plugins），具体见下文扩展实践。

三、API 全景：从初始化到扩展

README 的 API 章节由自动生成标记（START/END TOKEN(Autogenerated API docs)）包裹，包含两类成员：编辑器生命周期函数（initializeEditor、reinitializeEditor）与数据仓库（store），以及一组"Related"到@wordpress/editor的插槽组件。下面逐一展开并结合源码说明。

3.1 initializeEditor：编辑器实例的启动入口

initializeEditor用于初始化并返回一个 Editor 实例，其签名与参数如下：

参数	类型	说明
`id`	`string`	编辑器实例的唯一标识符（实际用作`document.getElementById( id )`的容器 id）
`postType`	`string`	待编辑文章的 post type
`postId`	`Object`	待编辑文章的 ID
`settings`	`?Object`	编辑器设置对象（可为空）
`initialEdits`	`Object`	初始的编程式编辑内容，视为非用户发起（可绕过"未保存更改"提示）

在 src/index.jsx 的实现中，该函数完成了一系列关键装配步骤，理解它们有助于把握整个编辑器的启动脉络：

查找容器并创建 React Root：const target = document.getElementById( id );后通过createRoot( target )创建 React 19 风格的根节点；
写入偏好默认值：通过dispatch( preferencesStore ).setDefaults(...)分别设置core/edit-post与core两个命名空间的默认偏好，例如fullscreenMode: true（默认全屏编辑）、editorMode: 'visual'、fixedToolbar: false、openPanels: ['post-status']、showIconLabels: false等。这意味着文章编辑器的大量 UI 开关都收敛到了@wordpress/preferences数据仓库中；
注册核心块：调用registerCoreBlocks()、registerCoreBlockBindingsSources()，并注册旧版小工具块（registerLegacyWidgetBlock）与组件组块（registerWidgetGroupBlock）。当globalThis.IS_GUTENBERG_PLUGIN为真时，还会通过__experimentalRegisterExperimentalCoreBlocks注册实验性块；
环境兼容性检查：检测document.compatMode，若浏览器处于 Quirks Mode 则向控制台输出警告——该模式可能因 PHP 错误或<!DOCTYPE html>前存在 HTML 代码而触发，导致块与 Meta Box 重叠渲染；
全局事件防御：为dragover/drop添加preventDefault，避免文件被拖拽到非投放区时浏览器默认打开文件；
预加载数据解析：通过enablePreloadMultiUse()与preloadResolutions( postType, postId )驱动@wordpress/core-data的 resolver 从预加载缓存中取数（用户、实体配置、主题、全局样式、权限等），待 Promise 完成后调用editorStore.setupEditor( post, initialEdits, settings.template )，最终将<Layout>渲染进根节点；
返回 root：函数末尾return root;，调用方可继续控制该渲染根。

上述实现印证了 README 对initialEdits的描述——它会在setupEditor时作为"非用户发起"的初始编辑传入，从而跳过未保存更改提示。

3.2 reinitializeEditor：已废弃的空操作

export function reinitializeEditor() { deprecated( 'wp.editPost.reinitializeEditor', { since: '6.2', version: '6.3', } ); }

src/index.jsx 中该函数"用于在出错后重新初始化编辑器"，但目前已是一个被标记废弃（自 6.2 起弃用，计划 6.3 移除）的 noop——调用它只会触发@wordpress/deprecated的废弃提示。因此新代码不应再依赖此 API。

3.3 store：core/edit-post 数据仓库

store是 edit-post 命名空间的数据仓库定义，类型为Object。从 src/store/index.js 可见其由createReduxStore( STORE_NAME, { reducer, actions, selectors } )创建并立即register( store )注册，STORE_NAME常量值为'core/edit-post'（见 src/store/constants.js）。也就是说，你可以通过wp.data.select( 'core/edit-post' )或wp.data.dispatch( 'core/edit-post' )在控制台或插件代码中访问它。

actions：状态变更操作

src/store/actions.js 中定义了一批 action，值得注意的现状是：绝大多数侧边栏/面板类 action 已标记废弃，并委托给core/interface或core/editor，例如：

openGeneralSidebar( name )/closeGeneralSidebar()：打开/关闭通用侧边栏，委托interfaceStore.enableComplementaryArea( 'core', name )；
openModal( name )/closeModal()：自 6.3 起废弃，改用core/interface的同名 action；
openPublishSidebar/closePublishSidebar/togglePublishSidebar：自 6.6 起废弃，改用core/editor；
toggleEditorPanelEnabled/toggleEditorPanelOpened/removeEditorPanel：自 6.5 起废弃，改用core/editor；
switchEditorMode( mode )：自 6.6 起废弃，改用core/editor。

仍保持活跃的 action 主要包括：

toggleFeature( feature )：切换core/edit-post命名空间下的偏好开关（写入 preferences store）；
togglePinnedPluginItem( pluginName )：在工具栏上固定/取消固定插件项；
showBlockTypes( blockNames )/hideBlockTypes( blockNames )：显示/隐藏指定块类型（委托core/editor的私有 API）；
toggleFullscreenMode()：切换全屏模式，并弹出带 "Undo" 操作的 snackbar 通知；
Meta Box 相关：initializeMetaBoxes()（初始化postboxes脚本并挂接editor.savePost钩子以在保存时提交 Meta Box）、requestMetaBoxUpdates()（收集.metabox-base-form与各位置的 Meta Box 表单数据，先触发window.tinyMCE.triggerSave()，再 POST 到window._wpMetaBoxUrl）、setAvailableMetaBoxesPerLocation、metaBoxUpdatesSuccess/Failure等。

selectors：状态读取

src/store/selectors.js 提供状态查询能力，同样存在大量废弃迁移：

活跃的：getEditorMode（读取core命名空间editorMode，默认'visual'）、isEditorSidebarOpened、isPluginSidebarOpened、getActiveGeneralSidebarName（返回形如edit-post/document或my-plugin/insert-image-sidebar的活跃侧边栏名）、getHiddenBlockTypes、isFeatureActive、isPluginItemPinned、getActiveMetaBoxLocations、isMetaBoxLocationVisible、hasMetaBoxes、isSavingMetaBoxes、getEditedPostTemplate等；
已废弃的：getPreferences/getPreference（自 6.0 起改用core/preferences）、isPublishSidebarOpened（6.6）、isEditorPanelRemoved/Enabled/Opened（6.5）、isModalActive（6.3）、isInserterOpened/isListViewOpened（6.5）、isEditingTemplate（6.5）等。

其中getPreferences的实现值得一提：它为了兼容旧插件，会把 preferences store 的inactivePanels/openPanels通过convertPanelsToOldFormat转换成旧的{ panelName: { enabled, opened } }结构——这从侧面说明本包承担了相当多的向后兼容职责。

3.4 Plugin* 组件：已迁移的插槽再导出

README 的 API 列表中，以下组件均以 "Related: ... in @wordpress/editor package" 形式出现：

PluginBlockSettingsMenuItem（块设置菜单项）
PluginDocumentSettingPanel（文档侧边栏设置面板）
PluginMoreMenuItem（更多菜单项）
PluginPostPublishPanel（发布后面板）
PluginPostStatusInfo（文章状态信息行）
PluginPrePublishPanel（发布前面板）
PluginSidebar（插件侧边栏）
PluginSidebarMoreMenuItem（更多菜单中的侧边栏入口）

它们在 src/deprecated.jsx 中被定义为包装组件：当 URL 路径包含site-editor.php（即站点编辑器环境）时直接返回null；否则调用deprecateSlot( name )打印"自 6.6 起废弃、请改用wp.editor.xxx"的提示，并把 props 透传给@wordpress/editor中的同名组件。

因此结论很明确：面向未来开发的插件应直接从@wordpress/editor（全局wp.editor）导入这些组件，而不是从wp.editPost取用。README 将它们列入 API，更多是历史兼容层面的记录。

3.5 其他导出：私有 API 与辅助组件

src/index.jsx 末尾还导出了：

__experimentalFullscreenModeClose：全屏模式的关闭按钮组件；
__experimentalMainDashboardButton：主仪表盘按钮（从@wordpress/editor私有 API 解锁而来）；
以及store与deprecated.jsx的全部导出。

这些实验性/私有 API 通过 src/lock-unlock.js 中__dangerousOptInToUnstableAPIsOnlyForCoreModules的 lock/unlock 机制访问，仅限 WordPress 核心模块使用，插件与主题不应依赖（其确认字符串亦明确声明"private features are not for use in themes or plugins"）。

四、扩展文章编辑器 UI：registerPlugin 与插件插槽

README 明确指出扩展编辑器 UI 的唯一推荐入口是registerPluginAPI，它让你把插件所有的 UI 元素定义在一个地方。该 API 由 packages/plugins/README.md 提供（npm 包@wordpress/plugins，WordPress 中对应脚本依赖wp-plugins，全局wp.plugins）。

核心 API 一览：

API	说明
`registerPlugin( name, settings )`	注册一个插件。`name`在所有已注册插件中必须唯一；`settings`含`icon`、`render`、`scope`等
`getPlugin( name )`	返回已注册插件的设置（`WPPlugin \\| undefined`）
`getPlugins( scope )`	返回无 scope 或指定 scope 的全部插件
`PluginArea`	渲染所有插件填充内容的组件（默认隐藏 div），支持`scope`与`onError`
`unregisterPlugin( name )`	注销插件
`usePluginContext()`	获取插件上下文（推荐）；`withPluginContext`为 HOC，已于 6.8.0 废弃

例如，通过PluginArea在自定义页面渲染带 scope 的插件：

import { PluginArea } from '@wordpress/plugins'; const Layout = () => ( <div> Content of the page <PluginArea scope="my-page" /> </div> );

在文章编辑器中，PluginArea由核心在合适位置渲染，插件只需用registerPlugin注册一个render函数，render 内部返回任意插槽组件（如PluginSidebar）即可。

五、实战：从零搭建一个读写 Meta 字段的插件侧边栏

下面这套完整流程取自仓库内的官方教程 docs/how-to-guides/plugin-sidebar-0.md，它演示的正是 README "Extending the post editor UI" 章节所述能力：用registerPlugin+PluginSidebar（来自wp.editor）扩展文章编辑器。

Step 1：让侧边栏跑起来

创建plugin-sidebar.js：

( function ( wp, React ) { var el = React.createElement; var registerPlugin = wp.plugins.registerPlugin; var PluginSidebar = wp.editor.PluginSidebar; registerPlugin( 'my-plugin-sidebar', { render: function () { return el( PluginSidebar, { name: 'my-plugin-sidebar', icon: 'admin-post', title: 'My plugin sidebar', }, 'Meta field' ); }, } ); } )( window.wp, window.React );

对应的 PHP 注册脚本，注意脚本依赖必须包含wp-plugins、wp-editor、react，并在enqueue_block_editor_assets钩子中入队：

<?php /* Plugin Name: Sidebar plugin */ function sidebar_plugin_register() { wp_register_script( 'plugin-sidebar-js', plugins_url( 'plugin-sidebar.js', __FILE__ ), array( 'wp-plugins', 'wp-editor', 'react' ) ); } add_action( 'init', 'sidebar_plugin_register' ); function sidebar_plugin_script_enqueue() { wp_enqueue_script( 'plugin-sidebar-js' ); } add_action( 'enqueue_block_editor_assets', 'sidebar_plugin_script_enqueue' );

激活后，编辑器右上角会出现一个图钉样式的图标，点击即可展开插件侧边栏。

Step 2：加入表单控件与样式

使用@wordpress/components中的TextControl创建输入框，注意此时需把wp-components加入脚本依赖：

( function ( wp ) { var el = React.createElement; var registerPlugin = wp.plugins.registerPlugin; var PluginSidebar = wp.editor.PluginSidebar; var TextControl = wp.components.TextControl; registerPlugin( 'my-plugin-sidebar', { render: function () { return el( PluginSidebar, { name: 'my-plugin-sidebar', icon: 'admin-post', title: 'My plugin sidebar', }, el( 'div', { className: 'plugin-sidebar-content' }, el( TextControl, { label: 'Meta Block Field', value: 'Initial value', onChange: function ( content ) { console.log( 'content changed to ', content ); }, } ) ) ); }, } ); } )( window.wp );

配套的plugin-sidebar.css（给出内边距），并在 PHP 中同时注册、入队样式：

.plugin-sidebar-content { padding: 16px; }

Step 3：注册 post_meta 字段

字段需要暴露给 REST API，块编辑器正是通过 REST 访问数据的：

register_post_meta( 'post', 'sidebar_plugin_meta_block_field', array( 'show_in_rest' => true, 'single' => true, 'type' => 'string', ) );

验证字段是否已加载到编辑器 store（浏览器控制台）：

wp.data.select( 'core/editor' ).getCurrentPost().meta;

若返回undefined，请确保你的 post type 支持custom-fields（可通过register_post_type的supports参数或add_post_type_support启用）。

Step 4：用 useSelect 初始化输入控件

useSelect（来自@wordpress/data，脚本依赖wp-data）在组件加载时取数，并在数据变化时更新。注意getEditedPostAttribute返回的是包含未保存编辑在内的最新值：

var MetaBlockField = function () { var metaFieldValue = useSelect( function ( select ) { return select( 'core/editor' ).getEditedPostAttribute( 'meta' )[ 'sidebar_plugin_meta_block_field' ]; }, [] ); return el( Text, { label: 'Meta Block Field', value: metaFieldValue, onChange: function ( content ) { console.log( 'content has changed to ', content ); }, } ); };

可用下列命令验证组件随 store 更新（输入框内容会变为 "hello world!"）：

wp.data .dispatch( 'core/editor' ) .editPost( { meta: { sidebar_plugin_meta_block_field: 'hello world!' } } );

Step 5：用 useDispatch 写回 Meta 字段

useDispatch( 'core/editor' ).editPost会在每次按键时更新编辑器 store：

var editPost = useDispatch( 'core/editor' ).editPost; return el( TextControl, { label: 'Meta Block Field', value: metaFieldValue, onChange: function ( content ) { editPost( { meta: { sidebar_plugin_meta_block_field: content }, } ); }, } );

保存文章后重新加载编辑器，输入控件会用数据库中最后保存的值重新初始化，即证明数据已正确持久化到post_meta。

避坑提示：与"自定义字段"面板的冲突

若用户在编辑器偏好（右上角三点菜单 → Preferences → Panels）中启用了Custom Fields，编辑器底部会出现同名自定义字段输入框。该字段与侧边栏TextControl指向同一 meta 属性，但保存时自定义字段的值会后写覆盖，导致侧边栏中的改动丢失。两种解决方案：

将 meta 字段名加下划线前缀（如_sidebar_plugin_meta_block_field），将其标记为私有 meta，从而不显示在 Custom Fields 中——此时需在register_post_meta的args中提供最终返回true的auth_callback；
在TextControl的onChange中同步更新 Custom Fields 对应 textarea 的值，保证两处一致：

return el( TextControl, { label: 'Meta Block Field', value: metaFieldValue, onChange: function ( content ) { editPost( { meta: { sidebar_plugin_meta_block_field: content } }) document.querySelector( {the-value-textarea} ).innerHTML = content; }, } );

若不需要启用 Custom Fields，则不存在此问题。

六、八种插槽组件速查

以下组件的完整文档在 packages/editor/README.md（约 541–977 行），它们用于将插件 UI 注入文章编辑器不同区域。本包在历史版本中曾再导出这些组件（现位于 src/deprecated.jsx），因此理解它们等于理解 edit-post 的扩展点。

PluginSidebar

在编辑器最右侧渲染一个可固定（pinnable）的侧边栏；当isPinnable为true时自动渲染对应的菜单项。

name（string，必填）：侧边栏标识，插件作用域内必须唯一；
title（string）：侧边栏顶部标题；
icon（WPBlockTypeIconRender）：Dashicon 名称或 SVG 元素，用于固定到工具栏时显示；
isPinnable（boolean）：是否允许固定到工具栏；
className（string）：附加到侧边栏主体的类名。

import { __ } from '@wordpress/i18n'; import { PanelBody } from '@wordpress/components'; import { PluginSidebar } from '@wordpress/editor'; import { more } from '@wordpress/icons'; const MyPluginSidebar = () => ( <PluginSidebar name="my-sidebar" title="My sidebar title" icon={ more }> <PanelBody>{ __( 'My sidebar content' ) }</PanelBody> </PluginSidebar> );

手动打开侧边栏（无需PluginSidebarMoreMenuItem）也可以用 dispatch API：

wp.data .dispatch( 'core/edit-post' ) .openGeneralSidebar( 'plugin-name/sidebar-name' );

注意：上述openGeneralSidebar正是 src/store/actions.js 中仍活跃的 action 之一，它通过interfaceStore.enableComplementaryArea( 'core', name )实现。

PluginSidebarMoreMenuItem

在"更多菜单"（More Menu）的 Plugins 分组中渲染一个菜单项，用于激活对应的PluginSidebar。

target（string，必填）：目标侧边栏的name，必须与PluginSidebar的name一致；
icon（WPBlockTypeIconRender）：显示在菜单项文本左侧的图标。

PluginDocumentSettingPanel

在文档侧边栏的"状态与可见性"（Status & Visibility）面板下方渲染一个设置面板。

name（string，必填）：面板的机器友好名称；
title（string）：面板标题；
className、icon、children：类名、固定图标与子内容。

const MyDocumentSettingPlugin = () => ( <PluginDocumentSettingPanel className="my-document-setting-plugin" title="My Panel" name="my-panel" > { __( 'My Document Setting Panel' ) } </PluginDocumentSettingPanel> ); registerPlugin( 'my-document-setting-plugin', { render: MyDocumentSettingPlugin } );

PluginPostStatusInfo

在文档侧边栏的 Summary 面板中渲染一行信息（该组件围绕"功能职责"而非"位置"命名，位置未来可能变化）。

className（string）：附加到该行的类名；
children：要渲染的内容。

PluginPrePublishPanel / PluginPostPublishPanel

分别在发布流程的发布前（点击"发布"按钮后弹出的面板）与发布后（发布成功后面板）渲染内容。

title（string）：面板顶部标题；
initialOpen（boolean）：是否默认展开（未提供标题时总是展开）；
icon：固定到工具栏时的图标，传false则不渲染图标；
className、children：类名与内容。

PluginBlockSettingsMenuItem

在选中块时的块设置菜单中渲染一个新菜单项。

label（string）：菜单项文本；
onClick（Function）：点击回调；
icon：Dashicon 名称或 SVG 元素；
allowedBlocks（Array）：限定仅在哪些块（如['core/paragraph']）上显示；未提供则对所有块显示；多选时仅当全部选中块都在列表中才显示；
small（boolean）：是否隐藏 label 仅显示图标；
role（string）：菜单项的 ARIA role。

PluginMoreMenuItem

在"更多菜单"的 Plugins 分组中渲染一个菜单项，可作按钮或链接使用，组件内文本即菜单项标签。

icon：菜单项图标；
onClick：点击回调。

七、迁移与兼容性：从 wp.editPost 走向 wp.editor

结合 src/deprecated.jsx 与 src/store/actions.js、src/store/selectors.js 中的大量deprecated()调用，可以清晰看到本包近几个版本的核心演进方向：扩展能力整体向@wordpress/editor与@wordpress/interface收敛。

旧用法（`core/edit-post`/`wp.editPost`）	新用法	废弃起始版本
`PluginSidebar`等 8 个组件	`@wordpress/editor`中的同名组件（`wp.editor.*`）	6.6
`openModal`/`closeModal`	`core/interface`	6.3
`getPreferences`/`getPreference`	`core/preferences`	6.0
`openPublishSidebar`等	`core/editor`	6.6
`toggleEditorPanel*`/`removeEditorPanel`	`core/editor`	6.5
`switchEditorMode`	`core/editor`	6.6
`isInserterOpened`/`isListViewOpened`	`core/editor`	6.5
`reinitializeEditor`	无（noop）	6.2 → 计划 6.3 移除

对存量插件而言，这些deprecated包装仍然可用（会打印控制台提示）；对新插件而言，直接使用wp.editor与wp.plugins是更稳妥的选择。另外需要留意：PluginSidebar等组件在站点编辑器（site editor）环境下会直接返回null（见 src/deprecated.jsx 中基于site-editor.php的判断），插件若需兼容站点编辑器，应采用@wordpress/editor包中针对双环境设计的对应方案。

八、延伸阅读与仓库导航

本包主体文档：packages/edit-post/README.md
初始化与导出实现：packages/edit-post/src/index.jsx
插槽组件废弃包装：packages/edit-post/src/deprecated.jsx
Store 定义与常量：packages/edit-post/src/store/index.js、packages/edit-post/src/store/constants.js
Store 的 actions 与 selectors：packages/edit-post/src/store/actions.js、packages/edit-post/src/store/selectors.js
私有 API 锁机制：packages/edit-post/src/lock-unlock.js
URL 与文章 ID 同步组件说明：packages/edit-post/src/components/browser-url/README.md
插件注册 API：packages/plugins/README.md
扩展组件的完整参数文档：packages/editor/README.md
侧边栏完整教程：docs/how-to-guides/plugin-sidebar-0.md
数据访问（useSelect/useDispatch）：packages/data/README.md
ES2015+ polyfill：@wordpress/babel-preset-default

结语

@wordpress/edit-post是理解 Gutenberg 文章编辑器如何"被组装起来"的最佳入口：从initializeEditor的初始化管线、core/edit-poststore 的偏好与 Meta Box 管理，到经由registerPlugin接入的八大插槽组件，它把 WordPress 文章编辑场景的方方面面串成一条完整的扩展链路。对于插件开发者而言，掌握本文的侧边栏实战流程与迁移指南，即可在文章编辑器中稳定地构建自定义 UI 并读写post_meta，同时确保代码与 WordPress 核心的演进方向保持一致。

【免费下载链接】gutenbergThe Block Editor project for WordPress and beyond. Plugin is available from the official repository.项目地址: https://gitcode.com/GitHub_Trending/gu/gutenberg

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

企业官网建设流程全解析