什么时候使用设置API,什么时候使用主题定制工具更好?有关此事的指导。虽然还为时过早,但我认为主题定制器是引入更多类似于Squarespace的编辑功能的暗示性第一步。有谁知道有计划退出设置API以便使用主题定制程序的计划吗?我们是否应该慢慢地朝着它前进,还是最好还是坚持使用设置API?他们可以并肩生活吗?如果可以,责任分工在哪里?

#1 楼

问题的前提是有缺陷的。 Customizer API不是选项API,而是选项预览API。 Customizer API依靠Settings API或Theme Mods API来注册通过这两个API中的任何一个添加的现有设置的控件。

定制器不能-也不能-定义/注册尚未通过Settings API或Theme Mods API注册的新设置。换句话说:Customizer API不是直接向数据库添加设置或直接从数据库检索设置的API。相反,Customizer API使用Settings API或Theme Mods API将设置保存到数据库或从中检索设置。

因此,Customizer API不能替代以下之一现有的选件API;相反,它是设置页面的替代方法。 Customizer不在乎设置是通过Settings API还是Theme Mods API注册的,此类设置可以在Customzer中进行混合和匹配。实际上,在大多数情况下,此类设置是混合使用的:自定义标头和自定义背景是主题模块,网站标题和说明是设置API。 Customizer API,我建议阅读Otto的出色教程:


如何在自己的主题中利用Theme Customizer
Theme Customizer Part Deux:摆脱选项页面
为主题自定义程序创建自定义控件

因此,问题不是针对指定的API,要么不是针对指定的API。适当的一个或一个问题是:


使用Settings API或Theme Mods API来注册现有设置,以通过Customizer API预览

使用Customizer API或自定义主题设置页面,以允许用户配置主题选项。


评论


谢谢Chip。我仍然不是100%跟着您,但是您给了我足够的力量去进一步研究这个问题。我认为我的困惑源于功能的重叠和名称的相似性。是否有页面清楚地记录(以更抽象的方式)不同API的用例?我浏览法典并没有多大运气。它只是着重于应用API的细节。

–Dre
13年5月2日在12:00

我添加了更多内容,以尝试更深入地解释。另请参见,特别是指向Otto的Customizer教程的链接。我认为它们将有助于澄清问题。

–芯片Bennett
13年5月2日,12:19

您先生是一位绅士。

–Dre
13年5月2日在13:06

#2 楼

有时可能会很简单:Settings API不是主题定制器。两者对于不同的任务来说是不同的。

设置API

您正在编写插件或主题没有不需要任何视觉效果的选项反馈?请使用此选项。

主题定制程序

您需要具有视觉效果的选项,用户应该能够看到?选择此选项。

评论


这是我的初步结论。但是,两者之间有很多功能重叠,这就是导致原始问题的原因。此外,从用户体验的角度来看,根据是否可见将主题选项分为两个位置的想法使我感到困扰。这并不是说我不同意你的看法;我只是在此阶段征求意见。整个主题本身有点模糊。也许“从头开始”的一些明确定义的指导将是有益的。感谢您的输入!

–Dre
13年5月1日在10:33

@Dre猜猜您误读了一点:如果您甚至只有一个需要视觉反馈的选项,请使用ThemeCustomizer。因此,经验法则是:主题->主题定制程序|插件->设置API。

– kaiser
13年5月1日在10:59

通常,所有主题定义的选项都应具有呈现效果。 :)也就是说:自定义API需要设置API或主题模块API才能存在。自定义API并不是这两个API之一的替代方案,而是自定义主题设置页面的替代方案。

–芯片Bennett
13年5月1日14:26

你们对定制器是否有任何回避问题?在3.5.1和3.6(trunk)中,这对我来说都显得很气质。我发现标题和关闭/保存按钮常常只是无法正确响应单击,有时不得不多次单击(在主干中更是如此)。这在FF和Chrome中都适用。

– t31os
2013年5月1日15:18



@ t31os以前有此问题,但没有保持一致。但是已经有一段时间没有尝试了。我建议使用console.log()进行所有操作,以便了解触发了什么和中断了什么。 JavaScript调试并不容易...

– kaiser
13年5月1日在15:48