Onde colocar meu código: plugin ou functions.php?

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.

Um teste fácil em que o código está melhor posicionado:

• escreve o código no functions.php
• alternar tema

• você sente falta da funcionalidade, o blog não funciona corretamente ou fragmentos do tema antigo (por exemplo, códigos de acesso) são deixados?

  • sim: coloque-o em um plug-in

  • não: deixe em functions.php

Exemplos: Escreva um shortcode. Depois de mudar o tema, os códigos de acesso simples são deixados nos seus posts. Por isso, será melhor colocado em um plugin.

Escreva uma função para listar os últimos comentários. Depois de mudar o tema, tudo está bem porque talvez o outro tema tenha uma função equivalente.

Isso realmente depende do código e do que ele fará. Alguns códigos influenciam apenas o estilo ou o conteúdo do tema, outros modificam as postagens do blog.

Eu não acho que haja uma resposta fácil para essa pergunta, mas aposto que poderíamos fazer um fluxograma para ajudar na decisão. Aqui está um esboço de tal fluxograma, que pode e deve ser expandido. Comente com sugestões!

• Este código está hospedado em uma instalação de site único do WordPress?
  • Sim - O tema do site só muda com grandes redesigns e mudanças na funcionalidade?
    • Sim - O código em questão é específico deste design atual ?
      • Sim: funções.php
      • Não: Plugin
    • Não (muda frequentemente ou por um capricho) - Plugin
  • Não (Multisite) - Você hospeda a instalação multisite OU é uma solução multisite hospedada que permite plugins?
    • Sim: A funcionalidade em questão específica deste site , ou pode / deve ser usada por outros sites na rede?
      • Específico para este site: functions.php
      • Compartilhado entre vários sites - você quer forçá-lo em todos os sites?
        • Sim: Plugin, armazenado no diretório mu-plugins ou ativado pela rede
        • Não: esta é uma rede de sites não relacionados ? (por exemplo, clientes diferentes)
          • Sim: seria ruim ou não profissional se o cliente A visse ou ativasse o plug-in que você escreveu para os clientes B, C e D? (por exemplo, talvez isso quebre o site ou cause funcionalidade indesejável)
            • Sim: funções.php
            • Não: Plugin
          • Não: provavelmente plugin
    • Não (hospedado por um serviço como o VIP que não permite plugins): use functions.php

• Temas principais - às vezes com funcionalidade compartilhada, seria melhor criar um tema pai e colocar a funcionalidade no arquivo functions.php do tema pai.
• Os diretórios de plug-in de grandes instalações multisite podem rapidamente se tornar indisciplinados, portanto, às vezes, a funcionalidade compartilhada usada por uma baixa porcentagem de sites (por exemplo, < 1%) seria melhor duplicar em arquivos functions.php.

A partir daqui Temas VS Plugins

Adicione um código personalizado a um tema filho. Assim, quando você atualizar o tema pai, seu código personalizado não será perdido.

Você também pode criar um plug-in específico do site que também contenha todo o seu código personalizado.

No que diz respeito a escrever código versus plugins, você pode usar plugins e funções no entanto, para a maioria do que você quer, a codificação manual é a mais fácil de modificar, exceto em alguns casos, como caixas meta onde você pode usar plugin, a menos que você seja um desenvolvedor de temas.

 function modify_contact_methods($profile_fields) {

// Add new fields
$profile_fields['twitter'] = 'Twitter Username';
$profile_fields['facebook'] = 'Facebook URL';
$profile_fields['gplus'] = 'Google+ URL';

return $profile_fields;
}
add_filter('user_contactmethods', 'modify_contact_methods');

enlace

1. Adicionar novo tipo de postagem personalizado - Código
2. Adicionar novos campos aos usuários - código acima
3. Adicionar novos widgets - Código
4. Adicione permalinks personalizados - Configurações do link permanente do WordPress

Eu sei que este é um cavalo morto e que Chip o cobriu, mas queria acrescentar alguns pensamentos.

Se você fizer uma programação viva e se encontrar trabalhando em sites wordpress em prazos, você descobrirá que isso realmente se resume ao tempo.

Mais frequentemente do que não, especialmente para aqueles que estão começando, é muito mais rápido e simples adicionar o que você precisa em um tema e chamá-lo.

Dito isto, se você trabalha no wordpress em uma base semi-regular, você deve considerar seriamente fazer o seguinte :

1. Crie um esqueleto de plug-in

Isso deve lidar com tudo o que você normalmente precisa fazer com um plug-in, incluindo ativação, desativação, atualização de versão, criação de painéis de administrador e desinstalação.

Se você tiver tempo para fazer isso, você encontrará:

• Já não é necessário muito tempo extra para adicionar funcionalidades através de plugins
• Você pode começar a criar uma lista sólida de plug-ins para reutilizar em outros projetos, conforme necessário, economizando muito tempo a longo prazo.
• Você pode disponibilizá-los publicamente se quiser mais visibilidade

Agora, você pode criar as coisas de maneira adequada e para fazer projetos futuros com mais rapidez.

2. Crie um esqueleto de tema

Isso deve lidar com tudo o que é comumente necessário em um tema:

• Uma folha de estilo principal contendo estilos que você usa normalmente (redefine, etc.)
• Um arquivo index.php adequado, manipulando tudo o que você precisa para qualquer modelo
• Um arquivo functions.php - você não o usará quase tanto, mas ainda será útil.

Depois de fazer isso, crie um esqueleto de tema filho que use seu tema principal.

• Adicione a folha de estilo, fazendo referência ao seu tema pai.
• Adicione o arquivo functions.php

Depois de concluir essas duas etapas, a criação de novos sites para as pessoas se torna muito mais rápida.

Se você fizer o acima, poderá trabalhar com o seguinte:

• Gaste seu novo tempo livre e fique mais familiarizado com PHP, WordPress, JavaScript, CSS e / ou mySQL ... quanto mais você aprender sobre isso, mais rápido você fará as coisas.
• Atualize seus esqueletos de plug-ins, temas e temas infantis enquanto descobre coisas que você deve melhorar. Não importa o quão bom você seja, se continuar aprendendo, encontrará melhorias a serem feitas.

E, se você fizer todas as opções acima , você descobrirá que a resposta de Chip não será apenas ideal, ela se tornará ideal.

A resposta simples é esta ...

O código depende de alguma funcionalidade incorporada em um tema específico? Se sim, coloque um tema.

Você quer que esse código seja transferível entre sites e entre temas? Se sim, coloque um plugin.

Se a resposta for não aos dois acima, imagine o site daqui a 5 anos, quando chegar a hora de um novo design. A função do código está escrevendo algo que sobreviverá à próxima atualização de design? Se sim, coloque um plugin.

Além disso, se você não estiver usando temas filho e planeja atualizar o tema, sugiro também que use um plug-in.