展望未来的WordPress

自 wordpress 成立以来，2018 年发生了一些最基本、影响最深远的变化，这体现在 Gutenberg 插件（及其上方的行）中。

但在我看来，主导 2019 年的不是古腾堡，而是它预示的变化。

因此，让我们来看看 2019 年 WordPress 及其用户和开发者社区可能会发生什么。

WordPress 代码库

Gutenberg 代表了 WordPress 代码库发生根本性转变的开始。

还记得 Matt Mullenweg 的State of the Word 2015（是的，那是很久以前的事了），当时他告诉大家“深入学习javascript ”？

好吧，现在是那些听了他的人高兴的时候了。这也是 WordPress 社区由已经拥有 JavaScript 和其他前端语言技能的人扩充的时候，现在可以将这些人与 WordPress 一起使用。

古腾堡是基于块的。这些块是用 javaScript 编写的。如果您曾经编写过一个在帖子编辑屏幕上添加元框的插件，那么现在最好添加一个块。为此，您需要学习的不是 php，而是 JavaScript。

主题开发人员也是如此——您可能还不需要学习 JavaScript，但您可能需要更新您的主题，以便它们为 Gutenberg 输出的块设置样式，而不是旧编辑器输出的样式。

并且块不会局限于帖子和页面编辑屏幕。不好了。

Gutenberg 的第 2 阶段将在帖子编辑器之外使用块，并在 WordPress 管理员的其他地方实现它们。小部件、菜单和定制器：您命名它，它将使用块。我们的目标是将 WordPress 变成一个所见即所得的页面构建器类型的 CMS，但没有大多数页面构建器的代码膨胀。

这是 WordPress 定制器的外观：

这是一个雄心勃勃的目标，它将为用户和开发人员彻底改变 WordPress。对于用户来说，这将意味着一个新的、流线型的界面，感觉更像 21 世纪。对于开发人员来说，这意味着学习 JavaScript。是的，深深的。

那么这一切对 WordPress 社区意味着什么呢？

WordPress 社区

WordPress 社区并不是一个真正的实体。我们大多数参加 WordCamps 的人所看到的社区实际上是开发人员社区。但是那里有一个庞大且不那么同质的 WordPress 用户社区，他们的需求非常不同。

WordPress 用户不倾向于与 WordPress 社区结盟，而是与他们自己的部落结盟，这将包括许多在同一空间工作的 WordPress 用户。我是其中一个社区的一员：作家社区。在那个社区，对古腾堡的反应是混合的。人们经常对重大变化反应很差，现在的重点是错误和已损坏的站点。

但随着时间的推移，我认为 WordPress 用户将受益于这些变化。也许不是 Gutenberg 本身，因为它太接近旧的编辑体验，感觉不仅仅是一个附加功能，而是计划中的 WYSIWYG 和 Customizer 更改。

新的用户界面，随着它的发展和成熟，将吸引以前使用过像 Wix 这样的网站构建器的用户，并且喜欢在他们做的时候看到他们在他们的网站上做什么。

只要可访问性问题得到解决（很快就会解决更多问题），这可能预示着 WordPress r api d 增长时期的开始。尽管我预计一些喜欢旧系统的用户会在此过程中放弃。

但是开发商呢？

似乎开发者社区现在感到很痛苦。随着古腾堡的争吵（尤其是可访问性和临时通知发布），有一种感觉是社区没有被倾听。WordPress 正在满足 WordPress.com 的需求，而不是其用户和开发人员社区的需求。

Automattic 不应该对此置之不理。开源不仅仅关乎代码库和许可证：它也关乎项目的精神。真正的开源项目不是自上而下的。它们是民主的、咨询性的项目，考虑到了各种各样的群体，并且不受像 Automattic 这样的商业实体的需求驱动。

Automattic 和 Matt Mullenweg 之前曾面临过批评。他们回应了他们并建立了桥梁。我相信他们可以再次这样做。WordPress 及其社区的未来对于我们所有人来说都太重要了。

更积极的一点是，转向 JavaScript 提供了很多机会。它已经为社区带来了新人和新技能。这将意味着 WordPress 开发人员正在跟上 Web 开发中最具活力和不断发展的语言之一的发展。学习 JavaScript 的 WordPress 开发人员将有机会获得更多更高薪的工作。

可访问性

可访问性问题值得一提。除了发布日期的分歧（没人会满意）之外，关于古腾堡的最大争论是关于可访问性。

多年来，可访问性并不是 WordPress 的基础。没有可访问性团队，我们大多数人都是从不属于核心 WordPress 团队的开发人员那里了解这个主题的，但他们在可访问性领域工作或对它充满热情。

但近年来情况发生了变化。WordPress 有一个可访问性团队，新版本在发布之前会进行可访问性审核，而可访问性始终是 WordCamps 的热门话题。

然而，这一进展与古腾堡发生了逆转。可访问性是许多基于 JavaScript 的可视化工具的共同挑战。它们是为那些可以看到屏幕上的内容并使用鼠标与之交互的人设计的。否则 WYSIWYG 中将没有 S。

但是为视觉使用而设计的系统并不是为可访问性而设计的。许多残障网络用户在他们的浏览器中关闭 JavaScript，因为它使页面难以交互。并且块系统的设计并未考虑到可访问性。

这个问题变得如此可怕，以至于 WordPress 可访问性负责人 Rian Rietveld辞职，理由是“大多数测试人员拒绝再次查看 Gutenberg 的许多可访问性问题”。

无障碍团队得到的反馈是，他们应该在提出无障碍票时解释为什么 无障碍票很重要。这让我感到难过，因为我的期望是 WordPress 开发人员理解为什么可访问性修复很重要，而无需反复告知。似乎另一个问题是可访问性团队没有可以与 Gutenberg 代码交互的熟练 react 开发人员。如果可访问性对 WordPress 的未来很重要，那么为可访问性团队提供 React 开发人员应该与将其提供给核心团队一样重要。

这种争论仍在继续。有人说 Matt Mullenweg 的反应不够充分，但 Automattic 现在已同意资助对 Gutenberg 的可访问性审计。还有待观察的是这将如何影响 Gutenberg Phase 2 的代码。希望核心团队能够从中吸取教训，并确保从一开始就将可访问性纳入代码库，而不是在最后添加。

WordPress 在全球拥有数百万用户，其中很大一部分将有可访问性需求。如果 WordPress 将继续满足他们的需求（并证明它重视所有网络用户），那么我希望这将意味着 WordPress 可访问性的改进。如果不吸取教训，那可能是一场灾难。