Imagine o seguinte cenário: você encontra um trecho de código muito legal em um dos muitos sites de tutoriais do WordPress e o cola no arquivo functions.php do seu tema.
O snippet de código funciona como anunciado e, em seguida, você lança seu tema para venda em um mercado de temas bem conhecido. Vamos escolher um aleatório e escolher… ThemeForest.
De repente, seu tema se torna muito popular, talvez por causa da enorme lista de “recursos” aparentemente úteis que você listou na página de vendas do tema. Com o sucesso do seu tema, vem também uma série de consultas de suporte, a maioria relacionada à quebra de plugins durante o uso do tema.
Como isso aconteceu, você se pergunta? Talvez seja porque você colou cegamente pedaços aleatórios de código do WordPress em seu arquivo functions.php sem realmente pensar ou antecipar quaisquer possíveis problemas de compatibilidade.
Um exemplo da vida real
Então, eu estava tentando encontrar um trecho de código que extraísse todas as imagens anexadas de uma publicação e as exibisse automaticamente nessa publicação. Acabei encontrando um trecho de código no Stack Overflow, colei-o em meu arquivo de funções e ele pareceu resolver o problema.
A primeira linha de código era a seguinte:
add_filter('the_content', 'strip_shortcodes');Bem, funcionou, não pensei em nada. Mais tarde, tentei incorporar um formulário de contato com um shortcode. Surpresa, não funcionou e passei cerca de uma hora tentando descobrir o motivo. Se eu realmente tivesse lido o código que estava colando, eu saberia.
Isso foi feito para o site de um cliente, não para um tema lançado, portanto, felizmente, não tive que lidar com uma enxurrada de consultas de suporte devido ao meu erro estúpido.
O que pensam os desenvolvedores de plug-ins comerciais
Aqui está uma citação de Carl Hancock (desenvolvedor do Gravity Forms) sobre esse mesmo tópico:
Oferecer suporte ao popular plug-in Gravity Forms significa que vemos mais do que nosso quinhão de temas mal codificados. Um dos principais problemas relacionados ao suporte que encontramos são os temas que não foram desenvolvidos usando as práticas recomendadas, o que resulta em problemas de estilo do Gravity Forms e, em alguns casos, conflitos que fazem com que o Gravity Forms não funcione corretamente.
O maior culpado nessas situações são os temas que incluem trechos de código copiados e colados de sites de tutoriais. Os desenvolvedores de temas parecem pensar que, só porque o trecho de código estava em um site de tutorial, ele deve ser bom. Infelizmente, esse nem sempre é o caso e essas decisões ruins resultam em dores de cabeça e problemas de suporte para os usuários.
Deseja limitar a possibilidade de ter problemas com plug-ins causados por um tema mal desenvolvido? Prefira os desenvolvedores de temas de boa reputação, como Press75, iThemes, Headway Themes, Organic Themes, WooThemes e StudioPress, para citar alguns. Desconfie dos mercados de temas em que a experiência e o conjunto de habilidades do autor podem ser insuficientes. Na maioria dos casos, você recebe o que pagou.
Práticas recomendadas de codificação
Muitos desses problemas podem ser evitados seguindo os padrões de codificação do WordPress. Por exemplo, você deve colocar prefixos nos nomes das funções para evitar possíveis conflitos.
No caso de problemas de estilo com o Gravity Forms, talvez você queira evitar determinados estilos gerais em elementos de formulário e entrada e, em vez disso, usar os seletores de ID padrão do WordPress para a maior parte dos estilos de formulário.
Isso inclui #searchform, #s, #searchsubmit na caixa de pesquisa. Também #commentform #author, #url, #email, #comment, #submit para o formulário de comentários.
Conclusão
Se você for um desenvolvedor de temas e não for muito versado em PHP, tenha cuidado ao copiar e colar esses trechos de código em seu tema. Mesmo que não seja muito bom em PHP, você pode pelo menos ler o código e tentar entendê-lo antes de usá-lo.
Por exemplo, se você descobrir que seus códigos de acesso não estão funcionando corretamente, uma linha de código que menciona “strip_shortcodes” pode ter algo a ver com isso.
Às vezes, tenho a impressão de que os desenvolvedores de temas do WordPress simplesmente colam trechos aleatórios em seu arquivo functions.php, apenas para que possam listar outro “recurso” nas páginas de vendas do tema.
Embora eu não seja um grande fã desse tipo de ideia, isso entra em uma discussão totalmente diferente sobre o papel dos temas e plug-ins nos sites do WordPress, que deixarei para um post futuro.
Interesting..I’m a theme developer myself thank you from bringing this to my attention…
I’ve even seen people copy and paste code with copyright notices (asking that the code not be shared!) still intact.
@mkjones – is the problem that the filter was removed, or that its removal wasn’t advertised? I almost always remove the wpautop filter because it automatically destroys perfectly good HTML (of course I tell everyone that it’s gone).
What really irritates me the most is when they paste Jquery (and 20+ other scripts/plugins) directly in the header of their theme or in some hard to find. IS wp_enqueue_script that difficult?
I actually posted a quick example of a Themeforest Jquery Fiasco in my forums if anyone wants to check it out.
Just wanted to add one more thing that may be helpful to some of your readers.
Earlier this month I was helping out a client that purchased a support license for my plugin. The clients theme had around 20 different Jquery plugins loaded into the header.php. Not one of them were using wp_enque_script.
Most of these scripts were only being used for the home page slider and gallery page (that didn’t yet exist.) Since they were getting loaded across the entire site, the scripts were throwing Jquery errors on all of the rest of the pages in the site that had no need for these scripts.
Rather than rewriting the entire header.php and because I didin’t know if any of the scripts may be needed for future pages. I used a few conditional tags to solve the problem. By using conditional tags, I was able to turn off all of the arbitrary scripts, when the site loaded the registration form that was being generated by my plugin.
I actually posted a quick example of a Themeforest Jquery Fiasco in my forums, if anyone wants to check it out.
Sorry Leland, can you remove that first line in my last comment? I thought I removed it before posting.
Thanks!
Oh MAN I hate this. It causes NO end of headaches when customising themes.
I seem to recall the classic:
remove_filter(‘the_content’, ‘wpautop’);
Creeping into one a while ago. Without being properly advertised as a theme ‘feature’ 🙁
I completely agree with you here! I have been down this road and done this mistake myself, only to find myself in trouble later on.
The things you can do with your functions.php are great, but you need to be organized and careful with what you do if you don’t want to spend hours debugging later.
One of the recommandations I would give would be to carefully organize these snippets of code if you want to keep them.
Keep them in separated files, well commented, double test after implementing. In the end, documenting your work always pays off imo.
Couldn’t have said it any better myself. This isn’t just limited to random code snippets found in tutorials around the Web. Theme developers just randomly drop any and all code into functions.php without thinking about — you’d think they’d use a hook once in a while.