Como muitos de vocês sabem, na semana passada Syed Balkhi participou do WordCamp Raleigh 2012. Durante o evento, um de seus tweets gerou um grande debate. Neste artigo, nosso fundador Syed Balkhi debaterá se os Tipos de Postagem Personalizados do WordPress pertencem ao arquivo functions.php ou a plugins. Abaixo está um tweet que iniciou este debate:
Não adicione Tipos de Postagem Personalizados em functions.php -> Você deve SEMPRE usar um plugin específico do site – http://t.co/bebYXq2F #wcraleigh
— WordPress Beginner (@wpbeginner) 4 de novembro de 2012
Após o tweet, muitas pessoas respeitáveis na comunidade WordPress se manifestaram. Você pode ver a conversa completa aqui. Curtis McHale foi um passo além e elaborou sobre o tópico em seu novo post no blog.
A conversa do Twitter levantou alguns pontos importantes.
Resumo dos Argumentos
Argumento dos Plugins: O usuário sempre terá os dados, mesmo que mude o tema. Pode não parecer tão bonito, mas permanecerá lá.
Argumento do Functions.php: Dados sem design seriam irrelevantes. Confundiria ainda mais os usuários.
Com qual lado você concorda mais? Claramente ambos os lados têm seus problemas, mas qual é o menor dos dois males?
Eis o motivo pelo qual acreditamos que os Tipos de Postagem Personalizados devem SEMPRE residir em um plugin específico do site ou em um plugin separado.
Vida Longa aos Dados
Tipos de Postagem Personalizados são dados. Na maioria dos casos, seus dados sobreviverão ao design atual. Tendo mudado nossos temas algumas vezes, entendemos essa afirmação claramente. Posts, Páginas, Links, Anexos e Revisões são todos tipos de postagem que vêm integrados ao WordPress. Além disso, temos tipos de postagem como Livros, Depoimentos, Ofertas, etc. Agora, você consegue imaginar se mudarmos um tema e tudo isso desaparecer? Certamente, não gostaríamos que isso acontecesse.
Tendo desenvolvedores em nossa equipe, isso não deveria importar muito. Considerando que todos os nossos temas são projetados sob medida por nossa equipe, qual a diferença que isso realmente faz? O segredo está em duas palavras: tempo e centralização. Contanto que tenhamos todos os dados necessários, tudo o que teremos que fazer no futuro é mudar o estilo. Não teremos que nos preocupar em copiar e colar as funções de um arquivo para outro a cada vez. E se você quiser replicar a funcionalidade? Simplesmente pegue o plugin e o coloque em seu novo site. Mude o estilo e pronto.
Regras e Padrões
Quando você usa a palavra SEMPRE, como fizemos em nosso tweet, pode significar tanto regra quanto padrões. Tanto regras quanto padrões são feitos para a maioria. Sempre haverá cenários de casos especiais onde as regras são flexibilizadas e os padrões são quebrados, mas isso não significa que devemos nos livrar dos padrões completamente.
Existem muitos tipos de postagem genéricos que geralmente exigem o mesmo conjunto de campos de metadados adicionais. Alguns exemplos que vêm à mente seriam: Citações, Livros, Receitas, Depoimentos, Portfólio, etc.
Considerando o grande número de temas de fotografia e portfólio que estão disponíveis no mercado gratuito e comercial, não faz quase nenhum sentido fazer com que o usuário insira novamente todas as informações de seu tipo de post personalizado toda vez que ele muda de tema. Vamos dar uma olhada em um cenário de exemplo:
Fotógrafo – O usuário configurou um WordPress que possui funcionalidade de blog (CPT padrão “post”). Ele quer adicionar um portfólio de seu trabalho (requer um CPT de Portfólio). Ele quer mostrar depoimentos de clientes (requer um CPT de Depoimento). Todas essas informações certamente viverão além do design de um tema. Um ano depois, o usuário quer mudar a aparência de seu site e dar uma renovada. Encontra um novo tema que tem todas as funções semelhantes. No momento em que ele troca o tema, BOOM. Todos os dados anteriores que ele inseriu desapareceram. Há um menu chamado Portfólio e um menu chamado Depoimentos, mas nenhum dos dados está lá. O usuário pensa “SANTO DEUS, perdi todo o meu conteúdo”. Cria novas perguntas de suporte no fórum. Envia e-mails para sites como WPBeginner, etc. Se não receberem uma boa resposta, terão que reinserir todos os dados. Essa é uma péssima experiência para o usuário.
Então, como resolvemos esse problema?
Solução Possível?
Criamos uma nova base padrão. Justin Tadlock já começou a trabalhar nesse problema há um tempo, criando um plugin de portfólio base. Será a solução perfeita para todos? NÃO, mas será para a maioria.
Como Justin pergunta em seu post, quais campos padrão devem ser incluídos no plugin de portfólio (referindo-se a meta de postagem). Esse tipo de conversa precisa acontecer entre desenvolvedores que estão criando funcionalidades semelhantes em seus temas. Por que copiar e colar a mesma coisa repetidamente de um tema para outro quando isso pode ser feito através de um plugin? Assim que se tornar um padrão, outros autores de temas começarão a se adaptar a ele.
Por exemplo, estamos vendo um aumento no suporte de estilo para Gravity Forms em frameworks de temas WordPress como Genesis e outros. Por quê? Porque eles entendem que seus usuários estão usando.
Existem alguns temas robustos para WordPress que vêm carregados com funcionalidades que acreditamos que deveriam ser plugins. Temas de Quadro de Empregos, temas de Rastreamento de Problemas, temas de Anúncios Classificados, temas Imobiliários, etc. Todos eles deveriam ser alimentados por um plugin base. Isso já está acontecendo com o WooCommerce. A WooThemes lançou inúmeros temas que têm suporte de estilo integrado para o plugin. Outras empresas de temas prometeram lançar temas de e-commerce baseados no WooCommerce também. Você pode mudar de um tema para outro e manter todos os seus produtos como estão. É quase como se o tema tivesse mudado, mas tudo se encaixou perfeitamente. Essa é a experiência de mudança de tema pela qual precisamos nos esforçar.
Por que não fazer a mesma coisa com Portfólio, Depoimentos e outros tipos de postagem personalizados genéricos? É porque é muito simples em comparação com o e-commerce, que é uma fera maior para conquistar? Claramente, o e-commerce tem muito mais campos em comparação com os outros, então deveria ser muito mais fácil para esses tipos de postagem genéricos. É apenas uma questão de fazer um esforço consciente para tornar as coisas melhores.
Dê uma olhada no plugin ReciPress. Ele cria uma caixa de metadados personalizada com campos de receita e a anexa a posts. No entanto, é possível anexá-la a tipos de postagem personalizados. Qualquer pessoa que use este plugin pode mudar de tema sem ter que passar por tanto transtorno.
Seria bom ver temas como o AgentPress serem alimentados por um plugin base centralizado. Seria ótimo ver a transição de mudança de temas se tornar mais fácil. Por exemplo, se um usuário mudar de um tema de fotografia para outro, não deveria ser um caos. Pequenos erros podem acontecer, mas pelo menos no quadro geral, as coisas funcionarão.
Você sempre pode dar exemplos de tipos de postagem super personalizados criados para uso de clientes de uma única vez, mas essa é a exceção, não a regra.
O que vocês acham sobre este tópico? Onde o código dos tipos de postagem personalizados deve residir? No arquivo functions.php ou em plugins?
Yazmin
Tendo perdido meus CPTs inúmeras vezes ao trocar de temas, acho frustrante ter que configurar a mesma funcionalidade repetidamente no functions.php.
Eu prefiro completamente a rota do plugin e esse é o método que usarei daqui para frente para meus projetos de negócios também.
Joshua Jarvis
Tendo exatamente este problema com um tema de imóveis. As “listagens” eram todos tipos personalizados em um tema que agora está funcionalmente obsoleto. Quando fui atualizar o tema, perdi todo o conteúdo de postagem personalizada, agora tenho que descobrir uma maneira de transferir tudo. Tenho opções, mas se fosse um plugin, isso não seria necessário.
Equipe Editorial
Extremamente desculpe pelo seu inconveniente. É por isso que escrevemos este post, pois sabemos que isso realmente torna a vida do usuário final mais difícil.
Admin
Hugh H. Sands
“Não teremos que nos preocupar em copiar e colar as funções de um arquivo para outro toda vez.”
Não consigo imaginar alguém escrevendo código para um CPT em functions.php quando é tão fácil isolá-lo com includes
Este debate gira na maioria das vezes em torno de dados vs design e eu me pergunto, sendo bem novo no WP, e o desempenho? Plugins impõem alguma sobrecarga?
Equipe Editorial
Este artigo deve responder à sua pergunta sobre plugins e desempenho:
https://www.wpbeginner.com/opinion/how-many-wordpress-plugins-should-you-install-on-your-site/
Admin
Hugh Sands
Obrigado pelo link, muito útil!
Kelvin Alfonso
Eu sempre incluí CPTs através de um arquivo separado em functions.php, mas acho que vou mudar para a rota de plugins. Obrigado!
Sudhakar
Sou iniciante e não tenho experiência para comentar a favor ou contra um plugin ou functions.php. Mas estou me perguntando se eu quiser seguir a rota do functions.php e fazer isso em um tema filho, qual é o problema então? Por que preciso tê-lo em um plugin, meu tema filho não me salvaria de futuras atualizações e mudanças de tema?
Equipe Editorial
Seu tema filho o salvaria de futuras atualizações de tema. No entanto, ele NÃO o salvará se você mudar de tema. Porque você muda o tema filho se mudar o tema ativo.
Admin
Pat Ramsey
Sou um defensor da rota de plugins para tipos de postagem personalizados e taxonomias. A menção do autor sobre um plugin específico do site é como eu faço. Coloco quaisquer tipos de postagem personalizados, taxonomias personalizadas e metaboxes neste plugin, adaptado ao propósito do site. Eventualmente, o tema do site mudará, mas os dados permanecem e ainda são facilmente acessíveis.
shawn
Se os desenvolvedores continuarem a ignorar o fato de que separar "dados" de "design" é necessário para criar aplicativos modulares, e não importa onde os dados sejam colocados, reutilizar esses dados / código sempre será um problema.
Parece haver uma percepção por parte de alguns na comunidade WP, por uma razão ou outra, de que você só pode acessar dados no ecossistema WordPress se eles estiverem encapsulados em um plugin, então continuamos vendo discussões como esta contribuindo para “O grande debate plugin vs tema”.
O foco precisa ser colocado na evolução do sistema arcaico de plugins do WordPress, para a criação de bibliotecas baseadas em padrões de design modulares que separam código / dados do design. Bibliotecas que podem ser usadas tanto em temas quanto em plugins…
Debates como estes são inúteis na era pós-PHP4 do WP!!! (re-post)
Mark Simchock
Re: “Como Justin pergunta em seu post, quais campos padrão devem ser incluídos no plugin de portfólio (referindo-se a metadados de postagem). Esse tipo de conversa precisa acontecer entre desenvolvedores que estão criando funcionalidades semelhantes em seus temas.”
Eu? Eu prefiro um plugin bem documentado e projetado para ser aprimorado do que uma abordagem “fechada”, que serve para todos e é difícil de trabalhar (esse código).
Meu ponto é, talvez seja possível dizer: “Não estou tentando ser tudo para todos. Aqui está meu plugin básico. Veja como você o personaliza. Ele foi projetado para ser personalizado.” e simplesmente deixar por isso mesmo. Não importa o que você faça, é difícil antecipar todos os casos de uso, todas as necessidades de uso. Então, por que se preocupar? Por que não abordá-lo como um framework (de certa forma) e deixar o desenvolvedor que precisa apenas personalizar conforme necessário?
Justin Tadlock
Esse é realmente o plano. Estou construindo uma base extremamente pequena e facilmente personalizável. Mas, eu gostaria de saber quais campos, se houver, devem ser padrão.
Kevin Maines
Erro de digitação?:
“Considerando que todas as nossas equipes são projetadas sob medida por nossa equipe”
Equipe Editorial
Fixed it. Thanks for catching that
Admin
Affan Ruslan
Eu acredito que deveria estar em um plugin.
Caso o usuário não precise dos dados no futuro, ele sempre pode converter o post do tipo de post personalizado para o tipo de post "normal". Existe um plugin para isso, pesquise no repositório e você encontrará pelo menos um.
Christophe Debruel
Eu realmente não me importo com o que as pessoas dizem. O tipo de post personalizado vai para um plugin. Um tema pode ser facilmente modificado para se adequar ao tipo de post personalizado no frontend. Acho mais lógico estilizar o tema para o CTP do que ter temas diferentes com o mesmo código CTP.
Ingo
"Pods Framework" também poderia ser uma boa solução de plugin. Para CPT, CT e CF.
http://wordpress.org/extend/plugins/pods/
Equipe Editorial
Sim, pods é incrível.
Admin
Elliott Richmond
Plugin para mim. Pelo menos para um cliente não técnico, embora o tema possa não funcionar corretamente, ficará aparente que há um problema e isso os levará a contratar um desenvolvedor.
Kailas Mahajan
Tudo depende do projeto...
Se um projeto estiver lidando com a necessidade de mudar de tema após um certo período de tempo... pode usar um plugin.
Ou se um projeto que se mantém com o mesmo tema.. pode ir com function.php
Ross W
Todos estão falando sobre como os dados precisam ser estilizados pelo tema, e exemplos onde é o caso e onde os dados e o tema podem ser separados.
O que eu não vejo é alguém falando sobre casos em que um tema depende de ter alguns dados específicos disponíveis. Vamos dizer que você tem um tema que tem um mapa de países e alguns dados específicos de países, e que, sem esse mapa e dados, o tema perde parte de sua funcionalidade principal.
Sim, você ainda poderia fazer isso com os dados em um plugin, mas é razoável que um tema assuma que alguns dados existem? É razoável assumir que o plugin que cria os tipos de dados está instalado e ativado? (Perguntas genuínas… vamos discutir!)
E se meu cliente, um pouco não técnico, quiser criar uma cópia do site com o 'tema' dele? Ele ativa o tema em uma nova instalação do WordPress apenas para descobrir que um monte de coisas está faltando ou quebrado? Ele pensou que o tema continha tudo o que ele precisava para que o site dele ficasse com a aparência correta?
Eu consigo ver utilidades para ambas as abordagens. Para a maior parte do meu trabalho com clientes, eu configuro CPTs, meta-boxes e algumas funções para facilitar o acesso a eles, em arquivos de biblioteca e os incluo. Isso mantém todo o 'material' que meu tema precisa para funcionar em um único pacote, mas mantém a simplicidade para mover os CPTs para um novo tema, caso eu queira.
Claro, se um CPT parecer que pode ser usado em vários temas e não for TÃO específico que se aplique apenas aos dados de um único cliente, então você o transforma em um plugin que pode ser implantado à vontade.
Eu não acho que exista uma relação simples e unidirecional entre dados e temas. Nem sempre é o caso de 'eu tenho alguns dados que precisam de estilo'... às vezes 'meu estilo precisa de alguns dados'.
Pensamentos sobre isso?
Andres Hermosilla
Eu concordo totalmente que há um benefício em ter um pacote "completo". Muitas vezes, há funcionalidades muito específicas de um tema que são melhores quando integradas diretamente (ou seja, P2 da Auttomatic) em vez de um tema instalado e um plugin de tema.
Konstantin Kovshenin
Plugins. Ponto final.
Curtis McHale
Sua referência ao AgentPress é um dos motivos pelos quais sou 100% a favor de CPTs em plugins. Tive que lidar com temas assim e é muito difícil personalizá-los corretamente, a menos que você remova a função personalizada do tema. Meu cliente e eu passamos 20 horas para que o código chegasse a um ponto em que pudéssemos realmente trabalhar nele.
Birgit
Minha melhor e favorita solução recomendada é o altamente flexível TOOLBOX: http://wordpress.org/extend/plugins/toolbox/
Equipe Editorial
Ideia legal. Gostaria de poder entender o que a captura de tela estava mostrando sem baixar o plugin.
-Syed
Admin
Birgit
The plugin is a “toolbox” for code snippets, that you do normally in your functions.php.
But with a theme update, custom code in the theme’s function.php might get lost.
So I use within my network installation this plugin, activated it network-wide and then the plugin comes with “modules”, that you can access for example by FTP.
You can create modules as much as you like – I have one for each of my blogs within this network. In this modules (= just .php files, let’s say just like site-specific plugins) you can add all the code, that you normally put in your theme’s function.php.
Then at the options page of the plugin you can activate in each blog, which module you would like to load and whether to load it only for frontend or only for backend or for both.
So I only need to have 1 plugin to serve all blogs with individual code snippets, that normally go to their functions.php – and can decide, where to load these modules.
uff, hope this is understandable, because my English is not the best
Talvez isso ajude você a ler: http://tinyurl.com/bf5dflt
Equipe Editorial
Brigit, I did translate the WP.org page as well. I understood what the plugin was intended for. However the screenshots were in German, and google is not smart enough to translate images just yet. Same issue is with the link you posted
Sara
Eu sempre prefiro plugins ao functions.php para qualquer coisa que possa materialmente "quebrar" no front-end ou perder dados se o tema for alterado. Isso é precisamente pelos motivos que você cita, e também sinto que é INSANO para aqueles de nós que não são realmente programadores PHP tentar solucionar conflitos quando você tem que comentar coisas no functions.php para isolar um problema.
matt
ok, então qual plugin de cpt você recomenda?
Equipe Editorial
A ideia é que você deve registrar CPTs em um plugin específico do site. Ainda não existe um plugin específico. Mas isso é apenas uma discussão da ideia de criar um plugin base para tipos de post genéricos.
Admin
Muhammad Waqas
Estou mais convencido com o uso de funções locais. Mas neste caso, acho que um plugin pode ser mais confiável. Por exemplo, se você começar a usar o wp com um framework específico. Na maioria dos casos, é possível que você se torne um escravo por muito tempo, a menos que contrate um profissional de wp para ajudá-lo a escapar desse framework sem perder suas configurações e dados. Por outro lado, os plugins podem funcionar em quase todos os temas.
Quando comecei a trabalhar com wp, eu preferia framework a plugin. A realidade é que o desenvolvedor de plugins considera novatos e pessoas menos letradas ao desenvolver algo. Eu pessoalmente acredito que a maior parte dos usuários de wp gosta de hacks manuais de código do que depender de plugins para funções principais de sites. A longo prazo, os plugins não são confiáveis. Eu sinto isso..