COS WP Woo
返回博客
功能扩展

拖放表单生成器:无需联系表单 7 的票证和调查

联系表格 7 + 一份表格有五个插件?我将告诉您我们如何将具有拖放、条件逻辑和应用程序存储功能的可视化表单设计器直接构建到 WooCommerce 插件中。

上周,我统计了我的一个客户网站上的插件数量。一家普通的 WooCommerce 商店,工业设备,没有什么异国情调。因此,我查看了活动插件列表 - 其中有用于一个反馈表单的 Contact Form 7、用于存储应用程序的条件字段、用于存储应用程序的 Flamingo、用于上传文件的文件上传,以及蛋糕上的樱桃 - 某种用于精美设计的付费附加组件,因为标准 CF7 表单看起来像是在 1998 年制作的。五个插件。五个潜在的故障点。五个更新源,每个更新源都可能会破坏某些内容。所有这些都是为了让客户可以写“我想知道液压油的价格,这是我的电话号码。”

然后我想 - 为什么会发生这种情况?为什么 WordPress 社区习惯于这样一个事实:要解决一个问题,您需要从五六个不同的插件组装一个构造函数,每个插件都由不同的作者编写,在不同的时间更新,并且只有在没有人更新任何内容的情况下才能与其他插件兼容?毕竟,反馈表似乎是互联网上最基本的东西之一。该人填写了字段,按下按钮,数据就被发送给经理。这有什么难的呢?但如果你深入挖掘一下——添加条件逻辑、文件加载、在数据库中存储请求、普通通知——那么一个简单的任务就会变成一个集成大量扩展的工程项目。

正是这种经历促使我们在 COS WP Woo 中创建自己的表单构建器。不仅仅是另一个表单插件——世界上已经看到了足够多的表单——而是一个可以完全解决问题的内置模块。具有可视化拖放构建器、条件逻辑、应用程序存储、电子邮件通知和通过短代码插入。集所有功能于一身,没有依赖性,没有版本冲突,每个插件都不需要单独的年度订阅。今天我想告诉你们它的内部运作方式、我们为什么做出这些决定以及我们的方法与每个人习惯的方法有何不同。

但在我们深入研究技术细节之前,让我们诚实地了解现有解决方案的问题所在。无意冒犯任何人 - Contact Form 7 为 WordPress 生态系统做出了巨大的贡献,值得尊重。但了解问题有助于评估为什么需要替代方案。

Contact Form 7 是一个插件,于 2007 年发布。距今已有 19 年了。从那时起,它的下载量已超过 3.4 亿次,并在数百万个网站上使用。但事情是这样的——它的架构基本上保持不变。表单使用带有 [text* your-name] 和 [email* your-email] 等标签的文本模板进行描述。没有可视化编辑器。没有预览。您在文本字段中编写表单代码,保存它,然后转到该页面并查看它是否像您想要的那样。依此类推,围成一圈。对于开发人员来说,这是可以忍受的。对于想要更改网站表单的经理或营销人员来说,这就是一堵墙。一堵由方括号和难以理解的参数组成的难以穿透的墙。

这仅仅是开始。您是否希望一个字段根据另一字段中的选择进行显示?设置条件字段。您是否希望将申请存储在数据库中而不只是发送到邮局?放火烈鸟。您希望客户能够附加 PDF 或照片吗?设置文件上传。你想要普通的款式吗?安装 CF7 Skins 或手动编写 CSS。这些任务中的每一个都是一个单独的插件,具有单独的作者、单独的更新周期和单独的许可证。在一个项目中,我数了一下与 Contact Form 7 相关的七个插件。七个。项目经理抱怨说,将 WordPress 更新到 6.5 后,三个表单停止工作,因为其中一个插件不兼容。这是一个熟悉的故事吗?

当然,还有付费替代方案 - WPForms、重力表格、强大表格。它们解决了 CF7 的许多问题:可视化编辑器、条件逻辑、应用程序存储 - 所有这些都在一个包中。但他们为此要钱。 WPForms Pro - 199 美元/年。重力形式 - 259 美元。这是针对一个网站的。如果您有十个项目,请将它们相乘。如果同时您还需要用于 B2B、搜索、交付、安全的 WooCommerce 扩展 - 插件的预算开始显得不合时宜。我与一家公司合作,每年仅支付插件费用就超过 1500 美元。而且这些表格远不是最昂贵的物品。

为什么在 WooCommerce 插件中构建表单

说实话,我们在规划 COS WP Woo 的表单模块时,团队内部存在争议。反对它的论点听起来是这样的:“表单是一个独立的宇宙,为什么要把它们拖到电子商务插件中?”而且这种争论并非没有意义。表单是一个非常复杂的主题,它们有自己的 UX 模式、自己的安全要求(CSRF、XSS、验证)以及自己的数据存储细微差别。但我与真实的 WooCommerce 商店合作得越多,就越清楚:表单是在线商店不可或缺的一部分。不是外部的、用螺栓固定在侧面的东西,而是有机的元素。

自己想想。 CP 申请表 - 它应该指向哪里?在销售经理的 CRM 中,它与 WooCommerce 绑定。选择类似物的申请表 - 她必须了解产品目录。回调表单 - 它应该出现在产品页面的上下文中。满意度调查表 - 它与订单相关。所有这些都不是抽象的“网站形式”,而是交易过程的要素。当它们存在于单独的插件中时,您就会失去上下文。经理在 Flamingo 中看到请求,但看不到它来自哪个页面或客户正在查看什么产品。或者他看到了它,但通过拐杖——隐藏字段、UTM 标签、通过 URL 传递参数。只要它有效,一切都有效。然后它就崩溃了,没有人明白为什么。

因此我们决定:表单是平台的一部分。不是插件,不是集成,而是一个了解有关 WooCommerce 上下文的一切的内置模块。它将数据存储在与其他模块相同的自定义表中。它通过插件中已配置的同一 SMTP 模块发送电子邮件。这是通过管理员习惯的相同 React 界面进行控制的。这个决定决定了接下来一切的架构。

现在让我们谈谈这在实践中是如何运作的。因为架构解决方案很棒,但对于站点管理员来说还有其他更重要的事情:他可以多快地创建表单、将其发布到页面上并开始接收申请。

当您在 COS WP Woo 管理中心打开表单模块(路径:商店 - 表单)时,您会看到所有表单的列表。这是一个包含名称、字段数量、状态和收到的申请数量的表。一切都简单明了。单击“创建表单”,您将进入全屏设计器。这就是乐趣的开始。

全屏模式是一个有意识的决定。我们尝试了很长时间不同的方法:侧边栏中的内置编辑器、模式窗口、标准 WordPress 布局中的单独页面。我们得出的结论是表单设计器应该占据整个屏幕。为什么?因为你正在构建一个视觉对象。您需要看看该形状在实际比例下是什么样子。您需要空间来拖动字段、设置条件和预览。挤进 WordPress 侧边栏的构建器就像通过锁孔画画一样。这是可能的,但为什么呢?

全屏画布和拖动字段

设计器分为三个区域。左侧是可用字段类型的面板。中间是表单画布,其中字段按照用户看到它们的顺序排列。右侧是所选字段的设置面板。这种三栏布局对于任何使用过 Figma、Canva 甚至 PowerPoint 的人来说都很熟悉。这是一种直观的模式,不需要培训。

可用的字段类型几乎涵盖了我在实际项目中遇到的所有场景。文本字段 - 用于姓名、申诉主题、自由评论。数字字段 - 用于数量、数量、预算。电子邮件 - 具有自动格式验证功能。电话 - 带有输入掩码,以便以统一格式接收号码。文本区域 - 用于扩展消息。下拉列表(选择)- 当您需要将选择限制为特定选项时:设备类型、交付区域、通信方式。用于多项选择的复选框:感兴趣的服务、所需的特性。单选按钮 - 当您需要精确选择一个选项时。日期 - 通过日历选择所需的交付或咨询日期。文件上传 - 图纸、技术规格、照片。甚至还有签名字段 - 供移动用户使用,他们可以直接用手指在屏幕上签名。顺便说一句,事实证明,这种需求以验收证书和保修维修申请的形式出现。

每个字段都是一个 React 组件,它在画布上的呈现与网站访问者所看到的完全一样。没有“在新选项卡中预览”——您可以在工作时立即看到结果。我们将字段从左侧面板拖到画布上,它就出现了。单击它,右侧将打开设置:标签、占位符、强制、宽度(两列布局的全宽度或半宽度)、默认值、工具提示文本。所有这些变化都是实时的 - 我们调整了右侧的标签,它立即在画布上更新。

为了实现拖放,我们使用 @hello-pangea/dnd 库 - 这是 @hello-pangea 的一个分支,它本身是 Atlassian 的 React-beautiful-dnd 的延续。选择不是随机的。我们尝试了几个选项:react-dnd、dnd-kit、带有 React 包装器的 Sortable.js。每个都有其优点,但 @hello-pangea/dnd 获胜是基于多种因素的结合。它提供了出色的触觉反馈 - 元素从面板“起飞”,跟随光标,画布上出现一个占位符,显示元素将去往的位置。它可以在触摸屏上正常工作 - 这很重要,因为越来越多的人通过平板电脑管理网站。而且它不需要编写自己的碰撞算法,而这必须在 dnd-kit 中手动配置。

但视觉设计师只是外部部分。在底层,每个表单都是一个 JSON 结构,存储所有字段的描述、它们的顺序、设置和验证规则。保存表单时,此 JSON 将保存到 wpaic_forms 表中。当访问者打开带有表单的页面时,后端的 PHP 代码会读取 JSON 并生成带有正确标记、验证和 JavaScript 处理程序的 HTML。这意味着即使插件的 React 部分未加载,表单也能正常工作 - 它完全位于前端的服务器端。没有渲染延迟,没有 SEO 问题。

在这里我想谈谈许多表单创建者忽略的一点。实时预览不仅仅是一种方便。这是错误预防。当经理以文本模式构建表单(如 CF7 中)时,他看不到结果。他在猜测。然后,他惊讶地发现“注释”字段出现在“名称”字段之前,或者复选框排列在列而不是行中,或者在移动设备上表单看起来像一张长纸。对于视觉设计师来说,这些错误是不可能的——你准确地看到了客户将看到的内容。而且它可以节省时间。我知道,因为我自己花了这些时间摆弄 CF7 模板并一遍又一遍地刷新浏览器中的页面。

现在让我们来谈谈是什么让表单真正强大 - 条件逻辑。提交油品选择申请表。第一个问题:“设备类型”-下拉列表:汽车、工业设备、液压、其他。如果客户选择“汽车”,则会出现“品牌”和“型号”字段。如果选择“工业设备”,则会出现“机构类型”和“操作条件”。如果“其他”是免费描述的文本字段。如果没有条件逻辑,您将必须一次显示所有字段,并且表单将变成一份两页的调查问卷,客户将不填写而逃跑。

在联系表单 7 中,这需要一个单独的条件字段插件,该插件通过 CSS 黑客和 JavaScript 处理程序工作,这通常与页面上的其他脚本发生冲突。我们将条件逻辑直接构建到构造函数中。在每个字段的设置中都有一个“显示条件”部分。您只需选择:“如果 [设备类型] 字段为 [车辆],则显示此字段。”或者“如果 [预算] 字段小于 10000,则隐藏此字段。”您可以使用“AND”或“OR”组合多个条件。其界面是一个可视化规则生成器,类似于我们在 CF 模块中用于自定义字段的界面。没有代码,没有文本公式。

条件逻辑通过 JavaScript 在客户端处理,它是根据 JSON 表单描述自动生成的。这意味着字段会立即出现和消失,无需重新加载页面,也无需 AJAX 请求。用户在列表中选择了一个选项,所需的字段就顺利出现了。我选择了另一个——以前的消失了,新的出现了。这创造了交互式界面而不是静态 HTML 表单的感觉。而且,重要的是,隐藏字段不参与验证 - 如果某个字段被条件隐藏,则即使将其标记为必填,也不会将其视为必填。这是许多实现失败的一个微妙点。

我记得在一个项目中,我们使用带有条件逻辑的 WPForms,并且遇到了一个错误:隐藏的必填字段阻止表单提交,因为即使该字段不可见,也会触发其验证。客户无法提交表格并离开。我们失去了应用程序,直到我们弄清楚并用 JavaScript 编写了一个拐杖。这是让您长期难忘的教训之一。因此,在我们的实现中,隐藏字段被排除在架构级别的验证之外 - 这不是错误修复,而是基本规则。

应用程序 - 不是邮件,而是数据库

现在我们讨论一个主题,在我看来,这是 Contact Form 7 和类似免费解决方案的主要弱点。应用程序去哪里?在 CF7 中,答案很简单 - 通过电子邮件。申请到了,我给经理发了一封电子邮件。点。没有电子邮件 - 没有申请。电子邮件服务器往往会丢失信件。垃圾邮件过滤器往往会阻止来自 WordPress 的通知,尤其是在服务器配置不完善的情况下 - 没有 SPF 记录、没有 DKIM、没有 DMARC。我个人就知道三个案例,其中一家企业因联系表格 7 的通知最终成为邮件服务器上的垃圾邮件而丢失了申请数周。直到客户开始打电话抱怨:“我提出了一个请求,为什么没有人回电话?”之前没人知道这件事。

Flamingo 解决了这个问题 - 它将门票存储在 WordPress 数据库中。但这是一个单独的插件,有自己的界面、自己的存储逻辑和自己的局限性。应用程序存储为自定义帖子 (post_type),这会在 wp_posts 表上创建负载,而该表在大型网站上已经臃肿。在我们拥有 16000 个产品的项目之一中,wp_postmeta 表重达 937 兆字节 - 从表单添加请求将是疯狂的。

我们走了不同的路线。所有应用程序都存储在自定义表 wpaic_form_entries 中。这是一个具有最佳结构的专用表:记录ID、表单ID、JSON格式的请求数据、创建日期、状态(新建、已读、进行中、关闭)、发送者IP地址、用户代理、用户ID(如果授权)。定制桌子不是心血来潮,而是有意识的建筑决策。它不会阻塞 wp_posts,具有用于快速搜索和过滤的正确索引,并且线性扩展 - 一万个提交的速度与十个一样快。

在管理界面中,请求显示在一个方便的表格中,能够按表单、状态、日期和全文搜索进行过滤。您可以找到包含“液压”一词的所有申请,或过去一周的所有申请,或特定表格的所有未读申请。您可以打开每个应用程序,以美观的格式查看所有数据,下载附件,更改状态并添加内部评论。

当然,还有导出。没有导出的表单就像没有报告的 CRM。没有用。我们支持通过字段选择、按日期和状态过滤导出到 CSV。我们上传了 CSV,在 Excel 或 Google Sheets 中打开它,并分析了哪些产品的需求更频繁、应用程序来自哪些地区、哪些表单转换得更好。这是当应用程序仅存在于邮件中时您丢失的数据。

还有一个很少被谈论的细微差别。当应用程序存储在数据库中时,您可以进行审核。您确切地知道已收到多少份申请。不是“大约”,也不是“通过邮件判断”,而是准确的。经理不能说“没有申请”——它会记录在系统中,包括日期、时间、IP 地址和所有数据。这对于 B2B 公司尤其重要,因为每个应用程序可能花费数十万卢布。由于垃圾邮件过滤器而丢失这样的应用程序不仅带来不便,而且是直接损失。

但说实话 - 电子邮件通知也是需要的。并非所有经理都会每小时登录 WordPress 管理员来检查新应用程序。因此,我们实现了双系统:申请始终保存在数据库中(这是保证),同时发送电子邮件通知(这是效率)。此外,电子邮件是通过内置 SMTP 模块 COS WP Woo 发送的,您可以在“电子邮件设置”部分中配置一次。没有单独的 SMTP 插件,没有 WP Mail SMTP,价格为 49 美元/年。一个 SMTP 模块可处理所有事务 - 订单通知、应用程序通知、安全通知。

电子邮件通知是可自定义的。对于每个表单,您定义:谁将通知发送给经理(可以有多个地址)、使用什么模板、要包含哪些数据。并单独向客户发出通知:“谢谢,您的申请已被接受,我们将在 24 小时内与您联系。”客户端通知将发送到“电子邮件”类型字段中指定的电子邮件 - 插件自动确定哪个字段包含收件人地址。电子邮件模板 - 带有占位符的 HTML:{{field_name}}、{{form_title}}、{{submission_date}}。您可以自定义外观、添加公司徽标和联系信息。我们没有编写通用模板引擎,而是针对特定任务编写的目标工具 - 因此它可以按预期工作,并且不会因非标准设计而中断。

我将告诉你另一个技术解决方案,它看起来可能是一件小事,但实际上它可以省心。上传文件。在带有文件上传插件的联系表单 7 中,文件作为附件附加到电子邮件中。直到有人发送您的电子邮件服务器不允许通过的 25 MB 文件时,此操作才会起作用。或者 50 MB - 那么 PHP 将因内存限制错误而崩溃。在我们这里,文件被上传到服务器上的受保护目录(公共访问之外,以便机器人不会下载客户端文档),并通过 ID 链接到应用程序记录。您将在电子邮件中收到下载链接,该链接仅适用于授权管理员。它更安全、更可靠并且不依赖于邮件服务器的限制。客户可以附上一张 50 兆字节的图纸 - 经理一定会收到它。

现在 - 简码。看来,这里有什么可讨论的呢? [wpaic_form id="42"] - 表单出现在页面上。但一如既往,问题在于细节。短代码可以插入帖子、页面、小部件、弹出插件、主题模板,甚至 WooCommerce 产品描述中。表单适应容器 - 如果容器较窄(侧边栏或弹出窗口),表单会切换到单列模式。如果宽(全屏页面),设置为半宽的字段将显示在两列中。这是开箱即用的响应行为。您不必担心 CSS 媒体查询——设计器会处理它。

你知道 CF7 的短代码方法总是让我恼火吗?在那里,短代码是插入它的唯一方法。没有古腾堡块,没有 Elementor 小部件。简码就是这样。 2026 年。我们还从一个短代码开始 - 这是在任何地方都适用的最通用的 WordPress 机制。但我们的短代码很聪明:它接受参数来自定义外观。您可以设置主题(浅色、深色、透明),可以隐藏表单标题,可以为提交按钮设置自定义文本。所有这一切都不需要一行 CSS - 通过短代码属性。

公平比较:us、WPForms、Gravity Forms 和 CF7

我承诺进行诚实的比较,所以让我们在没有营销点头的情况下进行比较。每个解决方案都有自己的优点,我不会假装我们的构建器是完美的。

联系表 7 - 免费、轻量级、经过时间考验。如果您需要一种没有条件逻辑且无需存储应用程序的简单表单,CF7 可以处理它。所有 WordPress 开发人员都知道这一点,已经为此编写了数千份指南。但是,一旦任务变得更加复杂“姓名-电子邮件-消息”,插件动物园就开始了。而这个动物园在支持和调试冲突方面的成本往往超过任何付费解决方案的成本。

WPForms 是一个很棒的插件,具有很棒的可视化编辑器。他们的拖放功能是市场上最好的之一。条件逻辑、应用程序存储、与 CRM 集成 - 一切都在那里。但 WPForms 是一个单独的插件,仅解决表单问题。它不知道您的 WooCommerce 目录,未与您的运输系统集成,并且不使用您的 SMTP 模块。他存在于自己的泡沫中。 Pro 版本每年的费用为 199 美元,这是条件逻辑和文件上传所需要的。 5年多了——光是表格就一千美元。

Gravity Forms 也许是 WordPress 最强大的表单生成器。多步骤表单、计算、与支付系统的集成、Webhooks、令人惊叹的插件生态系统。但这种能力是有代价的——无论是美元(Elite 许可证每年 259 美元)还是复杂性。重力形式可以做到这一切,但设置这一切需要时间和专业知识。对于简单的反馈表单,就像用大炮射麻雀一样。

我们在 COS WP Woo 中的表单生成器是中庸之道。它无意于在具有复杂计算或包含数百个问题的多步骤调查的场景中取代重力形式。但它百分百满足了 WooCommerce 商店的实际需求。反馈表、选择请求、CP 请求、满意度调查、B2B 注册调查问卷 - 所有这些都可以在可视化构造器中在几分钟内构建完成。此外,这些表格是单一平台的一部分。它们使用通用 SMTP,存储在优化的自定义表中,并通过与所有其他模块相同的界面进行管理。而且它们不需要额外花钱 - 它们包含在 COS WP Woo 许可证中。

让我给您举一个实践中的具体例子。客户是工业油经销商。他需要三种形态。第一个是产品页面上的“请求价格”:姓名、公司、电话、电子邮件、下拉列表“批量容量”(从 20 到 200 升、从 200 到 1000、从 1000 升)、评论。第二个是目录页面上的“类似物选择”:设备类型(附加字段的条件逻辑)、当前石油(文本)、所需特性(复选框)、文件上传(TOR 或设备护照)。三是“合作”页面“成为合作伙伴”:公司详细信息、TIN(长度验证)、地区、采购量、上传构成文件。

使用联系表 7,该项目将需要:CF7 + 条件字段 + Flamingo + 文件上传 + 样式 = 5 个插件和至少 3 小时的自定义(包括 CSS 编辑)。使用 WPForms Pro - 1 个插件,每年 199 美元,大约需要一个小时的设置。使用我们的构建器 - 0 个额外插件,0 个额外成本,并且在可视化构建器中大约需要 40 分钟。此外,所有三种表单都立即与 SMTP 集成,应用程序存储在具有搜索和导出功能的单个数据库中,经理可以在管理其他所有内容的同一界面中看到它们。

我想谈谈比较时经常忽略的一个方面。表现。 Contact Form 7 在网站的每个页面上加载其样式和脚本,即使页面上没有表单。这是一个已知问题,可以通过附加插件(Asset CleanUp、Perfmatters)或手动编辑代码来解决。 WPForms 仅加载表单页面上的资源,但其 JavaScript 包缩小后重量为 60-80 KB。我们的表单在服务器上以纯 HTML 形式呈现,并使用最少的 JavaScript 进行条件逻辑和验证。 CSS 表单 - 5 KB,JavaScript - 8 KB。它们仅加载到实际存在表单简码的页面上。对于拥有 16,000 个产品页面的商店来说,差异是显而易见的 - 每增加 KB 的 CSS 和 JS 都会乘以缓存中的数千个页面、浏览器中的解析时间和 Core Web Vitals。

我还想提一下安全性。表单是攻击者的入口点。通过输入字段进行 SQL 注入、通过文本字段进行 XSS、通过表单替换进行 CSRF 攻击、每分钟淹没数千个应用程序的垃圾邮件机器人。我们通过 WordPress 清理函数处理所有数据:HTML 字段的 sanitize_text_field()、sanitize_email()、wp_kses_post()。每个表单都受到随机数令牌的保护。上传的文件会通过 MIME 类型和扩展名进行检查 - 即使将 PHP 文件重命名为 .jpg,您也无法上传该文件。如果您在 COS WP Woo 中激活了安全模块,那么 WAF 还会检查所有传入数据是否存在 SQL 注入和 XSS 攻击模式。当表单和安全性是来自不同作者的不同插件时,这是不可能的集成。

关于技术设备,我想说的最后一件事。表单模块的架构与所有其他 COS WP Woo 模块遵循相同的模式:用于业务逻辑的 PHP 服务 (FormService)、用于 API 的 REST 控制器 (FormController)、用于界面的 React 页面 (FormBuilder)。该服务在 class-plugin.php 中注册,端点通过名称空间 wpaic/v1 工作,数据存储在自定义表中。如果您熟悉我们插件的架构,那么您已经知道表单是如何工作的。如果没有,表单是一个很好的切入点,因为它们以最纯粹的形式显示模式:从通过 REST API 的表单的 JSON 描述到在前端呈现。

当我们的构造函数不够时

我不想以“我们的解决方案是最好的”的营销说明来结束这篇文章。这不公平。在某些情况下,我们的表单生成器并不是最佳选择。

如果您需要包含数十个步骤的多步骤表单、进度条并保存中间结果,请查看重力表单。他们已经成熟可靠地实施了这一点。如果您需要与 HubSpot、Salesforce 或 AmoCRM 等开箱即用的 CRM 集成,WPForms 和 Gravity Forms 有现成的插件,但我们必须使用 Webhooks 或编写自定义集成。如果您需要直接在表单中集成 Stripe 或 PayPal 的付款表单,这不是我们的场景;为此,我们有一个带有支付模块的成熟的 WooCommerce 结帐。如果您正在构建包含 100 个问题且具有分支和评分功能的复杂调查问卷,则需要专门的工具,例如 Typeform 或 Google Forms。

但是,如果您是 WooCommerce 商店的所有者或管理员,并且您需要工作表单来进行反馈、票证、CP 请求、带条件逻辑的调查、文件上传和数据库存储 - 我们的表单生成器将比 CF7 + 插件的任何组合或 WPForms Pro 的年度订阅更快、更可靠且更便宜。

您知道对我来说最有说服力的证据是什么,证明我们走在正确的道路上吗?不是技术指标,不是字段类型的数量,不是与竞争对手的比较表。就在那一刻,一个客户项目的经理——一个一生都害怕“进入代码”的人——在二十分钟内整理了一份带有条件逻辑的申请表​​,通过短代码将其插入到三个页面上,第二天就出现了这样的问题:“我可以再制作一份调查表格吗?我已经大致了解了如何做。”这是工具质量的真实指标 - 当一个人不需要说明、不需要开发人员、并且不需要一个表单的五个插件时。

尝试 COS WP Woo,并在五分钟内构建您的第一个表单。表单模块位于商店 - 表单部分。拖放字段、设置条件、在页面上插入短代码 - 并开始接收保证到达经理的申请。