平台 · Sana Commerce 定制

定制 Sana Commerce，又不影响下一次升级。

获得 Sana 认证的 ProjectThunder 在受支持的框架内定制 Sana Commerce Cloud 与 9.x：主题、add-on、SDK、前端脚本、自定义字段与集成。目标很简单。让它成为你的样子，同时保持可升级。

规划一次定制
可定制的内容

绝大多数关键之处，无需触碰核心代码。

Sana 通过受支持的扩展点，为你留出了真正塑造店面的空间。诀窍在于知道该用哪一个杠杆，让最终效果契合你的品牌与买家，同时平台在底层持续更新。整体了解我们在 Sana Commerce Cloud 上的构建方式。

主题与 UX

  • 自定义主题，构建于 Sana 的设计系统之上：布局、字体、配色与组件样式，与你的品牌相契合。
  • HTML、CSS 与 JavaScript 注入，通过 Sana Admin 实现店面各处的定向前端行为。
  • 内容与商品陈列，通过 CMS 管理：着陆页、导航与产品展示。
  • 响应式与无障碍，在 Web 与移动端测试，趋向 WCAG 2.1 AA。

add-on 与 SDK

  • 自定义 add-on，通过 Sana Commerce Cloud SDK 实现标准产品未提供的能力。
  • 使用有文档记录的扩展点，而非修改核心代码，让 add-on 始终保持在 Sana 的升级路径上。
  • 长期支持的 SDK 节奏，让 add-on 的发布按可预期的时间表落地。
  • 自定义结账步骤、店面逻辑，以及面向特定买家的工作流。

集成

  • 支付：通过受支持的 add-on 模式接入 Sana Pay 与第三方网关。
  • 税务：集成服务商（例如 Vertex 或 Avalara），无需在店面中重写税务逻辑。
  • 搜索：使用 Sana 内置搜索，或为深度 B2B 目录接入外部搜索。
  • PIM 与数据：连接器将丰富的产品内容输入店面。

自定义工作流与字段

  • 自定义字段，从 ERP 或 Sana 呈现到产品、账户与订单上。
  • B2B 订购模式：再次订购、审批、多地址、账户层级的细节。
  • 账户门户增强：文档附件、订单历史视图、信用状态可见性。
  • 配置优先，仅在配置确实无法覆盖之处才动用代码。
设计上即升级安全

为何待在框架之内如此重要。

Sana Commerce Cloud 大约每两周自动升级一次。这一节奏是一项优势，而非困扰，但前提是你的定制构建得当，能够顺势同行。受支持的定制与有风险的核心改动之间的界线，正是成败的关键所在。

受支持的定制

  • 主题、CMS 内容，以及通过 Sana Admin 进行的 HTML、CSS 与 JavaScript 注入。
  • 基于 SDK 以及有文档记录的扩展点与 API 构建的 add-on。
  • 使用配置与自定义字段，而非分叉的代码。
  • 结果：店面持续接收 Sana 的自动升级与修复。

有风险的核心改动

  • 编辑或分叉 Sana 核心代码，以强行实现框架未暴露的行为。
  • Sana 无法为你升级的定制，可能让项目脱离自动升级路径。
  • 与内部实现的隐性耦合，而后续的 Sana 版本可能在不另行通知的情况下加以更改。
  • 结果：每一次升级都变成一次手动且有风险的合并，而非悄然进行的后台更新。
我们的做法

我们的原则：配置优先，其次扩展点，几乎从不动核心。

01

把需求映射到一个杠杆。

在动手写代码之前，我们先判断配置、主题改动、注入，还是一个规范的 add-on 能否实现它。大多数事情都能在不触碰核心的情况下完成。

02

构建于有文档记录的 API 之上。

当确需编写代码时，我们使用 SDK 与 Sana 的扩展点，而非未来版本可能更改的内部细节。这能让工作始终保持在升级路径上。

03

坦诚说明取舍。

如果某个需求确实必须改动核心，我们会如实告知，说明随之而来的升级成本，并在任何人承诺维护一个分叉之前，先寻找受支持的替代方案。

我们的服务范围

一次定制合作都包含哪些。

自定义 Sana 主题与设计系统工作
HTML / CSS / JavaScript 注入与前端脚本
使用 Sana SDK 进行自定义 add-on 开发
支付、税务、搜索与 PIM 集成
从 ERP 与 Sana 将自定义字段呈现到产品、账户、订单上
B2B 工作流定制：再次订购、审批、层级
对现有定制的升级安全性审查
与你的 ERP 或 Sana 实施合作伙伴协同
上线后的长期合约与托管支持
常见问题

Sana Commerce 定制，逐一解答。

定制会在 Sana 升级时出问题吗？

只要构建方式得当，就不应出问题。Sana Commerce Cloud 大约每两周发布一次自动升级。通过受支持的扩展点完成的工作（主题，HTML、CSS 与 JavaScript 注入，配置，自定义字段，以及使用有文档记录的 API 的 add-on）会随这些升级一同前行。项目陷入麻烦的地方在于编辑 Sana 核心代码，Sana 无法替你升级它，还会让你脱离自动升级路径。我们把改动保持在框架之内，让平台能够在其底层持续更新。

你们能定制 Sana Commerce Cloud 与本地部署的 9.x 吗？

两者都能，不过方式有所不同。在 Sana Commerce Cloud 上，我们通过 SDK、add-on 框架、主题以及 Sana Admin 注入来开展工作，并倾向于使用扩展点，让店面始终处于自动升级中。本地部署的 Sana Commerce 9.x 允许更深入的代码级定制，但它是一种不同的生命周期：add-on 已不再针对 9.3 更新，因此我们将 9.x 的工作视为一个需要维护的稳定版本，而非持续升级的 SaaS。如果你正在使用 9.x 并在权衡是否迁移到 Cloud，我们会如实告诉你，你的定制能否顺利移植。如果你同时也在权衡其他选项，请参阅我们的平台对比。

你们能构建自定义 add-on 吗？

能。我们使用 Sana Commerce Cloud SDK 构建自定义 add-on，以实现标准产品未涵盖的能力：定制的支付或税务服务商、连接到 PIM 或搜索服务的连接器、自定义结账步骤，或者针对你买家下单方式的店面逻辑。我们基于有文档记录的扩展点与 API 进行构建，而非修补核心，按 Sana 的长期支持 SDK 节奏运行 add-on，并在其进入生产环境之前在 staging 上进行测试。

你们会与我们的 ERP 合作伙伴协同吗？

会，而且这种情况很常见。许多 Sana 项目都涉及一个独立的 ERP 或 Sana 实施合作伙伴，由其负责 SAP 或 Microsoft Dynamics 一侧。我们作为 Web、设计与开发团队加入其中：负责店面、主题、add-on 与前端集成，并在数据契约与字段映射方面与你的 ERP 合作伙伴协调。我们是一家获得 Sana 认证的 Web 与开发机构，而非 ERP 经销商，因此我们乐于分担工作，而不必独揽每一层。进一步了解如何与我们的 Sana Commerce 机构团队合作。

Sana Commerce 定制

已经有定制想法了吗？

告诉我们你需要店面实现什么。我们会告诉你，它该落在主题、注入、add-on，还是（极少数情况下）更深的层面，并会让它保持升级安全。

877.609.9029
开启一次对话