WordPress é uma forma muito popular de colocar um site em funcionamento rapidamente. No entanto, na pressa, muitos desenvolvedores acabam tomando decisões horríveis. Alguns erros, como sair WP_DEBUG definido como true pode ser fácil de fazer. Outros, como agrupar todo o seu JavaScript em um único arquivo, são tão comuns quanto engenheiros preguiçosos. Qualquer que seja o erro que você cometer, continue lendo para descobrir os 12 erros mais comuns do WordPress que os 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, percebi 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, pois o tema, sendo desenvolvido ativamente, aumentará em recursos e, às vezes, você verá arquivos com 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 bloqueio de renderização código na seção principal da página.
2. Isso torna o gerenciamento do código dentro do arquivo mais difícil, já que 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 plug-ins ativos. Claro, o arquivo pode ser dividido em vários e enfileirado no WordPress, mas se em algum momento posterior, o administrador do site realiza uma atualização do tema main.js arquivo, então todo o processo tem que começar tudo de novo.

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

Ao desenvolver um plug-in, é melhor usar uma convenção de nomenclatura que evite conflito de código no caso de haver outros plug-ins usando o mesmo nome. É por isso que muitos desenvolvedores prefixam suas variáveis ​​e nomes de função 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 plug-ins ativados.

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

1. Colisões de nomes entre o código que eles criam e o PHP interno ou de terceiros, classes, funções ou constantes
2. Capacidade de criar um alias (ou abreviar) Extra_Long_Names projetado para corrigir o primeiro problema ou melhorar a legibilidade do código-fonte. Este é o meu favorito, já que frequentemente desenvolvo temas ou plug-ins que possuem muitos códigos. Com isso, posso ler e gerenciar o código facilmente, sem ter que me preocupar muito em ter nomes longos e exclusivos.

Eu recomendo um bom entendimento dos namespaces antes de usá-los, pois eles geralmente podem ser usados ​​da maneira errada.

Dependendo do projeto que você vai assumir, é provável que você tenha que se ater ao 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 o Padrões de codificação PHP para WordPress, então é melhor segui-los 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 duplas) se você não estiver avaliando nada na string. Além disso, o código deve ser indentado para ser lido, especialmente se ele tiver código aninhado (por exemplo, IF s em IF s, aninhado FOREACH se FOR s).

3. Não aproveitando a funcionalidade central existente do WordPress para seu verdadeiro potencial

Como o WordPress vem com um conjunto de bibliotecas atualizadas regularmente que podem ser chamadas apenas em nossos plug-ins e temas, é melhor apenas usar o máximo possível da funcionalidade central existente. Já vi temas e plug-ins do WordPress com 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 que o pacote ficará maior e demorará mais para carregar na rede, você também deve garantir que todas as bibliotecas de terceiros sejam atualizadas regularmente, o que é apenas mais uma coisa para cuidar.

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 mais 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, já que seu painel é consistentemente melhorado) e torna o site mais seguro no caso de vulnerabilidades encontradas em versões de código antigo.

4. Não tornando 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 contribuindo para seu código. Se uma atualização automática for realizada no plugin ou no tema, quaisquer mudanças 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, uma vez que você pode alterar a funcionalidade existente sem editar o tema pai ou o próprio plugin. Além disso, se você está oferecendo um plug-in para download gratuito no WordPress.org e posteriormente deseja criar uma extensão premium que dependeria 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 Defina como false

Por padrão, o WP_DEBUG constante é definida como 'falsa' para evitar a impressão de quaisquer erros, avisos e avisos de PHP. Em um ambiente ativo, essa é uma opção 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 'verdadeiro', pois isso nos notificará de quaisquer erros em nosso código. Mesmo que os erros não afetem diretamente a funcionalidade, muitas vezes o forçam 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ê desenvolve não gere erros de PHP em nenhuma instalação do WordPress.

Embora isso seja algo que os desenvolvedores mais experientes façam, 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 de PHP.

6. Escrever código PHP sem considerar que a página poderia 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 do PHP.

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

Se o seu cliente instalar um plugin que armazena em cache a página (por exemplo, W3 Total Cache ou WP Rocket) sem acionar as condicionais em seu tema ou plug-ins, seu código PHP se tornará 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, apenas se realmente for necessário. O ideal é 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 para uma versão anterior facilmente sempre que algo der errado com o site. Além disso, os clientes podem usar o Git para manter o controle de todo o histórico de trabalho feito por todos os desenvolvedores que foram contratados para aquele projeto específico, especialmente se for um grande site personalizado WordPress de longo prazo.

Embora possa ser intimidante no início, especialmente para desenvolvedores juniores, entender o Git valerá a pena e um software Git GUI como o SourceTree (um dos meus favoritos) seria simplesmente a maneira como você interage com seus repositórios Git, formando o todo curva de aprendizado mais agradável. Depois de entender como funciona, considere verificar Melhores práticas e dicas do Git por desenvolvedores do ApeeScape isso explica com mais profundidade algumas maneiras de usar o Git.

8. Enfileirando arquivos CSS e JavaScript quando não forem necessários

Ter muitas solicitações HTTP tornaria o carregamento do site mais lento, tendo, portanto, 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 plug-ins. Por exemplo, pode haver dois plug-ins 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 é muito comumente carregado em sites ativos várias vezes. Isso provavelmente acontece devido a plug-ins ou temas mal escritos.

9. Usando .php Arquivos para saída de código CSS ou JavaScript em vez de estático .css e .js arquivos

Já vi temas e até mesmo plug-ins do WordPress que tinham arquivos como style.php que foram usados ​​apenas para gerar código CSS personalizado e imprimi-lo. Coisas como cores, tamanhos de fonte e espaçamento entre os elementos foram definidos nas configurações do tema e depois salvos no banco de dados. Em seguida, style.php é lido (por exemplo,) e gera o código CSS com base nas configurações personalizadas que foram atualizadas no painel.

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

1. Conforme o arquivo CSS está sendo carregado no head (o que é normal e a maioria deles está carregando assim), há um problema de desempenho que vem com isso, pois o navegador tem que baixar o arquivo completamente antes de renderizar a página. Se o ambiente do WordPress for lento por causa de alguns plug-ins, isso atrasará consideravelmente o tempo de carregamento. Mesmo que técnicas de cache sejam usadas ou apenas parte do ambiente WordPress seja carregada 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 precisam verificar algo. Claro, o arquivo pode ser executado no navegador (embora eu tenha certeza que quando for impresso, não será nem 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 customizado fora do diretório do plugin. Exemplo: /wp-content/uploads/theme-name-custom-css/style-5.css. Desta forma, caso o tema ou plugin sejam atualizados, o arquivo customizado não será perdido.

10. Não usando a arquitetura certa (organização de código) para os plug-ins 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 for ativado, como WooCommerce), a arquitetura certa e a organização do código devem ser configuradas.

Se você tiver que construir 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 vai ser caracterizado 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 front-end, uma classe como class.scripts.php pode ser usado e enfileirar os arquivos front-end em um método como enqueue_public_scripts() ao enfileirar os arquivos que devem ser carregados na área de administração dentro do enqueue_admin_scripts() método.

Em vez de misturar o HTML com o código PHP, é melhor mantê-lo separado implementando o padrão MVC nos plug-ins e temas. Um bom exemplo é o plugin WooCommerce. Possui modelos para vários layouts que também podem ser substituídos facilmente por meio do tema ou de vários filtros, apenas porque a lógica é separada do design. O modelo que contém 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 haja uma série de padrões de arquitetura possíveis, eles podem ser amplamente agrupados em três variações:

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

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

A segurança geralmente não é levada a sério no desenvolvimento do WordPress, já que muitos desenvolvedores novatos se concentram mais nos resultados que o cliente deseja. Tudo está bem até que o site do cliente seja hackeado 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 bom número 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 o lançamento de um patch sólido e bem testado.

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

Vulnerabilidades de XSS: para evitar isso, duas coisas devem ser feitas: limpar a entrada de dados e limpar os dados de saída. Dependendo dos dados e do contexto em que são usados, existem vários métodos no WordPress para limpar 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 higienizar a entrada de dados é sanitize_text_field() . Ele verifica se há caracteres UTF-8 inválidos e converte em um únicoesc_url() função, 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 como a maioria dos hosts permite. No entanto, se isso acontecer e o código não for escrito corretamente para lidar com isso, alguns erros podem ser impressos (por exemplo, funções ausentes ou variáveis ​​que não foram declaradas) que conteriam informações valiosas para invasores em potencial. Um snippet de código comum que você vê com frequência em plug-ins e temas é:

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

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

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

Por exemplo, o seguinte URL no painel seria usado para destruir uma postagem: img/back-end/16/12-worst-mistakes-advanced-wordpress-developers-make.jpg —Ao acessar este URL, o WordPress validará as informações do cookie de autenticação e se você tiver a permissão correta (por exemplo, você é um administrador com todos os privilégios), essa postagem será excluída.

O que um invasor pode fazer é fazer seu navegador acessar esse URL sem o seu conhecimento criando um link em uma página de terceiros, como no exemplo a seguir: Ao fazer essa solicitação ao WordPress, o navegador irá anexar automaticamente seu cookie de autenticação e o WordPress considerará a solicitação válida.

É quando um nonce surge, pois o invasor não será capaz de obter o valor do nonce (gerado para o administrador que está realmente conectado ao WordPress) tão facilmente. O novo URL de solicitação seria assim: img/back-end/16/12-worst-mistakes-advanced-wordpress-developers-make.jpg&_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 hackeado, confiando na hospedagem (o que pode ser útil, mas apenas até certo ponto) e no fato de terem comprado plug-ins / temas comerciais (que geralmente levam partindo do pressuposto de que são muito seguros), devemos sempre fazer testes de penetração em nossos sites, a fim de identificar vulnerabilidades exploráveis ​​antes que qualquer hacker seja capaz de identificá-las e explorá-las.

Observe que um grande número de hacks por aí nem mesmo é feito por uma pessoa com a intenção de hackear especificamente seu site. Muitas vezes, existem bots que fazem a varredura de 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 certas páginas do site que levaria a todo tipo de site duvidoso (por exemplo, pornografia, drogas ilícitas). Às vezes, os hacks ficam 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 até reinstalar o WordPress (sim, a mesma versão, se você tiver a última) para que todos os arquivos hackeados sejam substituídos pelos arquivos centrais originais do WordPress.

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

Muitas vezes, quando os desenvolvedores ficam presos e encontram uma solução em lugares como StackOverflow, eles ficam felizes com o fato de que conseguiram 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 do código de projeto existente. Sim, é confortável apenas copiar e colar snippets 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 para trabalhos comerciais 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 for otimizado, esta prática de “copiar e colar” pode levar a uma manutenção lenta e difícil do site, especialmente se mais de um snippet for usado em vários locais dentro do projeto.
3. O código não pode ser licenciado para reutilização e incluir o código em um projeto do cliente pode causar muitos problemas legais.

Melhoria Constante

Todos cometem erros e cada erro é uma oportunidade de melhorar a si mesmo. Como Desenvolvedores WordPress , nosso setor se move em um ritmo muito rápido e nunca há um 'jeito certo' de 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 esqueci um? Deixe-me saber nos comentários e discutiremos.

Relacionado: Meus Cinco Piores Erros de Desenvolvimento WordPress