六个月前，一位老熟人给我打电话，我是一家工业分销商的技术总监，该分销商在 WooCommerce 上拥有一家拥有 16000 个产品的在线商店。他听起来就像一个刚刚收到保险杠维修账单的人，同时发现卡斯柯不承保这项费用。 “奥列格，”他说，“我们的 ACF Pro 订阅即将用完，他们改变了定价，现在我们的网站数量每年要价 249 美元。我还读到 WP Engine 购买了它们，现在每个人都想知道接下来会发生什么。我们完全与他们联系在一起 - 所有产品卡、所有特性、粘度选择、温度范围。如果他们关闭或破坏 API，我们将站起来。”这句话——“我们会崛起”——引起了我的注意，因为这不是我第一次听到它。我每个月至少从不同的人那里听到一次，其背后隐藏着同样的问题，很少有人思考这个问题，直到它击中他们的额头。
问题听起来很简单：关键功能依赖第三方插件。 ACF - 高级自定义字段 - 已成为 WordPress 中自定义字段的事实上的标准。几乎每一家超越简单的“名称-价格-描述”的 WooCommerce 商店都以这种或那种方式使用 ACF 或其类似物。产品特性、技术规格、文档、产品之间的连接、特定项目的交付条件 - 所有这些都存在于自定义字段中。而这一切，其实都掌握在第三方开发者手中，他们可以随时改变游戏规则。这正是发生的事情。
当 WP Engine 收购 ACF 时，社区中掀起了一股焦虑的浪潮。并不是因为 WP Engine 是一家糟糕的公司，而是因为 WordPress 的历史充满了主要参与者接管插件导致意想不到的后果的例子。有时插件会停止开发。有时定价政策会发生变化，导致小企业被迫寻找替代方案。有时所做的更改会破坏向后兼容性。当您坐在一万六千个产品旁边，每个产品都有二十到三十个自定义字段时，您会想 - 您应该做什么？移动？在哪里？靠什么？这些问题并不抽象，而是抽象的。我收到了来自客户的直接电话，他们在 WooCommerce 商店中投入了多年的工作。
我记得在莫斯科举行的 WordPress 会议上，我与汽车服务中心网络的所有者进行了对话，他在 WooCommerce 上有一个包含一万二千件商品的备件目录。他表示，当将 ACF 从 6.1 版本更新到 6.2 时，产品卡上的所有条件字段都“脱落”。这些字段就不再出现了——因为条件逻辑的内部机制发生了变化。他们在两天内修复了该问题，但这两天期间该网站使用了错误的产品卡。一万二千张缺少特征的卡片不仅仅是“不便”，更是转换的直接损失。这不是 ACF 的错 - 他们改进了产品。但对第三方代码的依赖意味着您接受任何更改，即使是那些您还没有准备好的更改。
我不是作为理论家，而是作为实践者来思考这个问题。在我们的主要项目（一家大型润滑油分销商）中，wp_postmeta 表已增长到 937 兆字节。仅元数据就几乎有千兆字节。一万六千八百四十四种货物，每一种都有几十个田地。粘度、闪点、倾点、制造商批准、GOST、系列、系列、基料类型 - 我刚刚开始列出这些。所有这些都在 wp_postmeta 中，因为这就是 ACF 的工作原理。每个值都是表中的单独行。每个中继器又多了几行，其中包含有关元素数量的元信息。当您同时对三个或四个字段执行 WP_Query 元查询时，数据库开始哭泣。我并没有夸大其词。我发现在配备 NVMe 驱动器和 32 GB RAM 的服务器上，查询需要 8 秒才能完成。
如果我们以不同的方式看待它会怎样？不是作为一项技术任务（用另一个插件替换一个插件）而是作为一项战略决策，决定您信任谁来处理您的业务数据？当我与构建 ERP 系统的工业公司合作时，没有一家公司认真考虑过“让我们将关键逻辑转移到我们无法控制且需要支付年度订阅费用的第三方模块中”这一选项。这太荒谬了。但出于某种原因，在 WordPress 世界中这被认为是常态。一家拥有两万个产品目录的公司将所有特性、所有连接、所有技术参数存储在第三方插件中。他为这种特权付出了代价。并且每次更新都有失去访问权限的风险。也许是时候停止认为这是常态并开始构建属于您的基础设施了？
这就是为什么，当我们为 COS WP Woo 设计自定义字段模块时，我将任务设置得比“像 ACF 一样，而且免费”更广泛。免费是一个不错的奖励，但不是目标。我们的目标是把事情做好。确保两年后，当底座的尺寸增加两倍时，它不会受到伤害。更重要的是，不要发现自己的业务关键功能取决于您无法控制的供应商的决策。
为什么 wp_postmeta 是一个架构陷阱
让我们看看为什么我如此坚持认为在 wp_postmeta 中存储自定义字段是一个坏主意，特别是对于拥有大型目录的在线商店。 WordPress 是作为一个博客平台而创建的。 postmeta 表旨在存储有关记录的附加信息 - 每条记录的键值对。当您有一百篇文章并且每篇文章都附加了三到四个字段时，这非常有效。但是，当您有 16000 个产品，每个产品有 25 个字段时，您仅会获得 40 万行直接值。如果还有每个中继器包含三个元件，则乘以三。加上 ACF 用于存储字段键、中继器中元素的顺序和标志的技术字符串。结果，我们很容易在一个表中获得一百万到一个半行。
这就是乐趣的开始。如果您正确索引和查询数据，MySQL 可以很好地处理一百万行。但wp_postmeta有一个特定的结构：post_id、meta_key、meta_value。索引位于 post_id 和 meta_key 上。当您搜索“粘度 = 5W-30 且闪点大于 200 且 KAMAZ 批准 = 是的所有产品”时，MySQL 必须将 postmeta 表进行多次 JOIN 到自身。每个元查询都是一个单独的 JOIN。三个条件 - 九百兆字节的同一个表的三个 JOIN。查询优化器开始创造奇迹，但不是您期望的奇迹。它尝试找到最佳执行计划，遍历选项，有时选择对表进行完整搜索 - 然后您会收到挂起服务器的请求。
我们进行了测量。在我们配备 Redis 缓存和优化 MySQL 的生产服务器上，在没有缓存的情况下，对包含 16000 个产品的目录执行具有三个元条件的查询需要 3 到 8 秒的时间。使用 Redis 会更快，但前提是缓存还热。并且每次产品更新时缓存都会失效。当您与 1C 同步时（每小时更新一次余额和价格），缓存会循环失效。事实证明，这是一个恶性循环：你安装Redis来加速元查询，但同步会杀死缓存，用户再次在过滤页面上等待五到八秒。这不是一个理论问题，而是任何与会计系统集成的 WooCommerce 商店的日常现实。
当我们在 COS WP Woo 中设计 CF 模块时，我们立即设想了一种不同的存储架构。三个自定义表：wpaic_cf_field_groups用于字段组，wpaic_cf_fields用于字段描述，wpaic_cf_values用于值。值表的结构不同 - 它了解数据类型、字段之间的关系以及嵌套。它不会将所有内容都存储为 meta_value 中的文本，而是使用类型化列。数值存储为数字，日期存储为日期，JSON 存储为 JSON。这使得MySQL可以使用正常的索引和正常的优化。在 postmeta 中需要 8 秒的具有三个条件的相同查询在自定义表上执行需要 200 到 300 毫秒。相差二十到三十倍。这不是一个营销数字 - 这是基于真实数据、在具有真实负载的真实生产服务器上进行的测量。
还有一个很少讨论的不明显的细微差别。 wp_postmeta 中的meta_value 列的类型为LONGTEXT。这意味着该列上的索引是部分索引，仅基于第一个字符。当您使用等于运算符进行元查询时，MySQL 可以使用索引。但是当你需要LIKE或者数字比较时，索引就没用了，因为MySQL不知道meta_value存储的是数字。它被迫将表的每一行的字符串转换为数字。对于九百兆字节的数据，这意味着完整的搜索。并且任何 MySQL 设置都无济于事 - 问题出在存储架构本身，而不是服务器配置。我们在实际查询上使用 EXPLAIN 对此进行了测试 - MySQL 诚实地显示类型：ALL，即全表扫描。
但事情是这样的。快速存储只是基础。 WordPress 管理员中的用户并不关心他的数据的物理位置。对他来说，重要的是界面工作方便、字段创建容易、中继器不会出现故障以及古腾堡正常显示自定义内容。这里我们来看看ACF的核心价值实际上是什么——不是数据存储，而是管理接口。在这里，我们不仅需要重复 ACF 所做的事情，而且还需要向前迈出一步。
二十种字段类型和一个无需说明的界面
当我分析客户如何使用 ACF 时，我整理了最常遇到的字段类型列表。文本字段、文本区域、数字、电子邮件、URL - 这些是您离不开的基本内容。选择、复选框、单选也是标准配置。但接下来更有趣的事情开始了：对象之间的关系、图像库、日期和时间、颜色选择器、所见即所得编辑器、文件附件、真/假开关、谷歌地图（尽管说实话，只有少数人需要最后一个）。这些“高级”类型使自定义字段成为真正强大的工具。
我们在 COS WP Woo 的 CF 模块中实现了二十多种字段类型。我不会将本文变成技术文档并逐一列出，但我想重点介绍一些我认为对 WooCommerce 商店至关重要的内容，并且我们以与 ACF 完全不同的方式实现这些内容。
CfRelationshipField - 对象之间的关系。这是我们几乎所有客户都使用的方式，温和地说，ACF 在大型目录上效果不佳。当您有 16000 个产品并且需要选择相关产品时，ACF 中的 AJAX 搜索开始变慢。你输入三个字母，等一两秒，结果就出来了，但你不确定是否找到了所有匹配的产品，因为ACF限制了输出。我们的 CfRelationshipField 实现使用索引搜索和分页。您开始输入产品名称，结果会立即显示，即使是在包含两万件商品的目录中也是如此。因为搜索不是通过LIKE通过meta_value进行的，而是通过普通的全文索引进行的。结果是分页的 - 您可以滚动浏览所有匹配项，而不是希望您需要的产品位于前二十名中。
CfGalleryField - 图片库。又一个痛处。在 ACF 中，图库通过标准 WordPress 媒体加载器运行，这是......可以忍受的。但是，当您需要上传十张产品照片时，按正确的顺序对它们进行排序，裁剪一张，替换另一张 - 该过程变成了在模态窗口上进行一系列点击。我打开媒体库，选择一个文件，关闭它，意识到我需要修剪它 - 再次打开它，找到该文件，打开编辑器，裁剪它，保存它，关闭它。我们的 CfGalleryField 直接内置于元盒中：将文件直接拖放到字段区域、拖放排序、裁剪图像，而无需离开产品编辑器。这看起来是一件小事，但是当内容管理员每天处理 50 个产品时，每个保存的点击都会乘以 50。一周下来，一个半小时的纯粹时间就累积起来了。一个月内 - 整个工作日。我不喜欢以分钟为单位计算效率，但当差异如此明显时，数字就说明了一切。
现在谈谈自定义领域的专业工作与业余工作的区别 - 中继器和灵活内容。 ACF 长期以来一直将两种类型的字段保留在付费墙后面，这本质上决定了您是否可以在 WordPress 上构建具有复杂数据结构的严肃目录。
重复器和灵活内容：当简单字段不够时
你知道什么有趣吗？当我向新客户展示字段类型列表时，他们通常会说：“好吧，我们只需要文本和选择，其余的都是不必要的。”经过三个月的工作，他们使用关系、画廊、重复器和灵活的内容，并询问：“是否有一个字段类型......”需求随着对可能性的理解而增长。因此，对我们来说，一次性实现所有二十多种类型，而不是逐渐添加它们，是非常重要的。因为当客户意识到他需要中继器但没有中继器时，他就会回到ACF。然后就几乎不可能退货了。第一印象很重要，如果在使用的第一天没有找到所需的字段类型，那就没有第二次机会了。
老实说，中继器是大多数人购买 ACF Pro 的功能。 ACF的免费版本不包含它，这也是每年花费四十九美元订阅的主要原因。 WooCommerce 中的中继器是什么？想象一张产品卡——机油。它已获得汽车制造商的批准：宝马 Longlife-01、梅赛德斯-奔驰 MB 229.5、大众 VW 502.00。每个容差不仅仅是一行文本。这是一个具有名称、编号、状态（有效或过时）以及确认文档链接的对象。一种油可以有二到十五个这样的公差。没有中继器如何存储这个？当然，您可以将所有内容填充到一个以逗号分隔的文本字段中。但是这样您将无法按容差正确过滤，您将无法以结构化形式显示它们，您将无法检查它们的有效性。或者您可以创建十五个单独的字段“公差 1”、“公差 2”...“公差 15” - 但这是丑陋且不灵活的。
Repeater 优雅地解决了这个问题。您创建一组子字段 - “批准名称”、“编号”、“状态”、“文档” - 并指示该组是可重复的。在产品编辑器中，内容管理员看到“添加权限”按钮，单击它，然后会出现一个包含四个字段的新块。填好后，再次点击——第二个区块出现了。您需要更改顺序 - 用鼠标拖放。需要删除 - 单击叉号。一切都很直观，一切都有效。经理不需要了解有关数据库、JSON 或元字段的任何信息 - 他只需单击“添加”并填写表单即可。
COS WP Woo 中的 CfRepeaterField 在几个重要方面超越了标准 ACF 中继器。在 ACF 中，中继器数据作为一组单独的元字段存储在 postmeta 中：_tolerances_0_name、_tolerances_0_number、_tolerances_1_name、_tolerances_1_number 等。再加上一个单独的字段_tolerances，它存储元素的数量。对于具有 10 个容差和 4 个子字段的产品，仅一个中继器就有 41 个后元条目。表中的 41 行已经重达近 1 GB。如果您的产品有三个中继器 - 一个用于批准，一个用于技术特性，一个用于文档 - 您可以轻松地在一个产品的 postmeta 中获得一百二十行。乘以一万六千个产品，仅从中继器就可以得到近两百万行。我们的实现将转发器数据作为 JSON 文档存储在类型表的一个字段中。所有子字段的所有十个容差 - 一个条目而不是四十一个。同时，搜索和过滤通过 MySQL JSON 函数进行，该函数在 8.0 及更高版本中速度相当快并且支持索引。
但中继器只是一个小东西。真正的力量始于灵活的内容。想象一下，您不仅需要创建一组可重复的相同字段，还需要创建来自不同块的构造函数。例如，在品牌页面上，可能有：带有描述的文本块、带有表格形式特征的块、带有产品图库的块、带有视频评论的块、带有经销商评论的块。每个块都有自己的字段结构 - 文本块只有一个所见即所得编辑器，图库有一组带标题的图像，特征表有一个带有参数值对的重复器。用户应该能够以任何顺序添加任何块 - 就像乐高构造函数一样。这是灵活的内容。
我们模块中的 CfFlexibleContentField 正是实现了这种场景。您定义一组“布局” - 每个布局都有自己的字段。在编辑器中，内容管理员选择所需的布局，将其添加到页面并填写字段。也许添加另一个相同或不同的。可以拖动块并更改顺序。结果是完全自定义的页面结构，由现成的组件组装而成，无需任何代码。我相信灵活的内容使 WordPress 从博客平台转变为成熟的企业级内容管理系统。因为没有它，每个非标准页面都需要开发人员干预，但内容管理员可以自己处理。对于 B2B 公司来说，这一点至关重要：品牌页面、行业产品目录、技术部分——所有这些都必须定期更新，而且每次都吸引程序员是无利可图的。
在这里，我们谈到了一个对我来说是一个真正的启示的主题 - 自定义字段与古腾堡的集成。当我开始这个项目时，我持怀疑态度。我认为古腾堡对于 WooCommerce 来说既笨重又多余。但我错了，原因如下。
古腾堡块和视觉规则构建器
你知道 ACF 最让我恼火的是什么吗？事实上，自定义字段与内容是分开存在的。您打开产品编辑器，顶部有带有描述的古腾堡，在下面的五个滚动屏幕下，有带有自定义字段的 ACF 元框。两个独立的宇宙，彼此一无所知。内容管理员被迫来回滚动，记住他负责的内容，并希望他没有错过下部元框中某处的必填字段。这不是一个架构问题——这是一个用户体验问题。对于每天处理五十种产品的内容经理来说，这种经验决定了他的生产力。
我见过一些项目，人们在主题级别通过 JavaScript 和 AJAX 在管理中发明了自己的可重复字段。它确实有效，但每次 WordPress 或 WooCommerce 更新都变成了彩票。由于 jQuery 的更改、新的元框格式或 TinyMCE 编辑器的更新，自行编写的中继器可能会损坏。每次开发人员都会花费数小时来修复本应成为平台标准功能的内容。具有可重复块的自定义字段并不是奢侈品，它们是任何重要目录的基本基础设施。事实上，WordPress 仍然没有将其包含在核心中，这是围绕自定义字段存在整个插件行业的主要原因之一。
当我们设计 CF 模块时，我设定了一个目标：每组自定义字段应该自动接收古腾堡中的块视图。不是“可以通过单独的插件配置”，不是“需要额外的开发”，而是自动的。我创建了一组字段，相应的块立即出现在古腾堡中。这是通过 CfBlocks 组件实现的，该组件根据字段组的配置动态注册古腾堡块。从技术上讲，它的工作原理是这样的：保存一组字段时，PHP 代码通过 register_block_type() 生成块注册，React 组件直接在编辑器中呈现输入表单。
这在实践中是什么样的？假设您创建了一组字段“油品技术特性”，其中包含以下字段：粘度、闪点、倾点、制造商公差、应用领域。保存组后，石油规格块将出现在古腾堡块库中。内容管理员可以将其直接插入到产品内容中、描述旁边、段落之间 - 任何位置。这些字段显示在内容的上下文中，而不是显示在页面底部的单独元框中。这从根本上改变了工作流程。您不再是“在顶部填写描述，然后向下滚动并填写特征”，而是获得单个流程 - 描述，然后是具有特征的块，然后是另一个描述，然后是具有公差的块。一切都以正确的顺序集中在一处。
当然，我们还保留了元盒的经典方法。并非所有用户都准备好使用古腾堡，也并非所有脚本都需要块表示。有些公司的 WordPress 编辑器设置为经典模式，改变人们的习惯不是我们的工作。如果您习惯了元盒，请注意，它们的工作方式与 ACF 中的完全相同。但切换到区块的机会是存在的，而且不需要额外的努力。这是团队准备情况的问题，而不是技术限制的问题。
现在谈谈视觉设计师 - 这是我在本模块中最自豪的事情之一。 CfLocationRulesBuilder 是一个可视化构建器，可准确确定自定义字段的显示位置。在 ACF 中，这通过下拉列表实现：“如果记录类型是产品并且产品类别是 masla，则显示此字段组。”丢失、小文本、不明显的 AND/OR 逻辑甚至会让经验丰富的用户感到困惑。我们的构建器是一个用 React 构建的可视化界面，其中规则以卡片的形式表示。您可以从字面上看到逻辑：该条件块通过 AND 连接，并通过 OR 连接到另一个块。你拖动卡片，改变条件，你就会立即明白会发生什么。我向几位内容经理展示了这一点，他们之前几个月都不敢碰 ACF 设置 - 他们在五分钟内就搞清楚了。没有文档，没有培训。
CfConditionalLogicBuilder 更进一步。这是单个字段级别的条件逻辑：根据其他字段的值显示或隐藏一个字段。例如，如果机油类型为“发动机”，则显示“发动机公差”字段。如果类型是“液压”，则显示“ISO 等级”字段。如果选择制造商“Shell”，则显示附加字段“Shell line”。为什么这是必要的？然后，机油和液压油的产品卡是具有不同字段集的两张不同的卡。条件逻辑不是一次向经理显示所有 30 个字段（其中一半不适用），而是仅显示相关字段。更少的字段 - 更少的错误 - 更快的完成。 ACF 有这个功能，但它是作为一个简单的条件列表实现的，没有视觉反馈。我们的构建器直观地显示了字段之间的连接 - 您可以看到哪些字段依赖于哪些字段，以及应用了哪些逻辑。最重要的是，您可以直接在设计器中测试条件，而无需转到产品编辑器。
很长一段时间以来，我一直想知道这些视觉构建器是否值得我花时间。代码就是这样：它可能只是一个配置文件或一个软件 API。但后来我想起有多少次客户打电话给我询问“为什么这个领域没有出现在这样那样的类别中？” - 答案总是相同的：位置规则配置不正确，因为配置界面难以理解。视觉设计师并不能解决世界上所有的问题，但它解决了这个特定的问题——人们在设置时不再犯错误，也不再给我打电话。相信我，这值得我们在这些组件上花费数周的开发时间。
兼容性层和生态系统：为什么它不仅仅是另一个插件
当我们开始设计 CF 模块时，我立即意识到百分之九十的潜在用户都是已经在使用 ACF 的人。他们还没有准备好“拿起并转换”。他们有调用 get_field() 和 the_field() 的主题模板。他们有通过 ACF API 与 ACF 集成的插件。他们在functions.php 中有使用ACF 挂钩的自定义代码。没有兼容层的迁移意味着：重写网站的整个前端、所有模板、所有集成。对于一个拥有一万六千个产品的网站来说，这意味着数月的工作和破坏某些东西的巨大风险。即使新工具客观上更好，聪明的企业也不会承担这种风险。
因此，我们实现了 register_cf_compat() - 一个兼容层，它拦截所有标准 ACF 函数并将它们路由到我们的模块。 get_field()、the_field()、get_sub_field()、have_rows() 函数都可以工作。您可以停用 ACF，激活我们的模块，您的模板将继续工作，而无需更改任何代码。兼容性层在包装函数级别工作。当您的模板使用字段键和帖子 ID 调用 get_field 时，我们的包装器会确定该字段属于哪个字段组，访问 wpaic_cf_values 表而不是 postmeta，并以 ACF 返回的相同格式返回值。对于转发器，逻辑更复杂 - have_rows() 初始化内部迭代器，the_row() 移动指针，get_sub_field() 从当前行检索值。所有这些机制都被准确地再现，因为我们理解：模板中的一个损坏的地方，客户端将永远返回到 ACF。
但我想说实话：100% 兼容性是一个乌托邦。如果您的代码直接使用 ACF 内部类，或者您绑定到文档中没有的特定挂钩，则可能存在细微差别。我们已经介绍了公共 API，该 API 在文档中进行了描述，并且在 95% 的情况下使用。其余五个是需要单独分析的外来物种。对于绝大多数站点，迁移如下所示：安装 COS WP Woo、激活 CF 模块、从 ACF 导入字段组、停用 ACF、检查 - 它有效。
数据迁移是一个单独的过程。兼容层允许您的站点立即工作，但数据仍然物理上位于 postmeta 中。为了获得性能优势，我们需要将数据从 postmeta 传输到我们的自定义表。这是一个单独的操作，由后台进程通过操作计划程序执行 - 无需停止站点，无需停机。对于一万六千个产品，迁移大约需要二十到三十分钟。迁移后，您可以获得与旧代码的兼容性和新存储的性能。当您确定一切正常时，可以保留 postmeta 中的旧数据作为备份或删除。
REST API 怎么样？这是开发人员提出的问题，而且完全合理。在现代项目中，前端越来越与后端分离——无头架构、移动应用程序、与外部系统的集成。通过 API 访问自定义字段并不是一种奢侈，而是一种必需。 ACF Pro 提供了 REST API，但有一些注意事项：您需要显式地为每组字段启用 API 支持，响应格式并不总是可预测的，对于中继器，数据采用平面形式，您需要将其独立组装成结构。我们的模块从一开始就提供完整的 REST API。一个控制器，具有适用于字段和值组的完整 CRUD。字段值以嵌套格式提供：repeater 作为对象数组返回，Flexible Content 作为指示布局类型的块数组返回。客户端无需手动收集数据。格式是可预测的、有记录的并且在版本之间不会改变。
九个服务在后台运行该模块。 CfFieldGroupService 管理字段组。 CfFieldService - 各个字段及其配置。 CfFieldValueService - 读取和写入值。 CfRelationshipService - 对象之间的连接。管理面板中的六个 React 页面提供完全控制：字段组列表、组编辑器、布局规则设计器、条件逻辑设计器、从 ACF 迁移、模块设置。一切都建立在标准 WordPress 组件上，因此界面看起来很原生，并且不会与其他插件冲突。
我知道很多人会说：“如果有 Carbon Field、Pod、Meta Box，为什么要做这一切呢？”这是一个公平的问题，我会直接回答。 Carbon Fields 是一个很棒的免费插件，但它没有用于在管理面板中创建字段的可视化界面，一切都是通过代码完成的。这对于开发人员来说很正常，但对于内容管理者来说却是死胡同。 Pods 是一个功能强大的框架，但它对于大多数任务来说都太过分了，而且学习曲线陡峭，即使是经验丰富的 WordPress 用户也会感到害怕。 Meta Box 很好，但需要付费购买高级功能，并且再次与自己的十几个插件生态系统绑定。它们中的每一个都解决了部分问题，但没有一个解决了我在开头描述的问题：依赖第三方供应商来提供关键任务功能。
但最重要的是，这些插件都没有与您的搜索、1C、B2B 模块集成。 COS WP Woo 中的 CF 模块是生态系统的一部分。它与 1C 集成模块配合使用，将产品属性从 1C：贸易管理映射到自定义字段。它与一个搜索模块配合使用，该模块可以通过 Typesense 对自定义字段进行索引以进行全文搜索。它与 B2B 模块配合使用，该模块使用自定义字段来配置组访问权限。当经理向中继器添加新许可证时，我们的模块将数据写入 wpaic_cf_values，通过搜索模块挂钩更新 Typesense 搜索索引，并检查许可证是否引用 KAMAZ 或 MAZ，自动将产品添加到“俄罗斯设备”类别。管理者的一项操作会在不同的系统中产生三种结果。
我并不是说 ACF 是一个不好的产品。他很棒。他为 WordPress 中的自定义字段制定了标准，对此我们非常感激。但世界已经改变。 WordPress 已成为严肃的电子商务、B2B 门户以及与 ERP 系统集成的平台。对自定义字段的需求增长如此之快，以至于“一切都在后元中，一切都通过元查询”的方法根本停止了扩展。这不是 ACF 的错 - 这是任务的演变。我经常用交通来比喻。 ACF 是一款可靠的轿车，适合在城镇中行驶。但是，当您需要将二十吨货物从车里雅宾斯克运输到莫斯科时，您会乘坐卡车。不是因为轿子不好，而是因为任务不同。
至于成本，咱们老老实实算算吧。 ACF Pro 的费用从每年 49 到 249 美元不等，具体取决于站点的数量。五年来，仅针对定制领域，从 245 美元到 1245 美元。除此之外，还需要按元字段过滤、基于元字段的 B2B 定价、元字段的搜索索引所需的 WooCommerce 扩展，总拥有成本会增加三到四倍。 COS WP Woo 将所有这些都包含在一个许可证中。自定义字段、搜索、B2B、1C - 一切都协同工作，一切都由一个团队支持，一切都同步更新。无需每次更新时都检查五个插件的兼容性。无需编写挂钩将一个插件链接到另一个插件。无需祈祷 ACF 更新不会破坏与搜索插件的集成。
但我不希望这篇文章听起来像推销。因此，我会诚实地说明我们的模块还没有做什么。我们没有单独的前端插件来根据自定义字段生成表单 - 我们有为此的表单模块。我们没有 Elementor 或 WPBakery 的块 - 我们依赖 Gutenberg，如果您的网站完全基于 Elementor 构建，则集成将通过短代码而不是本机小部件进行。而且我们与 ACF 的兼容性层并未覆盖 100% - 我已经讨论过奇异的场景。这是一个诚实的立场，我更愿意对这些限制持开放态度，而不是稍后再处理失望的用户。
这就是我认为最重要的。当您选择用于存储和管理业务数据的工具（自定义产品字段就是您的业务数据）时，您应该考虑五到十年的视野。五年后ACF还会存在吗？很可能是的。但费用会一样吗？它会支持相同的架构吗？ WP Engine 是否会朝着您的业务需求方向发展？没有人知道这一点。当你有 16000 个产品并且 postmeta 表重达 1 GB 时，这些问题的每一个错误答案都非常昂贵。我选择可预测性——一种我控制的工具，它可以有效地存储数据，与我的生态系统集成，并且不依赖于第三方供应商的战略决策。
有一个想法我想留到最后。我们生活在一个数据是企业主要资产的时代。您的产品的特性、它们的连接、它们的技术参数不仅仅是数据库中的字段。这是贵公司多年来积累的知识。每种油的粘度、与每种类型发动机的兼容性、针对每个行业的建议 - 每个字段填写的背后都是数小时的技术工作。这些知识存储在一个您无法控制的工具中，其格式对于您的任务来说不是最佳的，存储在一个重达近 1 GB 的表中，并且每次请求都会减慢速度。也许是时候考虑如何正确存储这些知识了？是时候选择一个像尊重客户一样尊重您的数据的工具了。
如果您目前坐在屏幕前，拿着一封关于续订 ACF Pro 订阅的公开信，并思考“如果我不续订怎么办？” ——尝试问自己三个问题。您对 ACF 的依赖需要花费多少金钱 - 不仅是订阅费用，还有支持集成的时间？您的 postmeta 表的重量是多少？这对网站速度有何影响？如果 ACF 更改 API 或定价政策，您是否有备用计划？如果至少有一个答案不适合您，那么就该考虑做出改变了。
试用 COS WP Woo - 十四天免费。安装、激活自定义字段模块、从 ACF 导入一组，使用一周。感受请求速度的差异，尝试视觉规则生成器，看看中继器在古腾堡块中如何工作。然后用自己的双手，使用自己的数据做出决定，无需营销承诺。因为最好的论据就是你自己的经历。