发布插件到 WordPress.org
WordPress.org 为每一个想要开发插件的开发者提供免费托管服务,通过这个服务,我们可以: 监控插件下…
WordPress.org 为每一个想要开发插件的开发者提供免费托管服务,通过这个服务,我们可以:
- 监控插件下载数量
- 获取插件版本使用统计
- 接收用户的反馈和评价
- 通过免费论坛提供支持
WordPress.org 同时提供了一个 WordPress插件 API,供开发者监控插件的统计数据。
要求
WordPress.org 有一个详细的插件指南,指南中提供了示例和说明,下面是其中最重要的几个方面。
- 插件的许可能必须与 GNU通用公共许可证v2 或更高版本的兼容,强烈建议使用和 WordPress 相同的许可证 – “GPLv2或更高版本”,如果没有为插件指定许可证,则插件的许可能默认被认为兼容 GPLv2或更高版本。
- 插件和开发者不得做任何非法、不诚实或道德上的冒犯行为。
- 提供的 Subversion 版本库只能用于 WordPress插件,插件目录是一个托管和分发插件的站点,也不是公共列表站点。
- 插件不得在公共站点上嵌入外部链接(如 “Power by” 链接或广告),也不得在没有明确用户许可和文档的情况下调用外部服务。
插件提交
我们需要通过以下 3 个步骤提交插件到 WordPress.org 插件库。
- 在 WordPress.org 注册一个有效的、经常使用的电子邮件地址,如果代表公司提交插件,请使用公司官方的电子邮件地址注册。
- 添加 plugins@wordpress.org 到电子邮件的白名单,以确保可以收到插件库发送的电子邮件。
- 提交插件,简要介绍一下插件功能,以及一个完整的,准备好的插件。
一旦插件进入等待审核队列,WordPress插件审核团队会在 14 个工作日内审核插件,大部分问题可以通过遵循知道方针来避免。如果发现插件有问题,审核团队会联系开发人员,并提改进建议。获得批准后,开发人员将收到一封电子邮件,其中包含如何访问 Subversion 存储库的详细信息,然后我们就可以通过 SVN 来上传我们的插件了。
上传后插件(和一个描述文件)后,插件将出现在插件目录中。
更多信息
- 如何使用SVN
- readme.txt是如何工作的
- 插件资源(标题图片和图标)如何工作
- 特殊的用户角色和功能
- 开发者FAQ
- 插件安全
- 接管现有的插件
详细的插件指南
插件目录
WordPress插件目录的目的是为所有 WordPress 用户(从技术人员到普通用户)提供一个空间, 供我们下载安全的、与 WordPress 项目目标一致的插件。
为此,我们希望确保为开发人员提供一个简单透明的过程来提交插件到插件目录。作为我们不断努力使插件目录包含过程更加透明的一部分,我们创建了一个开发人员指南列表。我们努力为所有开发者创造一个公平的竞争环境。
如果您有任何改善文档的建议或其他相关问题,请发送电子邮件至 plugins@wordpress.org 并通知我们。
对开发者的期望
所有具有提交访问权限的用户以及所有正式支持插件的用户都应遵守目录指南。违反规则可能导致插件或插件数据(针对以前认可的插件)从目录中删除,直到问题得到解决。插件数据(如用户评论和代码)可能无法恢复,这取决于违规行为的性质以及同行审查的结果。重复违规可能会导致作者的所有插件被删除,开发者被禁止在 WordPress.org 上托管插件。
插件开发者有责任确保他们在 WordPress.org 上的联系信息是最新和准确的,以便他们收到来自插件团队的所有通知。联系信息不允许被转发到支持系统的自动回复的电子邮件,因为这会导致开发者不能及时处理电子邮件。
目录中的所有代码应尽可能安全。安全是插件开发人员的最终责任,插件目录会尽可能强制执行此操作。如果一个插件被发现有安全问题,它将被关闭,直到问题得到解决。在极端情况下,插件可能会被 WordPress 安全团队更新,并为了大众的安全而进行传播。
尽管我们尽可能详细地解释相关准则,但也不可能面具到的涵盖所有情况。如果您不确定插件是否会违反准则,请通过 plugins@wordpress.org 与我们联系咨询。
插件目录使用指南
1、插件必须与GNU通用公共许可证v2兼容
虽然任何 GPL 兼容许可证都是可以的,但强烈建议使用与 WordPress 相同的许可证 – “GPLv2或更高版本”。所有代码,数据和图像等任何在 WordPress.org插件目录中托管的的内容都必须符合 GPLv2。包含的第三方库,代码,图像或其他,必须兼容。有关兼容许可证的具体列表,请阅读 gnu.org 上的 GPL 兼容许可证列表。
2、开发人员对其插件的内容和操作负责。
插件开发者有责任确保插件中的所有文件都符合插件指南。禁止故意编写代码来规避指导原则,或者修复要求删除的代码(请参阅#9 非法/不诚实行为)。在上传到 SVN 之前,开发人员需要确认所有包含文件的许可,从原始源代码到图像和库。此外,这些资源必须遵守其所使用的第三方服务和 API 的使用条款。如果无法验证类库许可证或 API 条款,则不能使用。
3、必须从 WordPress插件目录页面提供一个插件的稳定版本
WordPress.org 分发的唯一版本是插件目录中的插件。开发者可能在其他地方开发代码,但用户使用的插件是从插件目录中下载的。通过备用方法分发代码,而不使插件库里的代码保持最新,可能会导致插件被删除。
4、代码必须(大部分)具有可读性。
目录中的代码不允许使用类似于p,a,c,k,e,r的混淆功能,不能使用 uglify 混淆或不明确的命名(如$ z12sdf813d)等方法来隐藏代码。不幸的是,许多人使用这种方法来尝试和隐藏恶意代码,如后门或跟踪。此外,WordPress 代码旨在让任何人都能够学习,编辑和适配。如果代码不具可读性,开发人员会面临不必要的障碍。可以使用压缩的代码,但也应该尽可能包含未压缩的版本。我们推荐以下 WordPress核心编码标准。
5、不允许发布试用版
插件可以不应该包含受只能通过付款或升级提供的限制或锁定的功能。在试用期或配额之后,这些功能不应该被禁用。免费功能也应该被原样包含在付费功能中(见指南 6:serviceware),插件内的所有代码应该完全可用。我们建议在 WordPress.org 外部托管插件的附加组件,以排除包含高级功能的代码。插件可以以用户能够接收的方式推广其他插件(不要劫持管理后台),他们不应该过分突出或打扰用户。
6、允许提供软件即服务(SAAS)
充当插件通过使用第三方服务(例如,视频托管站点)接口提供服务,即便是付费服务。服务本身必须提供内容功能,并在和插件一起提交的自述文件中描述清除,最好链接到服务的使用条款。
不允许的服务和功能包括:
- 不允许存在仅用于验证许可证或密钥,而本地包含插件的所有功能方面的服务。
- 禁止从插件移出任意代码来创建服务,以使服务错误地出现以提供补充功能。
- 插件不应该是服务的店面。不允许仅作为从外部系统购买产品的前端的插件。
7、插件不应该在未经用户同意的情况下追踪用户。
为了保护用户隐私,插件不应该在未经过用户明确和授权的同意情况下,访问外部服务器来跟踪用户。有关如何收集和使用用户数据的文档应该包含在插件的自述文件中,最好有明确的隐私政策。
禁止追踪的一些例子包括:
- 自动收集用户数据,无需用户明确确认。
- 有意误导用户提交信息作为使用插件本身的要求。
- 卸载图像和脚本时不作为服务。
- 没有文档说明(或说明不完善)的情况下使用外部数据(如黑名单)。
- 跟踪使用和/或视图的第三方广告机制。
这项政策的例外是软件即服务,例如Twitter,亚马逊 CDN 插件或 Akismet。通过安装,激活,注册和配置利用这些服务的插件,就可以获得这些系统的同意。
8、插件不应该通过第三方系统发送可执行代码。
从文件服务的外部加载代码是允许的,但所有的通信必须尽可能安全。不允许在不作为服务的情况下在插件中执行外部代码,例如:
- 提供更新或以其他方式安装来自 WordPress.org以外的服务器的插件,主题或加载项
- 安装相同插件的高级版本
- 除字体包含以外的其他原因调用第三方 CDN;所有与服务无关的 JavaScript 和 CSS 都必须包含在本地。
- 使用第三方服务来管理定期更新的数据列表,当服务的使用条款中没有明确允许时。
- 使用 iframe 连接管理页面;应该使用API来降低安全风险
管理服务与软件交互并将软件推送到站点是允许的,只要该服务处理自己的域上的交互,而不是在 WordPress 仪表板中。
9、开发人员及其插件不得做任何非法,不诚实或道德上的冒犯行为。
虽然这是主观的而且比较宽泛,但是其目的是防止插件,开发者和公司滥用最终用户以及其他插件开发者的自由和权利。这包括(但不限于)以下示例:
- 人为地通过关键字填充,黑帽 SEO 或其他方式来操纵搜索结果
- 提供驱动更多的流量到使用插件的网站
- 对他人进行补偿,误导,施压,勒索或勒索其他人的评论或支持
- 暗示用户必须付费解锁包含的功能
- 创建帐户以生成假评论或支持票据(即 sockpuppeting)
- 以其他开发者的插件和呈现他们作为原创的工作
- 未经许可使用用户的服务器或资源,例如僵尸网络或加密挖掘的一部分
- 违反 WordCamp 行为准则
- 违反论坛指引
- 针对任何其他WordPress社区成员的骚扰,威胁或滥用行为
- 伪造个人信息,故意伪装身份,并对以前的违规行为予以制裁
- 故意试图利用准则中的漏洞
10、未经明确要求用户的许可,插件不得在公共站点上嵌入外部链接或贡献
包含在代码中的所有 “Powered By” 或者信用显示和链接必须是可选的,并且默认不显示在用户的前端页面。用户必须有选择信用链接的权利,而不是放在使用条款中,强制要求显示信用链接或才能工作。如果代码是在服务而不是插件中生成的,则允许服务按照他们认为合适的方式来标记其输出。
11、插件不应该劫持管理仪表板
用户喜欢插件使用起来像 WordPress 的一部分,而不是使用自成一格的界面来让自己感到困惑。
升级提示,通知和警报必须在有限的范围内谨慎使用,或仅在插件的设置页面上使用。任何站点范围内的通知或嵌入式仪表板小部件都可以在问题解决时自行消失或允许用户关闭。错误消息和警报必须包含有关如何解决情况的信息,并在完成时自行移除。
应该避免在 WordPress 仪表盘上做广告,它们通常是无效的。用户很少访问仪表盘,当他们这样做时,他们正试图解决一个问题。让插件更难使用通常不会得到好评,我们建议在其中放置广告时保持节制。切记:不允许通过这些广告追踪引荐(参见指南7),大多数第三方系统不允许后端广告。滥用广告系统的指导方针会导致开发者向上游报告。
欢迎和鼓励开发人员将自己的网站或社交网络链接,以及本地(包括插件内)的链接包括在内,以增强体验。
12、WordPress.org上的公共页面(自述文件)不能包含垃圾推广信息。
面向公众的页面(包括自述文件和翻译文件)不得包含垃圾推广信息。垃圾推广行为包括(但不限于)不必要的关联链接,竞争对手插件标签,总共超过12个标签,黑帽SEO和关键字填充。
允许链接到直接需要的产品,如插件使用所需的主题或其他插件,适度允许。同样,相关的产品可以用在标签中,但不能使用竞争对手的标签。如果一个插件是一个WooCommerce扩展,可以使用标签 “woocommerce”。但是,如果该插件是 Akismet 的替代品,则可能不会使用该字段作为标签。
自述文件是为人写的,而不是机器人。
在所有情况下,推广链接必须公开,并且必须直接链接到相关服务,而不是重定向或伪装的 URL。
13、插件必须使用 WordPress 的默认库。
WordPress 包含许多有用的库,比如 jQuery,Atom Lib,SimplePie,PHPMailer,PHPass 等等。出于安全性和稳定性的原因,插件不应该在自己的代码中包含这些库的其他版本。相反,插件必须使用 WordPress 打包的这些库的版本。
有关 WordPress 中包含的所有 JavaScript 库,请查看 WordPress 包含的默认脚本和注册。
14、应该避免频繁地提交插件。
SVN 存储库是一个发布版本库,而不是开发版本库,所有提交,代码或自述文件将触发与插件关联的 zip 文件的重新生成。所以只有准备部署的代码(是一个稳定的版本,测试版或RC版)才能被推送到 SVN。强烈建议在每个提交中包含描述性和信息性消息。频繁的“垃圾”提交消息,如“更新”或“清理”,使其他人难以遵循更改。多个只调整插件的小方面(包括自述文件)的快速提交会对系统造成不必要的压力,并且可以被视为调戏最近更新的列表。
当更新自述文件只是为了表示支持最新版本的 WordPress 时,是一个例外,可以提交。
15、每个新版本的插件版本号必须递增
只有当插件版本增加时才会提醒用户更新。主干的 readme.txt 必须始终反映当前版本的插件。有关标记的更多信息,请阅读 SVN 关于 Tag 的说明以及 readme.txt 是如何工作的。
16、提交时必须提供完整的插件。
所有插件在批准之前都会被检查,这就是为什么需要 zip 文件的原因。名称不能“保留”以备将来使用或保护品牌(见#17:尊重品牌)。其他开发人员可能会使用未使用的已批准插件的目录名称。
17、插件必须尊重商标,版权和项目名称
除非合法所有权/代表证明能够得到确认,否则禁止将商标或其他项目用作插件 slug 唯一或初始权。例如,WordPress 基金会已经注册了“WordPress”一词,在域名中使用“wordpress”是一种违法行为。这个政策延伸到插件 slugs,我们不会允许一个 slug 开始另一个产品的任期。
例如,只有 Super Sandbox 的员工可以在 “Super Sandbox Dancing Sloths” 或其他安排中使用 “super-sandbox” 或其品牌。非 Super Sandbox 员工应该使用诸如“Dancing Sloths for Superbox” 等格式,以避免潜在的误导用户相信该插件是由 Super Sandbox 开发的。同样,如果您不代表 “MellowYellowSandbox.js” 项目,则将其用作插件的名称是不合适的。
建议使用原始品牌,因为这不仅有助于避免混淆,而且对用户来说更加难忘。
18、我们保留尽我们所能维护插件目录的权利
我们的意图是尽可能地以公平的方式执行这些指导方针。我们这样做是为了确保整体插件的质量和用户的安全。为此,我们保留以下权利:
- …随时更新这些指南。
- …禁用或删除目录中的任何插件,即使原因没有明确指出。
- …授予例外,并允许开发人员有时间解决问题,甚至是安全相关的问题。
- …删除开发人员对插件的访问,以取代新的,活跃的开发人员。
- …在没有开发者同意的情况下为了公共安全而对插件进行更改
作为回报,我们承诺尽可能地为最终用户和开发者使用这些权利。
规划插件
你已经写下了下一个流行度比肩 Hello Dolly 的插件,并且想让 WordPress 世界的人们了解并使用他,你该怎么做?
1、尽可能多的测试
运气好的话,你的插件会被许多人们在多种情况和托管环境下使用,要确保插件已经得到了尽可能多的测试,测试涵盖了各种情况,并且让用户使用起来不会觉得沮丧。
2、选择一个好名称
插件的名称应该反映你和插件的独特性,选择名字的时候,确保没有侵犯商标或与其他的产品名称产生冲突。例如,如果你不在 Facebook 工作,你就不应该命名你的插件为 “Facebook’s Dancing Squirrels”,命名为 “Dancing Squirrels for Facebook” 会更好一点,想出一个好名称不是一件容易的事情,所以,慢慢来,提交后,插件网站将无法更改,但是显示名称可以随时更改。
3、撰写优秀的代码
README.text 文件是最好的开始,因为这个文件是所有插件的标准参考点,要确保该文件中包含:
- 简要描述插件的实际作用是什么,如果插件的功能很多,分成两个插件可能会更好一点。
- 安装说明,特别是需要特出配置的时候,如果用户需要注册服务,请确保给出了注册链接。
- 关于如何获得支持的指导,以及你可以提供和不提供什么样的支持。
4、在 WordPress.org 上发布第一个版本
WordPress.org 插件目录是潜在用户下载和安装插件最简单的方式,把插件发布到 WordPress.org 插件目录后,你的插件可以让用户通过点击几下来下载或更新。
发布只一个版本之前,你需要在插件目录注册一个账户。插件得到审核后,你将被授予 Subversion 存储库,WordPress.org 网站提供了完善的文档,可以帮助你完成第一个 Subversion 提交。
5、拥抱开源
开放源代码是这个时代最伟大的想法之一,因为他可以跨越国界进行协作。通过鼓励人们贡献,你可以让别人可以和你一样热爱你的代码,下面是几个开放你源代码的好地方。
- Github 让其他人参与你的项目变得非常简单。其他开发人员和用户可以轻松的提交错误修复或报告,功能请求和全新的代码贡献。
- Bitbucket 是类似于 Github 之外的替代选择。
- WordPress.org 插件目录提供并且要求你使用 Subversion。
6、倾听你的用户
你经常会发现,用户经常会在比你想象得多得情况下使用你得代码,这是非常有价值得反馈。通过 WordPress.org 发布你的代码意味着你的插件会自动得到一个支持论坛。用上它,你可以通过电子邮件订阅接收帖子更新,并及时回复你的用户,他们和你一样热爱你的插件。
Automattic 幸福的工程师——Andrew Spittle 有两篇关于提供良好支持的文章 “Avoiding Easy” 和 “The Speed of Support.” Jetpack 也有一篇文章关于 如何撰写良好 Bug 报告 的文章。
7、定期推送新版本
最好的插件是随着时间的推移不断更显迭代的插件,每次更新都提供一些小改进,而不用让用户等得太辛苦。记住,不断更新会导致 “更新疲劳”,用户将在疲劳的时候停止更新,保持一个合适的更新频率很重要,不要太多,也不要太少。
8、坚持工作
和生活中其他方面一样,最好的事情来自良好的耐心和努力的工作。
使用 Subversion
我们将在这里描述一些关于使用 Subversion 的基本知识,开始使用, 作出改变, 和 标签发布。
这个文档对于使用 SVN 并不是一个完整和可靠的说明,更多是关于在 WordPress.org 上发布插件的快速入门,更全面的文档,请参阅 SVN 书籍。
有关更多信息,请参阅以下文档:
- How the readme.txt works
- How plugin assets (header images and icons) work
术语
如果你是使用 Subversion 的新手,你需要先了解几个术语,让我们来看看 Subversion 的工作方式,介绍几个术语。
所有的文件将几种存储在我们服务器上的 SVN 仓库中,在这个仓库中,任何人都可以将你的插件文件复制到本地机器,但是,作为插件作者,只有你有提交代码的权限。这意味着你可以对文件进行更改,添加新文件和删除本地计算机上的文件,并将这些更改上传到 SVN 中央服务器。这个过程会检查更新代码仓库以及 WordPress.org 插件目录中显示的信息。
Subversion 会跟踪所有代码变化,以便你可以在需要的时候,查看所有旧版本和新版本。处理记住每个单独的版本,你可以告诉 Subversion 来标记某些版本库以便参考,标签非常适合标记插件的不同版本。
SVN 目录
SVN 仓库包含以下几个目录:
/assets/
/branches/
/tags/
/trunk/
- Assets 中存放着 插件使用截屏, 插件 Banner 图片, and plugin 图标.
- 所有的开发工作都在
trunk
目录中进行。 - 插件发布保存在
tags
目录中。 - 代码分支保存在
branches
目录中。
及时你在别处开发你的插件(如 Git 仓库),我们也建议你保持 trunk 文件夹于你的代码保持同步,以方便 SVN 比较。
怎么使用
下面的说明将引导你了解使用 SVN 的一些基础知识。
开始全新的插件
你只需要将已有的插件文件添加到新的 SVN 仓库中即可。
要做到这一点,你需要先在你的机器上创建一个本地目录来存放一个 SVN 仓库副本:
$mkdir my-local-dir
然后,检出于构建的插件仓库
$svn co https://plugins.svn.wordpress.org/your-plugin-name my-local-dir
> A my-local-dir/trunk
> A my-local-dir/branches
> A my-local-dir/tags
> Checked out revision 11325.
如上面代码所示,Subversion 已经把所有的目录从中英 SVN 仓库添加到本地副本 (“A” 代表添加)。
要添加您的代码,打开 my-local-dir
文件夹:$cd my-local-dir
现在,你可以通过任何方式把代码添加到 trunk 目录中。添加后,必须让 Subversion 知道你想把这些文件添加到中央代码仓库中。
my-local-dir/$svn add trunk/*
> A trunk/my-plugin.php
> A trunk/readme.txt
[c-alert type=danger content=不要把主插件文件放在 trunk 的子文件夹中,如 /trunk/my-plugin/my-plugin.php,这样做会破坏下载。您可以使用子文件夹来包含插件文件。 /]
添加完文件后,我们将提交并推送更改到中央插件仓库。
my-local-dir/$svn ci -m 'Adding first version of my plugin'
> Adding trunk/my-plugin.php
> Adding trunk/readme.txt
> Transmitting file data .
> Committed revision 11326.
需要包含所有标签的提交信息。
如果提交因为 “禁止访问” 而失败,并且您知道您已提交访问权限,请将您的用户名和密码添加到提交命令。
编辑以存在于代码仓库中的文件
假设你已经提交了代码带插件仓库,现在需要做一些修改。首先,进入本地版本库,并确保本地的代码是最新的。
$cd my-local-dir/
my-local-dir/$ svn up
> At revision 11326.
在上面的例子中,本地代码是最新的。如果中央存储库中有更改,它们将被下载并合并到您的本地副本中。
现在,你可以使用你喜欢的任何编辑器编辑需要改变的文件。
如果您没有使用 SVN GUI 工具(如 SubVersion 或 Coda),则在进行更改后,仍然可以检查并查看本地副本与中央存储库之间的不同之处。首先我们检查本地副本的状态:
my-local-dir/$ svn stat
> M trunk/my-plugin.php
上面的命令告诉我们,我们的本地 trunk/my-plugin.php 与我们从中央存储库下载的副本不同(“M”代表“修改”)。
让我们来看看该文件中究竟发生了什么变化,所以我们可以检查一下,确保一切正确。
my-local-dir/$ svn diff
> * What comes out is essentially the result of a
* standard `diff -u` between your local copy and the
* original copy you downloaded.
如果一切看起来都没问题,我们就可以提交代码到中央代码仓库了。
my-local-dir/$ svn ci -m fancy new feature: now you can foo *and* bar at the same time
> Sending trunk/my-plugin.php
> Transmitting file data .
> Committed revision 11327.
搞定!
标记一个新版本
每次发布一个插件,我们都应该该版本的代码打一个标签,这样做可以让用户轻松获取最新或更早的版本,也可以让你轻松跟踪代码更改,并让 WordPress.org 插件目录指定应该让用户下载哪个版本的插件。
首先,将你的代码副本复制到 tags/ 目录中的子目录,为了兼容 WordPress插件仓库,新的子目录应该看起来像一个版本号,比如 2.0.1.3 是一个好选择,而 good, cool, hotness 就是个馊主意了。
我们可以使用 svn cp 而不是常规的 cp 来利用SVN的特性。
my-local-dir/$svn cp trunk tags/2.0
> A tags/2.0
现在,可以向以前一样提交代码了到插件仓库了。
my-local-dir/$ svn ci -m tagging version 2.0
> Adding tags/2.0
> Adding tags/2.0/my-plugin.php
> Adding tags/2.0/readme.txt
> Committed revision 11328.
或者,您可以使用 HTTP URL 来复制并节省带宽:
my-local-dir/$svn cp https://plugins.svn.wordpress.org/your-plugin-name/trunk https://plugins.svn.wordpress.org/your-plugin-name/tags/2.0
这样做会远程执行复制,而不是在本地复制所有内容并上传。如果你的插件更大,这样做是个不错的选择。
标记新版本后,不要忘了更新 trunk/readme.txt 中的 Stable Tag 字段!
恭喜!你已经更新了你的代码!
更多信息
- readme.txt 是怎样工作的
- 插件 assets (头图像和图标) 是z怎么工作的
- The SVN Book
插件开发者常见问题
提交和评论
怎么提交我的插件?
转到添加页面并上传您的压缩文件。
提交后发生了什么?
你会收到一封自动发送的电子邮件,告诉你有关提交的信息,然后会有人手动审查你的代码。如果我们发现插件在安全性、文档或演示方面都没有问题,插件将被批准。如果发现问题,你会收到一封邮件,邮件中会详细说明你需要解决的问题。
插件的网址是什么?
当你提交一个插件,你会得到一个自动的电子邮件,告诉你插件的 Slug 将是什么。Slug 是基于主插件文件(插件头文件)中插件名称生成的。如果你设置你的插件名称:Boaty McBoatface,那么你的 URL 将是 https://wordpress.org/plugins/boaty-mcboatface,你的 Slug 将是 boaty-mcboatface。如果有一个名字已经存在的插件,那么你会在提交时得到一个警告。
插件得到批准后,将不能重命名。请明智地选择。
为什么我得到了一个与提交的不同的 slug
有时我们会注意到拼写错误并为您修复。其他时候,你选择的名字有一个明显的问题,不能使用。例如,如果你提交 “WooCommerceTango Salsa Add-on” ,你的 Slug 默认将为 woocommerce-tango-salsa-add-on
,如果你不为WooCommerce工作,我们将为你修改为 woo-tango-salsa-add-on
,但是,如果您的 zip 文件被命名为 woo-tango-salsa,或者您使用有意拼写的类名,那么我们可能会使用它。
基本上,我们会修复我们认为对您不利的事情,如果我们不确定,我们会通过电子邮件通知您。对于明显的错误,我们将帮你解决这个问题。
插件获得批准需要多长时间
没有一个官方的平均时间,因为没有两个插件是相同的,如果你的插件代码量很小,并且所有代码都是正确的,应该在七天之内得到批准。如果你的插件有任何代码问题,只要你及时修正了,也后很快得到批准。如论那种方式,你都会收到来自 plugins@wordpress.org 的电子邮件,请将其添加到你的电子邮件白名单中,并耐心等待我们的回复。
如果我的插件有问题,我需要在多长时间内修复?
多长时间都可以,没有时间要求。
为什么我的插件在 6 个月后被拒绝?
如果您在 6 个月内没有回复我们的评论,我们可能会拒绝,以便将你的请求在待处理的队列保持在 1000 以下。如果您已经回复了,即便只有一次,或者告诉我们告诉我们您正在编写代码,我们就不会拒绝。
修复了插件之后,我需要创新提交吗?
不用,只需要回复电子邮件就可以了,即便是在一年之后。
我有 10 个插件,我可以一次提交吗?
不可以。您一次只能在审阅队列中插入一个插件。由于所有插件在7天内得到初步审查,这不应该是一个困难。
我应该并避免做的具体事情是什么?
我们整理了一些非常明显的注意事项,所有这些都在我们的指导方针中列出。大多数可以总结为“不要成为垃圾邮件发送者”,但要触及人们做的最多的事情:
- 充当服务时不包括readme.txt文件
- 没有使用 WP_DEBUG 模式测试插件
- 包含了 WordPress 绑定的 JavaScript 库的自定义版本。
- 调用了不必要的外部资源
- 添加了“Powered By”链接
- 跟踪用户
再次,这是一个简要的概述。请阅读指南,完整的清单是非常详细的。
插件库不接受哪些插件?
我们不接受不做任何事情的插件,违法或鼓励不良行为。这包括黑帽 SEO 垃圾邮件,内容调整器,仇恨插件等。一个插件应该是直接有益于用户的东西。它不应该要求用户编辑文件,它应该只是开箱即用。我们也不接受 100% 复制其他人的工作或插件,复制在 WordPress 核心中发现的功能。基本上,你的插件应该做一些新的,或以新的方式,或解决一个具体的问题。
我可以更改我的插件名称吗?
可以,也不可以,您可以更改显示名称,但是一旦插件获得批准,slug(即属于您的插件网址的一部分)将无法更改。这就是为什么我们多次提出警告。
要更改显示名称,请编辑主插件文件并将 “Plugin Name:” 的值更改为新名称。你也可能想在你的readme.txt中编辑你的头文件
有没有不被允许使用的名称
粗俗或冒犯的插件名称(显示名称或 Slug)将不被允许。
有没有不能在 slug 中使用的名称
有!除了上述的低俗之外,我们还有以下限制:
- 在极端情况下,插件不得在其 Slug 中使用 “WordPress” 或 “Plugin”
- 不能在插件 Slug 中使用版本号
- 由于系统限制,只能使用包含英文字母和阿拉伯数字的 Slug
- 除非由官方代表提交,插件不得以商标术语或特定项目/库/工具的名称开头
我们鼓励每个人都有自己的创意,并提出独特的名字。截至2017年3月,我们将自动更正任何具有不可接受名称的插件。如果最好的名字有问题,我们会联系你确定。
可以在我的显示名称中使用 WordPress 或 plugin 吗?
是的,但是非常不建议,这是没有意义并且多余的。
我犯了一个错误,并提交了一个错误的名字的插件。我该如何解决?
在提交的时候,你应该收到了一封邮件让你可以联系我们。直接回复或发送电子邮件 plugins@wordpress.org 说明情况,我们可以在批准之前纠正插件 Slug,我们可以在批准插件之前解决这个问题,所以我们总是可以帮助你纠正错误,如果没有,我们将告诉你需要做些什么,在我们批准之前,我们会尝试纠正拼写错误,但有时后,我们也会犯错。
我已经有一个插件,但我想重做它!我只是再次提交,对吧?
不,相反,你应该重写现有的插件。使其成为主要的版本发布。我们不能重新命名插件或转移用户,所以新的用户不会继承任何现有的用户,评论,支持主题,评级,下载,收藏夹等。基本上,你会把所有现有的用户冷落,基本上就是这个意思。
使用 SVN 仓库
我应该把文件放在哪里?
把你的代码文件直接放在版本库的 trunk/目录下。每当你发布一个新版本时,通过拷贝当前的中继版本到标签/目录的一个新的子目录来标记该版本。
确保你更新了trunk/readme.txt 以反映新的稳定标签。
自述文件的图像(例如屏幕截图,插件标题和插件图标)属于SVN签出根目录下的资产/目录(您可能需要创建)。例如,这将与标签/和主干/相同。
我可以把文件放在 /trunk 的一个子目录中吗?
不,这将会使 zip 生成工具失效而导致不能生成在你的 zip 插件包。
如果的插件很复杂,有很多文件,你可以把它们组织成子目录,但是 readme.txt 文件和根插件文件应该直接放在 trunk/目录。
我应该如何命名我的标签(a.k.a.版本)
你的 Subversion 标签应该看起来像版本号。具体来说,他们只应该包含数字和句点。 2.8.4 是一个不错的标签,而 neato releaso 是一个糟糕的标签。有些死板,是吗?是的,这样有助于处理和消除歧义,我们建议你使用 语义化版本 来跟踪插件发布。
我应该在SVN中保留多少个标签?
尽可能少。在插件仓库中,很少有人需要你的旧代码。记住,插件仓库的 SVN 不适合用来做版本控制。如果需要,你可以使用 Github 来控制版本。SVN 应该有你当前的版本,但是不需要保留以前版本的次版本。只为他们的最后一两个比较好。
我可以在插件中包含外部 SVN 吗?
不,抱歉。您可以把 SVN 外部添加到您的代码仓库,但他们不会被添加到可下载的 zip 文件中。
你的 WordPress.org 页面
WordPress.org 插件目录在哪里获取数据?
根据您在插件文件和 readme.txt 文件中指定的信息以及 Subversion SVN 仓库的信息。阅读关于 readme.txt 如何工作的更多信息。
您还应该充分利用主插件文件中的插件头描述。这些信息将定义 WordPress.org 托管页面以及WordPress管理显示的用户名。建议使用这些标题来完整的记录你的插件。
我可以指定WordPress.org插件目录应该使用哪个版本的插件吗?
是的,通过在 trunk 目录的 readme.txt 文件中指定 Stable Tag 字段指定。
我应该在插件的 changelog 中写点什么?
更新日志是对您的插件所做的全部或重要更改的日志或记录,包括更改记录,如错误修复,新功能等。如果您需要帮助格式化更新日志,我们建议保留更新日志,因为这是许多产品使用的格式。
我应该在插件的 changelog 中保留多少版本?
始终在更新日志中保留主要版本,如,如果你当前的版本是 3.9.1,那么你需要保留 3.9 的更新日志,更老版本的更新日志应该被移除或者合并到 changelog.txt 中,这样做会在保持插件自述文件精简的同时,允许用户访问这些更新日志。最多在自述文件中保留最新版本和一个主要版本的更新日志。插t件的 changelog.text 不会在 WordPress 的插件目录显示,但没关系,大多数用户只需要了解最新信息。
如何在插件的描述页面上包含视频?
对于YouTube和Vimeo视频,只需将视频链接粘贴到您的说明中。请注意,视频必须设置为允许嵌入。
对于由 WordPress.com VideoPress 服务托管的视频,请使用 wpvideo 简码。如果需要,简码也可以用于 YouTube 和 Vimeo,就像在 WordPress 中使用一样。
插件目录需要多长时间来反映我的更改
WordPress.org 每个几分钟就会更新一次,但是,根据更新队列的大小,更改可能需要更长时间,请至少提前 6 个小时联系我们。
怎么为我的插件做一个炫酷的 Banner?
您可以通过将正确命名的文件上传到 assets 文件夹来制作自己的插件标题。
阅读关于插件标题的更多信息。
怎么为我的插件添加一的图标
您可以通过将正确命名的文件上传到assets文件夹来制作自己的插件图标。
阅读有关插件图标的更多信息。
支持论坛
如何获得论坛帖子的更新通知?
转到 https://wordpress.org/support/plugin/YOURPLUGIN 并向下滚动到帖子列表的底部。在那里你会看到 RSS 链接的选项,以及注册电子邮件。
点击电子邮件的订阅链接,或者在您喜欢的阅读器中使用RSS链接。
怎么获得所有插件的通知?
如果您正在跟踪 WordPress 论坛,https://wordpress.org/support/view/plugin-committer/YOURID 将列出您所提交插件的所有支持请求和评论。如果不是一个代码提交者,只是被列为作者?使用 https://wordpress.org/support/view/plugin-contributor/YOURID
那些只是 RSS 链接。如果您需要订阅电子邮件,请转到 https://profiles.wordpress.org/YOURID/profile/notifications/并输入要通过电子邮件发送的项目。
怎么为我的插件添加一个支持账户?
您可以将支持代表添加到您的插件。支持代表可以将论坛主题标记为已解决或指定(与插件作者和贡献者相同),但不具有提交插件代码的权限。
用于管理插件支持代表的 UI 可以在管理提交者旁边的插件页面的高级视图中找到。一旦有人被添加为支持代表,他们将在回复插件支持主题或评论时获得插件支持者标志。
关闭插件
我怎么关闭我的插件?
如果你要求删除你的插件,通过请求后,你的插件将会被永久关闭,无法恢复,除非你能提供合理的理由。
以具有提交访问权限的帐户邮件发送邮件到 plugins@wordpress.org 并链接到您的插件。如果您的电子邮件不是具有该插件提交访问权限的人员,系统会要求您使用其他电子邮件发送邮件。
我的插件关闭后发生了什么?
插件关闭后,插件的当前 URL 会被重定向到插件的主目录,并不会再被生成。所有人不再能通过网站下载插件,也不能通过 WordPress 后台安装。SVN 仓库将保持可访问的状态,允许其他人按照目录的原则下载和分发代码。
为什么我的插件会被关闭?
可能是因为插件违反了准则,有行为或安全问题。在任何情况下,您都应该收到来自 plugins@wordpress.org 的电子邮件,来告诉你插件被删除的原因。
为什么别人的插件被关闭了?
我们不公开为什么我们关闭插件给任何人,除了插件开发人员和WordPress核心开发人员。不要打扰问。这是出于安全原因。如果我们公布为什么我们关闭一个插件,每个人都会知道漏洞。如果我们选择不说“这是为了安全”,那么每当我们说 ‘我们不能告诉你’ 时,世界就会知道这是为了安全。基本上,这会让每个人都不那么安全。
我可以让别人的插件被关闭吗?
如果您在 plugins@wordpress.org 的插件中报告安全问题或指南违规,我们将审核报告并采取适当的措施。大多数情况下,这涉及关闭一个插件。
有人发布了我的插件的副本,我该怎么办?
通过电子邮件 plugins@wordpress.org 提供一个被盗插件的链接,或者一个可以下载被盗版插件的链接。我们将比较这两个文件,以及我们所有的代码历史记录,以确定插件是否确实是盗窃,还是只是一个未经认可的分支。请记住,如果您授权您的插件为 GPLv2 或更高版本,那么只要版权保持完整并且您被记入信息,则完全可以分发您的作品。
我可以发送安全报告吗?
通过电子邮件 plugins@wordpress.org,并且清楚简洁地描述问题。确保解释你是如何验证这是一个漏洞的(链接到到像 secunia.com 这样的网站上的插件列表是完美的)。如果您提供了报告链接,请不要删除它!我们会直接把它传递给插件的开发者。
发现了一个插件的错误后,我可以得到赏金吗?
我们与任何错误奖励计划没有任何关系,所以我们不会将您的报告等提交给他们。我们工作的唯一一个是 hackerone.com/automattic,这是与 Automattic 属性相关的错误。其他的一切都是自己的,不要要求我们提交东西。
你们是否提供帮助或 CVE?
不,我们目前无法提供帮助。
我的插件被关闭了,我可以重新打开吗?
也许可以。如果我们出于安全原因而关闭了你的插件,解决问题后,回复电子邮件,大多数情况下我们会重新打开插件。如果插件被关闭使用违反了准则,取决于违规的严重性和性质。例如,重复违规者相对于第一次违规者来说,不太可能重新打开插件。
插件所有者
我怎么让其他人访问我的插件?
如果你想添加用户作为提交者,这是让他们访问更新代码,你可以打开 https://wordpress.org/plugins/YOURPLUGIN/advanced 页面,并添加他们的用户名作为提交者。如果您向把它们显示为作者,需要将其用户名添加到 readme.txt 文件中。
我怎么从我的插件中移除其他人的访问权限?
任何有提交权限的人都可以这样做。转到 https://wordpress.org/plugins/YOURPLUGIN/advanced 将鼠标悬停在其 ID 上,将会出现一个删除链接,点击即可。
我怎么接管一个已遗弃的插件?
我们会建议用户弃用不再开发的插件。我们要求您先尝试与原始开发者联系,以便他们可以添加您作为插件提交者。在某些情况下,这是不可能的,这时候,你可以开始修复插件。确保它是符合编码标准、安全的,并在版权信息里面包括自己。然后你就可以联系我们采用你的插件了。
我们不保证你会得到任何人的插件。
提议购买我的插件的请求合法吗?
许多开发人员收到未经请求的电子邮件或优惠购买他们的插件。我们发现其中绝大多数是欺诈性的,不建议你跟进。虽然合法的报价确实来了,但是他们通常来自与插件相关的官方公司,或者来自一个完善的插件公司。不要相信那些以 “我们正在向WordPress社区伸出援手……” 或者 “我们正在寻求获得现有的WordPress插件……” 开头的邮件。这样的购买往往通过从事一些低俗的手段(比如追踪用户或其他严重违反指南)来破坏插件(和原始开发者)的声誉。
如果你选择出售你的插件(或者把它交给其他人),请确保新的所有者了解存储库的所有准则。如果他们违反我们的条款,该插件将被删除,我们可能不会根据违规的程度退还。无论谁拥有提交插件的权利都应该对用户负责。垃圾邮件,插入追踪数据和添加垃圾功能是破坏您的插件的最快方法。
我们主张只将您的插件给予您亲自审核的人,并且相信他们会对你的代码和用户负责。
如果插件开发人员死亡了会发生什么?
当开发人员确定已经死亡时,他们会从自己的插件中删除,以防止不道德的获取和伤害用户。如果他们是唯一的开发者,那么插件可能会被关闭。所有的尝试都是为了找到他们的朋友和同事,为他们提供一个机会来首先认领代码,如果没人认领,插件将被关闭。
本文收集自互联网,转载请注明来源。
如有侵权,请联系 wper_net@163.com 删除。
还没有任何评论,赶紧来占个楼吧!