常见问题

这是插件审查团队在审查插件时遇到的一些最常见问题的汇编。

本列表包含来自团队电子邮件消息的摘录，不应被视为完整或详尽的列表；审查的结果取决于团队的亲自审查。

安全

清理

输入数据必须在输出时进行清理、验证和转义

当您在插件中包含 POST/GET/REQUEST/FILE 调用时，对它们进行清理、验证和转义非常重要。这里的目的是防止用户意外通过系统发送垃圾数据，并保护他们免受潜在的安全问题。

清理：输入的数据（无论是用户还是自动输入的）必须尽快进行清理。这降低了 XSS 漏洞和中间人攻击（posted data is subverted）的可能性。

验证：无论什么情况，所有数据都应进行验证。即使您进行了清理，也要记住，您不希望有人在只有数字作为有效值时输入‘dog’。

转义：输出时必须正确转义数据，以便在 echo 时无法劫持管理界面。有许多 esc_*() 函数可以使用，以确保您不会向人们显示错误的数据。

为了帮助您完成这项工作，WordPress 提供了一些清理和转义函数。您可以在这里阅读有关这些函数的内容：

https://developer.wordpress.org/apis/security/sanitizing/ https://developer.wordpress.org/apis/security/escaping/

请记住：您必须使用最适合上下文的函数。如果您正在清理电子邮件，请使用 sanitize_email() ，如果您正在输出 HTML，请使用 wp_kses_post() ，依此类推。

这里的一个简单口号是：

尽早清理
转义要晚些
始终验证

清理所有内容，检查所有内容，转义所有内容，并且永远不要信任用户总是输入合理的数据。毕竟，用户来自各行各业。

清理：关于转义和清理函数的混淆

注意：转义函数不能用于清理。它们服务于不同的目的。即使它们似乎非常适合此目的，大多数函数都是可过滤的，人们期望使用它们进行转义。因此，另一个插件可能会改变它们的行为并使您的插件处于风险之中并变得可利用。

如果您试图 echo 变量，您必须先清理它然后转义它，例如：

echo esc_html(sanitize_text_field($_POST['example']));

清理：使用过滤函数进行清理

注意：当使用像 filter_var、filter_var_array、filter_input 和/或 filter_input_array 这样的函数时，您需要 将 FILTER 参数设置为任何可以清理输入的过滤器类型。

如果留空过滤参数，PHP 默认将应用过滤器“FILTER_DEFAULT”，这实际上并没有进行清理。

$post_id = filter_input(INPUT_GET, 'post_id', FILTER_SANITIZE_NUMBER_INT);

清理：随机数

注意：在使用 wp_verify_nonce 检查随机数时，您需要使用 wp_unslash AND sanitize_text_field 清理输入，这是因为该函数是可插拔的，扩展程序不应信任其输入值。

示例：

if ( ! isset( $_POST['prefix_nonce'] ) || ! wp_verify_nonce( sanitize_text_field( wp_unslash ( $_POST['prefix_nonce'] ) ) , 'prefix_nonce' ) )

处理整个输入

我们强烈建议您永远不要尝试处理整个 $_POST/$_REQUEST/$_GET 堆栈。这会使您的插件变慢，因为您不必要地循环遍历不需要的数据。相反，您应该只尝试处理对插件功能所需的项。

转义

变量和选项在 echo 时必须进行转义

与清理所有内容密切相关，所有被 echo 的变量在被 echo 时都需要转义，以便它们无法劫持用户或（更糟）管理界面。有许多 esc_*() 函数可以使用，以确保您不会向人们显示错误的数据，以及一些允许您安全地 echo HTML 的函数。

目前，我们要求您在 echo所有 $-变量、选项和任何类型的生成数据时进行转义。这意味着您不应该在构建变量时进行转义，而是在最后输出它时进行转义。我们称之为“晚些转义”。

除了保护自己免受可能的 XSS 漏洞之外，晚些转义确保您保持未来的自己安全。虽然今天您的代码可能只输出硬编码的内容，但这在未来可能不成立。通过花时间正确转义当您 echo 时，您防止了未来的错误成为关键的安全问题。

这同样适用于您保存到数据库的选项。即使您在保存时正确进行了清理，清理和转义的工具也是不可互换的。清理确保它安全用于处理和存储在数据库中。转义使其安全输出。

还要注意，有时一个函数在 echo 时实际上应该返回内容。这是返回 JSON 编码内容时的常见错误。非常罕见的是您实际上应该 echo 的内容。Echo 是因为它需要显示在屏幕上供人类阅读。返回（即您会在 API 中执行的操作）可以 json 编码，但要记住清理当您保存到该 json 对象时！

有许多选项可以安全所有类型的内容（html、email 等）。是的，即使是 HTML 也需要正确转义。

请记住：您必须使用最适合上下文的函数。基本上有选项可以 echo 所有内容。即使是安全地 echo HTML。

转义：使用 esc_url_raw

我们知道这令人困惑，esc_url_raw 函数不是转义函数，而是一个类似于 sanitize_url 的清理函数。具体来说，它用于清理 URL 以便在数据库或重定向中使用。

适当的转义 URL 的函数是 esc_url。

转义：使用 __

函数 __ 获取未转义的翻译，请要么：

• 使用转义结果值的替代函数，如 esc_html__ 或 esc_attr__。
• 或者用适当的转义函数（如 esc_html、esc_attr、wp_kses_post 等）包装 __ 函数。

示例：

<h2><?php echo esc_html__('Settings page', 'plugin-slug'); ?></h2>
<h2><?php echo esc_html(__('Settings page', 'plugin-slug')); ?></h2>

转义：使用 _e 和 _ex

函数 _e 和 _ex 输出未转义的翻译，请使用转义输出的替代函数。

• _e 的替代方案是 esc_html_e、esc_attr_e 或简单地使用由转义函数包装并在 echo 内的 __。
• _ex 的替代方案是使用由转义函数包装并在 echo 内的 _x。

示例：

<h2><?php esc_html_e('Settings page', 'plugin-slug'); ?></h2>
<h2><?php echo esc_html(__('Settings page', 'plugin-slug')); ?></h2>
<h2><?php echo esc_html(_x('Settings page', 'Settings page title', 'plugin-slug')); ?></h2>

转义：使用 json_encode

当您需要 echo JSON 时，最好使用函数 wp_json_encode，同时确保您没有通过第二个参数传递的选项避免转义。

echo wp_json_encode($array_or_object);

转义：HTML

在转义时，存在某些情况您的插件需要输出 HTML。这可以使用函数wp_kses_post或wp_kses来完成。函数wp_kses_post将允许任何可以在帖子内容中使用的常见 HTML，wp_kses将允许您使用其第二个和第三个参数设置的任何 HTML，请参考其文档。

一个常见的错误是使用esc_html来转义 HTML。此函数并非为此目的设计，它旨在转义将进入内部HTML 标签的输出，因此它会剥离任何 HTML 标签。

示例：

echo wp_kses_post($html_content);
echo wp_kses($html_content, array( 'a', 'div', 'span' ));

转义：使用清理函数

清理函数不能用于转义。它们服务于不同的目的。即使它们似乎非常适合此目的，大多数函数都是可过滤的，人们期望使用它们进行清理。因此，另一个插件可能会改变它们的行为并使您的插件处于风险和可利用的状态。

如果您尝试回显变量，您必须先清理它然后转义它，例如：

echo esc_html(sanitize_text_field($_POST['example']));

文件

文件：使用 WordPress 文件上传器

请使用 WordPress 的文件上传器

当插件使用move_uploaded_file()时，它们将其上传排除在 WordPress 函数的内置检查和平衡之外。相反，您应该使用内置函数：

文件：未过滤的上传

不允许 ALLOW_UNFILTERED_UPLOADS。

将此常量设置为 true 将允许用户上传任何类型的文件（包括 PHP 和其他可执行文件），从而产生严重的安全风险。作为开发人员，我们不应在任何逻辑中使用或允许使用此常量，甚至不在条件语句中使用。

WordPress 包含一个安全文件列表，您可以在函数wp_get_mime_types中看到。

如果您需要添加列表中未包含且不会构成安全风险的具体文件，您可以使用upload_mimes过滤器来实现。

文件：远程调用文件

将图像、js、css 和其他脚本卸载到您的服务器或任何远程服务（如 Google、MaxCDN、jQuery.com 等）是不允许的。当您调用远程数据时，您引入了对另一个站点的非必要依赖。如果您调用的文件不是 WordPress 核心的一部分，则应在插件中本地包含它，而不是远程包含。如果该文件确实包含在 WordPress 核心中，请调用该文件。

此规则的例外情况是如果您的插件正在执行服务。我们将根据具体情况允许此操作。由于这可能会令人困惑，我们有一些不允许的示例：

• 将 jQuery CSS 文件卸载到 Google – 您应在插件中包含 CSS。
• 插入带有帮助文档的 iframe – 链接或在插件中包含文档是首选。
• 从您的域调用图像 – 它们应包含在您的插件中。

以下是我们允许的一些示例：

• 从 Google 或其批准的 CDN 调用字体家族（如果符合 GPL）
• 回叫您服务器的 API 以处理可能的垃圾评论（如 Akismet）
• 将评论卸载到您的服务器（如 Disqus）
• 向服务提供商（如 Twitter 或 YouTube）发出 oEmbed 调用

请从插件中删除外部依赖项，并尽可能在插件中包含所有文件（即不是远程调用的）。如果您认为您正在提供服务，请以解释服务、被调用的服务器以及是否需要账户来连接的方式重写您的 readme.txt。

库

库：使用开发版本

使用库的 Beta / Alpha / 开发版本

除非您的插件需要其功能，否则我们不建议您使用库的 beta 版本。相反，您应该使用该库的最稳定版本。

如果您有技术原因必须使用 beta 版本，请解释原因。否则，请将您的库更改为稳定版本。

库：不再维护

不再维护的库是不允许的

我们不再接受使用任何不再受其开发人员支持或维护的库，因为它们构成了重大的安全风险。请考虑其他选项。

库：已过时

您使用的第三方库中至少有一个已过时。请升级到最新稳定版本以获得更好的支持和安全性。我们不建议您使用 beta 版本。

WPDB：不安全的 SQL 调用

在进行数据库调用时，保护您的代码免受 SQL 注入漏洞非常重要。您需要更新代码以使用wpdb调用并使用 prepare() 准备查询以保护它们。

请审查以下内容：

• https://developer.wordpress.org/reference/classes/wpdb/#protect-queries-against-sql-injection-attacks
• https://codex.wordpress.org/Data\_Validation#Database
• https://make.wordpress.org/core/2012/12/12/php-warning-missing-argument-2-for-wpdb-prepare/
• https://ottopress.com/2013/better-know-a-vulnerability-sql-injection/

WPDB：占位符数组

注意：使用占位符将单个值传递给wpdb::prepare()相当直接，但如果我们需要传递一个值的数组呢？

您需要为数组的每个项目创建一个占位符，并将所有相应的值传递给这些占位符，这似乎很棘手，但这里有一个代码片段可以做到。

$wordcamp_id_placeholders = implode( ', ', array_fill( 0, count( $wordcamp_ids ), '%d' ) );
$prepare_values = array_merge( array( $new_status ), $wordcamp_ids );
$wpdb->query( $wpdb->prepare( "
    UPDATE `$table_name`
    SET `post_status` = %s
    WHERE ID IN ( $wordcamp_id_placeholders )",
    $prepare_values
) );

有一个核心工单可以在未来使这变得更容易：https://core.trac.wordpress.org/ticket/54042

不使用 HEREDOC-NOWDOC

不要在插件中使用 HEREDOC 或 NOWDOC 语法

虽然两者都是完全有效的，并且在许多方面是 PHP 的令人向往的功能，允许您输出内容，但它们带来的成本对大多数插件来说太高了。

主要问题是大多数（如果不是全部）代码嗅探器在使用 HEREDOC 或 NOWDOC 时无法检测代码中缺乏转义。虽然有一些方法可以绕过这个问题，但它们的结果是将所有可读性扫进垃圾堆，并留下一个混乱的 mess，无法正确扫描。

我们认为这里的风险高于收益，这就是为什么我们不允许可使用的原因。

直接文件访问

允许对插件文件的直接文件访问

直接文件访问发生在有人直接查询 PHP 文件时。这可以通过在浏览器的 URL 栏中输入文件的完整路径或直接向文件发送 POST 请求来完成。

对于仅包含类或函数定义的文件，直接访问时发生奇怪事情的风险很小。但是，对于包含可执行代码（例如函数调用、类实例创建、类方法调用或其他 PHP 文件的包含）的文件，安全风险很难预测，因为它取决于具体情况，但它可能存在且可能很高。

您可以通过在所有可能如果直接访问则执行代码的 PHP 文件顶部添加以下代码来轻松防止这种情况：

if ( ! defined( 'ABSPATH' ) ) exit; // Exit if accessed directly

兼容性

前缀

通用函数/类/define/命名空间/选项名称

所有插件都必须拥有唯一的函数名、命名空间、define、类和选项名称。这可以防止您的插件与其他插件或主题发生冲突。我们需要您更新插件以使用更独特和明确的名称。

一个很好的方法是使用前缀。例如，如果您的插件名为“Easy Custom Post Types”，那么您可以使用如下名称：

• 函数 ecpt_save_post()
• 类 ECPT_Admin{}
• 命名空间 ECPT;
• update_option( 'ecpt_settings', $settings );
• define( 'ECPT_LICENSE', true );
• 全局变量 $ecpt_options;

不要再尝试使用两个 (2) 或三个 (3) 字母的前缀了。我们仅在 WordPress.org 上就托管了近十万个插件。在我们服务器之外还有数万个更多。相信我们，您会遇到冲突。

您还需要避免使用 __ (双下划线)、wp_ 或 _ (单下划线) 作为前缀。这些是为 WordPress 本身保留的。您可以在类内部使用它们，但不能作为独立的函数。

请记住，如果您使用 _n() 或 __() 进行翻译，那是可以的。我们仅谈论您为插件创建的函数，而不是来自 WordPress 的核心函数。事实上，正是这些核心功能使得您需要在自己的插件中不使用这些前缀！您不希望破坏您的用户使用的 WordPress。

与此相关的是，使用 if (!function_exists('NAME')) { 围绕所有您的函数和类听起来是个好主意，直到您意识到致命的缺陷。如果其他东西有一个同名的函数并且它们的代码先加载，您的插件就会损坏。使用 if-exists 应仅保留给共享库。

请记住：好的前缀名称对您自己的插件来说是独特且明确的。这将有助于您和下一个人在调试时，以及防止冲突。

PHP

PHP：不要使用短标签

PHP 的短标签的主要问题在于 PHP 选择了一个由另一种语法使用的标签 (<?)：XML。考虑到 XML 解析和管理是多么普遍，这是一个大问题。

我们知道从 PHP 5.4 开始，<?= ... ?> 标签在任何地方都得到支持，无论短标签设置如何。这意味着它们应该可以在可移植代码中使用，但事实证明并非如此。再加上许多代码嗅探器在使用短标签时无法检测代码中缺乏转义的事实，这使得对任何人来说都不值得麻烦。

基本上这里的风险远高于收益，这就是为什么我们不允许使用它们的原因。

PHP：全局更改设置

不要强制全局设置 PHP 设置

虽然许多插件可能需要最佳的 PHP 设置，但我们恳请您不要将它们设置为全局默认值。

拥有像 ini_set('memory_limit', '-1'); 这样的定义在全局运行（如在 init 或您的代码的 __construct() 部分）意味着您将为此站点上的所有内容运行该设置，这可能会导致您的用户违反其主机上的任何限制或限制。

如果您必须使用这些设置，您需要将它们专门限制为仅需要它们的精确函数。

PHP：设置默认时区

这很少是个好主意。人们应该能够在 WordPress 中定义自己的时区。

此外，WordPress 明确设置并期望默认时区为 UTC（在 settings.php 中），日期/时间函数有时依赖于默认时区是 UTC 这一事实。例如，如果您执行 date_default_timezone_set(get_option('timezone_string'))，然后稍后尝试从 get_post_time() 或 get_post_modified_time() 获取 GMT 时间戳，它将无法给您正确的日期。

PHP：错误报告

不要在生产代码中使用错误报告

虽然 error_reporting() 是 PHP 中的绝佳工具（https://www.php.net/manual/en/function.error-reporting.php），但如果您在插件中永久设置它，您将破坏所有使用您代码的人。如果他们有一个理由尝试调试恰好使用您代码的网站，他们将无法获得干净的测试，因为您在干扰输出。它在您的插件的日常功能中没有位置。

插件标准

主文件约定

插件的主文件名不符合约定。

我们希望主插件文件（包含插件头信息的文件）具有与插件文件夹相同的名称，这也与插件的 slug / 永久链接相同。

例如，如果您的插件 slug 是 ecpt-social-manager，我们期望您的主插件文件名是 ecpt-social-manager.php。

请注意，使用一些常见名称作为主插件文件的文件名在某些配置中会导致问题。

请查看我们关于如何 在插件中构建文件和文件夹结构 的提示。

不完整的头信息

您的头信息要么缺失，要么不完整。

请查看 头信息要求 并相应更新您的插件，将头信息仅放在主文件中。

不完整的 Readme

您的 readme 要么缺失，要么不完整。

在某些情况下，例如对于第一个插件、具有依赖项的插件或调用外部服务的插件，我们需要您提供完整的 readme。这意味着您的 readme 必须包含头信息以及适当的描述和文档，说明其工作原理以及如何使用的说明。

我们的目标是确保每个人都知道他们正在安装什么以及在安装之前需要做什么。没有意外。如果您的插件正在向其他服务器发出调用，这一点尤为重要。我们期望在用户安装您的插件之前向他们提供所需的所有信息。

您的 readme 还必须根据 Validator 进行验证，否则我们将拒绝它。请记住，我们不希望看到 readme.MD。虽然它们可以工作，但 readme.txt 文件将始终优先，并且并非所有 markdown 都能按预期工作。

我们恳请您基于此创建您的 readme：https://wordpress.org/plugins/readme.txt

未声明 GPL 兼容许可证

必须声明此插件的许可证。您可以使用插件 readme 和插件头信息中可用的字段来执行此操作。

请记住，所有代码、数据和图像——任何存储在托管在 WordPress.org 上的插件目录中的内容——都必须符合 GPL 或 GPL 兼容许可证。包含的第三方库、代码、图像或其他内容也必须兼容。

对于特定兼容许可证列表，请阅读 gnu.org 上的 GPL 兼容许可证列表。

不正确的稳定标签

在您的 readme 中，您的“稳定标签”与主插件文件中指示的插件版本不匹配。

您的稳定标签应该是您插件的稳定版本，而不是 WordPress 的稳定版本。为了使您的插件能够从 WordPress.org 正确下载，这些值必须相同。如果它们不同步，您的用户将无法获得您代码的正确版本。

我们建议您使用语义化版本管理（也称为 SemVer）来管理版本：

• 软件版本管理
• SemVer

请注意：虽然目前使用 trunk 的稳定标签在插件目录中有效，但它实际上并不是指示新版本的支持或推荐方法，并且已知会导致自动更新问题。

我们恳请您正确使用标签并在发布插件新版本时递增它们，就像您更新主文件中的插件版本一样。使它们匹配是全面向前支持的最佳方式。

声明的许可证不匹配

在声明此插件的许可证时，它必须相同。

请确保您在 readme 文件和插件头信息中声明相同的许可证。

只要其他来源的代码在许可证下得到充分说明且属于 GPL 或兼容 GPL 的许可证，本插件包含这些代码是可以的，但我们需要为您的代码声明唯一的许可证。

使用 HTTP API

使用 CURL 代替 HTTP API

WordPress 自带一个广泛的 HTTP API，应使用它而不是创建自己的 curl 调用。它既更快又更广泛。如果必须的话，它会回退到 curl，但它会首先使用 WordPress 的原生功能。

如果您需要，可以使用 setopt 与 https://developer.wordpress.org/reference/hooks/http_api_curl/

请注意：如果您在第三方供应商库中使用 CURL，这是允许的。我们需要纠正的是您自己的代码（专属于此插件或任何专用的 WordPress 库）。

使用 wp_enqueue 命令

您的插件没有正确包含 JS 和/或 CSS。您应该使用内置函数：

当包含JavaScript 代码时，您可以使用：

• wp_register_script() 和 wp_enqueue_script() 从文件添加 JavaScript 代码。
• wp_add_inline_script() 为之前声明的脚本添加内联 JavaScript 代码。

当包含CSS时，您可以使用：

• wp_register_style() 和 wp_enqueue_style() 从文件添加 CSS。
• wp_add_inline_style() 为之前声明的 CSS 添加内联 CSS。

请注意，自 WordPress 5.7 起，您可以使用新函数和过滤器传递诸如 async、nonce 和 type 等属性：WordPress 5.7 中的脚本属性相关函数

如果您想在管理页面中加载，您将需要使用管理加载。

• admin_enqueue_scripts
• admin_print_scripts
• admin_print_styles

包含核心中已有的库

您的插件包含了一个 WordPress 已经包含的库的副本。

WordPress 包含许多有用的库，如 jQuery、Atom Lib、SimplePie、PHPMailer、PHPass 等。出于安全和稳定性的原因，插件不得在其代码中包含这些库，而必须使用随 WordPress 分发的这些库的版本。

您可以在这里查看 JS 库列表：

WordPress 包含和注册的默认脚本和 JS 库

虽然我们还没有一个很好的面向公众的页面来列出所有这些库，但我们在这里有一个列表：

核心贡献者

本地包含核心之外的附加组件是可以的，但请仅添加这些额外文件。例如，您不需要整个 jQuery UI 库用于一个文件。如果您的代码无法与内置版本的 jQuery 一起工作，这很可能是 noConflict 问题。

国际化

国际化：使用变量

国际化：不要将变量或定义用作文本、上下文或文本域参数。

为了使字符串在您的插件中可翻译，您正在使用一组特殊函数。这些函数统称为“gettext”。

有一个 WordPress 社区中的专门团队 用于翻译并帮助将 WordPress 核心、插件和主题的字符串翻译成其他语言。

为了使它们能够翻译此插件，请不要使用变量或函数调用作为任何 gettext 函数的文本、上下文或文本域参数，所有参数都必须是字符串。请注意，翻译解析器在不执行代码的情况下读取代码，因此它无法读取这些函数中不是字符串的内容。

例如，如果您的 gettext 函数如下所示……

esc_html__( $greetings , 'plugin-slug' );

……翻译者将无法看到任何可翻译的内容，因为 $greetings 不是字符串，它无法被翻译。您需要提供要翻译的字符串，以便他们可以在翻译系统中看到并翻译它，正确的做法如下……

esc_html__( 'Hello, how are you?' , 'plugin-slug' );

这也适用于翻译域，这是一个错误的调用：

esc_html__( 'Hello, how are you?' , $plugin_slug );

这里的修复方法如下：

esc_html__( 'Hello, how are you?' , 'plugin-slug' );

另外请注意，翻译域必须与您的插件 slug 相同。

如果我们想在翻译中包含动态值怎么办？很简单，您需要添加一个占位符，它将是字符串的一部分，并在 gettext 函数完成其魔法后更改它，您可以使用 printf 来做到这一点，如下所示：printf( /* translators: %s: First name of the user */ esc_html__( 'Hello %s, how are you?', 'plugin-slug' ), esc_html( $user_firstname ));

您可以在 此处阅读更多信息。

合规性

更改已激活的插件

不允许插件更改其他插件的激活状态，这是必须由用户执行的操作。

也不允许干扰用户在激活或停用插件时的操作，除非这样做是为了防止错误（例如：当您的插件依赖于另一个插件时，在该插件未激活时停用您的插件）。

WordPress 6.5 引入了 插件依赖项，您可以使用它来管理依赖项（尽管如果您将其用作后备方案是可以的）。

更新检查器

包含更新检查器/更改更新功能

请删除您插件中用于提供更新的检查。

我们不允许插件向其他服务器打电话以获取更新，因为我们通过 WordPress.org 托管为您提供此服务。我们的准则之一是您实际上使用我们的托管服务，因此我们需要您删除该代码。

我们还要求插件不得干扰内置更新器，因为它会导致用户在 WordPress 5.5 及更高版本中出现意外结果。

未记录的第三方

对第三方或外部服务的未记录使用

我们允许插件要求使用第三方（即外部）服务，前提是它们以清晰的方式得到充分说明。

我们要求联系其他服务的插件披露这一点，使用清晰和简单的语言，以便用户了解数据被发送到哪里。这使他们能够确保任何与数据传输相关的法律问题都得到解决。即使您是第三方服务提供商也是如此。

为此，您必须更新您的 readme 以执行以下操作：

• 清楚说明您的插件依赖第三方作为服务以及在何种情况下
• 提供指向服务的链接。
• 提供指向服务使用条款和/或隐私政策的链接。

请记住，这是为了您自己的法律保护。对服务的使用必须事先声明并得到充分说明。

包含不必要的文件夹

此插件包含看起来对于运行您的插件不需要的文件夹和文件。一些示例包括：

• 开发工具
• 生产环境不需要的供应商文件夹（bower、node、grunt 等）
• 演示
• 单元测试

如果您试图包含您自己的代码的可读版本（以符合我们的准则），这是可以的，请记住我们也允许您在 readme 中放置指向它们的链接。

您还应保留和/或链接配置文件，例如composer.json文件，以便他人可以审查、研究并分叉此代码。

详细插件指南

但是您可以并且应该安全地删除插件中其他不需要的文件夹。

不允许的文件

插件通常由与插件功能相关的文件（php、js、css、txt、md）以及可能的一些多媒体文件（png、svg、jpg）和/或数据文件（json、xml）组成。

我们检测到一些不属于插件中通常存在的文件，它们是否必要？如果不必要，则不允许这些文件存在。

包含来自“高级”来源的代码

某些高级库明确不允许包含在免费（WordPress.org托管）插件中。必须删除这些库。

GPL

GPL：包含非 GPL 兼容代码

为了被收录在我们的目录中，所有代码都必须与 GPLv2（或更高版本）许可证兼容。

您必须删除该代码并修改插件以使其不再需要。我们建议您找到 GPL 兼容的代码并使用它。有关哪些类型的许可证与 GPL 兼容的更多信息，请查看以下链接：

• GNU 许可证 – 许可证列表
• GPL FAQ – 所有兼容性

GPL：没有公开文档的资源

您的压缩内容没有公开文档资源

在审查您的插件时，我们无法找到您 JavaScript 和/或 CSS 相关源代码的非编译版本。

为了遵守我们关于代码可读性的指南，我们需要您包含源代码和/或对您在插件中包含的非压缩开发库的链接。如果您包含链接，这可能位于您的源代码中，但我们要求您也在 readme 中包含它。

详细插件指南

我们强烈认为开源的一个优势是审查、观察和适应代码的能力。通过维护一个免费可用代码的公共目录，我们鼓励并欢迎未来的开发者与 WordPress 互动并将其向前推进。

话虽如此，随着使用更复杂库的大型插件的出现，人们很好地利用了构建工具（如 composer 或 npm）来生成其分发的生产代码。为了在保持插件大小较小的同时仍然鼓励开源开发的需求之间取得平衡，我们需要插件将任何压缩文件的源代码以易于查找的位置向公众提供，并在 readme 中对其进行文档说明。

例如，如果您制作了一个 Gutenberg 插件并使用 npm 和 webpack 对其进行压缩和缩小，您必须要么在发布的插件中包含源代码，要么提供对公共维护源代码的访问权限，以便他人可以审查、研究并分叉。

我们强烈建议您包含有关如何使用任何构建工具的说明，以鼓励未来的开发者。

GPL：使用 composer 但没有 composer.json 文件

我们注意到您的插件正在使用 Composer 来处理库依赖项，这很好，因为它将有助于在未来维护和更新您的插件，同时避免与其他使用相同库的插件发生冲突。

composer.json文件描述了您项目的依赖项，也可能包含其他元数据。它是一个小文件，通常可以在插件的最顶层目录中找到。

由于开源的一个优势是审查、观察和适应代码的能力，我们希望您将该文件包含在您的插件中，即使它仅用于开发目的。这将允许他人行使我们所有人都受益的开源自由。