自从十多年前插件和主题升级机制已包含在内核中以来，第三方开发人员就一直在寻求一种绕过系统的简便方法。WordPress 5.8最终将根据此功能要求提供服务。
尽管长期以来就有可能对更新系统进行过滤，但是这样做的方法比所需的更为复杂。他们还要求插件本身在网站上处于激活状态。早就应该有一个简单的标志来启用/禁用每个插件的功能。
“实用程序是这是一个抽象的API，它允许两件事，” Dion Hulse<在GitHub pull请求中写道，该请求对代码进行了修补：
- 一个用于声明URI /字符串的插件，如果设置了该字符串，则WordPress.org更新API会忽略该插件。
- 在站点上运行的代码可以使用标头主机名/数据为插件提供更新，以将其存储在更新瞬态中，而不必跳过诸如覆盖瞬态/经常检查等麻烦。
WordPress 5.8将提供一个新的Update URI 插件头字段。如果其值与https://wordpress.org/plugins/{$slug}/或之外的其他值匹配w.org/plugin/{$slug}，则WordPress不会尝试对其进行更新。
除此之外，如果开发人员想要处理非WordPress.org插件的更新，则可以推出自己的解决方案。这就是新update_plugins_{$hostname}过滤器起作用的地方。WordPress将解析包含在插件Update URI头中的URL，并使用主机名作为值。然后，开发人员可以参与其中，并做他们需要的任何事情。
具有由WordPress.org托管的扩展名的插件作者将不必担心添加此新标头。插件指南的规则＃8已经禁止通过第三方系统发送可执行代码。以下小节将更具体地介绍这种情况：
从WordPress.org以外的服务器提供更新或以其他方式安装插件，主题或附加组件
13个月前，6年前的一张ticket引发了一些讨论。“当计划的插件自动更新运行时，我现在已经毫不客气地从客户端的网站上删除了一个插件，”使用用户名apedog的投稿人写道。“实际上，这是我第二次遇到我的插件的命名冲突问题。在这两种情况下，我都选择了没有先验命名冲突的插件名称。但是，在稍后的某个时间，其他人也用相同的通用名称编写了一个插件，并将其提交给wp.org存储库。从那时起，我的插件无法正常工作。”
尽管删除问题并不是WordPress的问题，但也许是保持对话进行所需的火花。
进行积极的讨论并不总是表明某个功能获得了绿灯。这也不意味着有人会编写代码。许多这样的工单已经进行了数月或数年的交谈，直到最终失去生命和死亡。这张工单于2015年开放。但是，新功能有时更多地是关于时间安排，仅仅是纯粹的随机性，或者具有核心提交访问权限的开发人员仅能完成工作。
插件主题工单已被接受并提交给WordPress。但是，仍然存在这样一个问题它是否会成为主题。已有11年历史的主题工单出现的表明，这种情况有可能发生。
评论留言