Os erros mais comuns no desenvolvimento de temas do WordPress (e como corrigi-los)

Publicados: 2019-05-14

Enviar um tema para o diretório de temas do WordPress.org é uma ótima maneira de compartilhar seu trabalho e contribuir com a comunidade do WordPress. Atualmente, existem mais de 7.000 temas no diretório, dos quais o mais popular ultrapassa 300.000 instalações ativas. (Não incluindo Twenty____ Temas que são empacotados com o WordPress e têm contagens de instalação na casa dos milhões.)

Antes de enviar seu tema para o diretório, é importante entender primeiro o processo de revisão, pois se o seu tema não atender a esses requisitos, ele poderá ser rejeitado na hora.

Temas com 3 ou mais questões distintas podem ser encerrados como não aprovados. No entanto, os autores do tema podem reenviar o tema depois de corrigirem os problemas.

https://make.wordpress.org/themes/handbook/review/required/

Os revisores estão do seu lado e querem que seu tema seja publicado, uma vez que atenda aos padrões exigidos. Se o seu tema tiver apenas pequenos problemas que o impeçam de ser incluído no diretório, seu revisor trabalhará com você para corrigi-los.

Infelizmente, se o seu tema tiver muitos problemas, ele será fechado como não aprovado. Se você decidir corrigir os problemas, poderá fazer o upload do tema novamente - mas ele se juntará ao final da fila.

Da minha experiência revisando mais de 100 temas, consegui identificar os problemas mais comuns que impedem a aprovação de temas. Ao compartilhar isso com você neste artigo, espero poder ajudá-lo a evitar ficar preso na fila ou ser rejeitado.

Carregando seu tema

Quando você carrega um tema, ele entra na fila para ser revisado. Em média, levará dois meses para o seu tema chegar à frente da fila e receber sua primeira revisão. Todos os revisores são voluntários com tempo limitado disponível para concluir as revisões. Uma variedade de fatores pode afetar o tempo de espera. Quando mais pessoas se voluntariam para revisar temas, a fila se move rapidamente. Por outro lado, quando temas com muitos problemas são enviados, a fila diminui.

Ao enviar um tema que atende a todos os requisitos, o processo de revisão fica muito mais fácil e, por fim, seu tema será publicado mais cedo. Neste guia, exploraremos os problemas mais comuns que manterão seu tema na fila e impedirão que ele seja aprovado.

Nota: Os autores de temas que têm um histórico de envio de temas sem problemas podem se inscrever para se tornarem 'Autores Confiáveis'.

Problemas de nomenclatura

Quando você carrega um tema, a primeira verificação que é realizada é para ver se o nome já está em uso. Frequentemente, você será informado de que o nome que escolheu já está em uso, mesmo que não consiga ver um tema com esse nome no diretório.

Como poderia ser? A razão é que o teste não está verificando apenas o diretório, está verificando todo o ecossistema WordPress. Se um tema foi lançado em qualquer lugar (Github, ThemeForest, etc.) e tem mais de 50 instalações ativas, esse nome não estará disponível para uso.

Nota: se você lançou seu tema em outro lugar e acumulou mais de 50 instalações, você ainda pode usar esse nome no diretório.

Saída sem escape

Os revisores de temas levam a segurança muito a sério, há até um recurso dedicado. Um artigo inteiro poderia ser escrito sobre como escrever temas seguros, mas nesta seção vamos explorar um aspecto: saída de escape.

A saída sem escape coloca os usuários do seu tema em risco. Aqui está um exemplo de um valor sem escape ($title):

 $title = get_option('my_custom_title');
echo '<h2>' . $título. '</h2>';

O problema com o acima é que, embora saibamos que tipo de valor $title deve ser, uma string, não verificamos se esse é o caso.

Se um hacker conseguiu alterar o valor de 'my_custom_title' no banco de dados, seu tema produzirá esse valor. Isso apresenta um grande risco, pois eles podem substituir a saída pretendida por Javascript embutido:

 alert('Isso é perigoso');

A solução é escapar de toda a saída para garantir que ela inclua apenas o tipo de dados que estamos esperando.

Nosso exemplo poderia ser corrigido assim:

 $title = get_option('my_custom_title');
echo '<h2>' . esc_html( $ titulo ) . '</h2>';

A desvantagem de usar esc_html é que ele remove todas as tags HTML. Se $title incluiu negrito ou itálico, por exemplo:

 $title = 'Este artigo é <strong>muito</strong> útil';
echo esc_html( $ titulo );

A palavra 'muito' não estaria em negrito no frontend; em vez disso, produziria o código <strong>muito</strong>.

Isso ilustra por que é importante usar as funções de escape corretas para o contexto. Se estivéssemos esperando algum HTML na saída, seria melhor usar wp_kses_post() ou wp_kses() e definir o parâmetro $allowed_html.

Funções que saem também precisam ser escapadas:

 <a href="<?php echo esc_url(get_permalink()); ?>">

A exceção são as funções principais do WordPress que incluem 'the_' em seu nome, geralmente já estão escapadas.

 function the_permalink( $ post = 0 ) {
    /**
     * Filtra a exibição do permalink para a postagem atual.
     *
     * @desde 1.5.0
     * @desde 4.4.0 Adicionado o parâmetro `$post`.
     *
     * @param string $permalink O permalink do post atual.
     * @param int|WP_Post $post Post ID, objeto WP_Post ou 0. Padrão 0.
     */
    echo esc_url( apply_filters( 'the_permalink', get_permalink( $ post ), $ post ) );
}

Texto intraduzível

Para serem aceitos no diretório, todos os temas devem estar 100% prontos para tradução. Isso significa que cada string de texto que suas saídas de tema devem ser traduzíveis.

O WordPress já possui os sistemas e funcionalidades para lidar com o processo de tradução, você só precisa garantir que suas strings usem as funções corretas.

Embora simples de implementar, isso é muitas vezes esquecido, pois vai contra o fluxo de como as pessoas escrevem HTML.

Normalmente, você pode fazer algo assim:

 <h1>404 - Não encontrado</h1>

Para torná-lo traduzível, você precisa adicionar algum PHP:

 // As funções __ são a base da localização.
<h1><?php echo __( '404', 'texto-domínio' ); ?>

// As funções _e ecoam o valor.
<h1><?php _e( '404', 'texto-domínio' ); ?>

// Escape e ecoe a string.
<h1><?php esc_html_e( '404', 'texto-domínio' ); ?>

// localização e variáveis.
<h1><?php _n( 'Um post', '%s posts', $count, 'text-domain' ); ?>

Strings de saída por funções também devem estar prontas para tradução:

 // não está pronto para tradução :-(
<?php next_posts_link( 'Entradas mais antigas' ); ?>

// pronto para tradução :-)
<?php next_posts_link( esc_html__( 'Entradas mais antigas', 'domínio-texto' ) ); ?>

Dica: Muitos exemplos de código no codex.wordpress.org não usam as funções de tradução, portanto, tenha cuidado ao copiá-los e colá-los.

Enfileirando recursos incorretamente

Os arquivos .css e .js que seu tema usa devem ser enfileirados usando as funções corretas: wp_enqueue_style() para CSS e wp_enqueue_script() para Javascript.

Um erro comum é codificar scripts e estilos diretamente no <head> ou antes de </body>. Existem dois problemas nessa abordagem:

1. Impossível remover

Se um plug-in precisar remover um recurso que você carregou, isso não será possível. Se você tivesse usado as funções de enfileiramento adequadas, poderia ser feito assim:

 /**
 * Dequeue o tema javascript.
 *
 * Ligado à ação wp_enqueue_scripts, com prioridade tardia (100),
 * para que seja depois que o script foi enfileirado.
 */
function wptavern_dequeue_script() {
   wp_dequeue_script( 'scripts de tema' );
}
add_action( 'wp_enqueue_scripts', 'wptavern_dequeue_script', 100 );

2. Carregamento Duplicado

Se você enfileirar um recurso, jQuery por exemplo, e um plugin também enfileirar, o WordPress é inteligente o suficiente para carregá-lo apenas uma vez.

 /**
 * Enfileirar jQuery
 *
 * jQuery será carregado apenas uma vez, apesar dos dois enfileiramentos.
 * jQuery é empacotado com WordPress, então não precisamos especificar um src. 
 */
function wptavern_enqueue_script() {
   wp_enqueue_script('jquery');
   wp_enqueue_script('jquery');
}
add_action( 'wp_enqueue_scripts', 'wptavern_enqueue_script' );

Se, em vez disso, você tivesse codificado o jQuery em seu <head>, não haveria como o WordPress saber, e ele seria carregado duas vezes.

Funcionalidade de território de plug-in

O escopo de um tema deve lidar apenas com o design e a estética de um site, todas as outras funcionalidades devem ser tratadas pelo próprio WordPress ou plugins.

Na tentativa de agregar mais valor aos seus temas, os autores de temas geralmente tentam incorporar funcionalidades extras, por exemplo, controles de SEO ou tipos de postagem personalizados.

O problema de agrupar funcionalidades em um tema é que os dados não são portáveis. Tome os controles de SEO como exemplo, se o usuário alterar o tema, ele perderá todo o trabalho que fez para otimizar suas páginas. Em contraste, usando um plugin de SEO, os dados e a funcionalidade são independentes do tema e serão retidos ao alterar o tema.

Alguns exemplos de funcionalidade de território de plug-in:

  • Análise/Acompanhamento
  • Controles de SEO
  • Formulários de contato
  • Códigos de acesso
  • Blocos de Gutenberg

Dica: Se o seu código gravar no banco de dados, é muito provável que seja território de plug-in. A exceção seriam as configurações relacionadas ao design (posição da barra lateral, cores, etc.).

Sem prefixo

Prefixar é uma maneira de garantir que seu código não entre em conflito com o código de plugins. O namespace no PHP é a melhor maneira de obter o mesmo efeito. No entanto, alguns usuários ainda estão usando versões antigas do PHP (5.2) que não suportam esse recurso.

Justin Tadlock compartilhou uma lista de coisas comuns que devem ser prefixadas:

  • Nomes de funções PHP.
  • Nomes de classes PHP.
  • Variáveis ​​globais do PHP.
  • Ganchos de ação/filtro.
  • Manipuladores de script.
  • Punhos de estilo.
  • Nomes de tamanho de imagem.

Fonte: https://themereview.co/prefix-all-the-things/

 // exemplo de função.
meu_prefix_example();

//exemplo de classe.
class Meu_Prefixo_Exemplo { … }

// exemplo de ação e filtro.
do_action( 'my_prefix_action' );
apply_filters( 'meu_prefixo_filtro', $valores);

// exemplos de enfileiramento.
wp_enqueue_script( 'my_prefix_script', get_template_directory_uri() . '/js/custom-script.js' );
wp_enqueue_style( 'my_prefix_style', get_template_directory_uri() . '/css/styles.css' );

// exemplo de tamanho de imagem.
add_image_size( 'my_prefix_image_size', 220, 180 ); // 220 pixels de largura por 180 pixels de altura.

Exceção: ao enfileirar recursos de terceiros, não adicione um prefixo:

 // enfileirando um script de terceiros (chosen.js).
 wp_enqueue_script( 'escolhido', get_template_directory_uri() . '/js/chosen.js' );

Problemas de licenciamento

Seu tema e todos os seus arquivos devem ser 100% compatíveis com GPL. Isso inclui imagens, bibliotecas, scripts e fontes.

Todos os recursos de terceiros devem listar suas informações de origem e licença.

Esse requisito pode ser particularmente complicado, pois nem todas as licenças são compatíveis com GPL. A licença Unsplash tem apenas uma restrição:

“Esta licença não inclui o direito de compilar fotos do Unsplash para replicar um serviço semelhante ou concorrente.”

Essa única restrição, no entanto, é suficiente para torná-lo não compatível com GPL e, como tal, você não verá imagens do Unsplash incluídas nos temas do wordpress.org.

Uma lista de licenças compatíveis com GPL está disponível aqui – https://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses

Recentemente, stocksnap.io tem sido a fonte mais comum de imagens no diretório, pois todas as imagens listadas são licenciadas como CC0 (compatível com GPL).

Erros de captura de tela

Os requisitos afirmam que sua captura de tela deve ser uma representação não editada do seu tema que não se pareça com um anúncio. Isso significa que não há trabalho de photoshop, sobreposições, bordas ou efeitos extravagantes.

As imagens também devem seguir os mesmos requisitos de licenciamento que exploramos acima.

tema na foto: Blocksy

Bônus: use um padrão de codificação

Um código que parece fácil de ler e entender para você pode ser o oposto completo para um revisor que tem apenas 10 a 15 minutos para verificar seu código.

Embora não haja exigência de padrões de codificação, seguir um torna seu código mais fácil de ler, entender e manter. Eu pessoalmente uso e recomendo os 'Padrões de codificação WordPress', embora existam outros.

Usar PHP_CodeSniffer e o conjunto de regras do WordPress em seu editor de código pode facilitar muito a adesão a um padrão – https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards

Conclusão

Os Requisitos do Tema são criados com o usuário final em mente. Evite cometer os erros comuns que listei acima e seu tema será aprovado rapidamente. Se você quiser experimentar o processo de revisão do outro lado, pode até se tornar um revisor.