最近，一家工业润滑油网上商店的店主联系了我。 WooCommerce 上的网站，目录 - 大约四千种产品，流量相当不错，订单源源不断。但他的问题与销售或搜索引擎优化无关。他的字面意思是：“奥列格，我的网站上有 32 个插件，我不敢点击其中至少一个插件的“更新”按钮。上次我更新产品过滤器时，添加了购物车和比较。商店在那儿呆了两天。该怎么办？”你知道，在那一刻我发现自己在想我大约每个月都会听到一次这个故事。不同的利基市场，不同的业务规模，但问题是相同的——曾经为了增长而一点一点组装起来的插件动物园，但现在却变成了雷区。每次更新都是俄罗斯轮盘赌。每个新插件都可能与已安装的三个插件发生冲突。而最可悲的是，店主却认为这是理所当然的。就像 WooCommerce 的不可避免的罪恶一样。他们说，好吧，你能做什么，这样的平台是模块化的，基于插件，这就是每个人的生活方式。
嗯，不是全部。我想谈谈为什么“动物园”不是必然，而是一种选择。这是一个昂贵的选择，一个有风险的选择，而且在大多数情况下是一个无意识的选择。因为当你以每年 99 美元的价格安装第一个愿望清单插件时，你不会想到六个月内你会有 20 个这样的订阅，并且扩展的总检查量将超过托管本身成本的三倍。您只需解决一个特定问题：“我需要一个愿望清单。”然后“我需要进行产品比较。”然后“我需要一个 B2B 模块。”然后我们就出发了。我自己也经历过这一切——无论是作为商店老板还是作为为客户建造这些商店的人。在某个时刻，我意识到我不能再这样生活了。需要一种根本不同的方法。但让我们按顺序讨论一切。
典型 WooCommerce 商店剖析：幕后内容
让我们以 WooCommerce 上的条件“平均”在线商店为例。不是包含十种产品的登陆页面，而是一个正常的工作商店：数千种商品的目录、多个类别、过滤器、搜索、购物车、结账、个人帐户。没什么特别的——电子商务的基本设置。现在让我们看看这样的网站上有哪些插件可用，我不是在谈论一些虚构的场景，而是在谈论我见过和从事过的真实项目。
WooCommerce 为您提供开箱即用的目录、购物车和结帐功能。其他的都是插件。产品过滤 - 插件。目录搜索正常工作，不像标准的 WordPress 搜索返回页面而不是产品 - 插件。产品比较 - 插件。愿望清单是一个插件。巨型菜单，使目录在标题插件中组织得非常漂亮。 B2B 功能：批发价格、客户群体、报价请求——这已经是一整套插件了。安全 - 防火墙、强力保护、监控 - 插件。 SEO 分析和审核 - 插件。产品的自定义字段 - 插件。反馈和申请表 - 插件。通过 SDEK、Boxberry、KIT 交付 - 每个运营商一个插件。与 1C 的集成是一个单独的插件。上传到 Yandex.Market 是另一回事。重定向 - 更多。 XML 站点地图仍然正常。我还没有提到缓存、图像优化、带有文件夹的媒体库和十几个小实用程序。
我没有夸张。我现在将打开一个真实的项目并进行数学计算。我去年接手的一家商店有 27 个活跃插件，其中 19 个是 WooCommerce 功能的扩展。不是装饰性的“漂亮按钮”，而是工作模块，没有它商店就无法运作。拿走其中任何一个，就会有东西损坏。过滤器将停止过滤，搜索将停止搜索，B2B客户将看不到他们的价格，1C将停止上传余额。每个插件都是一个依赖项。有趣的地方就开始了——让我们计算一下它的成本是多少。
YITH WooCommerce 愿望清单高级版 - 99 美元/年。 YITH WooCommerce 比较高级版 - 79 美元/年。 YITH Ajax 产品过滤器 - 每年 99 美元。 Wordfence 高级版 - 每年 119 美元。 ACF Pro - 每年 99 美元（个人许可证 49 美元，但商业站点需要企业）。 SearchWP - 每年 99 美元。 WPForms Pro - 每年 199 美元（或者 Contact Form 7 是免费的，但有一堆收费的插件）。 MaxMegaMenu Pro - 每年 49 美元。 SDEK 交付插件 - 每年 3900 卢布。 Boxberry 插件 - 2500 卢布。用于 1C 集成的插件 - 每年 5,000 至 15,000 卢布，具体取决于功能。 Yoast SEO 高级版 - 每年 99 美元。 Yandex.Market feed 插件 - 从 2000 到 5000 卢布。适用于媒体组织的 Real Media Library - 49 美元。这甚至没有考虑到主题，主题本身每年的更新费用可能为 59 至 79 美元。
如果将其全部加起来，每年仅插件费用就在 900 美元到 1,500 美元之间。按 90 卢布兑换 1 美元的汇率计算，每年 81,000 - 135,000 卢布。用于订阅插件。不是为了托管，不是为了域名，不是为了程序员的工作——只是为了使用别人代码的权利。每年你都必须再次支付这笔费用，因为如果你停止支付，更新就会停止，如果没有更新，该插件迟早会在新版本的 WordPress 或 WooCommerce 上崩溃。我见过一些商店运行的是三年前的插件，但它们只能工作，因为所有者害怕将 WordPress 更新到某个版本以上。这不是一个策略——而是一个定时炸弹。
但钱也不是那么糟糕。金钱是可以计算、计划、预算的。更糟糕的是无法计算的损失——冲突、停机和生产力下降造成的损失。
二十个插件 - 二十个故障点
以下是我多年来在 WooCommerce 商店工作中学到的东西：每个插件都是一个独立的代码单元，由其自己的作者根据自己的标准编写，具有自己的架构。当您的网站上有 20 个插件时，您就有 20 种不同的方法来处理数据库、20 种不同的方式来连接 JavaScript 和 CSS、20 种不同的挂钩和过滤器系统来挂钩相同的 WooCommerce 事件。迟早，这二十个插件中的两个会开始发生冲突。并不是因为它们写得不好 - 通常这两个插件都具有出色的质量。只是他们的作者彼此不了解，无法预见他们的代码会同时在同一个网站上运行。
我记得有一个案例，客户的商店同时安装了 YITH Compare 和另一个开发人员的 B2B 定价插件。单独来看，两者都完美地工作。但同时发生的事情是，当 B2B 客户打开产品比较页面时，他看到的是零售价而不是批发价。为什么？因为 YITH Compare 通过 AJAX 请求生成其比较表，并且 B2B 插件通过 woocommerce_product_get_price 挂钩拦截价格，这在 Compare AJAX 请求的上下文中的工作方式与常规产品页面不同。该错误仅针对 B2B 客户、仅在比较页面上、仅针对某些产品重现。我们找了他三天。在三天的时间里，程序员坐下来理解两个插件的代码，我们对它们的源代码的访问有限，因为这两个插件都是高级的，代码很模糊。
现在想象一下，网站上这样的潜在冲突不是一两个，而是几十个。每对插件都是一个潜在的交叉点。如果您有二十个插件，则可能的对数为一百九十。一百九十个潜在的冲突。当然，并非所有这些都得到实施，但即使是二十个“射击”中的一个，那也几乎是十个真正的问题，每个问题都需要时间和金钱来诊断和纠正。
冲突不仅仅是功能错误。这也与生产力有关。每个插件都会将自己的表添加到数据库中。 ACF有自己的表格，wishlist有自己的，B2B模块有自己的，搜索有自己的，1C集成有自己的。在其中一个项目中，我计算出：二十个插件在数据库中总共创建了四十七个附加表。除了标准 WordPress 和 WooCommerce 表之外，还有 47 个表。当页面加载时，每个插件都会对其表进行自己的 SQL 查询。一个插件 – 两到五个请求。二十个插件 - 每个页面加载四十到一百个额外的 SQL 查询。每个人还包括自己的 CSS 文件和自己的 JavaScript。二十个 CSS 文件、二十个 JS 文件 - 浏览器必须额外下载、解析和执行 500-800 KB。在快速的互联网上，你可能不会注意到这一点，但 PageSpeed 会注意到，Yandex 在排名时也会注意到。
我在一个特定项目上对此进行了测量。油和润滑油商店，二十三个插件。服务器响应时间 (TTFB) 为 1.8 秒。目录页面的完全加载时间为 4.2 秒。我们开始一一禁用插件并再次测量。每个停用的插件平均需要 TTFB 80-120 毫秒。当我们用一种综合解决方案替换 17 个插件时，TTFB 下降到 0.7 秒。页面在 1.9 秒内开始加载。速度提高一倍 - 无需更改托管、无需 CDN、无需任何其他优化。仅仅是因为这样一个事实，即不再是十七个独立的代码段，每个代码段都以自己的方式初始化，加载其资源并向数据库发出自己的请求，而是一个具有单一架构的插件开始工作。
但是让我们谈谈通常被遗忘的另一个方面 - 更新。二十个插件意味着二十个不同的作者，二十个不同的更新时间表。一位作者每周发布一次更新，另一位作者每六个月发布一次更新。一个测试与最新版本的 WooCommerce 的兼容性，另一个则不测试。一个写了详细的变更日志，另一个则限制自己进行简洁的“错误修复”。每个插件的每次更新都是潜在的风险。我知道店主每周花两到三个小时只是检查可用的更新，阅读变更日志，决定现在更新什么，可以等待什么，进行备份，更新，检查是否有任何损坏。每周两到三个小时相当于一年一百到一百五十小时。用于插件更新。如果按照至少系统管理员的汇率换算成金钱，每年还有 150-30 万卢布的隐性开支。
当我决定受够了
我的转折点大约发生在三年前。我参与了一个大型 B2B 项目 - 一家工业化学品商店，有 15000 种产品，一个包含客户群体和个人折扣的复杂定价系统，与 1C 集成，多交付 SDEK 加 KIT 加业务线，按技术特征过滤、愿望清单、比较、报价请求表。为严肃的 B2B 商店设置的标准。该网站上有二十五个插件。然后 WooCommerce 推出了一个重大更新 - 我不记得具体是哪个版本，但更新很重要，对 API 进行了更改。一切都崩溃了。二十五个插件中有三个与新版本不兼容。其中之一，1C 集成插件，根本就停止工作了。作者在两周后发布了更新。两周来，商店一直在与 1C 不同步——余额没有更新，价格没有更新，新产品没有卸载。第二个插件，产品过滤器，在按价格过滤时开始产生错误。作者在四天后回复支持，并在一周后发布修复程序。第三个插件，B2B 定价模块，不再正确计算某一客户群的批发折扣。我们并没有立即注意到这个错误，而是当客户抱怨他被收取零售价而不是批发价时才注意到这个错误。在我们发现这一点之前，有多少订单的价格不正确——我仍然不知道。
然后我问自己这个问题：事实上，为什么一切都应该是这样的？为什么一家商店需要来自 25 个彼此一无所知的不同作者的 25 个独立软件产品？为什么你不能拥有一种产品来满足商店的所有需求？不是“一个把所有事情都做得很糟糕的插件”，而是一个具有深思熟虑的架构的产品，其中所有模块都在单个代码库中工作，使用公共库，公共钩子系统，数据库中的公共表？
我开始寻找这样的解决方案。我没有找到。更准确地说，我发现了几种尝试 - WooCommerce 的“一体化”插件，它承诺取代世界上的一切。但经过仔细检查，结果发现它们要么是一组松散耦合的模块粘合在一起形成一个 zip 文件，要么是每个模块的功能都被精简到仍然需要交付专门的插件才能实际工作的产品。这种组合中的“产品过滤器”由三个复选框和一个价格滑块组成。 “B2B”是用于输入团体折扣的字段。 “搜索”是具有不同模板的标准 WordPress 搜索。你无法以此为基础建立起严肃的事业。
然后我决定自己构建它。并不是因为我是世界上最聪明或最有经验的开发人员，而是因为我知道与我合作的特定商店的特定需求。我知道哪些功能是实际使用的，哪些是营销废话。我知道插件在哪里发生冲突以及原因。我知道哪些数据库查询是性能杀手以及如何优化它们。这就是 COS WP Woo 的诞生方式——一个插件，最初是我项目的内部工具，后来发展成为一个成熟的产品。
“一个插件而不是二十个”在实践中意味着什么？
我不会在这里描述每个按钮和每个复选框 - 有文档和页面包含各个模块的描述。我想讲一个原则。关于当您从大量插件转移到单一解决方案时会发生什么变化。为什么它不仅“更方便”，而且从根本上改变了商店的经济性和可靠性。
让我们从架构开始。当二十个插件被一个替换时，这并不意味着二十个代码库被机械地粘合到一个代码库中。这意味着创建一个单一架构，其中所有模块共享一个公共基础设施。通用级自动加载机 - 一台而不是二十台。通用钩子注册系统 - 所有模块都通过单个入口点以可预测的顺序连接，没有优先级冲突。通用REST API——通用命名空间、通用授权系统、通用响应标准。数据库中的共享表是有意义的 - 不是每个模块都创建自己的日志记录表，而是一个公共的 Activity_log 表为所有模块提供服务。常见的 JavaScript 包是一个文件而不是 20 个文件，由 webpack 编译、缩小，并通过 tree-shaking 删除未使用的代码。通用 CSS - 一种样式系统，而不是二十个文件，每个文件都带有自己的 Bootstrap 版本或自己的自定义框架。
实际上，这意味着当 B2B 定价模块计算一组客户的批发价格时，该价格立即对产品比较模块、心愿单模块、购物车模块、价格过滤模块可见。不是通过一个插件可以拦截而另一个插件不能拦截的中间挂钩。直接通过共享服务。因为所有这些模块都是一个整体的一部分，并且它们彼此了解。
当搜索模块为产品编制索引时，它会使用自定义字段模块中定义的所有自定义字段对其进行索引。不是因为“我们编写了与 ACF 的集成”，而是因为自定义字段和搜索是同一插件的两个模块，它们使用相同的服务来访问数据。当 1C 模块更新产品余额时，过滤模块、Yandex.Market feed 模块和心愿单通知模块（发送“产品有货”的信件）可立即使用更新后的数据。所有这一切都发生在一个请求内，无需额外的 AJAX 调用，无需中间缓存，无需通过 cron 进行同步。
让我使用真实项目中的具体数字来展示这一点。石油和润滑油商店与我上面提到的相同。在切换到 COS WP Woo 之前：23 个插件，数据库中的 47 个附加表，大约 90 个用于加载目录页面的 SQL 查询，前端连接的 18 个 CSS 文件和 15 个 JS 文件，TTFB 1.8 秒，完全加载 4.2 秒。过渡后：1个插件（当然还有WooCommerce，还有主题），数据库中30个表（是的，COS WP Woo也创建了自己的表，但数量较少，因为公共功能使用公共表），同一页面上大约35个SQL查询，前端有3个CSS文件和2个JS文件，TTFB 0.7秒，完全加载1.9秒。 PageSpeed Insights 显示，桌面版提高了 23 点，移动版提高了 18 点。没有任何其他优化 - 只需用单一解决方案替换大量插件即可。
现在谈谈钱。同样的 23 个插件每年需要客户花费大约 1,100 美元的订阅费用。再加上每年大约 200 小时的维护时间 - 更新、兼容性检查、解决冲突、联系不同供应商的支持。按系统管理员每小时 1,500 卢布的最低工资计算，这又是 300,000 卢布。总计：每年大约 400,000 卢布用于维护插件动物园。一个 COS WP Woo 许可证的价格 - 我不会在这里给出具体数字，因为我们有一个灵活的关税系统，具体取决于模块的数量 - 但我会这样说：每年节省至少三倍。而且这还没有考虑到停机、冲突和低站点速度造成的隐性损失。
但我想说实话 - 从大量插件切换到单一解决方案并不是免费的。这是一个项目。您需要迁移数据 - 用户愿望列表、B2B 组设置、自定义产品字段、搜索历史记录、重定向规则。我们需要配置新模块并检查一切是否按预期工作。你需要花时间。通常，迁移一家普通商店需要一到三天的时间。但如今，第一个月就得到了回报——由于订阅费用的节省、速度的提高、冲突的消失。
一体化的黑暗面 - 以及为什么 COS WP Woo 不是那样的
我完全理解“一个插件而不是二十个”的想法引起的怀疑。因为这个想法有一个众所周知的阴暗面，需要公开讨论。单一的“一体化”解决方案经常因三件事而受到批评：供应商锁定、臃肿的规模和复杂性，以及“如果一个插件坏了，一切都会坏”的风险。让我们诚实地审视这些论点，不带任何营销修饰。
供应商锁定。是的，当您从 20 个独立插件切换到一个复杂插件时，您就会依赖于一名开发人员。如果开发商放弃项目或破产，你就会遇到问题。这是一个真正的风险，我不会假装它不存在。但让我们从另一方面来看。当你有二十个插件时，你就依赖二十个开发人员。如果他们中至少有一个放弃了他们的插件，那么你也会遇到一个问题，只是一个本地问题。我见过这样的情况：流行的 WooCommerce 插件的作者干脆停止支持它，导致数千家商店留下死代码，这些代码与每次 WordPress 更新的兼容性越来越差。对于动物园来说，这似乎不太重要 - 您可以用模拟插件替换一个死插件。但是将数据从一个愿望清单插件迁移到另一个愿望清单插件也是一个项目，也需要时间和金钱。因此，这两种情况都存在供应商锁定的风险，只是形式不同。
特别是关于 COS WP Woo，我们分发了一个开源插件。您将获得完整、清晰的 PHP 和 JavaScript。如果我们明天从地球表面消失（我希望这不会发生），您的插件仍然可以工作，任何合格的 WordPress 开发人员都可以维护和修改它。这从根本上将我们与带有加密代码的插件区分开来，后者在没有有效许可证的情况下变成了南瓜。
充气尺寸。第二个经典论点是，如果一个插件包揽了所有事情，那么它不可避免地又重又慢。我只需要一个愿望清单 - 为什么我需要下载 B2B 和 1C 集成？这个论点是合乎逻辑的，但它忽略了一个重要的细微差别：只有激活的内容才会被加载。 COS WP Woo 构建在模块化、延迟加载的架构之上。如果您没有启用 1C 模块，则根本不会加载其代码。它不是“已加载但未执行”，而是没有物理连接。自动加载器不会加载非活动模块的类，JavaScript 使用代码分割和延迟加载 - 活动页面包不包含非活动模块的代码。实际上，如果您使用十个可用模块，则加载的代码的大小大约等于十个单独的插件，但有一个重要的区别：十个单独的插件有十个 jQuery 包装器副本、十个 AJAX 实用程序副本、十个不同的 CSS 框架。具有模块化架构的插件具有适用于所有模块的通用基础设施。因此，实际上，十个 COS WP Woo 模块的重量小于十个类似的独立插件。
第三个论点是“如果一个坏了，一切都会坏”。这里我就尽可能直接的说：是的，这是一个风险，我们从一开始就考虑到了。因此，每个 COS WP Woo 模块都隔离在自己的命名空间中，具有自己的服务、自己的 REST API 控制器和自己的前端类。如果Mega Menu模块突然发生错误，不会影响B2B模块或搜索模块。每个模块在初始化点都通过 try-catch 包装器连接，一个模块中的致命错误不会使整个插件崩溃。这不是一种理论 - 我们专门测试了这种情况：我们人为地破坏一个模块并检查其余模块是否继续工作。此外，单一代码库意味着统一测试 - 我们在每个版本中测试所有模块之间的兼容性，这对于包含 20 个独立插件的动物园来说是不可能的。
有时我还会听到另一个论点：“专门的插件总是比组合中的模块更好。”这也不完全正确。毫无疑问，Wordfence 是一款出色的安全产品。但是，如果您的商店只需要 WAF、暴力保护、文件完整性监控和双因素身份验证，您是否需要所有 Wordfence？ COS WP Woo 中的安全模块恰好满足了这些需求 - 不多也不少。 SearchWP 是一个很棒的搜索插件。但是，如果您的商店已经使用 Typesense 进行搜索（并且我们的搜索模块专门与 Typesense - 最快的开源搜索引擎配合使用），那么您不需要 SearchWP 及其基于 MySQL 的搜索，该搜索在包含一万个产品的目录时开始明显变慢。有时，“组合中的模块”在技术上比专门的插件更现代，仅仅是因为它是后来编写的并且考虑了其前辈的经验。
我并不是说 COS WP Woo 在任何情况下都比每个插件都好。 Wordfence 比我们更了解 WordPress 安全性。 Yoast比我们更了解SEO。但对于不需要一个模块，而是十到十五个模块的典型 WooCommerce 商店来说，单个解决方案的总价值远远超过单个“同类最佳”插件的好处。因为孤立的最佳品种和与其他十九个最佳品种结合的最佳品种是两种完全不同的体验。
让我浏览一下主要模块并告诉您它们到底替换了什么。不是以枯燥的清单的形式——我保证不会有清单——而是通过每个清单所解决的实际问题的棱镜。
AI 内容模块可能是 COS WP Woo 最独特的部分，因为实际上没有单独插件形式的直接类似物。是的，有用于 AI 内容生成的插件，但大多数都是 ChatGPT API 的简单包装器，一次生成一个文本。我们的模块以批处理模式工作：您设置参数，选择产品 - BatchProcessor 通过操作调度程序在后台处理至少一千个位置。在这种情况下，您可以选择一个提供商 - Anthropic Claude 或 OpenAI - 并为您的利基市场创建专门的提示。描述的 A/B 测试允许您比较不同文本选项对实际流量的转换。这个工具取代的不是插件，而是整个文案部门。我们的一位客户是一家汽车油店，一晚上就生成了 12000 种产品的描述。对于由三名文案撰稿人组成的团队来说，这需要三到四个月的手工工作。
SEO 和审核模块是我们对 Yoast Premium 加排名数学组合的答案。根据十五个或更多标准对产品卡进行全面审核：描述长度、元标签、图像替代文本、内部链接、结构化数据。自动为每个产品生成常见问题解答，并以 JSON-LD 格式输出 - 这些是直接出现在搜索结果中的相同“问题和答案”，可显着提高点击率。重定向模块取代了重定向或安全重定向管理器。 Sitemap 模块生成针对 WooCommerce 优化的 XML 站点地图 - 包含产品、类别、图像。所有这一切都是一个单一的生态系统：审核员了解自定义字段、重定向与搜索集成、站点地图考虑到产品的 B2B 可见性。
B2B 模块通常由三到五个插件覆盖：YITH B2B、WooCommerce B2B、批发定价插件、报价请求插件、子帐户插件。我们的 B2B 模块包括十个子模块：多级定价的客户群、单独的价格、产品可见性规则、最低订购量、电子钱包、采购部门员工的子账户、带有通信和反建议的报价请求工作流程、B2B 客户的自定义注册、商业提案的 PDF 文档、B2B 的支付网关 - 发票付款和采购订单。我不知道有哪个插件可以同时涵盖所有这些。通常，WooCommerce 上成熟的 B2B 需要三到五个插件，它们不可避免地会相互冲突，因为每个插件都以自己的方式修改 WooCommerce 定价逻辑。
搜索模块与 Typesense 配合使用，Typesense 是一个开源搜索引擎，比任何基于 MySQL 的搜索（包括 SearchWP 和 Relevanssi）更快、更相关。具有自动完成功能的即时搜索、分面过滤、同义词、查询分析、搜索管理 - 一切都开箱即用。加上与润滑剂卡和应用表的集成。取代 SearchWP（每年 99 美元）或 Relevanssi Premium（每年 99 欧元），并且速度更快。
安全模块 - WAF（Web 应用程序防火墙）、强力保护、文件完整性监控、双因素身份验证、地理封锁、自定义登录 URL、活动日志、XML-RPC 保护、验证码集成。取代 Wordfence Premium（119 美元/年）或 Sucuri（199 美元/年），满足典型的 WooCommerce 商店需求。我不会假装我们的模块完全类似于 Wordfence 及其签名数据库和威胁情报。但对于需要针对标准威胁进行基本保护的商店来说，这已经足够了，最重要的是，它不会与其他模块发生冲突。
表单模块是一个拖放表单生成器，它取代了 Contact Form 7（免费，但带有付费插件）或 WPForms Pro（199 美元/年）。反馈表、申请表、报价请求表 - 所有内容都收集在可视化构建器中，记录存储在具有完整日志记录的数据库中。与电子邮件模块集成允许您通过 SMTP 发送通知，而无需额外的插件。
自定义字段模块完全替代了 ACF Pro（高级自定义字段）。字段组、重复器、灵活的内容、图库、布局规则、条件显示逻辑。对于那些使用过 ACF 的人来说，转换几乎是无缝的，因为我们已经实现了一个兼容层，可以理解 ACF 函数 get_field() 和 the_field()。如果 ACF 有效，为什么要更换？因为 ACF 是另一个独立的插件，有自己的表、自己的更新、自己的潜在冲突。自定义字段的内置模块可以与搜索模块（字段在 Typesense 中自动索引）、审核模块（审核员检查自定义字段的完整性）和 1C 模块（字段映射到 1C 属性）一起本地工作。
Mega Menu 模块取代了 MaxMegaMenu Pro（49 美元/年）。我们确实从 MaxMegaMenu 迁移到了工作商店中的模块 - 我们停用了 MaxMegaMenu，激活了我们的模块，一切正常。嵌套子菜单、目录中的选项卡、图标、移动适配 - 一切都已就位。只是现在菜单不需要单独的 CSS 框架和单独的 JavaScript 包。
过滤器模块 - 类似于 YITH Ajax 产品过滤器（每年 99 美元）。按属性、价格、可用性、评级进行过滤。 AJAX 加载结果而无需重新加载页面。小屏幕上过滤器的移动覆盖。本机过滤索引不是针对 WooCommerce 表的直接 SQL 查询，而是在后台更新的预先计算的索引。即使是对两万个产品的目录，也可以在几毫秒内进行过滤。
运输模块 - 多种投递：SDEK、KIT、Business Lines、俄罗斯邮政、Boxberry。一个模块而不是五个单独的插件（每个运营商一个）。单一设置界面、用于在结账时选择交付方式的单一矩阵以及单一跟踪系统。节省 - 每年订阅单个运营商插件可节省 10,000 至 25,000 卢布。
模块 1C - OData 与 1C 集成：贸易管理。产品、价格、余额、类别、属性的同步。在 WooCommerce 分类法上映射 1C 特征。出口订单回到1C。取代 wc1c（每年 5,000 至 15,000 卢布）或各种 CommerceML 插件。主要区别在于 OData 集成而不是 CommerceML。 OData 是通过 HTTP 运行的 REST API，而 CommerceML 是通过 FTP/HTTP 进行文件共享，已经过时且不可靠。 OData 允许实时同步，CommerceML 只允许定期上传。
YandexFeed 模块 - 为 Yandex.Market 生成产品提要。替换每年花费 2000 至 5000 卢布的单独插件。与 B2B 模块集成 - 您可以从饲料中排除仅对批发商可见的产品。与自定义字段模块集成 - 自定义产品字段作为参数显示在 Feed 中。
我还没有提到模块比较（比较产品）、愿望清单（带有有关降价和库存退货通知的愿望清单）、购物车弹出窗口（弹出式购物车）、底部菜单（移动底部菜单）、CSS 编辑器（可视化 CSS 编辑器）、媒体文件夹（将媒体库组织到文件夹中）、登录页面（自定义登录页面）、插入代码（插入自定义代码 - 类似于代码片段）、电子邮件（SMTP 和电子邮件日志记录）、加载更多（目录的无限滚动）、商店定制器（WooCommerce 页面的定制）、样本（属性的颜色样本）、活动日志（活动日志）、文档库（产品页面上的文档和证书库）。
我不会隐藏它 - 每个模块都有专业竞争对手没有的功能，以及竞争对手更深入实现的功能。这很好。但重点并不是要单独击败每个竞争对手，而是要为商店提供一个功能齐全的整体，而不是各个不同部分的集合。在这个“整体”中，每个模块都加强了其他模块。
当买家将产品添加到愿望清单时，愿望清单模块会将其记录在数据库中，分析模块会在统计中考虑到这一点，电子邮件模块准备在价格下降时发送通知，搜索模块在对结果进行排名时会考虑产品的受欢迎程度。四个模块同步工作，无延迟、无数据重复、无冲突。尝试通过四个独立插件实现相同的目标 - 我真诚地祝你好运。
你知道“一个插件而不是二十个”方法的正确性最让我信服的是什么吗？不是省钱，不是提高生产力，而是简化升级。过去，当 WooCommerce 发布新版本时，我会首先打开包含 25 个插件的列表并检查每个插件的兼容性。然后我就等待所有作者发布更新。然后我一次更新一个，并在每一个之后进行检查。整个过程可能需要一周时间。现在我正在更新一个插件。一。我们在发布前测试了与新版本 WooCommerce 的兼容性，发布更新，客户端一键点击。如果出现问题 - 一个支持联系点、一个用于验证的变更日志、一个回滚到先前版本。不是写给二十五种不同支持服务的二十五封信 - 一项请求，一项答复，一项解决方案。
我思考了很长时间如何完成这篇文章，并决定不以一个漂亮的“总数”来结束它，而是这样说。 WooCommerce 上的插件繁多并不是平台的错误，也不是不可避免的。这是 WordPress 生态系统历史演变的结果：每个开发人员解决一个问题，将解决方案打包成一个插件，然后出售。当商店需要两到三次扩建时，这种方法很有效。但如今，当 WooCommerce 商店平均需要 15 到 20 个扩展时，“每个任务插件”模型开始出现问题。冲突、性能、维护成本——所有这些都随着每个添加的插件而非线性增长。两个插件 - 几乎没有问题。十个是可以忍受的。二十——你花在维护动物园上的时间多于发展业务的时间。
我并不是说每个 WooCommerce 商店都应该立即拆除所有插件并安装 COS WP Woo。如果你有一个小商店，有五个插件并且一切正常，看在上帝的份上，不要碰它。但是，如果您在本文中认识到自己 - 如果您有超过 15 个插件，如果您害怕更新，如果每个月都会出现问题，如果页面加载速度有很多不足之处，如果您为订阅支付的费用比托管费用更高 - 想想是否是时候把事情整理好。
免费试用 COS WP Woo 14 天。安装、激活必要的模块，看看它们在您的组合中如何工作。从当前插件迁移数据 - 对于大多数插件，我们在界面中提供了迁移工具。如果两周后您意识到一个插件真的可以取代二十个插件，您会惊讶于自己没有早点这样做。如果它不起作用，除了几个小时的测试时间之外，您不会损失任何东西。但我愿意打赌它会成功。