不久前，一位开发者告诉我一件令我印象深刻的事。他说修复 Shopify Liquid 文件很麻烦，因为自定义修改无法随着主题更新而自动扩展。一旦你开始编辑主题，实际上就等于创建了一个分支，未来的每次更新都必须手动进行差异比较并重新应用。
他说得没错。维护自定义 Shopify 主题的实际工作方式确实如此。
这也是许多团队避免对正在使用的主题进行深度修改的原因，其中包括无障碍环境修复工作。
无障碍环境修复通常需要在 Liquid 模板中进行更改：添加语义化 HTML、修正标题层级、向辅助技术暴露标签，或修复地标结构。这些更改无法可靠地通过后续层叠的 CSS 或 JavaScript 来实现。
但“Shopify 就是这样工作的”往往成为对话的终点。我认为不应止步于此。创建分支并非 Shopify 的问题，而是流程问题。而流程问题自有流程上的解决方案。
解决更新问题归结为两个思路：隔离更改，使大多数更改永远不会与更新发生冲突；并为那些无法隔离的更改保持一份清晰、可搜索的记录，从而使手动差异比较的工作量保持小巧且可预测。
核心问题
关于 Shopify 主题的两个事实造成了这种痛苦：
- 自定义编辑不会随主题更新而保留。 当 Shopify 发布基础主题的新版本时，它不会合并你的更改。你会获得新版本，而协调你的自定义修改则需由你自行完成。
- 连接到 GitHub 的主题将不再接收 Shopify 的主题更新。 一旦主题连接到 GitHub，Shopify 内置的“有可用更新”工作流就不再适用于该主题。如果你希望获取上游主题更新，就需要自行将其纳入你的 Git 工作流中。
因此，你希望同时拥有两样东西：版本控制以及获取上游更新的能力。你必须二选一吗？不必。你可以故意将它们存放在不同的位置。这是核心理念，下文所述仅是其具体实施机制。
在开始任何修复工作之前的设置
这些基础工作能让后续的更新过程轻松无痛。请优先完成这一步。
将 CSS 和 JavaScript 隔离到自定义文件中
任何样式或脚本更改都应放入其各自的自定义资源文件中，而不是直接编辑主题的现有文件。这些更改几乎永远不会与更新发生冲突。由于这些是新增的资源而非对主题文件的修改，上游主题更新很少会触及它们，因此 Git 会将它们视为独立的添加项，而非冲突的编辑。唯一的例外是加载它们的那一行代码：用于排队加载这些自定义资源的 stylesheet_tag 或 script_tag 位于 Liquid 中，通常在 theme.liquid 文件里，因此这单一的连接点是可能与更新发生冲突的 Liquid 编辑。像其他 Liquid 更改一样，用你的 A11Y-REMEDIATION 标记对其进行标注。只要处理好这一行代码，在差异比较开始之前，你的大部分工作就已经从差异列表中排除了。
标记每一个 Liquid 更改并维护列表
Liquid 是你无法完全隔离的部分。有时你必须直接编辑某个区块或代码片段。对于每一次这样的编辑，都要留下清晰的注释以说明更改内容，并维护一份你所触及的所有 Liquid 文件的持续更新列表。
有一个优化措施将在后期带来回报。在这些注释中使用一致且可搜索的标记：
{% comment %} A11Y-REMEDIATION: 添加了 aria-la
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
分享到：
长按或扫码识别 分享给好友
![长按或扫码识别 分享给好友]()
