Os 10 erros mais comuns que os desenvolvedores do WordPress cometem

Somos apenas humanos, e uma das características de ser humano é que cometemos erros. Por outro lado, também nos corrigimos, o que significa que tendemos a aprender com nossos erros e, com sorte, somos capazes de evitar cometer os mesmos duas vezes. Muitos dos erros que cometi no domínio do WordPress se originam da tentativa de economizar tempo ao implementar soluções. No entanto, eles normalmente ficariam de cabeça no caminho quando os problemas surgissem como resultado dessa abordagem. Errar é inevitável. No entanto, aprender com os descuidos de outras pessoas (e os seus, é claro!) é um caminho que você deve seguir proativamente.

Erro comum nº 1: manter a depuração desligada

Por que devo usar a depuração quando meu código está funcionando bem? A depuração é um recurso embutido no WordPress que fará com que todos os erros, avisos e avisos do PHP (sobre funções obsoletas, etc.) sejam exibidos. Quando a depuração está desativada, pode haver avisos ou avisos importantes sendo gerados que nunca vemos, mas que podem causar problemas mais tarde se não lidarmos com eles a tempo. Queremos que nosso código funcione bem com todos os outros elementos do nosso site. Portanto, ao adicionar qualquer novo código personalizado ao WordPress, você deve sempre fazer seu trabalho de desenvolvimento com a depuração ativada (mas certifique-se de desativá-la antes de implantar o site em produção!).

Para habilitar esse recurso, você precisará editar o arquivo wp-config.php no diretório raiz da sua instalação do WordPress. Aqui está um trecho de um arquivo típico:

 // Enable debugging define('WP_DEBUG', true); // Log all errors to a text file located at /wp-content/debug.log define('WP_DEBUG_LOG', true); // Don't display error messages write them to the log file /wp-content/debug.log define('WP_DEBUG_DISPLAY', false); // Ensure all PHP errors are written to the log file and not displayed on screen @ini_set('display_errors', 0);

Esta não é uma lista exaustiva de opções de configuração que podem ser usadas, mas esta configuração sugerida deve ser suficiente para a maioria das necessidades de depuração.

Erro comum nº 2: Adicionando scripts e estilos usando o gancho wp_head

O que há de errado em adicionar os scripts ao meu modelo de cabeçalho? O WordPress já inclui uma infinidade de scripts populares. Ainda assim, muitos desenvolvedores adicionarão scripts adicionais usando o gancho wp_head . Isso pode resultar no mesmo script, mas em uma versão diferente, sendo carregado várias vezes.

O enfileiramento aqui vem para o resgate, que é a maneira amigável do WordPress de adicionar scripts e estilos ao nosso site. Usamos o enfileiramento para evitar conflitos de plugins e lidar com quaisquer dependências que um script possa ter. Isso é obtido usando as funções wp_enqueue_script ou wp_enqueue_style para enfileirar scripts e estilos, respectivamente. A principal diferença entre as duas funções é que com wp_enqueue_script temos um parâmetro adicional que nos permite mover o script para o rodapé da página.

 wp_register_script( $handle, $src, $deps = array(), $ver = false, $in_footer = false ) wp_enqueue_script( $handle, $src = false, $deps = array(), $ver = false, $in_footer = false ) wp_register_style( $handle, $src, $deps = array(), $ver = false, $media = 'all' ) wp_enqueue_style( $handle, $src = false, $deps = array(), $ver = false, $media = 'all' )

Se o script não precisar renderizar o conteúdo acima da dobra, podemos movê-lo com segurança para o rodapé para garantir que o conteúdo acima da dobra seja carregado rapidamente. É uma boa prática registrar o script primeiro antes de enfileirar, pois isso permite que outras pessoas cancelem o registro do seu script por meio do identificador em seus próprios plugins, sem modificar o código principal do seu plugin. Além disso, se o identificador de um script registrado estiver listado na matriz de dependências de outro script que foi enfileirado, esse script será carregado automaticamente antes de carregar esse script enfileirado destacado.

Erro comum nº 3: evitar temas filhos e modificar arquivos principais do WordPress

Sempre crie um tema filho se você planeja modificar um tema. Alguns desenvolvedores farão alterações nos arquivos do tema pai apenas para descobrir, após uma atualização do tema, que suas alterações foram substituídas e perdidas para sempre.

Para criar um tema filho, coloque um arquivo style.css em um subdiretório da pasta do tema filho, com o seguinte conteúdo:

 /* Theme Name: Twenty Sixteen Child Theme URI: http://example.com/twenty-fifteen-child/ Description: Twenty Fifteen Child Theme Author: John Doe Author URI: http://example.com Template: twentysixteen Version: 1.0.0 License: GNU General Public License v2 or later License URI: http://www.gnu.org/licenses/gpl-2.0.html Tags: light, dark, two-columns, right-sidebar, responsive-layout, accessibility-ready Text Domain: twenty-sixteen-child */

O exemplo acima cria um tema filho baseado no tema padrão do WordPress, Twenty Sixteen . A linha mais importante deste código é aquela que contém a palavra “Template” que deve corresponder ao nome do diretório do tema pai do qual você está clonando o filho.

Os mesmos princípios se aplicam aos arquivos principais do WordPress: não siga o caminho mais fácil modificando os arquivos principais. Faça um esforço extra ao empregar funções e filtros plugáveis ​​do WordPress para evitar que suas alterações sejam substituídas após uma atualização do WordPress. As funções conectáveis ​​permitem que você substitua algumas funções principais, mas esse método está sendo gradualmente eliminado e substituído por filtros. Os filtros atingem o mesmo resultado final e são inseridos no final das funções do WordPress para permitir que sua saída seja modificada. Um truque é sempre envolver suas funções com if ( !function_exists() ) ao usar funções conectáveis, pois vários plugins tentando substituir a mesma função conectável sem esse wrapper produzirão um erro fatal.

Erro comum nº 4: valores de codificação

Muitas vezes, parece mais rápido apenas codificar um valor (como uma URL) em algum lugar no código, mas o tempo gasto na estrada depurando e corrigindo problemas que surgem como resultado disso é muito maior. Ao usar a função correspondente para gerar a saída desejada dinamicamente, simplificamos bastante a manutenção e a depuração subsequentes de nosso código. Por exemplo, se você migrar seu site de um ambiente de teste para produção com URLs codificados, de repente você perceberá que seu site não está funcionando. É por isso que devemos empregar funções, como a listada abaixo, para gerar caminhos de arquivos e links:

 // Get child theme directory uri stylesheet_directory_uri(); // Get parent theme directory get_template_directory_uri(); // Retrieves url for the current site site_url();

Outro mau exemplo de hardcoding é ao escrever consultas personalizadas. Por exemplo, como medida de segurança, alteramos o prefixo padrão da tabela de dados do WordPress de wp_ para algo um pouco mais exclusivo, como wp743_ . Nossas consultas falharão se movermos a instalação do WordPress, pois os prefixos da tabela podem mudar entre os ambientes. Para evitar que isso aconteça, podemos referenciar as propriedades da tabela da classe wpdb :

 global $wpdb; $user_count = $wpdb->get_var( "SELECT COUNT(*) FROM $wpdb->users" );

Observe como não estou usando o valor wp_users para o nome da tabela, mas, em vez disso, estou deixando o WordPress resolver isso. Usar essas propriedades para gerar os nomes das tabelas ajudará a garantir que retornamos os resultados corretos.

Erro comum nº 5: não impedir que seu site seja indexado

Por que não quero que os mecanismos de pesquisa indexem meu site? A indexação é boa, certo? Bem, ao construir um site, você não quer que os mecanismos de pesquisa indexem seu site até que você termine de construí-lo e tenha estabelecido uma estrutura de links permanentes. Além disso, se você tiver um servidor de teste onde testa as atualizações do site, não deseja que mecanismos de pesquisa como o Google indexem essas páginas duplicadas. Quando há vários pedaços de conteúdo indistinguíveis, é difícil para os mecanismos de pesquisa decidir qual versão é mais relevante para uma consulta de pesquisa. Os mecanismos de pesquisa, nesses casos, penalizarão sites com conteúdo duplicado, e seu site sofrerá nas classificações de pesquisa como resultado disso.

Como mostrado abaixo, as configurações de leitura do WordPress têm uma caixa de seleção que diz “Desencorajar os mecanismos de pesquisa de indexar este site”, embora isso tenha uma nota importante abaixo informando que “Cabe aos mecanismos de pesquisa honrar esta solicitação”.

Lembre-se de que os mecanismos de pesquisa geralmente não atendem a esse pedido. Portanto, se você deseja impedir de maneira confiável que os mecanismos de pesquisa indexem seu site, edite seu arquivo .htaccess e insira a seguinte linha:

 Header set X-Robots-Tag "noindex, nofollow"

Erro comum nº 6: não verificar se um plug-in está ativo

Por que devo verificar se existe uma função de plugin se meu plugin está sempre ligado? Com certeza, 99% do tempo seu plugin estará ativo. No entanto, e aquele 1% das vezes em que por algum motivo foi desativado? Se e quando isso ocorrer, seu site provavelmente exibirá alguns erros feios de PHP. Para evitar isso, podemos verificar se o plugin está ativo antes de chamarmos suas funções. Se a função do plugin estiver sendo chamada pelo front-end, precisamos incluir a biblioteca plugin.php para chamar a função is_plugin_active() :

 include_once( ABSPATH . 'wp-admin/includes/plugin.php' ); if ( is_plugin_active( 'plugin-folder/plugin-main-file.php' ) ) { // Run plugin code }

Esta técnica é geralmente bastante confiável. No entanto, pode haver casos em que o autor alterou o nome do diretório principal do plug-in. Um método mais robusto seria verificar a existência de uma classe no plugin:

 if( class_exists( 'WooCommerce' ) ) { // The plugin WooCommerce is turned on }

Os autores são menos propensos a alterar o nome da classe de um plugin, então eu geralmente recomendaria usar esse método.

Erro comum nº 7: carregar muitos recursos

Por que devemos ser seletivos no carregamento de recursos de plugin para páginas? Não há motivo válido para carregar estilos e scripts para um plug-in se esse plug-in não for usado na página para a qual o usuário navegou. Ao carregar apenas os arquivos de plug-in quando necessário, podemos reduzir o tempo de carregamento da página, o que resultará em uma melhor experiência do usuário final. Tomemos, por exemplo, um site WooCommerce, onde queremos apenas que o plugin seja carregado em nossas páginas de compras. Nesse caso, podemos remover seletivamente qualquer arquivo do carregamento em todas as outras páginas do site para reduzir o inchaço. Podemos adicionar o seguinte código ao arquivo functions.php do tema ou plugin:

 function load_woo_scripts_styles(){ if( function_exists( 'is_woocommerce' ) ){ // Only load styles/scripts on Woocommerce pages if(! is_woocommerce() && ! is_cart() && ! is_checkout() ) { // Dequeue scripts. wp_dequeue_script('woocommerce'); wp_dequeue_script('wc-add-to-cart'); wp_dequeue_script('wc-cart-fragments'); // Dequeue styles. wp_dequeue_style('woocommerce-general'); wp_dequeue_style('woocommerce-layout'); wp_dequeue_style('woocommerce-smallscreen'); } } } add_action( 'wp_enqueue_scripts', 'load_woo_scripts_styles');

Scripts podem ser removidos com a função wp_dequeue_script($handle) através do handle com o qual eles foram registrados. Da mesma forma, wp_dequeue_style($handle) impedirá que as folhas de estilo sejam carregadas. No entanto, se isso for muito desafiador para você implementar, você pode instalar o Plugin Organizer que fornece a capacidade de carregar plugins seletivamente com base em determinados critérios, como um tipo de postagem ou nome de página. É uma boa ideia desabilitar qualquer plug-in de cache, como o W3Cache, que você possa ter ativado para evitar que você tenha que atualizar o cache constantemente para refletir as alterações feitas.

Erro comum nº 8: manter a barra de administração

Não posso deixar a barra de administração do WordPress visível para todos? Bem, sim, você pode permitir que seus usuários acessem as páginas de administração. No entanto, essas páginas muitas vezes não se integram visualmente com o tema escolhido e não fornecem uma integração perfeita. Se você deseja que seu site pareça profissional, desative a barra de administração e forneça uma página de gerenciamento de conta de front-end própria:

 add_action('after_setup_theme', 'remove_admin_bar'); function remove_admin_bar() { if (!current_user_can('administrator') && !is_admin()) { show_admin_bar(false); } }

O código acima, quando copiado para o arquivo functions.php do seu tema, exibirá apenas a barra de administração para administradores do site. Você pode adicionar qualquer uma das funções ou recursos de usuário do WordPress na função current_user_can($capability) para impedir que os usuários vejam a barra de administração.

Erro comum nº 9: não utilizar o filtro GetText

Posso usar CSS ou JavaScript para alterar o rótulo de um botão, o que há de errado com isso? Bem, sim, você pode. No entanto, você está adicionando código supérfluo e tempo extra para renderizar o botão, quando pode usar um dos filtros mais úteis do WordPress, chamado gettext . Em conjunto com o textdomain de um plugin , um identificador exclusivo que garante que o WordPress possa distinguir entre todas as traduções carregadas, podemos empregar o filtro gettext para modificar o texto antes que a página seja renderizada. Se você pesquisar o código-fonte da função load_plugin_textdomain($domain) , ela fornecerá o nome de domínio que precisamos para substituir o texto em questão. Qualquer plug-in respeitável garantirá que o textdomain de texto de um plug-in seja definido na inicialização do plug-in. Se for algum texto em um tema que você deseja alterar, procure a linha de código load_theme_textdomain($domain) . Usando o WooCommerce mais uma vez como exemplo, podemos alterar o texto que aparece para o título “Produtos Relacionados”. Insira o seguinte código no arquivo functions.php do seu tema:

 function translate_string( $translated_text, $untranslated_text, $domain ) { if ( $translated_text == 'Related Products') { $translated_text = __( 'Other Great Products', 'woocommerce' ); } return $translated_text; } add_filter( 'gettext', 'translate_string', 15, 3 );

Este hook de filtro é aplicado ao texto traduzido pelas funções de internacionalização __() e _e() , desde que o textdomain seja definido através das funções acima mencionadas.

 _e( 'Related Products', 'woocommerce' );

Pesquise seus plugins por essas funções de internacionalização para ver quais outras strings você pode personalizar.

Erro comum nº 10: manter os links permanentes padrão

Por padrão, o WordPress usa uma string de consulta com o ID da postagem para retornar o conteúdo especificado. No entanto, isso não é amigável e os usuários podem remover partes pertinentes do URL ao copiá-lo. Mais importante ainda, esses permalinks padrão não usam uma estrutura amigável ao mecanismo de pesquisa. Ativar o que chamamos de permalinks “bonitos” garantirá que nossos URLs contenham palavras-chave relevantes do título do post para melhorar o desempenho nas classificações dos mecanismos de pesquisa. Pode ser uma tarefa bastante assustadora ter que modificar retrospectivamente seus permalinks, especialmente se seu site estiver em execução por um período significativo de tempo e você tiver centenas de postagens já indexadas pelos mecanismos de pesquisa. Portanto, depois de instalar o WordPress, certifique-se de alterar imediatamente sua estrutura de permalinks para algo um pouco mais amigável aos mecanismos de pesquisa do que apenas um ID de postagem. Eu geralmente uso o nome do post para a maioria dos sites que crio, mas você pode personalizar o permalink para qualquer formato que desejar usando as tags de estrutura de permalink disponíveis.

Conclusão

Este artigo não é de forma alguma uma lista exaustiva de erros cometidos pelos desenvolvedores do WordPress. Se há uma coisa que você deve tirar deste artigo, é que você nunca deve usar atalhos (e isso é verdade em qualquer plataforma de desenvolvimento, não apenas no WordPress!). O tempo economizado agora por más práticas de programação voltará para assombrá-lo mais tarde. Sinta-se à vontade para compartilhar conosco alguns erros que você cometeu no passado e, mais importante, quaisquer lições aprendidas, deixando um comentário abaixo.