15%

全场主机优惠15%

测试技能，享折扣

使用代码：

Skills
开始使用
21.10.2024
Category icon管理

如何在WordPress中使用经典编辑器：安装、配置及其实际适用场景

WordPress Classic Editor 是一个基于 TinyMCE 的所见即所得内容编辑器，早于 WordPress 5.0 中引入的 Gutenberg 块系统。它提供单一的线性编辑画布——视觉上类似于 Microsoft Word——文本、媒体和 HTML 共存于一个连续的字段中，而非离散的、可堆叠的块。对于今天需要安装它的用户，简短的答案是：从 WordPress 插件库安装官方 Classic Editor 插件，激活它，并在 Settings > Writing 下配置默认编辑器。

这两句话涵盖了核心问题。本指南的其余部分涵盖两种编辑器之间的架构差异、选择其中一种的合理技术原因、配置边缘情况，以及强制使用 Classic Editor 实际上会带来更多问题的场景。

Classic Editor 与 Gutenberg 块编辑器：技术比较

在调整任何设置之前，值得了解您实际上在两者之间切换的内容。这个决定不仅仅是外观上的。

维度Classic Editor（TinyMCE）Gutenberg 块编辑器
———
**底层技术**TinyMCE 4.x 基于 iframe 的所见即所得React.js 组件树
**内容存储**`post_content` 中的原始 HTML带有块语法注释的 HTML（`<!– wp:paragraph –>`）
**REST API 依赖**最小化——无需 REST API 即可工作需要 REST API 才能完全正常运行
**自定义 Meta Box 支持**完整的原生支持部分支持——旧版 meta box 在兼容层中渲染
**页面构建器兼容性**高（Elementor Classic、WPBakery 等）不稳定——取决于构建器版本
**版本差异**整篇文章的 HTML 差异块级差异（更精细）
**性能（编辑器加载）**更轻量——无 React 包较重的初始 JS 负载（~400 KB+ 压缩后）
**无障碍访问**成熟、经过充分测试持续改进中，但历史上不够一致
**长期支持**通过插件维护；无新功能积极开发中，WordPress 核心方向
**短代码处理**在可视化标签中内联渲染专用短代码块

在操作上最重要的区别是内容存储。Classic Editor 保存干净的 HTML。Gutenberg 将每个内容单元包裹在充当块分隔符的 HTML 注释注解中。如果您曾经在系统之间迁移内容——到无头 CMS、静态站点生成器或非 WordPress 平台——Classic Editor 的输出更容易解析和移植。Gutenberg 的块语法是 WordPress 解析器专有的。

开发者和站点所有者仍然选择 Classic Editor 的原因

旧版插件和主题兼容性

许多商业插件——特别是较旧的表单构建器、电子商务扩展和自定义文章类型插件——注册了直接将字段注入文章编辑界面的 meta box。在 Gutenberg 中，这些 meta box 被降级到在 iframe 兼容垫片内渲染的可折叠侧边栏面板中。这个垫片并不总是正常工作：JavaScript 冲突出现，条件逻辑中断，某些 meta box UI 框架（例如 jQuery UI 对话框）无法在嵌套文档上下文中正确初始化。

如果您的站点依赖使用 add_meta_box() 且具有复杂 JavaScript 依赖 UI 的插件，Classic Editor 可以消除这整类问题。

REST API 限制

Gutenberg 编辑器持续向 WordPress REST API 发出后台请求——用于获取块模式、自动保存草稿、检索文章锁定状态和验证用户权限。在 REST API 被有意限制的加固服务器环境中（通过 add_filter('rest_authentication_errors', ...) 或阻止 /wp-json/ 的服务器级规则），Gutenberg 将部分或完全无法加载。Classic Editor 没有此类依赖，在这些限制下将正常运行。

多站点和基于角色的编辑器控制

在 WordPress 多站点安装中，网络管理员有时需要在所有子站点上强制执行一致的编辑体验——特别是在涉及非技术编辑人员时。Classic Editor 插件支持 Settings > Writing 选项，以禁止每个用户切换编辑器，无论其个人偏好如何，将所有用户锁定在 Classic Editor 中。Gutenberg 没有等效的网络级强制机制，除非使用自定义代码。

文字密集型内容的工作流速度

对于生产大量文字内容的出版商——新闻文章、文档、法律文件——Classic Editor 的单画布模式确实更快。无需插入新块、选择块类型或在块设置面板之间导航。按下 Enter 键继续写作即可。对于习惯使用键盘和 HTML 标签快捷键的编辑人员，这一点很重要。

如何安装 Classic Editor 插件

Classic Editor 不随 WordPress 核心捆绑。它由 WordPress 贡献者团队作为官方插件维护，可从 WordPress.org 插件库获取。

方法 1：通过 WordPress 仪表板安装

  1. 登录您的 WordPress 管理面板（/wp-admin）。
  2. 导航到 Plugins > Add New Plugin。
  3. 在搜索字段中，输入 Classic Editor。
  4. 找到由 WordPress Contributors 编写的插件——验证作者，因为有名称相似的仿冒插件。
  5. 点击 Install Now，然后点击 Activate。

方法 2：通过 WP-CLI 安装

如果您从命令行管理 WordPress——这在任何 VPS 托管环境中都是标准做法——WP-CLI 比仪表板 UI 快得多：

wp plugin install classic-editor --activate

要在多站点安装中进行网络范围的安装：

wp plugin install classic-editor --activate-network

方法 3：手动上传

从 wordpress.org/plugins/classic-editor 下载插件 ZIP 文件，然后通过 Plugins > Add New Plugin > Upload Plugin 上传，或直接将其解压到您的服务器：

cd /var/www/html/wp-content/plugins/
unzip classic-editor.zip

解压后，通过 WP-CLI 或仪表板激活。

配置 Classic Editor 设置

激活后，插件在 Settings > Writing 下公开两个配置选项。

所有用户的默认编辑器

第一个选项设置站点范围的默认值。您可以在 Classic Editor 和 Block Editor 之间选择。将此设置为 Classic Editor 意味着每个新文章和页面默认在 TinyMCE 中打开。

允许用户切换编辑器

第二个选项控制个别用户是否可以在每篇文章的基础上覆盖站点默认值。启用后，将鼠标悬停在 Posts > All Posts 列表中的文章上，会显示两个操作链接：Edit（在站点默认编辑器中打开）和 Edit (Classic Editor) 或 Edit (Block Editor)，具体取决于当前默认值。

大多数旧版站点的推荐配置：

  • 默认编辑器：Classic Editor
  • 允许用户切换：否

这可以防止编辑人员意外在 Gutenberg 中打开内容，并无意中将块语法注释注入到在 Classic Editor 中编写的文章中——这种混合可能会在某些主题中导致渲染异常。

使用 Classic Editor 界面

可视化标签（所见即所得模式）

可视化标签通过 TinyMCE 基于 iframe 的预览渲染您的内容。工具栏提供：

  • 文本格式：粗体（Ctrl+B）、斜体（Ctrl+I）、删除线、下划线
  • 段落样式：标题 1 至标题 6、预格式化、引用块
  • 列表：有序和无序，带缩进/取消缩进控件
  • 链接：插入/编辑带有目标和标题属性的超链接
  • 媒体插入：打开 WordPress 媒体库以插入图片、视频、音频和文档
  • 从 Word 粘贴：粘贴时去除 Microsoft Word 的专有 HTML 标记
  • 无干扰写作模式：全屏切换，隐藏所有管理 UI

工具栏有两行。如果您只看到一行，请点击工具栏切换按钮（第一行的最后一个图标）以显示第二行，其中包括段落样式选择器、文本颜色、字符映射和撤销/重做。

文本标签（原始 HTML 模式）

文本标签公开存储在 post_content 中的原始 HTML。这不是一个完整的代码编辑器——它缺乏语法高亮和行号——但它让您直接访问标记。有用的场景：

  • 插入 TinyMCE 会去除或转义的原始 <iframe> 嵌入
  • 添加可视化标签 UI 不公开的自定义 HTML 属性
  • 调试由 TinyMCE 自动标签清理引起的渲染问题

需要了解的关键行为：当您从文本标签切换回可视化标签时，TinyMCE 会执行 HTML 清理。它将关闭未关闭的标签，去除某些元素（在某些配置中如 <script>），并规范化空白。如果您在文本标签中编写原始 HTML，请始终在发布前验证它在切换回可视化标签后是否保持完整。

摘要、自定义字段和讨论 Meta Box

在主编辑器画布下方，Classic Editor 以其原始布局显示完整的 WordPress 原生 meta box 集：

  • 摘要：主题和 SEO 插件用于元描述的纯文本摘要
  • 自定义字段：存储在 wp_postmeta 中的键值对——无需切换到侧边栏面板即可直接访问
  • 讨论：每篇文章的评论和引用通知设置
  • 别名：可编辑的 URL 别名字段（也在发布框中）
  • 作者：无需离开页面即可重新分配文章作者

这些 meta box 在 Classic Editor 中始终可见且全宽显示。在 Gutenberg 中，它们要么隐藏在侧边栏中，要么在兼容 iframe 中渲染——对于严重依赖自定义字段的工作流来说，这是一个有意义的用户体验差异。

按文章切换编辑器

如果您启用了”允许用户切换”选项，每篇文章的编辑器切换工作方式如下：

从文章列表：

  1. 转到 Posts > All Posts。
  2. 将鼠标悬停在文章标题上。
  3. 根据需要点击 Edit (Classic Editor) 或 Edit (Block Editor)。

从编辑器内部：

在 Gutenberg 中，三点选项菜单（右上角）中会出现一个写着 Switch to Classic Editor 的链接。在 Classic Editor 中，屏幕顶部附近会出现一个写着 Switch to Block Editor 的链接。

警告：将在 Gutenberg 中编写的文章切换到 Classic Editor——然后保存——将在原始 HTML 中保留块语法注释注解。这些注释对前端渲染无害，但会在 Classic Editor 的文本标签中显示为字面文本，这可能会令人困惑。切换回 Gutenberg 将正确重新解析它们。反向场景（在 Gutenberg 中打开 Classic Editor 内容）是干净的，因为 Gutenberg 会自动将无法识别的 HTML 包裹在经典块中。

不使用插件禁用 Classic Editor

如果您想强制使用 Gutenberg 并阻止使用 Classic Editor——或者如果您想在不安装插件的情况下禁用 Gutenberg——WordPress 提供了一个过滤器钩子：

// In functions.php or a site-specific plugin — disable Gutenberg for all post types
add_filter( 'use_block_editor_for_post', '__return_false' );

这对文章编辑实现了与 Classic Editor 插件相同的效果，但不影响站点编辑器（全站编辑）。要完全禁用 Gutenberg，包括 FSE：

add_filter( 'use_block_editor_for_post', '__return_false' );
add_filter( 'use_widgets_block_editor', '__return_false' );
remove_theme_support( 'widgets-block-editor' );

在安装额外插件受到策略限制的环境中，或者您希望禁用逻辑通过版本控制在主题或插件中管理而不依赖于第三方插件的激活状态时，这种方法更为可取。

Classic Editor 与 WordPress 托管环境

Classic Editor 插件本身是轻量级的，不会带来有意义的服务器端要求。然而，您的托管环境的更广泛背景会以值得注意的方式影响编辑体验。

在共享托管计划中，WordPress 管理面板可能感觉迟缓，因为 PHP 执行和数据库查询与同一服务器上的其他租户竞争。在这种情况下，Classic Editor 明显比 Gutenberg 更轻量——更少的 REST API 调用、无 React 渲染开销，以及更小的 JavaScript 负载意味着管理端页面加载更快。如果您使用共享虚拟主机计划并发现块编辑器速度较慢，Classic Editor 是一个实用的优化方案。

在带 cPanel 的 VPS 上，您可以完全控制 PHP 内存限制、OPcache 配置和 MySQL 查询缓存。在这种环境中，两种编辑器都表现良好，选择纯粹成为工作流偏好而非性能必要性。

对于在独立服务器上运行的高流量 WordPress 安装，编辑器选择对前端性能基本上没有影响——编辑界面只由经过身份验证的管理员用户加载，而发布的 HTML 输出才是影响页面速度的关键。

常见陷阱和边缘情况

TinyMCE 去除有效 HTML：TinyMCE 的 valid_elements 和 extended_valid_elements 配置控制可视化编辑器中允许哪些 HTML 标签和属性。默认情况下，它会去除 <article>、<section>、<figure>（在较旧的配置中）等标签以及任何自定义数据属性。如果您的内容需要这些，您必须通过 tiny_mce_before_init 过滤器扩展 TinyMCE 的允许元素：

add_filter( 'tiny_mce_before_init', function( $init ) {
    $init['extended_valid_elements'] = 'span[*],div[*],section[*],article[*]';
    return $init;
} );

自动保存冲突：Classic Editor 使用较旧的 wp_autosave() JavaScript 函数，该函数向 wp-admin/post.php 发送带有 action=autosave 的 POST 请求。如果您的服务器有激进的速率限制或 WAF 规则阻止向 wp-admin 发送重复的 POST 请求，自动保存将静默失败。如果发生内容丢失，请监控您的服务器错误日志。

Classic Editor 和全站编辑（FSE）主题：如果您的活动主题是 FSE 主题（在 theme.json 中声明 "blockTemplates": true 的主题），Classic Editor 仍然适用于文章和页面内容，但站点编辑器（/wp-admin/site-editor.php）完全基于 Gutenberg，不受 Classic Editor 插件影响。您无法使用 Classic Editor 编辑 FSE 主题模板。

插件停用行为：停用 Classic Editor 插件不会转换您的内容。在 Classic Editor 中编写的文章保持为干净的 HTML。在 Gutenberg 中编写的文章保留其块语法。Gutenberg 将正确解析两者。停用插件没有数据丢失风险。

决策矩阵：您应该使用哪种编辑器？

在以下情况下使用 Classic Editor：

  • 您的站点使用具有复杂 meta box UI 的插件，这些插件在 Gutenberg 的兼容层中无法正常工作
  • 您的服务器限制了 WordPress REST API
  • 您正在将内容迁移到非 WordPress 平台，需要干净、可移植的 HTML
  • 您的编辑团队规模较大、非技术性，并且在 Classic Editor 工作流上受过培训
  • 您在资源受限的共享托管环境中运行 WordPress

在以下情况下使用 Gutenberg：

  • 您正在构建没有旧版插件依赖的新站点
  • 您的主题基于块或兼容 FSE
  • 您需要可重用块、块模式或复杂的多列布局，而无需页面构建器
  • 您正在为客户项目使用 register_block_type() 构建自定义块
  • 您希望利用站点编辑器进行完整的主题自定义

在以下情况下同时使用两者（启用每用户切换）：

  • 您有一个混合团队，其中一些编辑偏好 Classic，另一些偏好 Gutenberg
  • 您正处于将旧版站点迁移到基于块的架构的过渡期
  • 您站点上的不同文章类型有不同的复杂性要求

实用技术清单

在将您的生产站点切换到 Classic Editor 之前，请验证以下内容：

  • ] 确认 Classic Editor 插件版本是最新的（查看 [wordpress.org/plugins/classic-editor 获取最新版本）
  • [ ] 在部署到生产环境之前，在暂存环境中测试所有活动插件的 meta box UI 在 Classic Editor 中的表现
  • [ ] 如果您有可能与插件默认值冲突的自定义 TinyMCE 配置，请检查您的 tiny_mce_before_init 过滤器
  • [ ] 决定”允许切换”策略并为您的编辑团队记录
  • [ ] 如果使用 WP-CLI，请使用 wp plugin list --status=active 确认插件已激活
  • [ ] 检查您的主题是否依赖 Gutenberg 特定的块样式（wp-block-* CSS 类）进行前端渲染
  • [ ] 在对现有 Gutenberg 内容的站点进行任何编辑器切换更改之前备份您的数据库
  • [ ] 如果在多站点网络上，决定是网络范围激活还是按站点激活，并在网络级别通过 Settings > Writing 强制执行

通过确保您的 SSL 证书有效且自动续期，将您的 WordPress 设置与适当安全的域名配对——无论您使用哪种编辑器，WordPress 管理面板传输的身份验证 Cookie 都必须受到 HTTPS 保护。

对于管理包含电子邮件通知、作者通信或新闻通讯集成的编辑工作流的团队，专用的电子邮件托管设置可确保 WordPress 事务性电子邮件（密码重置、评论通知、文章状态更改）可靠送达，而不是通过共享服务器的默认 sendmail 路由。

常见问题

Classic Editor 插件是否影响前端渲染或站点性能？

不影响。Classic Editor 插件只修改管理端编辑界面。它对 WordPress 向访问者渲染页面的方式没有任何影响。前端性能由您的主题、缓存层和服务器配置决定——而不是由用于编写内容的编辑器决定。

从 Gutenberg 切换到 Classic Editor 会损坏我现有的基于块的内容吗？

不会。Gutenberg 将块注解作为 HTML 注释存储在 post_content 中。Classic Editor 将在其文本标签中显示此原始 HTML，并尝试在可视化标签中渲染它。内容不会被删除或损坏。如果您在 Classic Editor 中保存 Gutenberg 文章而不编辑它，块注解将被保留。如果您编辑并保存，TinyMCE 可能会规范化一些空白，但不会去除注释注解。

我可以对某些文章类型使用 Classic Editor，对其他文章类型使用 Gutenberg 吗？

可以，但不能通过 Classic Editor 插件的设置 UI。您需要在代码中使用 use_block_editor_for_post_type 过滤器：

add_filter( 'use_block_editor_for_post_type', function( $use_block_editor, $post_type ) {
    if ( $post_type === 'product' ) {
        return false; // Use Classic Editor for WooCommerce products
    }
    return $use_block_editor;
}, 10, 2 );

Classic Editor 插件会被永久维护吗？

WordPress.org 承诺至少维护 Classic Editor 插件的安全和兼容性更新至 2024 年，并且在该承诺之后继续接收更新。但是，它不会获得新功能——它处于维护模式。对于长期新项目，Gutenberg 是 WordPress 核心的战略方向。

Classic Editor 与 WooCommerce 兼容吗？

兼容。WooCommerce 的产品编辑器历来建立在 Classic Editor meta box 上。最近的 WooCommerce 版本（8.x+）引入了基于块的新产品编辑器，但基于 Classic Editor 的旧版产品表单仍然可用，并且是大多数安装的默认选项。Classic Editor 插件不会干扰 WooCommerce 的产品编辑界面。

15%

全场主机优惠15%

测试技能，享折扣

使用代码：

Skills
开始使用
502 Bad Gateway 详解：含义、原因及故障排除方法
502 Bad Gateway 详解：含义、原因及故障排除方法

Table of Contents 关键词 为什么502错误令人如此困扰 502 Bad Gateway 的真正含义 错误在真实请求链中的发生位置 502错误的成因：主要故障类别 502错误的智能排查流程 第一阶段：确定所在层级 第二阶段：验证上游路径 第三阶段：将命令作为证据，而非例行程序 排查路径如何因托管模式而异 以层级思维应对，而非陷入恐慌 关键词 这份简短词汇表涵盖了在深入解释阶段最容易引起混淆的基础设施术语。...