API de configurações versus personalizador de temas
20
Quando seria apropriado usar a API de configurações e quando seria melhor usar o personalizador de temas?
Tendo pesquisado no Google a manhã inteira, não consegui encontrar nenhuma orientação bem considerada e recente sobre esse assunto. Embora ainda seja cedo para dizer, sinto que o personalizador de temas é um primeiro passo sugestivo para trazer mais recursos de edição semelhantes ao Squarespace . Alguém sabe de algum plano para excluir a API de configurações em favor do personalizador de temas? Devemos todos avançar lentamente em direção a ela ou estaríamos melhor aderindo à API de configurações? Eles podem viver lado a lado e, em caso afirmativo, onde estaria a divisão de responsabilidades?
A premissa da pergunta é falha. A API do Customizer não é uma API de opções , mas uma API de visualização de opções . A API do Customizer conta com a API Settings ou a API Theme Mods para registrar controles para configurações existentes adicionadas por meio de uma das duas APIs.
O Customizer não define - e não pode - definir / registrar novas configurações que ainda não foram registradas pela API Settings ou pela API Theme Mods. Disse de uma maneira diferente: A API do Customizer não é uma API para adicionar configurações diretamente ou recuperar configurações diretamente do banco de dados; em vez disso, a API do Customizer usa a API Settings ou a API Theme Mods para salvar configurações ou recuperar configurações do banco de dados.
Portanto, a API do Customizer não é uma alternativa a uma das APIs de opções existentes ; é uma alternativa para uma página de configurações . O Customizer não se importa se uma configuração é registrada pela API Settings ou pela API Theme Mods, e essas configurações podem ser combinadas e correspondidas no Customzer. Na verdade, na maioria dos casos, essas configurações são misturadas e combinadas: cabeçalho personalizado e plano de fundo personalizado são Mods de tema e Título e Descrição do site são API de configurações.
Para entender exatamente como as configurações e os controles são registrados pela API do Customizer, recomendo a leitura dos excelentes tutoriais da Otto:
Obrigado Chip. Ainda não te 100% segui, mas você me deu o suficiente para analisar o problema um pouco mais. Acho que minha confusão decorre da sobreposição de funcionalidade e da semelhança nos nomes. Existe uma página que documenta claramente os casos de uso (de uma maneira mais abstrata) das diferentes APIs? Não tive muita sorte olhando o códice; ele se concentra apenas nas porcas e parafusos da aplicação da API.
Dre
Eu adicionei mais, para tentar explicar um pouco mais profundamente. Veja também, especialmente, os links para os tutoriais do Otto's Customizer; Eu acho que eles ajudarão a esclarecer as coisas.
Chip Bennett
Você senhor é um cavalheiro.
Dre
5
Por mais simples que seja, às vezes: A API de configurações não é o Personalizador de temas . Ambos são coisas diferentes para tarefas diferentes.
API de configurações
Você está escrevendo um plug-in ou tem um tema que não tem opções que não precisam de feedback visual? Vá com esta opção.
Personalizador de temas
Você precisa ter opções que tenham um impacto visual que o usuário possa ver? Vá com esta opção.
Esta foi a minha conclusão inicial. No entanto, há uma grande sobreposição funcional entre os dois, que é o que leva às perguntas originais. Além disso, a ideia de dividir as opções de tema em dois locais, dependendo de serem visuais ou não, me parece problemática do ponto de vista do UX. Isso não quer dizer que eu não concorde com você; Estou apenas solicitando opiniões nesta fase. Todo o tópico em si é um tanto obscuro. Talvez alguma orientação bem definida "do alto" seja benéfica. Obrigado pela sua contribuição!
Dre
@ Acho que você leu um pouco: se você tem uma única opção que precisa de feedback visual, vá com o ThemeCustomizer. Portanto, a regra geral é: Theme -> Theme Customizer | Plugin -> API de configurações.
Kaiser #
Como regra geral, todas as opções definidas pelo tema devem ter um impacto na apresentação . :) Dito isto: a API de personalização requer tanto a API de configuração ou o tema Mods API para existir. A API de personalização não é uma alternativa para uma dessas duas APIs, mas uma alternativa para uma página de configurações de tema personalizada .
Chip Bennett
Vocês têm algum problema de responsividade com o personalizador? Parece-me bastante temperamental em 3.5.1 e mais ainda em 3.6 (tronco). Acho que os botões de cabeçalho e fechar / salvar geralmente não respondem adequadamente aos cliques e às vezes precisam clicar neles várias vezes (e mais ainda no porta-malas). Isso ocorre no FF e no Chrome.
T31os #
@ t31os Teve este problema antes, mas sem consistência. Mas não tentei por algum tempo. Sugiro a console.log()todas as suas ações para que você veja o que é acionado e o que é interrompido. Depuração de JavaScript não é fácil ...
Por mais simples que seja, às vezes: A API de configurações não é o Personalizador de temas . Ambos são coisas diferentes para tarefas diferentes.
API de configurações
Você está escrevendo um plug-in ou tem um tema que não tem opções que não precisam de feedback visual? Vá com esta opção.
Personalizador de temas
Você precisa ter opções que tenham um impacto visual que o usuário possa ver? Vá com esta opção.
fonte
console.log()todas as suas ações para que você veja o que é acionado e o que é interrompido. Depuração de JavaScript não é fácil ...