Lições aprendidas ao desenvolver plugins WordPress

Todo desenvolvedor de plugins do WordPress luta com problemas difíceis e códigos difíceis de manter. Passamos tarde da noite apoiando nossos usuários e arrancamos nossos cabelos quando uma atualização quebra nosso plugin. Deixe-me mostrar-lhe como torná-lo mais fácil.

Neste artigo, compartilharei meus cinco anos de experiência no desenvolvimento de plugins do WordPress. O primeiro plugin que escrevi foi um plugin de marketing simples. Ele exibia um botão de chamada para ação (CTA) com a frase de pesquisa do Google. Desde então, escrevi outros 11 plugins gratuitos e mantenho quase todos eles. Eu escrevi cerca de 40 plugins para meus clientes, desde muito pequenos até um que foi mantido por mais de um ano.

Bom desenvolvimento e suporte levam a mais downloads. Mais downloads significam mais dinheiro e uma melhor reputação. Este artigo mostrará as lições que aprendi e os erros que cometi, para que você possa melhorar seu desenvolvimento de plugins.

1. Resolva um problema

Se o seu plugin não resolver um problema, ele não será baixado. É simples assim.

Pegue o plugin Advanced Cron Manager (mais de 8.000 instalações ativas). Ele ajuda os usuários do WordPress que estão tendo dificuldade em depurar seu cron. O plugin foi escrito por uma necessidade - eu precisava de algo para me ajudar. Eu não precisava comercializar este, porque as pessoas já precisavam dele. Ele arranhou sua coceira.

Por outro lado, há o plugin Bug — voar na tela (mais de 70 instalações ativas). Ele simula aleatoriamente uma mosca na tela. Ele realmente não resolve um problema, então não vai ter um grande público. Foi um plugin divertido para desenvolver, no entanto.

Concentre-se em um problema. Quando as pessoas não veem seu SEO funcionando bem, elas instalam um plugin de SEO. Quando as pessoas querem acelerar seu site, elas instalam um plugin de cache. Quando as pessoas não conseguem encontrar uma solução para seus problemas, elas encontram um desenvolvedor que escreve uma solução para elas.

Como David Hehenberger atesta em seu artigo sobre como escrever um plugin de sucesso, a necessidade é um fator chave na decisão do usuário do WordPress de instalar um plugin específico.

Se você tiver a oportunidade de resolver o problema de alguém, arrisque-se.

2. Apoie seu produto

“3 em cada 5 americanos tentariam uma nova marca ou empresa para uma melhor experiência de serviço. 7 em cada 10 disseram que estavam dispostos a gastar mais com empresas que acreditam fornecer um serviço excelente.”

— Nykki Yeager

Não negligencie seu apoio. Não trate como uma obrigação, mas mais como uma oportunidade.

O suporte de boa qualidade é fundamental para que seu plugin cresça. Mesmo um plugin com o melhor código receberá alguns tíquetes de suporte. Quanto mais pessoas usarem seu plugin, mais tickets você receberá. Uma melhor experiência do usuário resultará em menos tíquetes, mas você nunca chegará à caixa de entrada 0.

Sempre que alguém publica uma mensagem em um fórum de suporte, recebo uma notificação por e-mail imediatamente e respondo assim que possível. Vale a pena. A grande maioria das minhas boas críticas foram obtidas por causa do suporte. Este é um efeito colateral: um bom suporte geralmente se traduz em avaliações de 5 estrelas.

Quando você fornece um excelente suporte, as pessoas começam a confiar em você e em seu produto. E um plugin é um produto, mesmo que seja totalmente gratuito e de código aberto.

Um bom suporte é mais complexo do que escrever uma resposta curta uma vez por dia. Quando seu plugin ganhar força, você receberá vários tickets por dia. É muito mais fácil gerenciar se você for proativo e responder às perguntas dos clientes antes mesmo de eles perguntarem.

Aqui está uma lista de algumas ações que você pode tomar:

• Crie uma seção de perguntas frequentes em seu repositório.
• Fixe o tópico “Antes de perguntar” na parte superior do seu fórum de suporte, destacando as dicas de solução de problemas e as perguntas frequentes.
• Certifique-se de que seu plug-in seja simples de usar e que os usuários saibam o que devem fazer depois de instalá-lo. UX é importante.
• Analise as perguntas de suporte e corrija os pontos problemáticos. Crie um fórum onde as pessoas possam votar nos recursos que desejam.
• Crie um vídeo mostrando como o plug-in funciona e adicione-o à página principal do seu plug-in no repositório do WordPress.org.

Realmente não importa qual software você usa para dar suporte ao seu produto. O fórum de suporte oficial do WordPress.org funciona tão bem quanto o e-mail ou seu próprio sistema de suporte. Eu uso o fórum do WordPress.org para os plugins gratuitos e meu próprio sistema para os plugins premium.

3. Não use o Composer

Composer é um software gerenciador de pacotes. Um repositório de pacotes está hospedado em packagist.org e você pode baixá-los facilmente para o seu projeto. É como NPM ou Bower para PHP. Gerenciar seus pacotes de terceiros da maneira que o Composer faz é uma boa prática, mas não o use em seu projeto WordPress.

Eu sei, eu joguei uma bomba. Deixe-me explicar.

Composer é um ótimo software. Eu mesmo uso, mas não em projetos públicos do WordPress. O problema está nos conflitos. O WordPress não possui nenhum gerenciador de pacotes global, então cada plugin precisa carregar dependências próprias. Quando dois plugins carregam a mesma dependência, isso causa um erro fatal.

Não existe realmente uma solução ideal para esse problema, mas o Composer o torna ainda pior. Você pode agrupar a dependência em sua fonte manualmente e sempre verificar se é seguro carregá-la.

O problema do Composer com os plugins do WordPress ainda não foi resolvido e não haverá nenhuma solução viável para esse problema em um futuro próximo. O problema foi levantado há muitos anos e, como você pode ler no artigo do WP Tavern, muitos desenvolvedores estão tentando resolvê-lo, sem sorte.

O melhor que você pode fazer é garantir que as condições e o ambiente sejam bons para executar seu código.

4. Suporte Razoável para Versões Antigas do PHP

Não suporta versões muito antigas do PHP, como 5.2. Os problemas de segurança e manutenção não valem a pena, e você não ganhará mais instalações dessas versões mais antigas.

Vá com PHP 5.6 como um requisito mínimo, mesmo que o suporte oficial seja descartado até o final de 2018. O próprio WordPress requer PHP 7.2.

Há um movimento que desencoraja o suporte de versões legadas do PHP. A equipe do Yoast lançou a biblioteca Whip, que você pode incluir no seu plugin e que exibe aos usuários informações importantes sobre a versão do PHP e por que eles devem atualizar.

Diga aos seus usuários quais versões você suporta e certifique-se de que o site deles não seja interrompido depois que o plug-in for instalado em uma versão muito baixa.

5. Foco no Código de Qualidade

Escrever um bom código é difícil no começo. Leva tempo para aprender os princípios e padrões de design “SOLID” e mudar os velhos hábitos de codificação.

Certa vez, levei três dias para exibir uma string simples no WordPress, quando decidi reescrever um dos meus plugins usando melhores práticas de codificação. Foi frustrante saber que deveria ter levado 30 minutos. Mudar minha mentalidade foi doloroso, mas valeu a pena.

Por que foi tão difícil? Porque você começa a escrever um código que parece à primeira vista um exagero e não muito intuitivo. Fiquei me perguntando: “Isso é realmente necessário?” Por exemplo, você precisa separar a lógica em diferentes classes e garantir que cada uma seja responsável por uma única coisa. Você também tem que separar classes para a tradução, registro de tipo de postagem personalizado, gerenciamento de ativos, manipuladores de formulários, etc. Então, você compõe as estruturas maiores a partir de pequenos objetos simples. Isso é chamado de injeção de dependência. Isso é muito diferente de ter classes “front end” e “admin”, onde você enfia todo o seu código.

A outra prática contraintuitiva era manter todas as ações e filtros fora do método construtor. Dessa forma, você não está invocando nenhuma ação ao criar os objetos, o que é muito útil para testes de unidade. Você também tem melhor controle sobre quais métodos são executados e quando. Eu gostaria de saber isso antes de escrever um projeto com um loop infinito causado pelas ações nos métodos do construtor. Esses tipos de bugs são difíceis de rastrear e difíceis de corrigir. O projeto teve que ser reformulado.

Os exemplos acima são apenas alguns exemplos, mas você deve conhecer os princípios SOLID. Estes são válidos para qualquer sistema e qualquer linguagem de codificação.

Quando você segue todas as práticas recomendadas, chega ao ponto em que todos os novos recursos se encaixam. Você não precisa ajustar nada ou fazer exceções ao código existente. É incrível. Em vez de ficar mais complexo, seu código fica mais avançado, sem perder a flexibilidade.

Além disso, formate seu código corretamente e certifique-se de que todos os membros de sua equipe sigam um padrão. Os padrões tornarão seu código previsível e mais fácil de ler e testar. O WordPress tem seus próprios padrões, que você pode implementar em seus projetos.

6. Teste seu plug-in com antecedência

Aprendi essa lição da forma difícil. A falta de testes me levou a lançar uma nova versão de um plugin com um erro fatal. Duas vezes. Nas duas vezes, obtive uma classificação de 1 estrela, que não pude transformar em uma crítica positiva.

Você pode testar manualmente ou automaticamente. O Travis CI é um produto de teste contínuo que se integra ao GitHub. Eu construí um conjunto de testes muito simples para o meu plugin de notificação que apenas verifica se o plugin pode inicializar corretamente em todas as versões do PHP. Dessa forma, posso ter certeza de que o plug-in está livre de erros e não preciso prestar muita atenção para testá-lo em todos os ambientes.

Cada teste automatizado leva uma fração de segundo. 100 testes automatizados levarão cerca de 10 minutos para serem concluídos, enquanto os testes manuais precisam de cerca de 2 minutos para cada caso.

Quanto mais tempo você investir em testar seu plugin antecipadamente, mais você economizará a longo prazo.

Para começar com o teste automatizado, você pode usar o comando WP-CLI \\`wp scaffold plugin-test\\`, que instala toda a configuração necessária.

7. Documente seu trabalho

É um clichê que os desenvolvedores não gostam de escrever documentação. É a parte mais chata do processo de desenvolvimento, mas um pouco vai longe.

Escreva código autodocumentado. Preste atenção aos nomes de variáveis, funções e classes. Não faça estruturas complicadas, como cascatas que não podem ser lidas facilmente.

Outra forma de documentar o código é usar o “doc block”, que é um comentário para cada arquivo, função e classe. Se você escrever como a função funciona e o que ela faz, será muito mais fácil entender quando você precisar depurá-la daqui a seis meses. Os Padrões de Codificação do WordPress cobrem essa parte, forçando você a escrever os blocos doc.

Usar as duas técnicas economizará o tempo de escrever a documentação, mas a documentação do código não será lida por todos.

Para o usuário final, você deve escrever artigos de alta qualidade, curtos e de fácil leitura, explicando como o sistema funciona e como usá-lo. Os vídeos são ainda melhores; muitas pessoas preferem assistir a um breve tutorial do que ler um artigo. Eles não vão olhar para o código, então facilite a vida deles. Uma boa documentação também reduz os tickets de suporte.

Conclusão

Essas sete regras me ajudaram a desenvolver produtos de boa qualidade, que estão começando a ser o core business da BracketSpace. Espero que eles também o ajudem em sua jornada com os plugins do WordPress.

Deixe-me saber nos comentários qual é a sua regra de ouro de desenvolvimento ou se você achou alguma das opções acima particularmente útil.