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


86

Existe um esquema fácil de entender para decidir que tipo de código pertence a um plugin ou ao tema functions.php?

Não são muitos casos e muitos debates sobre o assunto, principalmente porque existem alguns equívocos sobre o funcionamento interno do WordPress. Estou pedindo uma resposta baseada em fatos, não em opiniões.

Deve explicar como lidar com esses pontos (e provavelmente mais):

  • tipos de postagens e taxonomias personalizadas
  • formulários de contato
  • códigos de acesso
  • widgets personalizados
  • add_theme_support( 'automatic-feed-links' );
  • Funções de SEO como metaelementos personalizados
  • mudança de tema

Muitas vezes existem prós e contras de ambos os lados. Nossa pergunta mais popular Melhor coleção de código para o seu arquivo functions.php tem muitos trechos de código como respostas que são pelo menos discutíveis.
Precisamos de critérios que um iniciante possa entender, talvez uma lista de verificação - com motivos.

Veja também a pergunta relacionada de Chip Bennett em nosso meta site: Perguntas que solicitam especificamente uma solução "sem um plug-in"

Relacionado: Onde coloco os trechos de código que encontrei aqui ou em outro lugar na Web?


Eu me pergunto o que constituiria fatos para o propósito desta pergunta. A pessoa A diz que o CPT entra no plugin, a pessoa B diz que o CPT entra no tema. Como podemos obter um fato para validar uma das opiniões? Isso pode ser perigosamente próximo de "não construtivo".
Rarst

Respostas:


72

Gostaria de começar com esta pergunta: a funcionalidade está relacionada à apresentação de conteúdo, ou à geração / gerenciamento de 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 plug-in. Esta lista é longa:

  • Modificação dos principais filtros WP ( wp_headconteúdo, como links canônicos, gerador e outras meta HTML, etc.)
  • Site Favicon
  • Códigos de acesso pós-conteúdo
  • Postar links de compartilhamento
  • Scripts de rodapé do Google Analytics (e similares)
  • Ferramentas / controles de SEO
  • etc.

Se a funcionalidade está relacionada à apresentação do conteúdo , então é um candidato para ser incluído no tema. Nesse ponto, eu voltaria ao critério de troca de tema do @ Raf912 : você perderia a funcionalidade ao trocar de tema ? Se a resposta para essa pergunta for não , a funcionalidade pertence ao Tema. Alguns exemplos:

  • Removendo / substituindo o CSS principal da Galeria do WP
  • Filtragem do tamanho do excerto da postagem, texto "leia mais" etc.
  • Qualquer coisa implementada via add_theme_support()(suponho que essa deva ser óbvia)
  • CSS customizado

Normalmente, essas duas perguntas fornecerão uma linha de diferenciação bastante clara; no entanto, há exceções.

Tipos de postagem personalizados

Os Tipos de postagem personalizados, por exemplo, são um híbrido único de geração e apresentação de conteúdo, dada a maneira como a Hierarquia de modelos funciona para páginas de índice de arquivamento e páginas de postagem únicas . O aspecto de geração de conteúdo dos CPTs normalmente os colocaria diretamente no território dos plug-ins; no entanto, os plug-ins não podem definir páginas de modelo que se encaixem inerentemente no design / layout / estilo de um determinado tema (especialmente se o CPT exibir outro que não seja o título / conteúdo / meta comum, ou tiver taxonomias personalizadas associadas a ele).

A longo prazo, a solução para essa 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 comércio eletrônico, entradas de livros / bibliotecas de mídia etc.) .). Dessa forma, o conteúdo gerado pelo usuário permanecerá portátil entre os Temas que implementam a definição padrão / convencional de um determinado CPT, enquanto os desenvolvedores do Tema mantêm a flexibilidade de 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 quase onipresentes nos Temas atuais, são Territórios de Plugins, porque não têm nada a ver com a apresentação de conteúdo. A melhor solução seria que esses perfis fossem definidos em algum ponto do núcleo; no entanto, atualmente não há meios padrão / consensuais para definir esses links. Eles são melhor definidos no nível de configuração do site ou por usuário? Se por usuário, a meta de qual usuário é exposta no modelo? etc.

Então, novamente, a longo prazo, a solução para essa disparidade é definir o local onde esses links são definidos ou a comunidade de desenvolvedores do Theme desenvolver seu próprio consenso. Enquanto isso, não há realmente nada a não ser mantê-los definidos em cada Tema.


add_theme_support( 'automatic-feed-links' );não é de apresentação. Mas é exigido pelas diretrizes do tema . Por que é um risco necessário perder essa funcionalidade após uma troca de tema?
fuxia

1
Tudo o que é implementado via add_theme_support()só pode ser implementado através do Tema. O uso add_theme_support( 'automatic-feed-links' )no Tema realmente garante uma experiência consistente de Tema para Tema, pois os links de feed gerados serão os mesmos.
Chip Bennett

4
Eu acho que está com o nome errado: os links de feed não são de apresentação. Se o próximo tema não chamar essa função, o usuário perderá os links do feed. E você pode adicioná-lo por plug-in sem nenhum problema. É por isso que estou confuso. :)
fuxia

1
Você sabe: esse é um bom ponto. :)
Chip Bennett

50

Um teste fácil onde o código está melhor colocado:

  • escreva o código no functions.php
  • mudar de tema
  • você sente falta da funcionalidade, o blog não está funcionando adequadamente ou os fragmentos do tema antigo (por exemplo, códigos de acesso) são deixados?

    • sim: coloque-o em um plugin

    • no: deixe em functions.php

Exemplos: escreva um código curto. Depois de mudar o tema, os códigos de acesso simples são deixados em suas postagens. 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.

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


11
+1 Se o código for específico para o tema, coloque-o functions.php. Se precisar aplicar a mais de um tema, coloque-o em um plugin.
s_ha_dum

18

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 um fluxograma, que pode e deve ser expandido. Comente com sugestões!

  • Esse código deve ser hospedado em uma instalação de site único do WordPress?
    • Sim - o tema do site muda apenas com grandes reformulações e alterações na funcionalidade?
      • Sim - o código em questão é específico para este design atual ?
        • Sim: functions.php
        • Não: Plugin
      • Não (muda frequentemente ou por capricho) - Plugin
    • Não (Multsisite) - Você está hospedando a instalação multisite OU é uma solução multisite hospedada que permite plugins?
      • Sim: a funcionalidade em questão é específica para este site ou pode / deve ser usada por outros sites na rede?
        • Específico para este site: functions.php
        • Compartilhado entre vários sites - Deseja forçá-lo em todos os sites?
          • Sim: plug-in, armazenado no diretório mu-plugins ou ativado por rede
          • Não: essa é uma rede de sites não relacionados ? (por exemplo, clientes diferentes)
            • Sim: seria ruim ou pouco 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 interrompa o site ou cause funcionalidade indesejável)
              • Sim: functions.php
              • Não: Plugin
            • Não: provavelmente plugin
      • Não (hospedado por um serviço como VIP que não permite plugins): use functions.php
Alguns outros pensamentos que eu não sabia como me encaixar aqui:

  • Temas pai - às vezes com funcionalidade compartilhada, seria melhor criar um tema pai e colocar a funcionalidade no arquivo functions.php do tema pai.
  • Diretórios de plugins 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 nos arquivos functions.php.

6

A partir daqui Temas VS Plugins

Adicione código personalizado a um tema filho para que, quando você atualize o tema pai, seu código personalizado não seja perdido.

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

No que diz respeito à escrita de código versus plug-ins, você pode usar plug-ins e funções no entanto, para a maior parte do que deseja, a codificação manual é a melhor e mais fácil de modificar, exceto em alguns casos, como caixas de meta, nas quais você pode considerar usar um plug-in, a menos que é 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');

http://codex.wordpress.org/Plugin_API/Filter_Reference/user_contactmethods

  1. Adicionar novo tipo de postagem personalizada - Código
  2. Adicionar novos campos aos usuários - código acima
  3. Adicionar novos widgets - Código
  4. Adicionar links permanentes personalizados - WordPress Permalink Settings

5

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

Se você faz uma programação viva e se vê trabalhando em sites wordpress dentro de prazos, vai descobrir que realmente se resume ao tempo.

Na maioria das vezes, especialmente para aqueles que estão começando, é muito mais rápido e simples adicionar o que você precisa a um tema e chamá-lo de pronto.

Dito isto, se você trabalha no wordpress de forma semi-regular, deve considerar seriamente o seguinte :


  1. Construa um esqueleto de plug-in

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

Se você reservar um tempo para fazer isso, encontrará:

  • Não é preciso 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 ao público se quiser visibilidade extra

Agora você pode criar as coisas corretamente e realizar projetos futuros mais rapidamente.


  1. Construa um esqueleto de tema

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

  • Uma folha de estilo principal contendo os estilos que você usa normalmente (redefinições etc.)
  • Um arquivo index.php adequado, manipulando tudo o que você precisa para qualquer modelo
  • Um arquivo functions.php - você não o utilizará 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, referenciando seu tema principal.
  • Adicione o arquivo functions.php

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


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

  • Passe o seu novo tempo livre se familiarizando com PHP, WordPress, JavaScript, CSS e / ou mySQL ... quanto mais você aprender sobre isso, mais rápido você realizará as tarefas.
  • Atualize seus plug-ins, temas e esqueletos de temas filhos à medida que você encontra coisas que 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 , verá que a resposta de Chip não será apenas ideal, mas também ideal.


3

A resposta simples é essa ..

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

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

Se a resposta for não para as duas opções acima, imagine o site daqui a cinco anos, quando for a hora de um novo design. A função do código que você 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 filhos e planeja atualizar o tema, sugiro que você use um plug-in.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.