昨天，Alex Shiels 发布更新 到 建议的准则 用于WordPress阻止目录。 该文档添加了八个规则，供插件作者计划将一次性块添加到目录中时遵循。 该准则是对现有插件目录准则的附加要求。
相对于 原始建议，总体情绪没有变化。 Shiels感谢社区开发人员对原始指南的反馈，但没有详细说明由此而发生的变化。
主要准则是对砖块的常规要求。 开发人员需要一个block.json文件。 他们应该适当地命名东西。 插件应仅包含一个块。 插件只能触摸块编辑器。 一旦激活，块应无缝运行。
对于某些开发人员而言，其余准则肯定会令人失望或争论点。
仍不允许获利
最大的 对准则的反馈 我们在小酒馆（Tavern）收到了这封邮件，这实际上是对块开发商的商业利益的全面禁止。 区块仍然无法加入付费服务或在管理员内发布广告。 这种限制显然将使许多可能一直希望将阻止目录作为潜在获利途径的企业拒之门外。 现在，那些有利他主义兴趣的人将需要建立一次性的街区，仅仅出于他们内心的善良就回馈社区。
尽管这样做并没有天生的错误，但对于主要致力于将食物摆在桌面上的开发人员而言，它并没有吸引力。 具有回馈资源的业余爱好者和大型企业将非常适合在目录中添加块。 但是，这将使很多开发人员暂停，因为它不太可能获得良好的投资回报。 相反，这些开发人员更有可能使用其常规追加销售方法将其块提交到常规插件目录。 这只会使最终用户更难发现区块。
这是一个错失良机，无法构建一个全面的系统，对需要谋生的用户和开发人员都是公平的。 无论是通过插件标签系统还是关于获利的特定准则，我们都可以构建使每个人都有些高兴和疯狂的东西，这种折衷融合了良好的用户界面和体验。
似乎没有提案。 一月，卢克·卡比斯（Luke Carbis）写了一篇详细的 WordPress如何提供中间立场 即将发布的区块目录在可持续性（业务模型）和可访问性（免费选项）之间进行选择。 他担心的是，由于完全免费的模型是不可持续的，因此在几年之内，块目录中将充满不更新的块。 他的建议是一个基于徽章的系统，该系统可以让用户知道某个区块是否包含广告，是否使用了免费增值模式或是否需要登录第三方服务。
当前的准则不是一成不变的。 这是块目录的第一个版本。 随着目录的不断增长，团队可以更改内容并非毫无疑问。
不爱服务器端块
块目录准则仍然非常适合静态块。 PHP必须保持最少，并且主要用于加载任何必要的脚本和样式表。 目前服务器端块并没有引起太多关注，这可能是软件的局限性。
看到一些将服务器端块包含在块目录中的方法，将是很棒的。 例如，一个面包屑块将需要严重依赖PHP来呈现其输出。 它是动态的而不是静态的。 直到仍然需要几个月的时间才能在WordPress中进行全站点编辑之前，此特定区域才有用。 但是，我很想将我的旧面包屑插件变成一个块。 看到它在块目录中列出会很整洁。
还有无数其他情况。 发布列表，产品网格以及从外部API提取的数据都是一次性模块的良好用例。
不允许依赖
鉴于WordPress的工作方式，有必要禁止对其他插件的依赖以使任何特定功能块起作用。 这是一个古老的局限性，再次引起了人们的注意。 每个其他现代框架都使用某种依赖管理来解决此问题。
阻止目录可能进一步加剧该问题。 因为来自此目录的插件将是单个块，所以这通常意味着开发人员在多个项目中使用相同的代码位。 例如，最终用户可以激活依赖于同一JavaScript库的多个块插件。 因为没有100％的确定方式来确保仅加载该库的一个实例，所以用户可能在其站点上运行该库的多个实例。 这不是一个新问题，但是较小的块状插件意味着用户更有可能安装更多插件。 这增加了遇到此问题的可能性。
如果插件作者可以在WordPress中使用某种基本的依赖管理，那么它将解决很多问题。 多年来，开发人员已经创建了一些方法来最大程度地减少由于缺少此类系统而引起的问题。 但是，如果没有遵循的标准，没有什么是万无一失的。
这也使开发人员无法构建可以使整个开发社区受益的库，脚本和工具。 每个人都在内部构建自己的东西，而block目录则承诺会实现更多相同的东西。
像这样：
喜欢加载中……