Os 12 piores erros que os desenvolvedores avançados do WordPress cometem

O WordPress é uma maneira muito popular de colocar um site em funcionamento rapidamente. No entanto, em sua pressa, muitos desenvolvedores acabam tomando decisões horríveis. Alguns erros, como deixar WP_DEBUG definido como true , podem ser fáceis de cometer. Outros, como agrupar todo o seu JavaScript em um único arquivo, são tão comuns quanto engenheiros preguiçosos. Seja qual for o erro que você cometer, continue lendo para descobrir os 12 erros mais comuns do WordPress que desenvolvedores novos e experientes cometem. Se você estiver cometendo um desses erros, não se desespere. Cada erro é uma oportunidade de aprender.

1. Colocando o código JavaScript do tema WordPress em um arquivo principal

Certa vez, ao fazer a otimização da velocidade da página para os sites de um cliente, notei que eles estavam usando um tema premium que tinha todas as bibliotecas que estavam usando, incluindo o código personalizado, em um único arquivo chamado main.js , theme.js ou custom.js . Essa prática é ruim pelos seguintes motivos:

1. O arquivo, com o tempo, pode ficar muito grande conforme o tema, sendo desenvolvido ativamente, crescerá em recursos e às vezes você verá arquivos com tamanho de até 1 MB. O arquivo será carregado em todo o site mesmo que apenas 10% do código do arquivo seja necessário em algumas páginas. Isso fará com que as páginas demorem mais para baixar e mais lentas para renderizar, especialmente se for um código de bloqueio de renderização na seção principal da página.
2. Isso torna o gerenciamento do código dentro do arquivo mais difícil, pois você não pode usar funções como wp_dequeue_script() para descarregar parte do código em algumas páginas para melhorar a velocidade da página ou para evitar um conflito com outro código JavaScript que poderia ser carregado por um dos plugins ativos. Claro, o arquivo pode ser dividido em vários e enfileirado no WordPress, mas se em algum momento posterior, o administrador do site realizar uma atualização do arquivo main.js do tema, todo o processo terá que começar tudo de novo.

2. Usando nomes muito comuns para variáveis, funções, constantes ou classes

Ao desenvolver um plugin, é melhor usar uma convenção de nomenclatura que evite conflito de código caso haja outros plugins usando o mesmo nome. É por isso que muitos desenvolvedores prefixam suas variáveis ​​e nomes de funções com algo único e relacionado ao próprio plugin. Além de eliminar o conflito de código, também torna as coisas mais fáceis de encontrar quando você tem muitos plugins ativados.

Existem desenvolvedores, por outro lado, que preferem usar namespaces PHP para encapsular itens e resolver os dois problemas que autores de bibliotecas e aplicativos encontram ao criar elementos de código reutilizáveis, como classes ou funções:

1. Conflitos de nome entre o código que eles criam e PHP interno ou de terceiros, classes, funções ou constantes
2. Capacidade de alias (ou encurtamento) Extra_Long_Names projetados para corrigir o primeiro problema ou melhorar a legibilidade do código-fonte. Este é o meu favorito, pois costumo desenvolver temas ou plugins que têm muito código. Com isso, posso ler e gerenciar o código facilmente sem ter que me preocupar muito em ter nomes longos e exclusivos.

Eu recomendaria uma boa compreensão dos namespaces antes de usá-los, pois muitas vezes eles podem ser usados ​​de maneira errada.

Dependendo do projeto que você adotar, é provável que você tenha que manter o estilo de codificação existente, a menos que seu trabalho seja principalmente separado do existente. Caso você precise estender um plugin ou tema existente que já segue os padrões de codificação PHP para WordPress, então é melhor ficar com eles para ter um estilo consistente para que o código fique limpo e fácil de ler. Observe que algumas regras são aplicadas universalmente para melhorar o desempenho, desconsiderando o estilo de codificação. Por exemplo, é sempre melhor usar aspas simples (em vez de aspas duplas) se você não estiver avaliando nada na string. Além disso, o código deve ser indentado para ser lido, especialmente se tiver código aninhado (por exemplo, IF s dentro de IF s, FOREACH s aninhados e FOR s).

3. Não aproveitando a funcionalidade do núcleo do WordPress existente para seu verdadeiro potencial

Como o WordPress vem com um conjunto de bibliotecas atualizadas regularmente que podem ser chamadas em nossos plugins e temas, é melhor usar o máximo possível da funcionalidade principal existente. Eu vi temas e plugins do WordPress que tinham arquivos em seu diretório de ativos que já estavam nos arquivos principais do WordPress (por exemplo, jQuery ou Color Picker). Além do fato de o pacote ficar maior e levar mais tempo para carregar na rede, você também precisa garantir que todas as bibliotecas de terceiros sejam atualizadas regularmente, o que é apenas mais uma coisa a ser cuidada.

Aproveite o que o WordPress já tem a oferecer, pois as bibliotecas já são atualizadas pela equipe principal de desenvolvimento do WordPress e você pode ter um projeto leve e fácil de manter. Ao fazer atualizações regulares do WordPress, você obtém acesso a mais recursos (seja um plug-in, um tema ou o próprio núcleo do WordPress, pois seu painel é constantemente aprimorado) e torna o site mais seguro caso sejam encontradas vulnerabilidades nas versões de código antigas.

4. Não tornar o plugin ou tema fácil de alterar por meio de ações e filtros

Editar um plugin ou tema do WordPress diretamente é uma má ideia, a menos, é claro, que você esteja diretamente envolvido no desenvolvimento desse pacote e contribua com seu código. Se uma atualização automática for realizada no plugin ou no tema, quaisquer alterações diretas no pacote serão perdidas e você terá que editar os arquivos novamente.

É por isso que usar ações e filtros, bem como criar um tema filho (que estende o tema pai) são as abordagens mais eficazes para modificar um tema, pois você pode alterar a funcionalidade existente sem editar o tema pai ou o próprio plug-in. Além disso, se você estiver oferecendo um plug-in para download gratuito no WordPress.org e, posteriormente, desejar criar uma extensão premium que dependa do plug-in pai, você deve desenvolver o plug-in gratuito de forma que ele ser fácil de estender e adicionar extensões premium.

5. Desenvolvendo com WP_DEBUG definido como false

Por padrão, a constante WP_DEBUG é definida como 'false' para evitar a impressão de quaisquer erros, avisos e avisos do PHP. Em um ambiente ao vivo, essa é uma escolha recomendada, pois mantém os caminhos e scripts do servidor privado ocultos da exibição pública, o que é ótimo por motivos de segurança. No entanto, durante o estágio de desenvolvimento, é melhor defini-lo como 'true', pois ele nos notificará sobre quaisquer erros em nosso código. Mesmo que os erros não afetem diretamente a funcionalidade, muitas vezes isso forçará você a escrever um código melhor e desenvolver melhores hábitos de codificação. Isso aconteceu comigo. Isso também garantirá que o plugin ou tema que você desenvolver não gere erros de PHP em nenhuma instalação do WordPress.

Embora isso seja algo que os desenvolvedores mais experientes fazem, isso acontece, especialmente com pressa. Não importa o quão urgente seja o trabalho, os desenvolvedores devem sempre tentar manter os padrões de codificação do WordPress, com um olho óbvio nas melhores práticas do PHP.

6. Escrevendo código PHP sem considerar que a página pode ser armazenada em cache um dia

Este é um erro comum do PHP e, como o anterior, é relativamente fácil de evitar se você seguir os padrões de codificação PHP.

Alguns desenvolvedores têm o hábito de implementar trechos de PHP em temas e plugins que só são válidos se o código PHP for acionado o tempo todo. Por exemplo, uma função PHP que responde ao HTTP User Agent com certas ações deve ser executada ou não (por exemplo, enfileirar scripts que são destinados apenas a usuários móveis).

Se o seu cliente instalar um plugin que armazene a página em cache (por exemplo, W3 Total Cache ou WP Rocket) sem acionar as condicionais em seu tema ou plugins, seu código PHP será inútil. Se a intenção é tornar as páginas responsivas, isso deve ser feito no front-end por meio de consultas de mídia e JavaScript. Este último, somente se realmente for necessário. Idealmente, você deseja evitar o uso de JavaScript para tornar seu site responsivo.

7. Não rastrear alterações feitas de maneira profissional por meio de um sistema de controle de versão como o Git

Arquivos que são codificados de forma personalizada, como um tema filho ou um plug-in personalizado, devem estar sob controle de versão. O Git cria um registro do que foi alterado e permite que os desenvolvedores trabalhem juntos no mesmo projeto WordPress ou revertam facilmente para uma versão anterior sempre que algo der errado com o site. Além disso, os clientes podem usar o Git para acompanhar todo o histórico de trabalho que foi feito por todos os desenvolvedores que foram contratados para esse projeto específico, especialmente se for um site personalizado WordPress grande e de longo prazo.

Embora possa ser intimidante no começo, especialmente para desenvolvedores juniores, entender o Git valerá a pena e um software Git GUI como SourceTree (um dos meus favoritos) seria simplesmente a maneira como você interage com seus repositórios Git, tornando o todo curva de aprendizado mais agradável. Depois de entender como ele funciona, considere verificar as práticas recomendadas e dicas do Git por desenvolvedores da Toptal que explicam com mais profundidade algumas maneiras de usar o Git.

8. Enfileiramento de arquivos CSS e JavaScript quando não são necessários

Ter muitas solicitações HTTP tornaria o site mais lento para carregar, tendo assim uma pontuação mais baixa no Google PageSpeed, o que provavelmente afetaria a classificação de pesquisa. Também pode levar a erros de JavaScript devido a conflitos entre plugins. Por exemplo, pode haver dois plugins usando uma biblioteca jQuery comum, que pode ser carregada duas vezes e pode causar problemas. E realmente, este é o melhor exemplo, já que o jQuery é comumente carregado em sites ao vivo várias vezes. Isso provavelmente acontece devido a plugins ou temas mal escritos.

9. Usando arquivos .php para gerar código CSS ou JavaScript em vez de .css e .js estáticos

Já vi temas e até plugins do WordPress que tinham arquivos como style.php que eram usados ​​apenas para gerar código CSS personalizado e imprimi-lo. Coisas como cores, tamanhos de fonte e espaçamento entre elementos foram definidas nas configurações do tema e depois salvas no banco de dados. Então style.php é lido (por exemplo, <link rel='stylesheet' type='text/css' href='css/style.php?ver=1' /> ) e gera o código CSS com base nas configurações personalizadas que foram atualizados no painel.

Esta é realmente uma má prática em termos de desempenho do WordPress. Aqui estão as principais desvantagens que vêm com ele:

1. Como o arquivo CSS está carregando dentro da tag head (o que é normal e a maioria deles está carregando assim), há um problema de desempenho que vem com isso, pois o navegador precisa baixar o arquivo completamente antes de renderizar a página. Se o ambiente do WordPress estiver lento por causa de alguns plugins, isso atrasará consideravelmente o tempo de carregamento. Mesmo que sejam usadas técnicas de cache ou apenas parte do ambiente WordPress seja carregado para recuperar os valores do banco de dados. É melhor usar um arquivo .css estático.
2. No arquivo PHP, o código (regras CSS misturadas com variáveis ​​PHP e cláusulas condicionais) será mais difícil de ler pelos desenvolvedores quando eles precisarem verificar algo. Claro, o arquivo pode ser executado no navegador (embora eu tenha certeza que quando for impresso, nem será recuado ou bonito), mas se você tiver uma cópia local do projeto e navegar pelo código do tema e precisar para encontrar uma sintaxe CSS ou JavaScript (no caso de script.php ser usado), isso tornaria a legibilidade mais difícil.

A solução: salve qualquer CSS personalizado fora do diretório do plugin. Exemplo: /wp-content/uploads/theme-name-custom-css/style-5.css . Dessa forma, caso o tema ou plugin seja atualizado, o arquivo personalizado não será perdido.

10. Não usar a arquitetura correta (organização de código) para os plugins e temas do WordPress

Dependendo do tamanho e da natureza do plug-in (por exemplo, um plug-in autônomo ou uma extensão de plug-in que funciona apenas se um plug-in principal estiver ativado, como o WooCommerce), a arquitetura e a organização do código corretas devem ser configuradas.

Se você tiver que criar um plug-in WordPress de propósito único para um cliente e ele tiver uma interação limitada com o núcleo, temas e outros plug-ins do WordPress, não é eficaz projetar classes complexas, a menos que você tenha certeza de que o plug-in se expandirá consideravelmente mais tarde em.

Se o plug-in for rico em recursos com muito código, usar uma abordagem de codificação de Programação Orientada a Objetos (OOP) (com muitas classes) faria sentido. Por exemplo, se você tiver muitos códigos de acesso, poderá mantê-los todos em um arquivo de classe separado, como class.shortcodes.php , ou se houver arquivos CSS e JavaScript que devem ser carregados no painel e na visualização de front-end então uma classe como class.scripts.php pode ser usada e enfileirar os arquivos front-end dentro de um método como enqueue_public_scripts() enquanto enfileira os arquivos destinados a serem carregados na área de administração dentro do método enqueue_admin_scripts() .

Em vez de misturar o HTML com o código PHP, é melhor mantê-lo separado implementando o padrão MVC nos plugins e temas. Um bom exemplo é o plugin WooCommerce. Possui templates para diversos layouts que também podem ser substituídos facilmente através do tema ou de vários filtros apenas porque a lógica é separada do design. O modelo contendo o layout HTML é usado principalmente para imprimir as informações já processadas. Ter código HTML dentro de métodos PHP geralmente é uma prática ruim (há exceções, é claro, para pequenos pedaços de código HTML), especialmente para um plugin que é mantido por mais de um desenvolvedor à medida que cresce em tamanho.

De acordo com o WordPress Plugin Handbook, embora existam vários padrões de arquitetura possíveis, eles podem ser agrupados em três variações:

• Arquivo de plugin único, contendo funções
• Arquivo de plug-in único, contendo uma classe, objeto instanciado e, opcionalmente, funções
• Arquivo de plug-in principal e, em seguida, um ou mais arquivos de classe

11. Não levar a sério a segurança do WordPress ao escrever código

A segurança geralmente não é levada a sério no desenvolvimento do WordPress, pois muitos desenvolvedores iniciantes se concentram mais nos resultados que o cliente deseja. Tudo está bem até que o site do cliente seja invadido ou seu plugin publicado no WordPress.org tenha uma vulnerabilidade, deixando milhares de sites afetados. Essas coisas acontecem às vezes e até mesmo o núcleo do WordPress lidou com um número razoável de vulnerabilidades de segurança desde os primeiros dias do CMS. É nossa responsabilidade torná-lo o mais seguro possível e, caso algo aconteça, agir prontamente e garantir que lançamos um patch sólido e bem testado.

Algumas das dicas de segurança mais importantes são:

Vulnerabilidades XSS: Para evitar isso, duas coisas devem ser feitas: sanitizar a entrada de dados e sanear os dados de saída. Dependendo dos dados e do contexto em que são usados, existem vários métodos no WordPress para higienizar o código. Não se deve confiar em nenhum dado de entrada, nem em nenhum dado que será impresso. Uma função comum para sanitizar a entrada de dados é sanitize_text_field() . Ele verifica se há caracteres UTF-8 inválidos, converte caracteres < simples em entidades HTML, remove todas as tags, remove quebras de linha, tabulações e espaços em branco extras e remove octetos. Quanto à impressão de dados, um bom exemplo de saída de links é a função esc_url() , que rejeita URLs inválidos, elimina caracteres inválidos e remove caracteres perigosos.

Impedir o acesso direto aos seus arquivos: Os arquivos podem ser acessados ​​diretamente, pois a maioria dos hosts permite isso. No entanto, se isso acontecer e o código não for escrito adequadamente para lidar com isso, alguns erros podem ser impressos (por exemplo, funções ausentes ou variáveis ​​que não são declaradas) que conteriam informações valiosas para possíveis invasores. Um trecho de código comum que você vê com frequência em plugins e temas é:

 // Exit if accessed directly if ( ! defined( 'ABSPATH' ) ) exit;

Se a constante ABSPATH não estiver definida (o que deve ser para qualquer instalação do WordPress), o script sairá e não imprimirá nada.

Use Nonces: Conforme declarado na documentação do WordPress, um nonce é um “número usado uma vez” para ajudar a proteger URLs e formulários de certos tipos de uso indevido, malicioso ou não.

Por exemplo, a seguinte URL no painel seria usada para descartar uma postagem: http://example.com/wp-admin/post.php?post=123&action=trash —Ao acessar esta URL, o WordPress validará as informações do cookie de autenticação e se você tiver a permissão certa (por exemplo, você é um administrador com todos os privilégios), essa postagem será excluída.

O que um invasor pode fazer é fazer com que seu navegador acesse esse URL sem o seu conhecimento criando um link em uma página de terceiros, como no exemplo a seguir: <img src="http://example.com/wp-admin/post.php?post=123&action=trash" /> Ao fazer essa solicitação ao WordPress, o navegador anexará automaticamente seu cookie de autenticação e o WordPress considerará a solicitação como válida.

É quando um nonce entra em vigor, pois o invasor não poderá obter o valor nonce (gerado para o administrador que está realmente conectado ao WordPress) com tanta facilidade. O novo URL de solicitação ficaria assim: http://example.com/wp-admin/post.php?post=123&action=trash&_wpnonce=b192fc4204

Sem um nonce válido, uma resposta 403 Forbidden seria enviada ao navegador pelo WordPress com a conhecida mensagem de erro: “Tem certeza de que deseja fazer isso?”

Embora a maioria das pessoas não leve a sério a segurança do WordPress, pensando que seu site nunca seria invadido, confiando na hospedagem (que pode ser útil, mas apenas até certo ponto) e no fato de comprarem plugins/temas comerciais (que geralmente levam à suposição de que eles são muito seguros), devemos sempre fazer testes de penetração em nossos sites para identificar vulnerabilidades exploráveis ​​antes que qualquer hacker possa identificá-las e explorá-las.

Observe que um grande número de hacks por aí nem é feito por uma pessoa com a intenção de hackear especificamente seu site. Muitas vezes, existem bots que verificam sites WordPress automaticamente de forma consistente e no momento em que uma vulnerabilidade conhecida é encontrada, ela é explorada e o servidor usado para spam, obtendo informações privadas do banco de dados, colocando links ocultos em determinadas páginas do site que levaria a todo tipo de site desonesto (por exemplo, pornografia, drogas ilícitas). Às vezes, os hacks estão tão bem escondidos que você precisa de uma verificação adequada do seu site e ver a data em que arquivos específicos foram atualizados para detectar o código hackeado. É por isso que é bom reinstalar o WordPress (sim, a mesma versão se você tiver o último) para que qualquer arquivo hackeado seja substituído pelos arquivos principais genuínos do WordPress.

12. Usando funções e trechos de código do WordPress sem compreendê-los

Muitas vezes, quando os desenvolvedores ficam presos e encontram uma solução em lugares como StackOverflow, eles ficam felizes com o fato de terem conseguido fazer algo funcionar sem se preocupar em entender a lógica por trás desse código ou se esse código pode ser alterado para carregar mais rápido ou ter menos linhas de código.

Já vi essa prática tantas vezes quando trechos de código são copiados em scripts PHP quando apenas um terço desse código é realmente usado.

Isso pode ter algumas desvantagens, incluindo:

1. O código não usa o mesmo estilo que o código de projeto existente. Sim, é confortável apenas copiar e colar trechos que funcionam fora da caixa e, embora sejam bons para um pequeno projeto pessoal (pode se transformar em um grande projeto algum dia, quem sabe), essa prática geralmente não é boa quando se trata ao trabalho comercial onde uma consistência de estilo deve ser mantida.
2. Embora o código faça seu trabalho, ele pode conter funções ineficazes que não são recomendadas para a tarefa que precisa ser realizada. Se o código não estiver otimizado, essa prática de “copiar e colar” pode tornar o site lento e difícil de manter, especialmente se mais de um snippet for usado em vários locais do projeto.
3. O código pode não ser licenciado para reutilização, e incluir o código no projeto de um cliente pode causar muitos problemas legais.

Melhoria Constante

Todo mundo comete erros, e cada erro é uma oportunidade para melhorar a si mesmo. Como desenvolvedores do WordPress, nossa indústria se move em um ritmo muito rápido, e nunca há um “jeito certo” definido para fazer as coisas. No entanto, quanto mais você praticar e aprender, melhor você se tornará.

Você discorda de algum dos erros que apontei ou acha que deixei passar algum? Deixe-me saber nos comentários e vamos discutir.