Gostaria de começar com esta pergunta: A funcionalidade está relacionada à apresentação de conteúdo, ou geração / gerenciamento do conteúdo ou do site, ou da identidade do usuário?
Se a funcionalidade não estiver relacionada especificamente à apresentação do conteúdo , ela estará diretamente no Território do Plugin. Esta lista é longa:
- Modificando os principais filtros do WP (
wp_head
content, como links canônicos, gerador e outro HTML meta, etc - Favicon do site
- códigos de acesso pós-conteúdo
- links de compartilhamento de postagem
- Scripts de rodapé do Google Analytics (e semelhantes)
- Ferramentas / controles de SEO
- etc.
Se a funcionalidade estiver relacionada à apresentação de conteúdo , então é um candidato para ser incluído no tema. Neste ponto, eu reverteria para o critério de troca de tema do Raf912 : você perderia a funcionalidade quando você troca de temas? Se a resposta a essa pergunta for no , a funcionalidade pertence ao tema. Alguns exemplos:
- Removendo / substituindo o CSS do Gallery do WP
- Filtrar a duração do trecho da postagem, "ler mais" texto, etc.
- Qualquer coisa implementada por meio de
add_theme_support()
(suponho que essa seja óbvia) - CSS personalizado
Normalmente, essas duas perguntas fornecerão uma linha bastante clara de diferenciação; no entanto, existem exceções.
Tipos de postagem personalizados
Tipos de postagens personalizadas, por exemplo, são um híbrido exclusivo de geração e apresentação de conteúdo, dada a maneira como a Hierarquia de modelos funciona para um único tipo de postagem páginas de índice de arquivo e páginas de postagem única . O aspecto de geração de conteúdo dos CPTs normalmente os colocaria diretamente no Território do Plugin; no entanto, Plugins não podem definir páginas de modelo que se encaixam inerentemente no design / layout / style para qualquer Tema (especialmente se o CPT for diferente do Título / Conteúdo / Meta usual, ou tiver taxonomias customizadas associadas a ele).
A longo prazo, a solução para esta disparidade, IMHO, é ter uma convenção / consenso padrão para a definição de CPTs para determinados tipos de conteúdo (listagens de imóveis, eventos de calendário, produtos de e-commerce, biblioteca de livros / mídia entradas, etc.). Dessa forma, o conteúdo gerado pelo usuário permaneceria portátil entre os Temas que implementam a definição padrão / convenção de um determinado CPT, enquanto os desenvolvedores de Tema mantêm a flexibilidade para definir o design / layout / estilo desse CPT nos arquivos de modelo do Tema.
Links de mídia social
Da mesma forma, eu normalmente diria que os links de perfil de mídia social, que se tornaram onipresentes nos Temas atuais, são Plugin Territory, porque não têm nada a ver com a apresentação do conteúdo. A melhor solução seria que esses perfis fossem definidos em algum lugar no núcleo; no entanto, não há atualmente nenhum meio padrão / consensual de definir esses links. Eles são mais bem definidos no nível de definição do site ou por usuário? Se por usuário, qual meta do usuário é exposta no modelo? etc.
Então, novamente, a longo prazo, a solução para essa disparidade é que qualquer um dos núcleos defina onde esses links estão definidos, ou então a comunidade de desenvolvedores do Tema deve desenvolver seu próprio consenso. Entretanto, não há realmente nada para isso, mas para mantê-los definidos dentro de cada tema.